doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc6410.txt b/doc/rfc/rfc6410.txt
new file mode 100644
index 0000000..fe14c8c
--- /dev/null
+++ b/doc/rfc/rfc6410.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+