doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc7127.txt b/doc/rfc/rfc7127.txt
new file mode 100644
index 0000000..d03d018
--- /dev/null
+++ b/doc/rfc/rfc7127.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        O. Kolkman
+Request for Comments: 7127                                    NLnet Labs
+BCP: 9                                                        S. Bradner
+Updates: 2026                                         Harvard University
+Category: Best Current Practice                                S. Turner
+ISSN: 2070-1721                                               IECA, Inc.
+                                                            January 2014
+
+
+                 Characterization of Proposed Standards
+
+Abstract
+
+   RFC 2026 describes the review performed by the Internet Engineering
+   Steering Group (IESG) on IETF Proposed Standard RFCs and
+   characterizes the maturity level of those documents.  This document
+   updates RFC 2026 by providing a current and more accurate
+   characterization of Proposed Standards.
+
+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 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/rfc7127.
+
+Copyright Notice
+
+   Copyright (c) 2014 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.
+
+
+
+
+
+Kolkman, et al.           Best Current Practice                 [Page 1]
+
+RFC 7127         Characterization of Proposed Standards     January 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  IETF Review of Proposed Standards . . . . . . . . . . . . . .   2
+   3.  Characterization of Specifications  . . . . . . . . . . . . .   3
+     3.1.  Characterization of IETF Proposed Standard Specifications   3
+     3.2.  Characteristics of Internet Standards . . . . . . . . . .   4
+   4.  Further Considerations  . . . . . . . . . . . . . . . . . . .   4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
+   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
+   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   5
+
+1.  Introduction
+
+   In the two decades after publication of RFC 2026 [RFC2026], the IETF
+   has evolved its review processes of Proposed Standard RFCs, and thus
+   Section 4.1.1 of RFC 2026 no longer accurately describes IETF
+   Proposed Standards.
+
+   This document only updates the characterization of Proposed Standards
+   from Section 4.1.1 of RFC 2026 and does not speak to or alter the
+   procedures for the maintenance of Standards Track documents from RFC
+   2026 and RFC 6410 [RFC6410].  For complete understanding of the
+   requirements for standardization, those documents should be read in
+   conjunction with this document.
+
+2.  IETF Review of Proposed Standards
+
+   The entry-level maturity for the standards track is "Proposed
+   Standard".  A specific action by the IESG is required to move a
+   specification onto the Standards Track at the "Proposed Standard"
+   level.
+
+   Initially it was intended that most IETF technical specifications
+   would progress through a series of maturity stages starting with
+   Proposed Standard, then progressing to Draft Standard, then finally
+   to Internet Standard (see Section 6 of RFC 2026).  For a number of
+   reasons this progression is not common.  Many Proposed Standards are
+   actually deployed on the Internet and used extensively, as stable
+   protocols.  This proves the point that the community often deems it
+   unnecessary to upgrade a specification to Internet Standard.  Actual
+   practice has been that full progression through the sequence of
+   standards levels is typically quite rare, and most popular IETF
+   protocols remain at Proposed Standard.  Over time, the IETF has
+   developed a more extensive review process.
+
+
+
+
+
+
+Kolkman, et al.           Best Current Practice                 [Page 2]
+
+RFC 7127         Characterization of Proposed Standards     January 2014
+
+
+   IETF Proposed Standards documents have been subject to open
+   development and review by the Internet technical community, generally
+   including a number of formal cross-discipline reviews and,
+   specifically, a security review.  This is further strengthened in
+   many cases by implementations and even the presence of interoperable
+   code.  Hence, IETF Proposed Standards are of such quality that they
+   are ready for the usual market-based product development and
+   deployment efforts into the Internet.
+
+3.  Characterization of Specifications
+
+   The text in the following section replaces Section 4.1.1 of RFC 2026.
+   Section 3.2 is a verbatim copy of the characterization of Internet
+   Standards from Section 4.1.3 of RFC 2026 and is provided for
+   convenient reference.  The text only provides the characterization;
+   process issues for Draft and Internet Standards are described in RFC
+   2026 and its updates, specifically RFC 6410.
+
+3.1.  Characterization of IETF Proposed Standard Specifications
+
+   The entry-level maturity for the standards track is "Proposed
+   Standard".  A specific action by the IESG is required to move a
+   specification onto the standards track at the "Proposed Standard"
+   level.
+
+   A Proposed Standard specification is stable, has resolved known
+   design choices, has received significant community review, and
+   appears to enjoy enough community interest to be considered valuable.
+
+   Usually, neither implementation nor operational experience is
+   required for the designation of a specification as a Proposed
+   Standard.  However, such experience is highly desirable and will
+   usually represent a strong argument in favor of a Proposed Standard
+   designation.
+
+   The IESG may require implementation and/or operational experience
+   prior to granting Proposed Standard status to a specification that
+   materially affects the core Internet protocols or that specifies
+   behavior that may have significant operational impact on the
+   Internet.
+
+   A Proposed Standard will have no known technical omissions with
+   respect to the requirements placed upon it.  Proposed Standards are
+   of such quality that implementations can be deployed in the Internet.
+   However, as with all technical specifications, Proposed Standards may
+   be revised if problems are found or better solutions are identified,
+   when experiences with deploying implementations of such technologies
+   at scale is gathered.
+
+
+
+Kolkman, et al.           Best Current Practice                 [Page 3]
+
+RFC 7127         Characterization of Proposed Standards     January 2014
+
+
+3.2.  Characteristics of Internet Standards
+
+   A specification for which significant implementation and successful
+   operational experience has been obtained may be elevated to the
+   Internet Standard level.  An Internet Standard (which may simply be
+   referred to as a 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.
+
+4.  Further Considerations
+
+   Occasionally, the IETF may choose to publish as Proposed Standard a
+   document that contains areas of known limitations or challenges.  In
+   such cases, any known issues with the document will be clearly and
+   prominently communicated in the document, for example, in the
+   abstract, the introduction, or a separate section or statement.
+
+5.  Security Considerations
+
+   This document does not directly affect the security of the Internet.
+
+6.  Normative References
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [RFC6410]  Housley, R., Crocker, D., and E. Burger, "Reducing the
+              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
+              October 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.           Best Current Practice                 [Page 4]
+
+RFC 7127         Characterization of Proposed Standards     January 2014
+
+
+Appendix A.  Acknowledgements
+
+   This document is inspired by a discussion at the open microphone
+   session during the technical plenary at IETF 87.  Thanks to, in
+   alphabetical order, Jari Arkko, Carsten Bormann, Scott Brim, Randy
+   Bush, Benoit Claise, Dave Cridland, Spencer Dawkins, Adrian Farrel,
+   Stephen Farrell, Subramanian Moonesamy, and Pete Resnick for
+   motivation, input, and review.
+
+   John Klensin and Dave Crocker have provided significant
+   contributions.
+
+Authors' Addresses
+
+   Olaf Kolkman
+   Stichting NLnet Labs
+   Science Park 400
+   Amsterdam  1098 XH
+   The Netherlands
+
+   EMail: olaf@nlnetlabs.nl
+   URI:   http://www.nlnetlabs.nl/
+
+
+   Scott O. Bradner
+   Harvard University Information Technology
+   Innovation and Architecture
+   8 Story St., Room 5014
+   Cambridge, MA  02138
+   United States of America
+
+   Phone: +1 617 495 3864
+   EMail: sob@harvard.edu
+   URI:   http://www.harvard.edu/huit
+
+
+   Sean Turner
+   IECA, Inc.
+
+   EMail: turners@ieca.com
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.           Best Current Practice                 [Page 5]
+