News
According to RFC 2026, to become a proposed standard, a specification “is generally stable, has resolved known design choices, is believed to be well- understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable.” However, more experience with the specification might prove otherwise the specification might not be valuable, or have support, be well-understood, or even stable in which case the specification could lose its status as a proposed standard. No operational experience or even an implementation is necessary for a specification to achieve the proposed standard level, though both of those are helpful to a specification’s cause. If the specification is likely to have a significant impact on the Internet as it exists now, the IESG will very likely require that the specification be implemented and deployed.
Proposed standards are to be considered immature, but RFC 2026 encourages implementers to use the specification to build up a body of experience that can be drawn upon to judge the protocol’s value. A specification must spend at least six months as a draft standard before it can advance along the standards track. Draft Standard “A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the ‘Draft Standard’ level.” That’s how RFC 2026 puts it. Interoperable means that the implementations are “functionally equivalent or interchangeable.” To qualify, the implementations have to implement the entire specification. If some functions or options are left out, the implementation doesn’t count, unless the things that were left out of the implementations are also taken out of the specification.
Where a proposed standard should be generally stable, draft standard specifications “must be well-understood and known to be quite stable.” It is up to the working group chair to document the specification’s implementations, as well as to document interoperability test results and function/option support test results as a part of the chair’s recommendation for moving the proposed standard to draft standard status. Once a specification achieves draft standard status, it stays there for at least four months. This period must include an IETF meeting, so this period may be extended if the next IETF meeting occurs more than four months from the date the specification achieves draft standard. Once a specification attains the draft standard maturity level, it is considered a final specification, one that implementers are encouraged to deploy in production systems. Although the draft standard specification may be subject to changes before attaining full standard status, those changes are most likely to be limited to fixes for specific problems arising from continued experience with the specification.