Standard

 

As RFC 2026 makes clear, Internet standards actions must all be approved by the IESG, and standards actions include anything that modifies the state of the specification as it relates to the standards process. Anything that changes the state of a specification is a standards action. Actions occur when a specification enters the standards track, when it changes its maturity level within the standards track, or when it is removed from the standards track. None of those things can happen unless the IESG approves it. The IESG follows guidelines devised to identify specifications that are ripe for a standard action, but the documented criteria are not hard-and-fast rules but rather guidelines. These guidelines will be discussed later. The IESG, as a group, uses its own judgment when deciding on standards actions. It has the power to deny an action to a specification that otherwise might appear to fulfill all requirements or to approve an action for a specification that might appear to fall short in one or more areas. If any parties believe that a standard action was granted or denied in error, they can resort to the dispute resolution procedures discussed later in this section. The first step in the standards process is the entity sponsoring the specification publishing it as an Internet-Draft (I-D). Normally, this entity is the IETF working group, but it may also be an individual or some other organization. I-Ds produced by individuals or groups not directly connected to an IETF working group can be published as standards-track RFCs and are frequently published as informational RFCs as well. I-Ds are subject to modification based on community review, are transient documents, and are not intended to be referenced in the same way that RFCs are. I-Ds expire if they have not been modified for six months, though the timer starts again when a new version is published. An I-D published on January 1, 2001 would expire after June 30, 2001 if it was not revised; if a revision is published on June 1, 2001, then it is due to expire after November 30, 2001. If a revision is published January 15, 2001, then that I-D expires after July 15, 2001. However, the whole point of publishing an I-D is to have it accepted to the Standards Track rather than to have it persist as an I-D. This is the first standards action that must occur in the standards process for any specification. No action can occur until the I-D has been available online for at least two weeks. This time is to be used for community review, allowing members of the IETF and the rest of the world to read the draft and make comments on it. Although the IESG can’t take any action until at least two weeks after the I-D is published, nothing happens unless the IETF working group makes a recommendation to its area director. It can take quite some time and several revisions before the working group makes that recommendation. Normally, one or several members of a working group write a preliminary draft of the specification and publish it as an I-D. That draft stimulates discussion within the working group, which may result in modifications to the draft. A second I-D is published, stimulating further discussion, which in turn results in further modifications. For successful specifications, this process continues until the group is able to agree that the current version of the draft is ready to be published as an RFC Not all I-Ds become RFCs, however. Some may languish due to lack of inter- est. Others may be dropped when some other specification appears to solve the problem better. Some never achieve a stable form. When the IESG receives a recommendation for a standards action, it may consult with experts to review the recommendation. When the IESG is reviewing a document, it issues a last call notification to the IETF through the IETF- announce mailing list. Anyone may subscribe to this mailing list, and anyone may submit comments on the specification being reviewed. Once the specification is received from the working group, the last call period must be at least two weeks, but the IESG has the option of extending the last call period if it deems it necessary. Although the IETF working group’s recommendation carries weight with the IESG, it is far from binding. The IESG can even decide to consider a standards action different from that requested by the working group. Once the last call period is over, the IESG makes its decision and announces it through the IETF announce mailing list. If approved, the IESG then notifies the RFC Editor that the I-D should be withdrawn and republished as an RFC. The Standards Track Each time a specification is promoted to one of the three maturity levels of the Internet standards track—proposed standard, draft standard, and standard it must go through the IESG approval process noted previously. This section examines the stated criteria for promotion to each level as described in RFC 2026. Specifications must remain at the proposed and draft standard maturity levels for minimum periods of time, but these minimums are precisely that: absolute minimums. Advancement along the standards track can be quite slow. Rather than quickly advance a specification, the IESG and IETF working groups prefer that the standard is correct rather than risk enshrining a flawed standard. It is not uncommon for a proposed or draft standard to fail to advance on the standards track but to remain important for the Internet. For example, the Boot Protocol (BOOTP), documented in RFC 951 in 1985, is still a draft standard in 1999. Likewise, the IP Security Architecture, documented in RFC 2401 in November 1998, is still a proposed standard even though it replaces an earlier standards-track version documented by RFC 1825, published in 1995. When a specification stalls at some point in the standards track for two years, the IESG reviews the specification every year. The IESG may subsequently decide to terminate the effort or else decide that development of the specification should continue. At the same time, the IESG may determine that the specification itself is no longer relevant and should be reclassified as a historical RFC rather than a standard-track specification. As specifications advance, they are usually modified. These modifications usually require the publication of new RFCs to document the new versions of the specification. Though it may not be necessary to republish a specification when it changes maturity level (that is, the specification is unchanged), in most cases when a specification advances, a new RFC is published to reflect changes. If the modifications made during the revision process are sufficiently extensive, the IESG can decide the specification should go back and restart the process.