One document matched: draft-housley-two-maturity-levels-02.txt

Differences from draft-housley-two-maturity-levels-01.txt

 



INTERNET-DRAFT                                                R. Housley
Updates: 2026 (if approved)                               Vigil Security
Intended Status: BCP                                    1 September 2010
Expires: 5 March 2011                                                   


          Reducing the Standards Track to Two Maturity Levels
                draft-housley-two-maturity-levels-02.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" to "implements". }}

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) 2010 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
 


Housley                                                         [Page 1]

INTERNET-DRAFT                                            September 2010


   to this document.















































 


Housley                                                         [Page 2]

INTERNET-DRAFT                                            September 2010


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 benefits of the IETF
   engineering approach.

   {{ RFC Editor: please change "proposes" to "implements". }}

   During May 2010, the Internet Engineering Steering Group (IESG)
   discussed the possible ways of reducing impediments to standards
   progression.  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
   Standards and never advance to a higher maturity level.  Over time,
   this has resulted in IETF working groups and IESG members providing
   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.  Similarly,
   subsequent revisions to the documents ought to be easier to publish,
   whether the document is advancing on the maturity ladder or not.

   Maturity level advancement ought to be based on achieving
   interoperable implementations based on the IETF documents.  Further,
   protocols are improved by removing complexity associated with
   features that are not used in practice.

2.  The First Maturity Level: Proposed Standard

   The requirements for Proposed Standard are unchanged; they remain
   exactly as specified in RFC 2026 [1].

3.  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 criteria for advancing from Proposed Standard to Internet
   Standard are roughly the same as the current criteria for moving to
   Draft Standard as specified in RFC 2026 [1].
 


Housley                                                         [Page 3]

INTERNET-DRAFT                                            September 2010


   Along with documentation of interoperability testing, the
   documentation must include information about the support of each of
   the options and features.  Guidance on documenting the specific
   implementations which qualify the specification for Internet Standard
   status is provided in RFC 5657 [2].  It is important to choose an
   appropriate level of detail to document feature interoperability. 
   The granularity of features described in a specification is
   necessarily very detailed.  In contrast, the granularity of an
   implementation report need not be as detailed.  One effective
   approach is to characterize the interoperability quality and testing
   approach, and then call out any known problems in either testing or
   interoperability.  This implementation report must be submitted to
   the Area Director (AD).  This implementation report should be
   provided to the AD with the protocol action request, which is
   described in Section 6 of RFC 2026 [1].

4.  No Third Maturity Level

   The final "Standard" maturity level is simply abolished.  The benefit
   associated with a third maturity level has proven insufficient to
   justify the effort associated with document progression.  The
   "Internet Standard" becomes the final maturity level.

5.  Timing Requirements

   A specification shall remain at the Proposed Standard level for at
   least six (6) months.

   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 are expected, but a significant
   revision may require that the specification accumulate more
   experience at Proposed Standard before progressing.

   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.

6.  Downward References Permitted

   Internet Standards are allowed to make normative references to
   Proposed Standards.  The rules that make references to documents at
 


Housley                                                         [Page 4]

INTERNET-DRAFT                                            September 2010


   lower maturity levels are a major cause of stagnation in the
   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.

   Downward references to Internet-Draft documents continue to be
   prohibited.

7.  Transition to a Standards Track with Two Maturity Levels

   On the day these changes are published as a BCP, all existing Draft
   Standard and Standard documents automatically get reclassified as
   Internet Standard documents.  Corresponding changes would be made to
   the RFC Index and other features of the RFC Editor web site.

8.  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 out weights 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.

9.  Security Considerations

   This document does not directly affect the security of the Internet.

10.  IANA Considerations

   This document requests no action by the IANA.

   {{ RFC Editor: Please delete this section before publication. }}

11.  Acknowledgements

   A two-tier standards track proposal has been proposed many times. 
   Spencer Dawkins, Charlie Perkins, and Dave Crocker made a proposal in
 


Housley                                                         [Page 5]

INTERNET-DRAFT                                            September 2010


   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 and the IETF 78 plenary discussion in
   July 2010.

12.  Normative References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [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
   918 Spring Knoll Drive
   Herndon, VA 20170 USA
   Email: housley@vigilsec.com




























Housley                                                         [Page 6]