Reducing the Standards Track to Two Maturity Levels
The IETF standards track goes from three maturity levels to two, and annual review is dropped.
Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, DOI 10.17487/RFC6410, October 2011, <https://www.rfc-editor.org/info/rfc6410>.
@misc{rfc6410,
series = {Request for Comments},
number = 6410,
howpublished = {RFC 6410},
publisher = {RFC Editor},
doi = {10.17487/RFC6410},
url = {https://www.rfc-editor.org/info/rfc6410},
author = {R. Housley and D. Crocker and E. Burger},
title = {{Reducing the Standards Track to Two Maturity Levels}},
pagetotal = 6,
year = 2011,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6410 Vigil Security
BCP: 9 D. Crocker
Updates: 2026 Brandenburg InternetWorking
Category: Best Current Practice E. Burger
ISSN: 2070-1721 Georgetown University
October 2011
Reducing the Standards Track to Two Maturity Levels
Abstract
This document updates the Internet Engineering Task Force (IETF)
Standards Process defined in RFC 2026. Primarily, it reduces the
Standards Process from three Standards Track maturity levels to two.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6410.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
This document changes the Internet Standards Process defined in RFC
2026 [1]. In recent years, the Internet Engineering Task Force
(IETF) witnessed difficulty advancing documents through the maturity
levels: Proposed Standard, Draft Standard, and finally Standard.
These changes are designed to simplify the Standards Process and
reduce impediments to standards progression while preserving the most
important benefits of the IETF engineering approach. In addition,
the requirement for annual review of Standards Track documents that
have not reached the top of the maturity ladder is removed from the
Internet Standards Process.
Over the years, there have been many proposals for refining the
Internet Standards Process to reduce impediments to standards
progression. During May 2010, the Internet Engineering Steering
Group (IESG) discussed many of these proposals. Then, a plenary
discussion at IETF 78 in July 2010 demonstrated significant support
for transition from a three-tier maturity ladder to one with two
tiers.
In the Internet Standards Process, experience with a Proposed
Standard is expected to motivate revisions that clarify, modify,
enhance, or remove features. However, in recent years, the vast
majority of Standards Track documents are published as Proposed
Standards and never advance to a higher maturity level. Very few
specifications have advanced on the maturity ladder in the last
decade. Changing the Internet Standards Process from three maturity
levels to two is intended to create an environment where lessons from
implementation and deployment experience are used to improve
specifications.
The primary aspect of this change is to revise the requirements for
advancement beyond Proposed Standard. RFC 2026 [1] requires a report
that documents interoperability between at least two implementations
from different code bases as an interim step ("Draft Standard")
before a specification can be advanced further to the third and final
maturity level ("Standard") based on widespread deployment and use.
In contrast, this document requires measuring interoperability
through widespread deployment of multiple implementations from
different code bases, thus condensing the two separate metrics into
one.
The result of this change is expected to be maturity-level
advancement based on achieving widespread deployment of quality
specifications. Additionally, the change will result in the
incorporation of lessons from implementation and deployment
experience, and recognition that protocols are improved by removing
complexity associated with unused features.
In RFC 2026 [1], widespread deployment is essentially the metric used
for advancement from Draft Standard to Standard. The use of this
same metric for advancement beyond Proposed Standard means that there
is no longer a useful distinction between the top two tiers of the
maturity ladder. Thus, the maturity ladder is reduced to two tiers.
In addition, RFC 2026 [1] requires annual review of specifications
that have not achieved the top maturity level. This review is no
longer required.
2. Two Maturity Levels
This document replaces the three-tier maturity ladder defined in RFC
2026 [1] with a two-tier maturity ladder. Specifications become
Internet Standards through a set of two maturity levels known as the
"Standards Track". These maturity levels are "Proposed Standard" and
"Internet Standard".
A specification may be, and indeed, is likely to be, revised as it
advances from Proposed Standard to Internet Standard. When a revised
specification is proposed for advancement to Internet Standard, the
IESG shall determine the scope and significance of the changes to the
specification, and, if necessary and appropriate, modify the
recommended action. Minor revisions and the removal of unused
features are expected, but a significant revision may require that
the specification accumulate more experience at Proposed Standard
before progressing.
2.1. The First Maturity Level: Proposed Standard
The stated requirements for Proposed Standard are not changed; they
remain exactly as specified in RFC 2026 [1]. No new requirements are
introduced; no existing published requirements are relaxed.
2.2. The Second Maturity Level: Internet Standard
This maturity level is a merger of Draft Standard and Standard as
specified in RFC 2026 [1]. The chosen name avoids confusion between
"Draft Standard" and "Internet-Draft".
The characterization of an Internet Standard remains as described in
RFC 2026 [1], which says:
An Internet Standard is characterized by a high degree of
technical maturity and by a generally held belief that the
specified protocol or service provides significant benefit to the
Internet community.
The IESG, in an IETF-wide Last Call of at least four weeks, confirms
that a document advances from Proposed Standard to Internet Standard.
The request for reclassification is sent to the IESG along with an
explanation of how the criteria have been met. The criteria are:
(1) There are at least two independent interoperating implementations
with widespread deployment and successful operational experience.
(2) There are no errata against the specification that would cause a
new implementation to fail to interoperate with deployed ones.
(3) There are no unused features in the specification that greatly
increase implementation complexity.
(4) If the technology required to implement the specification
requires patented or otherwise controlled technology, then the
set of implementations must demonstrate at least two independent,
separate and successful uses of the licensing process.
After review and consideration of significant errata, the IESG will
perform an IETF-wide Last Call of at least four weeks on the
requested reclassification. If there is consensus for
reclassification, the RFC will be reclassified without publication of
a new RFC.
As stated in RFC 2026 [1], in a timely fashion after the expiration
of the Last Call period, the IESG shall make its final determination
and notify the IETF of its decision via electronic mail to the IETF
Announce mailing list. No changes are made to Section 6.1.2 of RFC
2026 [1].
2.3. Transition to a Standards Track with Two Maturity Levels
Any protocol or service that is currently at the Proposed Standard
maturity level remains so.
Any protocol or service that is currently at the Standard maturity
level shall be immediately reclassified as an Internet Standard.
Any protocol or service that is currently at the abandoned Draft
Standard maturity level will retain that classification, absent
explicit actions. Two possible actions are available:
(1) A Draft Standard may be reclassified as an Internet Standard as
soon as the criteria in Section 2.2 are satisfied.
(2) At any time after two years from the approval of this document as
a BCP, the IESG may choose to reclassify any Draft Standard
document as Proposed Standard.
3. Removed Requirements
3.1. Removal of Requirement for Annual Review
In practice, the annual review of Proposed Standard and Draft
Standard documents after two years (called for in RFC 2026 [1]) has
not taken place. Lack of this review has not revealed any ill
effects on the Internet Standards Process. As a result, the
requirement for this review is dropped. No review cycle is imposed
on Standards Track documents at any maturity level.
3.2. Requirement for Interoperability Testing Reporting
Testing for interoperability is a long tradition in the development
of Internet protocols and remains important for reliable deployment
of services. The IETF Standards Process no longer requires a formal
interoperability report, recognizing that deployment and use is
sufficient to show interoperability.
Although no longer required by the IETF Standards Processes, RFC 5657
[2] can be helpful to conduct interoperability testing.
4. Security Considerations
This document does not directly affect the security of the Internet.
5. Acknowledgements
A two-tier Standards Track has been proposed many times. Spencer
Dawkins, Charlie Perkins, and Dave Crocker made a proposal in 2003.
Additional proposals were made by Scott Bradner in 2004, Brian
Carpenter in June 2005, and Ran Atkinson in 2006. This document
takes ideas from many of these prior proposals; it also incorporates
ideas from the IESG discussion in May 2010, the IETF 78 plenary
discussion in July 2010, and yet another proposal submitted by
Spencer Dawkins, Dave Crocker, Eric Burger, and Peter Saint-Andre in
November 2010.
6. References
6.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
6.2. Informative References
[2] Dusseault, L. and R. Sparks, "Guidance on Interoperation and
Implementation Reports for Advancement to Draft Standard", BCP
9, RFC 5657, September 2009.
Author's Address
Russell Housley
Vigil Security, LLC
EMail: housley@vigilsec.com
Dave Crocker
Brandenburg InternetWorking
EMail: dcrocker@bbiw.net
Eric W. Burger
Georgetown University
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
ISO Plain Language
On this page
§1Introduction
This document changes the Internet Standards Process defined in RFC 2026. In recent years the IETF witnessed difficulty advancing documents through the maturity levels: Proposed Standard, Draft Standard, and finally Standard. The changes are designed to simplify the Standards Process and reduce impediments to standards progression while preserving the most important benefits of the IETF engineering approach. In addition, the requirement for annual review of Standards Track documents that have not reached the top of the maturity ladder is removed.
Over the years there have been many proposals for refining the Standards Process to reduce impediments to standards progression. During May 2010 the IESG discussed many of these proposals. Then a plenary discussion at IETF 78 in July 2010 demonstrated significant support for transition from a three-tier maturity ladder to one with two tiers.
Experience with a Proposed Standard is expected to motivate revisions that clarify, modify, enhance or remove features. However, in recent years the vast majority of Standards Track documents are published as Proposed Standards and never advance to a higher maturity level, and very few specifications have advanced on the maturity ladder in the last decade. Changing the Standards Process from three maturity levels to two is intended to create an environment where lessons from implementation and deployment experience are used to improve specifications.
The primary aspect of the change is to revise the requirements for advancement beyond Proposed Standard. RFC 2026 requires a report that documents interoperability between at least two implementations from different code bases as an interim step, Draft Standard, before a specification can be advanced further to the third and final maturity level, Standard, based on widespread deployment and use. In contrast, this document requires measuring interoperability through widespread deployment of multiple implementations from different code bases, thus condensing the two separate metrics into one.
The result is expected to be maturity-level advancement based on achieving widespread deployment of quality specifications. The change will also result in the incorporation of lessons from implementation and deployment experience, and recognition that protocols are improved by removing complexity associated with unused features. Since widespread deployment is essentially the metric used for advancement from Draft Standard to Standard in RFC 2026, using the same metric for advancement beyond Proposed Standard means there is no longer a useful distinction between the top two tiers, and the ladder is reduced to two tiers. The requirement for annual review of specifications that have not achieved the top maturity level is no longer required.
Almost every RFC the IETF publishes stops at Proposed Standard and stays there. Very few reach the top of the ladder, and the intermediate step in between rarely helps. This document cuts the ladder from three rungs to two and drops the paperwork that had not been happening anyway, so that what counts is whether the specification is actually deployed and working.
- 1996RFC 2026 defines the three-tier Standards TrackRFC 2026
- 2010IESG discussion in May and the IETF 78 plenary in July support a two-tier ladder
- 2011RFC 6410 reduces the Standards Track to two levelsRFC 6410
§2Two Maturity Levels
This document replaces the three-tier maturity ladder defined in RFC 2026 with a two-tier maturity ladder. Specifications become Internet Standards through a set of two maturity levels known as the Standards Track. These maturity levels are Proposed Standard and Internet Standard.
A specification may be, and indeed is likely to be, revised as it advances from Proposed Standard to Internet Standard. When a revised specification is proposed for advancement, the IESG shall determine the scope and significance of the changes to the specification and, if necessary and appropriate, modify the recommended action. Minor revisions and the removal of unused features are expected, but a significant revision may require that the specification accumulate more experience at Proposed Standard before progressing.
The track now has two rungs: Proposed Standard and Internet Standard. A document is expected to change as it climbs, and the IESG decides whether the changes are small enough to allow it to move straight away, or whether it needs more time at Proposed Standard first.
- Proposed Standard start
- Internet Standard
| From | To | Event |
|---|---|---|
| Proposed Standard | Internet Standard | IETF-wide Last Call of at least four weeks |
§2.2The Second Maturity Level: Internet Standard
This maturity level is a merger of Draft Standard and Standard as specified in RFC 2026. The chosen name avoids confusion between Draft Standard and Internet-Draft. The characterization of an Internet Standard remains as described in RFC 2026: an Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.
The IESG, in an IETF-wide Last Call of at least four weeks, confirms that a document advances from Proposed Standard to Internet Standard. The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. There are four criteria. There are at least two independent interoperating implementations with widespread deployment and successful operational experience. There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. There are no unused features in the specification that greatly increase implementation complexity. And if the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process.
After review and consideration of significant errata, the IESG will perform an IETF-wide Last Call of at least four weeks on the requested reclassification. If there is consensus for reclassification, the RFC will be reclassified without publication of a new RFC. In a timely fashion after the expiration of the Last Call period, the IESG shall make its final determination and notify the IETF of its decision via electronic mail to the IETF Announce mailing list. No changes are made to Section 6.1.2 of RFC 2026.
Internet Standard is the top rung, and it merges what used to be two. To get there, a document needs at least two independent implementations that are widely deployed and have worked in practice, no errata that would break a new implementation, no unused features that add a lot of complexity, and, where patents are involved, at least two separate successful licensing arrangements. The IESG then runs a Last Call of at least four weeks. If there is consensus, the existing RFC is reclassified and no new one is published.
- Two independent implementationsWith widespread deployment and successful operational experience.
- No harmful errataNo errata that would make a new implementation fail to interoperate with deployed ones.
- No unused complexityNo unused features in the specification that greatly increase implementation complexity.
- LicensingWhere patented or controlled technology is needed, at least two independent and successful uses of the licensing process.
§2.3Transition to Two Maturity Levels
Any protocol or service that is currently at the Proposed Standard maturity level remains so. Any protocol or service that is currently at the Standard maturity level shall be immediately reclassified as an Internet Standard.
Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions. Two possible actions are available. A Draft Standard may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. And at any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard.
Existing documents are moved over: anything at Standard becomes an Internet Standard, and anything at Proposed Standard stays where it is. The abandoned middle rung is left alone for now, with two ways out: it can be promoted to Internet Standard once it meets the criteria, or, after two years from the approval of this document, the IESG may push it back down to Proposed Standard.
§3Removed Requirements
The requirement for annual review is dropped. In practice, the annual review of Proposed Standard and Draft Standard documents after two years, called for in RFC 2026, has not taken place, and the lack of this review has not revealed any ill effects on the Internet Standards Process. As a result the requirement is dropped, and no review cycle is imposed on Standards Track documents at any maturity level.
The requirement for interoperability testing reporting is dropped as well. Testing for interoperability is a long tradition in the development of Internet protocols and remains important for reliable deployment of services. The IETF Standards Process no longer requires a formal interoperability report, recognizing that deployment and use is sufficient to show interoperability. Although no longer required by the IETF Standards Process, RFC 5657 can be helpful to conduct interoperability testing.
Two requirements are removed. The annual review of documents that had not yet reached the top rung is dropped, because it had not been happening and nothing bad came of it. The formal interoperability report is dropped too, since real deployment already shows that two implementations interoperate.
| Requirement in RFC 2026 | What happens now |
|---|---|
| Annual review of documents that had not reached the top maturity level | Dropped; no review cycle is imposed at any maturity level |
| A formal interoperability report before further advancement | No longer required; deployment and use are taken as sufficient |
§4Security Considerations
This document does not directly affect the security of the Internet. It changes the process by which a specification is reviewed and promoted, and the requirements for that promotion, rather than the technical content of any specification.
The document has no direct effect on the security of the Internet. It changes how documents are reviewed and labelled, not what they say.