INTERNET-DRAFT R. Housley
Updates: 2026 (if approved) Vigil Security
Intended Status: BCP D. Crocker
Brandenburg InternetWorking
E. Burger
Georgetown University
Expires: 1 March 2012 1 September 2011
Reducing the Standards Track to Two Maturity Levels
<draft-housley-two-maturity-levels-09.txt>
Abstract
This document proposes several changes to the Internet Engineering
Task Force (IETF) Standards Process defined in RFC 2026, primarily a
reduction from three standards track maturity levels to two.
{{ RFC Editor: please change "proposes several changes to the" to
"updates the". }}
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Housley, Crocker, and Burger [Page 1]
INTERNET-DRAFT June 2011
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.
1. Introduction
This document proposes several changes to the Internet Standards
Process defined in RFC 2026 [1]. In recent years, the Internet
Engineering Task Force (IETF) has witnessed difficulty in 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.
{{ RFC Editor: please change "proposes several changes to the" to
"changes the". }}
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.
Housley, Crocker, and Burger [Page 2]
INTERNET-DRAFT June 2011
In contrast, this document measures 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, while at the same time, incorporating lessons from
implementation and deployment experience, and recognizing 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, once approved, 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".
{{ RFC Editor: please change "This document, once approved, replaces"
to "This document replaces". }}
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.
Housley, Crocker, and Burger [Page 3]
INTERNET-DRAFT June 2011
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 criteria for advancing from Proposed Standard to Internet
Standard are confirmed by the IESG in an IETF-wide Last Call of at
least four weeks. 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 patented or otherwise controlled technology is required for
implementation, the implementations demonstrate at least two
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].
Housley, Crocker, and Burger [Page 4]
INTERNET-DRAFT June 2011
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 for efforts to conduct interoperability testing.
4. Security Considerations
This document does not directly affect the security of the Internet.
Housley, Crocker, and Burger [Page 5]
INTERNET-DRAFT June 2011
5. IANA Considerations
This document requests no action by the IANA.
{{ RFC Editor: Please delete this section before publication. }}
6. Acknowledgements
A two-tier standards track proposal has been proposed many times.
Spencer Dawkins, Charlie Perkins, and Dave Crocker made a proposal in
2003. Another proposal was made by Scott Bradner in 2004. Another
proposal was made by Brian Carpenter in June 2005. Another proposal
was made by 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.
7. References
7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
7.2. Informative References
[2] Dusseault, L., and R. Sparks, "Guidance on Interoperation and
Implementation Reports for Advancement to Draft Standard",
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
Housley, Crocker, and Burger [Page 6]