Movatterモバイル変換

Internet Engineering Task Force (IETF)                        R. HousleyRequest for Comments: 6410                                Vigil SecurityBCP: 9                                                        D. CrockerUpdates:2026                                Brandenburg InternetWorkingCategory: Best Current Practice                                E. BurgerISSN: 2070-1721                                    Georgetown University                                                            October 2011Reducing the Standards Track to Two Maturity LevelsAbstract   This document updates the Internet Engineering Task Force (IETF)   Standards Process defined inRFC 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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://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 toBCP 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 20111.  Introduction   This document changes the Internet Standards Process defined inRFC2026 [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 deploymentHousley, 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.   InRFC 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 inRFC2026 [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 inRFC 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 inRFC 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 inRFC 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 inRFC 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 ofRFC2026 [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 inSection 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 Requirements3.1.  Removal of Requirement for Annual Review   In practice, the annual review of Proposed Standard and Draft   Standard documents after two years (called for inRFC 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 20116.  References6.1. Normative References   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",BCP9,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",BCP9,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.comHousley, et al.           Best Current Practice                 [Page 6]