[Search] [pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 rfc6410    Best Current Practice
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


   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

   The list of Internet-Draft Shadow Directories can be accessed at

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

   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

   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

   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]