Reducing the Standards Track to Two Maturity Levels
RFC 6410

Document Type RFC - Best Current Practice (October 2011; Errata)
Updates RFC 2026
Also known as BCP 9
Was draft-housley-two-maturity-levels (individual in gen area)
Authors Dave Crocker  , Eric Burger  , Russ Housley 
Last updated 2020-01-21
Stream IETF
Formats plain text html pdf htmlized with errata bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 6410 (Best Current Practice)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Jari Arkko
IESG note Russ Housley ( is the document shepherd.
Send notices to (None)
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


   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

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
   ( 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

   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.
   In contrast, this document requires measuring interoperability
   through widespread deployment of multiple implementations from
   different code bases, thus condensing the two separate metrics into

   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
Show full document text