From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7120.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc7120.txt (limited to 'doc/rfc/rfc7120.txt') 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] + -- cgit v1.2.3