GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6410

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.

Housley, et al. Best Current Practice [Page 1] RFC 6410 Standards Track Maturity Levels October 2011

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

Housley, et al. Best Current Practice [Page 2] RFC 6410 Standards Track Maturity Levels October 2011

 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".

Housley, et al. Best Current Practice [Page 3] RFC 6410 Standards Track Maturity Levels October 2011

 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.

Housley, et al. Best Current Practice [Page 4] RFC 6410 Standards Track Maturity Levels October 2011

 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.

Housley, et al. Best Current Practice [Page 5] RFC 6410 Standards Track Maturity Levels October 2011

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

Housley, et al. Best Current Practice [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6410.txt · Last modified: 2011/10/11 00:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki