Network Working Group J. Klensin Internet-Draft Expires: December 29, 2005 V. Cerf MCI S. Bradner Harvard University June 27, 2005 Registration Policies for the IETF and IANA draft-klensin-iana-reg-policy-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 29, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract For many years, the IETF has maintained, via the IANA, registries of protocol and parameter names and numbers. The primary purpose of these registries is to ensure that different methods and options are properly identified and distinguished. Registration of such names or numbers generally does not necessarily imply approval of the Klensin, et al. Expires December 29, 2005 [Page 1] Internet-Draft Registration Policies June 2005 technology in the corresponding protocol. Instead, registration represents the desire to keep distinct options identified, separated, and public to avoid conflicts in use. In recent years, various changes in the nature of the instructions given to the IANA, increased perceptions of scarcity in the number spaces associated with some of the parameters, and other issues have led to a shift in emphasis from "registration to keep identifiers unique" toward evaluations of the quality of proposals of and preferences among protocols. This document argues that shift is undesirable. It articulates and clarifies the principles that the reasons for evaluation of registration requests is to ensure a minimum quality of definition, that any assertions of scarcity to restrict registrations must be accompanied by a plan for eliminating the scarcity problem, and that, if such a plan is not possible, to establish criteria for making decisions that are as specific and objective as possible. This document is intended to update the general considerations of RFC 2434, the specific allocation rules of RFC 2780, and the evaluation criteria associated with other documents that condition an IANA registration on Expert Review with IESG oversight or on IESG or IETF action. [[NOTE IN DRAFT: The length of this abstract exceeds the RFC Editor's recommended limits. It will be shortened in future versions, but the longer one is believed to be helpful for I-D announcements, etc.]] Klensin, et al. Expires December 29, 2005 [Page 2] Internet-Draft Registration Policies June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Registration Principle: Clarity of Definition . . . . . . . 6 3. Registration Principle: Allocating Scarcity . . . . . . . . 6 3.1 Scarcity in Parameter Spaces . . . . . . . . . . . . . . . 6 3.2 Scaling and Scarcity Reduction . . . . . . . . . . . . . . 7 4. Multiple category or arc registrations . . . . . . . . . . . 7 5. Interpretation of Requirements for IESG Review or Standards Action . . . . . . . . . . . . . . . . . . . . . . 8 6. Internationalization Considerations . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 8. Security considerations . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1 Normative References . . . . . . . . . . . . . . . . . . 9 10.2 Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . 12 Klensin, et al. Expires December 29, 2005 [Page 3] Internet-Draft Registration Policies June 2005 1. Introduction For many years, the IETF has maintained, via the IANA registries of protocol and parameter names and numbers. The original purpose of these registries was to ensure that different methods and options are properly identified and distinguished. Registration did not imply approval of the technology in the corresponding protocol. Instead, registration represented only the desire to keep distinct options identified, separated, and public to avoid conflicts. In recent years, the previous very general instructions to the IANA about registrations have been superceded by the inclusion of specific instructions in RFCs that define IETF protocols. These instructions have included rules for the establishment of the relevant registries themselves and details on how requests should be submitted, and new values defined, for any paramaters defined by the RFC. In addition a number of RFCs have been produced to provide instructions for IETF protocols that were defined before such instructions began to be included. Examples of those RFCs of registration instructions include [RFC2780], [RFC2939], [RFC3171], [RFC3228], [RFC3383], [RFC3438], [RFC3474], [RFC3475], [RFC3476], [RFC3575], [RFC3737], [RFC3818], [RFC3968], and [RFC3969]. These instructions, coupled with increased perceptions of scarcity in the number spaces associated with some parameters, have led to a shift in emphasis from "registration to keep identifiers unique" and toward evaluations of the quality of proposals and preferences about protocol design. The distinction between requiring clarity and lack of obvious conflict in a registration and blocking on unless the quality of the underlying protocol was adequate was, in retrospect, further muddied by [RFC2434] (which describes elements of the registration model) in different places, as o "To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority." (abstract, repeated in first paragraph of section 1) o "... preferred way of insuring review, and is particularly important if any potential interoperability issues can arise. [...] A new option may define fields that need to be parsed and acted on, which (if specified poorly) may not fit cleanly with the architecture of other options or the base protocols on which they are built." (section 2) o "Even when the space is essentially unlimited, however, it is usually desirable to have a minimal review to prevent the hoarding of or unnecessary wasting of a space." (section 2) Klensin, et al. Expires December 29, 2005 [Page 4] Internet-Draft Registration Policies June 2005 RFC 2434 was used as the primary guideline for the RFCs listed above that define IANA considerations for particular protocols. All three of the above statements are consistent with other text in RFC 2434, but the intent of the review is left open. In other words, it specifies how a review is to be performed, but not the criteria to be used. The present document argues that the apparent recent shift from "evaluate a registration request for clarity and to avoid interoperability problems" is undesirable and explicitly sets out evaluation principles for registrations. While it may be completely reasonable to require some specific level of approval of a protocol with an associated parameter value, especially when the specification for that allocation explicitly designates IETF approval and endorsement (see Section 4), this should not be used as a justification to require "approval" of registrations in general. For registrations, the principal reasons for review are to ensure adequate quality in the definitions to permit interoperability, to avoid redundant or spurious registrations, and to provide those who request the registrations an opportunity for non-binding IETF community advice on the nature of the parameters being proposed for registration or the protocol elements associated with them. A secondary, but still important, reason involves verification that the proposed protocol does not contain elements that are likely to cause serious harm to the Internet. However, the threshold for rejecting a registration on the basis of "serious harm" should be very high and represent broad and obvious community consensus. This is the case first because there might otherwise be suspicion that a claim of harm was being used to try to block an unpopular protocol or to give a favored one some advantage. Second, from a registration standpoint, the best way to handle a dangerous protocol may be to give it clear and distinct parameter values so its effects can be easily and accurately identified and quarantined. This document articulates and clarifies the principles that (i) the reasons for evaluation of registration requests is to ensure a minimum quality of definition, (ii) any assertion of a danger to the Internet or to the stable operation of other protocols (especially IETF Standards Track ones) must by supported by a public discussion to which all relevant parties can contribute, and (iii) that any assertions of scarcity to restrict registrations MUST be accompanied by a plan for eliminating the scarcity problem or a conclusion, supported by IETF consensus, that it is not possible to do so and a corresponding rationing plan for the remaining space. These principles derive from the assumption that growth and innovation on the Internet continue to be core values of the IETF and the Internet community. In summary, unless the "scarcity" rules of Section 3 apply, this document updates all "IANA registration" documents and "IANA Klensin, et al. Expires December 29, 2005 [Page 5] Internet-Draft Registration Policies June 2005 considerations" sections of documents to clarify the point that registration review is to focus on the issues above, rather than on concerns about, e.g., whether one protocol approach is better than another one. 2. Registration Principle: Clarity of Definition By longstanding IANA tradition, almost all protocol number or parameter registrations must be associated with a description of what the parameter represents. As mentioned in RFC 2434, while those descriptions are normally public, the IETF and IANA have sometimes made provisions for non-public definitions. But, in all cases, the definitions must be sufficiently clear to avoid any interoperability problems. Over the years, IANA has regularly sent registration requests back to the originator for clarification. Today, part of the purpose of review of registration requests in the IETF is to make determinations about whether an appropriate level of clarity has been achieved and about whether the documentation supplied is adequate. 3. Registration Principle: Allocating Scarcity As suggested in section 2 of [RFC2434], the size of a name space in which parameters are to be allocated determines whether care must be taken "to insure that the space doesn't become exhausted". However, that level of care MUST NOT be interpreted or implemented in an attempt to apply a single standard of taste or style to the Internet or otherwise as a mechanism for attempting to suppress innovation. A limited space requires diligent evaluation of requests to avoid spurious or vanity registrations and unnecessary ones, including registrations that are unlikely to ever be used. However, unless extraordinary circumstances arise, such evaluation must be carried out on the assumption that the size of the name space is, and will remain, adequate for all legitimate registrations of values that will be used with the associated protocols. 3.1 Scarcity in Parameter Spaces The size requirements for a particular name space may occasionally be underestimated, creating a requirement to minimize allocations and registrations in that particular name space to avoid a clear danger of running out of the space. If that situation arises for a particular name space, and its existence is confirmed by the IESG after an IETF review and Last Call as described in [RFC2026], then new registrations may be temporarily restricted to those required to meet the needs of IETF protocol development. However, such restrictions MUST NOT be applied without initiation of a plan to eliminate the scarcity, as discussed in the next subsection. Klensin, et al. Expires December 29, 2005 [Page 6] Internet-Draft Registration Policies June 2005 3.2 Scaling and Scarcity Reduction Difficulties with scaling are always a significant risk factor on the Internet, with regard to both protocol design and administrative procedures. When a parameter field is of fixed length, estimates must be made, sometimes under considerable uncertainty and with high costs associated with incremental size, as to how much parameter capacity is needed. If such an estimate is incorrect and a significant danger arises of running out of space, "conservation", i.e., restrictions on registrations or allocations to save space, will delay the date on which no further space is available, but will not eliminate the risk of that occurring. Because of the damaging effects on Internet innovation of rejecting otherwise-legitimate registrations because of name space exhaustion, a decision that a name space is facing a capacity crisis MUST BE made explicitly by the community, as outlined above, and MUST BE associated with a plan to expand the relevant name space unless that is deemed to be infeasible (see below). A plan to expand the name space MAY take the form of chartering a Working Group or creating an IAB workshop to develop a plan within an appropriate time, or other approaches may be used. A determination that the expansion of a name space is infeasible MUST include criteria for making allocations in the balance of the existing space and those criteria must be fair and balanced. The determination of infeasbility and the allocation plan MUST represent the consensus of the IETF community, determined through the same mechanisms used to approve a document as a BCP (see [RFC2026]). It is the explicit intent of this specification that registration requests not be rejected for reasons of name space shortages unless either an effort has been initiated to eliminate the shortage or a formal determination has been made by the community that it is infeasible to do so. 4. Multiple category or arc registrations In a number of cases, registration procedures or protocols have provided for registrations in a number of different categories, where those categories are associated with different levels of requirements for registration but where interoperability may be achieved by the use of any of the categories. Examples of this approach include the distinction between "user" and "system" port numbers most recently described in [RFC2780] and the distinctions among the various registration arcs for media type registrations described in [RFC2048]. A decision by the IESG or other designated party to require that a registration be made in a different arc or subsidiary name space than Klensin, et al. Expires December 29, 2005 [Page 7] Internet-Draft Registration Policies June 2005 was proposed is not to be considered a rejection of the registration request under the terms of this document. 5. Interpretation of Requirements for IESG Review or Standards Action A requirement for IESG approval, Standards Action, or RFC Publication implies that IESG approval is an acceptable alternative to the other two, not an exceptional case unless the requirement contains additional provisions specifying the conditions for IESG review and approval. Because, for reasons discussed above, the action on a registration request SHOULD BE to permit the registration unless special circumstances apply, the IESG MUST NOT deny a registration request for other than reasons of clarity without an IETF Last Call and IETF consensus that the rejection is appropriate for identified reasons consistent with those discussed in this document. If a registration request is denied for any reason, that reason must be stated explicitly and the decision may be appealed under the procedures specified in [RFC2026] or its successor(s). Of course, nothing in this document prevents an applicant from voluntarily withdrawing a registration request should that be deemed appropriate. 6. Internationalization Considerations This document specifies IETF procedures and does not interact with internationalization. 7. IANA Considerations This document specifies IETF and IESG considerations in recommending actions to IANA. It recommends that, when the IETF concludes that the protocol, extension, or option associated with a registration request is problematic or dangerous, the entry in the IANA registry should be annotated to identify the concern and, when appropriate, point to documentation or other materials that will better explain the concern or alternatives that might be less problematic. While this document specifies no particular registry actions for IANA, IANA should be prepared for requests from the IETF to annotate registry entries in that way. 8. Security considerations This document specifies IETF procedures. It should have no direct impact on Internet security. It does, however, firmly advocate the principle that it is preferable for options or extensions that could pose security or operational risks to be throughly documented and carefully identified in preference to hiding them and hoping that they will disappear. Klensin, et al. Expires December 29, 2005 [Page 8] Internet-Draft Registration Policies June 2005 9. Acknowledgements Comments were received on discussion leading to this document, or on a preliminary draft, from Bob Braden, Dave Crocker, Spencer Dawkins, Ned Freed, John Loughney, and others that contributed to text in this document and are greatly appreciated. 10. References 10.1 Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels'", RFC 2119, March 1997. 10.2 Informative References [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000. [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001. [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", BCP 57, RFC 3228, February 2002. [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002. [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Klensin, et al. Expires December 29, 2005 [Page 9] Internet-Draft Registration Policies June 2005 Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002. [RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 3474, March 2003. [RFC3475] Aboul-Magd, O., "Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)", RFC 3475, March 2003. [RFC3476] Rajagopalan, B., "Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling", RFC 3476, March 2003. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. [RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules", RFC 3737, April 2004. [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004. [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004. [RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004. Klensin, et al. Expires December 29, 2005 [Page 10] Internet-Draft Registration Policies June 2005 Authors' Addresses John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john-ietf@jck.com Vinton G. Cerf MCI 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 USA Phone: +1 703 886 1690 Email: vinton.g.cerf@mci.com Scott Bradner Harvard University 29 Oxford St Cambridge, MA 02138 US Phone: +1 617 495 3864 Email: sob@harvard.edu Klensin, et al. Expires December 29, 2005 [Page 11] Internet-Draft Registration Policies June 2005 Intellectual Property Statement 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 procedures with respect to rights in RFC 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-ipr@ietf.org. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin, et al. Expires December 29, 2005 [Page 12]