| Next: Open Standards, Open Documents, Up: The Internet Engineering Task Previous: IETF Documents |
The IETF motto is ``rough consensus and running code.'' Working group unanimity is not required for a proposal to be adopted, but a proposal that cannot demonstrate that most of the working group members think that it is the right thing to do will not be approved. There is no fixed percentage support that a proposal must achieve, but most proposals that have more than 90% support can be approved and those with less than 80% can often be rejected. IETF working groups do not actually vote, but can resort to a show of hands to see if the consensus is clear.
Non standards track documents can originate in IETF working group activity or from individuals who would like to make their thoughts or technical proposals available to the Internet community. Almost all proposals for RFC publication are reviewed by the IESG, after which the IESG will provide advice to the RFC Editor on the advisability of publishing the document. The RFC Editor then decides whether to publish the document and, if the IESG offers one, weather to include a note from the IESG in the document. IESG notes in this case are used to indicate discomfort with the proposal if the IESG feels that some sort of warning label would be helpful.
In the normal case of a standards track document an IETF working group will produce an Internet-Draft to be published as the RFC. The final step in the working group evaluation of the proposal is a ``last call,'' normally two weeks long, where the working group chair asks the working group mailing list if there are any outstanding issues with the proposal. If the result of the working group last call indicates that the consensus of the group is that the proposal should be accepted, the proposal is then forwarded to the IESG for their evaluation. The first step in the IESG evaluation is an IETF-wide last call sent to the main IETF announcement mailing list. This is so that people who have not been following the working group work can comment on the proposal. The normal IETF last call is two weeks for proposals that come from IETF working groups and four weeks for proposals not originating from IETF working groups.
The IESG uses the results of the IETF last-call as input to its deliberations about the proposal. The IESG can approve the document and request its publication, or it can send the proposal back to the author(s) for revision based on the IESG's evaluation of the proposal. This same process is used for each stage of the standards track.
Proposals normally enter the standards track as Proposed Standards, but occasionally if there is uncertainty about the technology or if additional testing is felt to be useful a document is initially published as an Experimental RFC. Proposed Standards are meant to be good ideas with no known technical flaws. After a minimum of six months as a Proposed Standard, a proposal can be considered for Draft Standard status. Draft Standards must have demonstrated that the documentation is clear and that any intellectual property rights issues with the proposal are understood and resolvable. This is done by requiring that there be at least two genetically independent, interoperable implementations of the proposal with separate exercises of licensing procedures if there are any. Note that it also requires that all of the separate features of the protocol be multiply-implemented. Any feature not meeting these requirements must be removed before the proposal can advance. Thus IETF standards can get simpler as they progress. This is the ``running code'' part of the IETF motto.
The final step in the IETF standards process is Internet Standard. After being at Draft Standard status for at least four months and demonstrating significant marketplace success, a proposal can be considered for Internet Standard status.
Two major differences stand out if one compares the IETF standards track with the process in other standards organizations. First, the final result of most standards bodies is approximately equivalent to the IETF Proposed Standard status. A good idea but with no requirement for actual running code. The second is that rough consensus instead of unanimity can produce proposals with fewer features added to quiet a noisy individual.
In brief, the IETF operates in a bottom-up task creation mode and believes in ``fly before you buy.''