l, proposed standards must be reviewed carefully by the community of interest. Although some implementation experience is highly desirable, it is not formally necessary for a specification to reach proposed standard status. This is not so for draft standards. In order to achieve the next maturity level, an RFC must point to at least two interoperable implementations in the real world. These implementations must contain all of the features that the specification describes SO that unproductive features can be removed from the spec. A time requirement is also in place to ensure adequate dis- cussion and review. Before becoming a draft standard, an RFC must stay at the proposed standard level for at least 6 months. Figure 2-15 Types of RFCs. Standards track Non-standards track Proposed Draft Standard Experimental Informational Historic Standard Standard Packet Switching, IP, and the IETF A specification on the standards track must eventually meet two main requirements: rough consensus and running code. These two requirements are key aspects of the IETF process. The last maturity level on the standards track is the Internet standard (STD) level. specification becomes a standard only when wide implemen- tation and operational experience appears within the community. Internet standards are stored in the STD subseries where new standards are assigned an STD number. Every IETF specification has an associated RFC number, and when a certain specification enters the next maturity level on its track, it is imme- diately assigned a new RFC number. For example, the proposed standard "An Extension to HTTP: Digest Access Authentication" was originally RFC 2069. When it reached the draft standard level, it became RFC 2617 "HTTP Authentication: Basic and Digest Access Authentication." The RFC archives document and preserve the full development cycle of each protocol in this way. When a specification reaches the Internet standard level and is included in the STD subseries, it keeps an RFC number nonetheless. For instance, the IP pro