The figure shows the RFC process used by ISOC, IAB, and the IETF for the standardization of protocols and procedures. It is defined in RFC 2026, The Internet Standards Process - Revision 3. This process is used to create a standard track document. Not all RFCs are standard track documents and not all standard track documents become Internet standards. There are three steps for a proposal to become an Internet standard:
Step 1. Internet-Draft (I-D) - The first step for the proposal is to be published as an Internet-Draft (I-D). I-Ds have no formal status and are subject to change or removal at any time. Any paper, report, RFC, or vendor claiming any sort of compliance should never reference I-Ds. I-Ds are subject to review by any member of the public.
Step 2. Proposed Standard - After the I-D has been received significant community review and is considered useful, stable, and well understood with community support, the I-D becomes a proposed standard. Proposed standards should be technically complete, but are considered immature specifications until properly tested and validated. Proposed standards receive an RFC number, but are not yet considered an Internet standard. At least two independent implementations are required to demonstrate and verify its functionality. At this point the IETF community considers the proposed standard as mature and useful. (There is another step known as the draft standard. In October 2011, the IETF merged the requirements of the draft standard with the proposed standard.)
Step 3. Internet Standard - The draft standard only becomes an Internet standard after significant implementation and successful operational experience has been obtained. At this point, the Internet standard or simply “standard” receives an standard (STD) series number.
The RFC development and approval process can take months, or even years depending upon the complexity of the technology. After an RFC is published as an Internet standard and assigned a number, it cannot be changed. Any change to a published RFC can only be performed through issuing a new RFC that updates or obsoletes the existing RFC. This process allows observing how individual protocols and services evolve over time. This is in contrast to documents issued by different standardization bodies like the IEEE or ITU-T that publish newer versions of their standards reusing their original names and numbers.