Network Working Group K. Kompella Request for Comments: 4020 Juniper Networks BCP: 100 A. Zinin Category: Best Current Practice Alcatel February 2005 Early IANA Allocation of Standards Track Code Points Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. RFC 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 code points 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 have sometimes simply chosen some "seemingly unused" 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 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 used silently 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 should not be deployed; however, both the length of the standards process and 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 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 make 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 these 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"  AND that 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.
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. 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 it is, 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. The date of allocation should also be 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 this value has been formally allocated by IANA. 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 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. 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 renewal requests must be reviewed by the IESG. The renewal request to the IESG must include the reasons why such 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 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, their expiration, 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 should not be expired while the document is under IESG consideration or waiting in the RFC Editor's queue after approval by the IESG.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.