Movatterモバイル変換

Network Working Group                                        K. KompellaRequest for Comments: 4020                              Juniper NetworksBCP: 100                                                        A. ZininCategory: Best Current Practice                                  Alcatel                                                           February 2005Early IANA Allocation of Standards Track Code PointsStatus 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).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 for which, by the IETF process, implementation and   deployment experience is desired or required prior to publication.1.  Introduction   In Standards Track 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 IANA allocation policies are described inRFC 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 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 earlyKompella & Zinin         Best Current Practice                  [Page 1]

RFC 4020        Early Allocation of Standard Code Points   February 2005   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" [2434] 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.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.Kompella & Zinin         Best Current Practice                  [Page 2]

RFC 4020        Early Allocation of Standard Code Points   February 2005   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.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 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 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 which document they should be      assigned to.   2) The WG chairs determine whether the conditions for early      allocations described insection 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.Kompella & Zinin         Best Current Practice                  [Page 3]

RFC 4020        Early Allocation of Standard Code Points   February 2005   Note that Internet Drafts should not include a specific value of a   code point until this value has been formally allocated by IANA.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.   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 (seesection 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.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 insection3.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).Kompella & Zinin         Best Current Practice                  [Page 4]

RFC 4020        Early Allocation of Standard Code Points   February 2005   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.4.  IANA Considerations   This document defines procedures for early allocation of code points   in the registries with the Standards Action policy and as such   directly affects IANA functions.5.  Normative References   [2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA          Considerations Section in RFCs",BCP 26,RFC 2434, October          1998.6.  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 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, but they should be subject to   scrutiny to ensure this.7.  Acknowledgements   Many thanks to Bert Wijnen, Adrian Farrel, and Bill Fenner for their   input.Kompella & Zinin         Best Current Practice                  [Page 5]

RFC 4020        Early Allocation of Standard Code Points   February 2005Authors' Addresses   Kireeti Kompella   Juniper Networks   1194 N. Mathilda Ave   Sunnyvale, CA 94089 USA   EMail:  kireeti@juniper.net   Alex Zinin   Alcatel   701 E Middlefield Rd   Mountain View, CA 94043   EMail: zinin@psg.comKompella & Zinin         Best Current Practice                  [Page 6]

RFC 4020        Early Allocation of Standard Code Points   February 2005Full Copyright Statement   Copyright (C) The Internet Society (2005).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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-   ipr@ietf.org.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Kompella & Zinin         Best Current Practice                  [Page 7]