tocol is defined in RFC 791, but because the status of this proto- col specification is Internet standard, it also appears in the STD subseries: STD0005. A specification cannot reach the Internet standard level without being a draft standard for at least 4 months, and at least one IETF meeting has to be held before a draft RFC can become an Internet standard. Non-standards Track and BCP RFCs As suggested earlier, some IETF specifications do not define any standard at all. These specifications follow the non-standards track. Experimental RFCs show results and conclusions from research and development work. They record the experiences of imple- menters and designers working on some area of the technology. Informational RFCs are used to spread general information to the com- munity. Neither experimental nor informational RFCs are reviewed as carefully as standards track documents because they do not incorporate a proposal. All RFCs become historic when they are obsoleted by a new RFC, or when they are no longer applicable. BCP RFCs standardize practices and give guidelines for policies and operations. BCP RFCs do not have maturity levels; their process is similar to the one for proposed standards. BCP RFCs are stored in the BCP sub- series, but retain their RFC number. For instance, RFC 2026 "The Internet Standards Process" is also BCP0009. Chapter 2 Internet Drafts (I-Ds) Internet drafts (as opposed to RFCs) are draft documents used inside the working groups to provoke and gather feedback. They are issued before a more definitive version of the specification reaches RFC status. An Internet draft is valid for at least 6 months or until a newer version of the draft appears. Internet drafts do not define standard docu- ments, and the IETF discourages referencing them in any way but as work in progress. Note that this books references some Internet drafts. The reader should be aware of the limited and unofficial status of an Internet draft. Internet drafts are also employed in the standards track. When a pro- posed sta