Created
April 11, 2014 06:48
-
-
Save anonymous/10444897 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4.1.1 Proposed Standard | |
The entry-level maturity for the standards track is "Proposed | |
Standard". A specific action by the IESG is required to move a | |
specification onto the standards track at the "Proposed Standard" | |
level. | |
A Proposed Standard 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, further experience | |
might result in a change or even retraction of the specification | |
before it advances. | |
Usually, neither implementation nor operational experience is | |
required for the designation of a specification as a Proposed | |
Standard. However, such experience is highly desirable, and will | |
usually represent a strong argument in favor of a Proposed Standard | |
designation. | |
The IESG may require implementation and/or operational experience | |
prior to granting Proposed Standard status to a specification that | |
materially affects the core Internet protocols or that specifies | |
behavior that may have significant operational impact on the | |
Internet. | |
A Proposed Standard should have no known technical omissions with | |
respect to the requirements placed upon it. However, the IESG may | |
waive this requirement in order to allow a specification to advance | |
to the Proposed Standard state when it is considered to be useful and | |
necessary (and timely) even with known technical omissions. | |
Implementors should treat Proposed Standards as immature | |
specifications. It is desirable to implement them in order to gain | |
experience and to validate, test, and clarify the specification. | |
However, since the content of Proposed Standards may be changed if | |
problems are found or better solutions are identified, deploying | |
implementations of such standards into a disruption-sensitive | |
environment is not recommended. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment