Network Working Group K. Kompella Internet Draft Juniper Networks Proposed Category: Best Current Practice A. Zinin Alcatel Expires: August 2004 February 2004 Early IANA Allocation of Standards Track Codepoints draft-kompella-zinin-early-allocation-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Kompella & Zinin Best Current Practice [Page 1] Internet Draft Early Allocation of Standard Codepoints February 2004 Abstract This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols where, by the IETF process, implementation and deployment experience is desired or required prior to publication. 1. Introduction In Standards Track RFCs, there is often the 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 IANA allocation policies are described in RFC 2434 [2434]. 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 codepoints are a scarce resource and/or the IETF community is willing to retain tight control of the protocol, policies such as IESG Approval, IETF Consensus, or Standards Action have been used. The Standards Action policy represents a problem in situations where implementation and/or deployment experience are desired or required for the Standards Action. To break the deadlock, "pre-RFC" implementations simply choose some code points; these may turn out to be different from those later assigned by IANA. To make matters worse, these "pre-RFC" implementations are often deployed. This creates several potential inteoperability problems between early implementations and implementations of the final standard as described below: 1. IANA allocates codepoints different from what early implementations assumed would be allocated. Early implementations won't interoperate with standard ones. 2. IANA allocates codepoints silently used for other extensions. Different extensions will collide. 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 not be deployed; however, both the length of the standards process as well as the immense value of early implementations and early deployments suggest finding a better solution. 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 Kompella & Zinin Best Current Practice [Page 2] Internet Draft Early Allocation of Standard Codepoints February 2004 required, and early deployments provide useful feedback on the technical and operational quality of the specification. This memo proposes that, under strictly controlled circumstances, IANA makes an early allocation of code points. The memo lays out the conditions for early allocation as well as the process to be followed; it also says how such allocations are dealt with in the event of a failure in the process (such as the RFC not being published). This memo only addresses the early allocation of code points from spaces whose allocation policy is "Standards Action" [2434] AND have been amended to permit early allocation. This permission must be granted by the IESG, and code spaces with permission for early allocation must be marked as such in the IANA registry. 2. Conditions for Early Allocation The following conditions must hold before a request may be made for early allocation of code points: a) The code points must be from a space designated as "Standards Action", amended by IESG approval to permit Early Allocation. 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 that is proposed as Standards Track. 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) There is sufficient interest in early (pre-RFC) implementation and deployment in the community. If conditions (a) or (b) are not met, then the processes in this memo do not apply. Kompella & Zinin Best Current Practice [Page 3] Internet Draft Early Allocation of Standard Codepoints February 2004 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. The processes as described below assume that the document in question is the product of an IETF Working Group. If this is not the case, replace "WG chairs" below by "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 the Working Group chairs, specifying which code points require early allocation and which document they should be assigned to. 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 in the case of the given document. 4) If so, with the approval of the Area Director(s), the WG chairs request IANA to make an early allocation. 5) IANA makes an allocation from the appropriate registry, marking it as "temporary", valid for a period of one year from the date of allocation. 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 backwards compatible. If at some point changes that are not backwards compatible are nonetheless required, a decision needs to be made whether previously allocated codepoints must be deprecated or not (see section 3.3 for more information on codepoint deprecation). The considerations include such aspects as possibility of existing deployments of the Kompella & Zinin Best Current Practice [Page 4] Internet Draft Early Allocation of Standard Codepoints February 2004 older implementations and hence the possibility for a collision between older and newer implementations in the field. If the document progresses to the point when 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 so 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 If early allocations expire before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may follow an abbreviated version of the process in section x.2 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. If a follow-up request is not made, or the document fails to progress to a Standards Track RFC, the WG chairs are responsible for informing IANA that the code points are to be marked "deprecated" (and are not to be allocated); the WG chairs are further responsible for informing IANA when the deprecated code points can be completely de-allocated (i.e., made available for new allocations). In particular, it is not IANA's responsibility to track the status of allocations or when they expire or when they may be re-allocated. Normative References [2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 Informative References [3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004 Kompella & Zinin Best Current Practice [Page 5] Internet Draft Early Allocation of Standard Codepoints February 2004 Security Considerations It is important to keep in mind 'denial of service' attacks on IANA as a result of the processes in this memo. There are two that immediately obvious: depletion of code space by early allocations; and process overburden of IANA itself. The processes described here attempt to alleviate both of these, but they should be subject to scrutiny to ensure this. Acknowledgments Many thanks to Bert Wijnen, Adrian Farrel and Bill Fenner for their input. Authors' Addresses Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA Email: kireeti@juniper.net Alex Zinin Alcatel Email: zinin@psg.com Full Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be Kompella & Zinin Best Current Practice [Page 6] Internet Draft Early Allocation of Standard Codepoints February 2004 revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kompella & Zinin Best Current Practice [Page 7]