One document matched: draft-housley-two-maturity-levels-05.txt
Differences from draft-housley-two-maturity-levels-04.txt
INTERNET-DRAFT R. Housley
Updates: 2026 (if approved) Vigil Security
Intended Status: BCP D. Crocker
Brandenburg InternetWorking
E. Burger
Georgetown University
Expires: 8 October 2011 6 April 2011
Reducing the Standards Track to Two Maturity Levels
<draft-housley-two-maturity-levels-05.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 IETF standards track maturity levels to two.
{{ RFC Editor: please change "proposes several changes to the" to
"changes 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.
This document is subject to BCP 78 and the IETF Trust's Legal
Housley, Crocker, and Burger [Page 1]
INTERNET-DRAFT April 2011
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 IETF Standards Process and reduce impediments to
standards progression while preserving the most important benefits of
the IETF engineering approach.
{{ 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 current environment, many documents are published as Proposed
Standard and never advance to a higher maturity level. In addition,
IETF working groups and IESG members provide much more scrutiny than
is called for by RFC 2026 [1] prior to publication as Proposed
Standard. One desired outcome is to provide an environment where the
IETF community is able to publish Proposed Standards as soon as rough
consensus is achieved. Another desired outcome is easier publication
of revisions that reflect implementation and deployment experience,
whether the document is advancing on the maturity ladder or not.
Maturity level advancement ought to be based on achieving widespread
deployment of quality specifications. Further, protocols are
improved by removing complexity associated with features that are not
used in practice.
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. The benefit
associated with a third maturity level has proven insufficient to
Housley, Crocker, and Burger [Page 2]
INTERNET-DRAFT April 2011
justify the effort associated with document progression. The two
maturity levels are Proposed Standard and Internet Standard.
{{ RFC Editor: please change "This document, once approved, replaces"
to "This document replaces". }}
Experience with a Proposed Standard often leads to revisions that
clarify, modify, enhance, or remove features. Review of revisions to
a Proposed Standard that is submitted for publication at the same
maturity level is generally limited to the changes. Reconsideration
of the portions that were previously approved for publication as a
Proposed Standard requires evidence that the unchanged features are
causing significant problems with use of the specification.
A specification shall remain at the Proposed Standard maturity level
for at least six (6) months before consideration for advancement to
the Internet Standard maturity level.
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]. Various influences have
made publishing a Proposed Standard much harder than the stated
requirements in RFC 2026. The intention of the two-tier maturity
ladder is to restore practice to the requirements for Proposed
Standard from RFC 2026, and stop performing more scrutiny than
intended in IETF working groups and the IESG. 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
Housley, Crocker, and Burger [Page 3]
INTERNET-DRAFT April 2011
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 two weeks:
* There are a significant number of implementations with
successful operational experience.
* There are no unresolved 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.
* If patented or otherwise controlled technology is required for
implementation, the separate implementations must also have
resulted from separate exercise of the licensing process.
Note that the distinct requirement from RFC 2026 [1] for reports of
interoperability testing among two or more independent
implementations is intentionally subsumed by the requirement for
actual deployment and use of independent and interoperable
implementations. The Last Call is intended to identify unused
portions of the specification that greatly increase implementation
complexity without burdensome implementation testing and
documentation.
3. 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.
4. Downward References Permitted
Internet Standards are allowed to make normative references to
Proposed Standards. The rules that prohibit references to documents
at lower maturity levels are a major cause of stagnation in the
Housley, Crocker, and Burger [Page 4]
INTERNET-DRAFT April 2011
advancement of documents. This change allows an Internet Standard to
freely reference features in any standards track RFC. The intent of
this change is to enable expeditious promotion of Proposed Standards
to Internet Standards.
Normative references to BCP documents continue to be allowed.
Downward normative references to Informational documents continue to
be allowed using the procedure specified in RFC 3967 [2].
Downward normative references to Historic documents, Experimental
documents, and Internet-Draft documents continue to be prohibited.
5. 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. This
reclassification is accomplished by submitting a request to the
IESG along with a description of the operational experience.
After review and consideration of significant errata, the IESG
will perform an IETF-wide Last Call of at least two 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) 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.
Housley, Crocker, and Burger [Page 5]
INTERNET-DRAFT April 2011
6. Open Question Regarding STD Numbers
Under current practice, a STD number is assigned only when a document
(or document set) reaches the full Standard maturity level. In
several situations, an RFC that has reached the full Standard
maturity level has been obsoleted by a RFC at Proposed Standard
maturity level, causing great confusion about which specification
ought to be implemented.
During the IETF 78 plenary discussion, several people advocated
abandoning STD numbers. These people felt that the confusion
associated with these numbers outweighs their value. Other people
felt that the ability to assign one number to a collection of
Internet Standards was very valuable.
This document makes no change to the current STD practice; however,
this topic deserves further discussion by the whole community.
7. Security Considerations
This document does not directly affect the security of the Internet.
8. IANA Considerations
This document requests no action by the IANA.
{{ RFC Editor: Please delete this section before publication. }}
9. 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.
10. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bush, R., and T. Narten, "Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level",
BCP 97, RFC 3967, December 2004.
Housley, Crocker, and Burger [Page 6]
INTERNET-DRAFT April 2011
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 7]
| PAFTECH AB 2003-2026 | 2026-04-21 20:02:05 |