doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc7120.txt b/doc/rfc/rfc7120.txt
new file mode 100644
index 0000000..be65727
--- /dev/null
+++ b/doc/rfc/rfc7120.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         M. Cotton
+Request for Comments: 7120                                         ICANN
+BCP: 100                                                    January 2014
+Obsoletes: 4020
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+          Early IANA Allocation of Standards Track Code Points
+
+Abstract
+
+   This memo describes the process for early allocation of code points
+   by IANA from registries for which "Specification Required", "RFC
+   Required", "IETF Review", or "Standards Action" policies apply.  This
+   process can be used to alleviate the problem where code point
+   allocation is needed to facilitate desired or required implementation
+   and deployment experience prior to publication of an RFC, which would
+   normally trigger code point allocation.  The procedures in this
+   document are intended to apply only to IETF Stream documents.
+
+   This document obsoletes RFC 4020.
+
+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/rfc7120.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton                    Best Current Practice                 [Page 1]
+
+RFC 7120                  Early IANA Allocation             January 2014
+
+
+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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Conditions for Early Allocation . . . . . . . . . . . . . . . . 4
+   3.  Process for Early Allocation  . . . . . . . . . . . . . . . . . 4
+     3.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     3.2.  Follow-Up . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     3.3.  Expiry  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
+     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
+   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton                    Best Current Practice                 [Page 2]
+
+RFC 7120                  Early IANA Allocation             January 2014
+
+
+1.  Introduction
+
+   In protocol specifications documented in RFCs, there is often a need
+   to allocate code points for various objects, messages, or other
+   protocol entities so that implementations can interoperate.  Many of
+   these code point spaces have registries handled by the Internet
+   Assigned Number Authority (IANA).  Several IETF policies for IANA
+   allocation of protocol parameters are described in RFC 5226
+   [RFC5226].  Some of them, such as "First Come First Served" or
+   "Expert Review", do not require a formal IETF action before the IANA
+   performs allocation.  However, in situations where code points are a
+   scarce resource and/or the IETF community has consensus to retain
+   tight control of the registry content, policies such as "IETF Review"
+   (formerly "IETF Consensus"), or "Standards Action" have been used.
+   Such allocation policies present a problem in situations where
+   implementation and/or deployment experience are desired or required
+   before the document becomes an RFC.
+
+   To break the deadlock, document authors often choose some "seemingly
+   unused" code points, often by selecting the next available value from
+   the registry; this is problematic because these may turn out to be
+   different from those later assigned by IANA.  To make this problem
+   worse, "pre-RFC" implementations are often developed and deployed
+   based on these code point selections.  This creates several potential
+   interoperability problems between early implementations and
+   implementations of the final standard, as described below:
+
+   1.  IANA allocates code points different from those that early
+       implementations assumed would be allocated.  Early
+       implementations won't interoperate with standard ones.
+
+   2.  IANA allocates code points for one extension while a "pre-RFC"
+       implementation of a different extension chooses the same code
+       point.  The different extensions will collide on the same code
+       point in the field.
+
+   This gets in the way of the main purpose of standards; namely, to
+   facilitate interoperable implementations.
+
+   It is easy to say that pre-RFC implementations should be kept private
+   and should not be deployed; however, both the length of the standards
+   process and the immense value of early implementations and early
+   deployments suggest that finding a better solution is worthwhile.  As
+   an example, in the case of documents produced by Working Groups in
+   the Routing Area, a pre-RFC implementation is highly desirable and
+   sometimes even required [RFC4794], and early deployments provide
+   useful feedback on the technical and operational quality of the
+   specification.
+
+
+
+Cotton                    Best Current Practice                 [Page 3]
+
+RFC 7120                  Early IANA Allocation             January 2014
+
+
+   This memo addresses the early allocation of code points so that
+   reservations are made in the IANA registries before the publication
+   of an RFC.  The early allocation mechanisms are applied only to
+   spaces whose allocation policy is "Specification Required" (where an
+   RFC is used as the stable reference), "RFC Required", "IETF Review",
+   or "Standards Action".  For an explanation of these allocation
+   policies, see [RFC5226].
+
+   A policy for IANA early allocations was previously described in
+   [RFC4020].  This document obsoletes RFC 4020 and includes other
+   registration procedures regarding the types of registries that can
+   qualify for early allocation.  The procedures in this document are
+   intended to apply only to IETF Stream documents.
+
+2.  Conditions for Early Allocation
+
+   The following conditions must hold before a request for early
+   allocation of code points will be considered by IANA:
+
+   a.  The code points must be from a space designated as "RFC
+       Required", "IETF Review", or "Standards Action".  Additionally,
+       requests for early assignment of code points from a
+       "Specification Required" registry are allowed if the
+       specification will be published as an RFC.
+
+   b.  The format, semantics, processing, and other rules related to
+       handling the protocol entities defined by the code points
+       (henceforth called "specifications") must be adequately described
+       in an Internet-Draft.
+
+   c.  The specifications of these code points must be stable; i.e., if
+       there is a change, implementations based on the earlier and later
+       specifications must be seamlessly interoperable.
+
+   d.  The Working Group chairs and Area Directors (ADs) judge that
+       there is sufficient interest in the community for early (pre-RFC)
+       implementation and deployment, or that failure to make an early
+       allocation might lead to contention for the code point in the
+       field.
+
+3.  Process for Early Allocation
+
+   There are three processes associated with early allocation: making
+   the request for code points; following up on the request; and
+   revoking an early allocation.  It cannot be emphasized enough that
+   these processes must have a minimal impact on IANA itself, or they
+   will not be feasible.
+
+
+
+
+Cotton                    Best Current Practice                 [Page 4]
+
+RFC 7120                  Early IANA Allocation             January 2014
+
+
+   The processes described below assume that the document in question is
+   the product of an IETF Working Group (WG).  If this is not the case,
+   replace "WG chairs" below with "Shepherding Area Director".
+
+3.1.  Request
+
+   The process for requesting and obtaining early allocation of code
+   points is as follows:
+
+   1.  The authors (editors) of the document submit a request for early
+       allocation to the Working Group chairs, specifying which code
+       points require early allocation and to which document they should
+       be assigned.
+
+   2.  The WG chairs determine whether the conditions for early
+       allocations described in Section 2 are met, particularly
+       conditions (c) and (d).
+
+   3.  The WG chairs gauge whether there is consensus within the WG that
+       early allocation is appropriate for the given document.
+
+   4.  If steps 2) and 3) are satisfied, the WG chairs request approval
+       from the Area Director(s).  The Area Director(s) may apply
+       judgement to the request, especially if there is a risk of
+       registry depletion.
+
+   5.  If the Area Directors approve step 4), the WG chairs request IANA
+       to make an early allocation.
+
+   6.  IANA makes an allocation from the appropriate registry, marking
+       it as "Temporary", valid for a period of one year from the date
+       of allocation.  The date of first allocation and the date of
+       expiry are also recorded in the registry and made visible to the
+       public.
+
+   Note that Internet-Drafts should not include a specific value of a
+   code point until IANA has completed the early allocation for this
+   value.
+
+3.2.  Follow-Up
+
+   It is the responsibility of the document authors and the Working
+   Group chairs to review changes in the document, and especially in the
+   specifications of the code points for which early allocation was
+   requested, to ensure that the changes are backward compatible.
+
+
+
+
+
+
+Cotton                    Best Current Practice                 [Page 5]
+
+RFC 7120                  Early IANA Allocation             January 2014
+
+
+   If at some point changes that are not backward compatible are
+   nonetheless required, a decision needs to be made as to whether
+   previously allocated code points must be deprecated (see Section 3.3
+   for more information on code point deprecation).  The considerations
+   include aspects such as the possibility of existing deployments of
+   the older implementations and, hence, the possibility for a collision
+   between older and newer implementations in the field.
+
+   If the document progresses to the point at which IANA normally makes
+   code point allocations, it is the responsibility of the authors and
+   the WG chairs to remind IANA that there were early allocations and of
+   the code point values allocated in the IANA Considerations section of
+   the RFC-to-be.  Allocation is then just a matter of removing the
+   "Temporary" tag from the allocation description.
+
+3.3.  Expiry
+
+   As described in Section 3.1, each temporary assignment is recorded in
+   the registry with the date of expiry of the assignment.  If an early
+   allocation expires before the document progresses to the point where
+   IANA normally makes allocations, the authors and WG chairs may repeat
+   the process described in Section 3.1 to request renewal of the code
+   points.  At most, one renewal request may be made; thus, authors
+   should choose carefully when the original request is to be made.
+
+   As an exception to the above rule, under rare circumstances, more
+   than one allocation renewal may be justified.  All such further
+   renewal requests must be reviewed by the IESG.  The renewal request
+   to the IESG must include the reasons why such further renewal is
+   necessary and the WG's plans regarding the specification.
+
+   If a follow-up request is not made, or the document fails to progress
+   to an RFC, the assignment will remain visible in the registry, but
+   the temporary assignment will be shown to have expired as indicated
+   by the expiry date.  The WG chairs are responsible for informing IANA
+   that the expired assignments are not required and that the code
+   points are to be marked "deprecated".
+
+   A deprecated code point is not marked as allocated for use as
+   described in any document (that is, it is not allocated) and is not
+   available for allocation in a future document.  The WG chairs may
+   inform IANA that a deprecated code point can be completely
+   de-allocated (i.e., made available for new allocations) at any time
+   after it has been deprecated.  Factors influencing this decision will
+   include whether there may be implementations using the previous
+   temporary allocation and the availability of other unallocated code
+   points in the registry.
+
+
+
+
+Cotton                    Best Current Practice                 [Page 6]
+
+RFC 7120                  Early IANA Allocation             January 2014
+
+
+   Implementers and deployers need to be aware that deprecation and
+   de-allocation could take place at any time after expiry; therefore,
+   an expired early allocation is best considered as deprecated.
+
+   It is not IANA's responsibility to track the status of allocations,
+   their expirations, or when they may be re-allocated.
+
+   Note that if a document is submitted for review to the IESG, and at
+   the time of submission some early allocations are valid (not
+   expired), these allocations must not be considered to have expired
+   while the document is under IESG consideration or is awaiting
+   publication in the RFC Editor's queue after approval by the IESG.
+
+4.  IANA Considerations
+
+   This document defines procedures for early allocation of code points
+   in the registries with the "Specification Required", "RFC Required",
+   "IETF Review", and "Standards Action" policies and as such directly
+   affects IANA.  This document removes the need for registries to be
+   marked as specifically allowing early allocation.  IANA has updated
+   impacted registries by removing any such markings.
+
+5.  Security Considerations
+
+   It is important to keep in mind that denial-of-service attacks on
+   IANA are possible as a result of the processes defined in this memo.
+   There are two that are immediately obvious: depletion of code space
+   by early allocations and process overloading of IANA itself.  The
+   processes described here attempt to alleviate both of these potential
+   attacks, but they are subject to scrutiny by IANA to ensure that they
+   work.  IANA may at any time request that the IESG suspend the
+   procedures described in this document.
+
+   There is a significant concern that the procedures in this document
+   could be used as an end-run on the IETF process to achieve code point
+   allocation when an RFC will not be published.  For example, a WG or a
+   WG chair might be pressured to obtain an early allocation for a
+   protocol extension for a particular company or for another Standards
+   Development Organization even though it might be predicted that an
+   IETF LC or IESG Evaluation would reject the approach that is
+   documented.  The requirement for AD consent of early review is an
+   important safeguard, and ADs with any concern are strongly
+   recommended to escalate the issue for IESG-wide discussion.
+
+
+
+
+
+
+
+
+Cotton                    Best Current Practice                 [Page 7]
+
+RFC 7120                  Early IANA Allocation             January 2014
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+6.2.  Informative References
+
+   [RFC4020]  Kompella, K. and A. Zinin, "Early IANA Allocation of
+              Standards Track Code Points", BCP 100, RFC 4020,
+              February 2005.
+
+   [RFC4794]  Fenner, B., "RFC 1264 Is Obsolete", RFC 4794,
+              December 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton                    Best Current Practice                 [Page 8]
+
+RFC 7120                  Early IANA Allocation             January 2014
+
+
+Appendix A.  Acknowledgments
+
+   Many thanks to Bert Wijnen, Adrian Farrel, and Bill Fenner for their
+   input on RFC 4020.  Thank you to Kireeti Kompella and Alex Zinin for
+   authoring RFC 4020.  Thank you to Adrian Farrel, Stewart Bryant, Leo
+   Vegoda, John Klensin, Subramanian Moonesamy, Loa Andersson, Tom
+   Petch, Robert Sparks, Eric Rosen, Amanda Baber, and Pearl Liang for
+   their reviews of this document.
+
+Author's Address
+
+   Michelle Cotton
+   Internet Corporation for Assigned Names and Numbers
+   12025 Waterfront Drive, Suite 300
+   Los Angeles, CA  90094-2536
+   United States of America
+
+   Phone: +1-310-823-5800
+   EMail: michelle.cotton@icann.org
+   URI:   http://www.icann.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cotton                    Best Current Practice                 [Page 9]
+