summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7120.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7120.txt')
-rw-r--r--doc/rfc/rfc7120.txt507
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]
+