INTERNET-DRAFT Danny McPherson, Ed. Geoff Huston, Ed. Internet Architecture Board Expires: April 2009 October 2008 Intended Status: Best Current Practice Defining the Role and Function of IETF Protocol Parameter Registry Operators 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The IETF Trust (2008). McPherson, Huston [Page 1] INTERNET-DRAFT Expires: April 2009 October 2008 Abstract Many IETF protocols make use of commonly defined values that are passed within protocol objects. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intent. For each IETF protocol parameter it is current practice for the IETF to delegate the role of protocol parameter registry operator to a nominated entity. This document provides a description of and the requirements for these delegated functions. McPherson, Huston [Page 2] INTERNET-DRAFT Expires: April 2009 October 2008 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of an IETF Protocol Parameter Registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Publication of Protocol Parameter Registry Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. The Procedures related to IETF Protocol Parameter Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. The Operation of IETF Protocol Parameter Reg- istries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Current IETF Protocol Parameter Assignments . . . . . . . . . 7 7. Roles and Responsibilities concerning IETF Proto- col Registries. . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Protocol Parameter Registry Operator Role . . . . . . . . . 8 7.3. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.5. Role of the IETF Trust. . . . . . . . . . . . . . . . . . . 12 8. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14 14. Appendix A: IAB Members . . . . . . . . . . . . . . . . . . . 15 McPherson, Huston [Page 3] INTERNET-DRAFT Expires: April 2009 October 2008 1. Overview Many IETF protocols make use of commonly defined values that are passed within protocol objects. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registries to record each of the possible values of a protocol parameter and their associated semantic intent. The document describes the function of these registries as they apply to individual protocol parameters defined by the IETF Internet Standards Process [RFC 2026]. At the time of writing this document (October 2008) the operation of the majority of the protocol parameter registries is delegated to the Internet Corporation for Assigned Names and Numbers (ICANN) according to the terms and conditions described in RFC 2860 [RFC 2860] and supplements developed thereafter. Not all IETF protocol parameter registries are delegated to ICANN, and at present the operation of the 'e164.arpa' registry has been delegated to the RIPE Network Coordination Center (RIPE NCC) [RIPE NCC]. The term "Internet Assigned Numbers Authority" (IANA), has been used historically to refer to the entire collection of protocol parameter registries. It is noted that there is current general use of this term to refer specifically to the set of registries operated by ICANN under terms of this delegation of function. While IETF documents continue to use the term "IANA Considerations" when referring to specific functions to be performed with respect to a protocol parameter registry [RFC 5226], it is noted that the use of the term 'IANA' in this context does not necessarily imply the delegation of the parameter registry operation to the body managed by ICANN. This IETF - IANA organizational separation is one that appears to be a relatively unique arrangement in the context of standards development organizations (SDOs), and similar arrangements of structural separation are not generally used by SDOs. Other SDOs that undertake a similar protocol parameter registration function generally do so as part of their secretariat service functions or their equivalent, thereby avoiding the overheads of detailed coordination of activity across multiple distinct organizations. However, as already noted, this structural separation of roles exists within several places in the IETF framework (e.g., to include the RFC Editor function) and the IETF has the responsibility to define and manage the relationship with the IANA role. This IETF responsibility includes the selection and management of the protocol parameter registry operator(s), as well as management of the parameter registration process and the guidelines for parameter allocation. McPherson, Huston Section 1. [Page 4] INTERNET-DRAFT Expires: April 2009 October 2008 Furthermore, as with other SDO's, the IETF asserts full authority over the management of all the IETF protocol parameter registries. 2. Definition of an IETF Protocol Parameter Registry Using the term 'IANA' in the sense of the entire set of IETF protocol parameter registries, the Internet Standards document, STD 2, published in October 1994, defined the role of the IANA as follows: The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols. The IANA is chartered by the Internet Society (ISOC) and the Federal Network Council (FNC) to act as the clearinghouse to assign and coordinate the use of numerous Internet protocol parameters. The Internet protocol suite, as defined by the Internet Engineering Task Force (IETF) and its steering group (the IESG), contains numerous parameters, such as Internet protocol addresses, domain names, autonomous system numbers (used in some routing protocols), protocol numbers, port numbers, management information base object identifiers, including private enterprise numbers, and many others. The common use of the Internet protocols by the Internet community requires that the particular values used in these parameter fields be assigned uniquely. It is the task of the IANA to make those unique assignments as requested and to maintain a registry of the currently assigned values [RFC 1700]. Again using the term 'IANA' in the sense of the entire set of IETF protocol parameter registries, the definition of the protocol parameter registry role is provided in [RFC 5226]: Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). McPherson, Huston Section 2. [Page 5] INTERNET-DRAFT Expires: April 2009 October 2008 3. Publication of Protocol Parameter Registry Assignments The current mode of publication of protocol parameter registry assignments undertaken within registries whose operation is currently delegated to ICANN is described in the Informational Document [RFC 3232], published in January 2002: From November 1977 through October 1994, the Internet Assigned Numbers Authority (IANA) periodically published tables of the Internet protocol parameter assignments in RFCs entitled, "Assigned Numbers". The most current of these Assigned Numbers RFCs had Standard status and carried the designation: STD 2. At this time, the latest STD 2 is RFC 1700. Since 1994, this sequence of RFCs have been replaced by an online database accessible through a web page (currently, www.iana.org). The purpose of the present RFC is to note this fact and to officially obsolete RFC 1700, whose status changes to Historic. RFC 1700 is obsolete, and its values are incomplete and in some cases may be wrong [RFC 3232]. The mode of publication of the e164.arpa protocol parameter registry operated by the RIPE NCC is documented in reference [RIPE ENUM]. 4. The Procedures related to IETF Protocol Parameter Management IETF Protocol Parameter registry actions are defined through the inclusion of an "IANA Considerations" section in Internet Standards documents, as described in [RFC 5226]. There are also RFCs that specifically address IETF protocol parameter considerations for particular protocols, such as [RFC 2780], [RFC 2939], and [RFC 2978]. 5. The Operation of IETF Protocol Parameter Registries As documented in the IAB Charter [RFC 2850], the role of the Internet Architecture Board includes responsibility for the IETF Protocol Parameter registration function (referred to in the charter as 'IANA'). The IAB, acting on behalf of the IETF, approves the McPherson, Huston Section 5. [Page 6] INTERNET-DRAFT Expires: April 2009 October 2008 appointment of an organization to act as a protocol parameter registry operator on behalf of the IETF, and also approves the terms and conditions of this delegation of this function. The technical direction of the IETF Protocol Parameter registry function is provided by the Internet Engineering Steering Group (IESG) [RFC 2850]. 6. Current IETF Protocol Parameter Assignments The list of current IETF protocol parameters for which parameter value assignments are registered within registries whose operation is currently delegated to ICANN is listed in reference [IANA]. In addition there is the e164.arpa registry function, which is listed in reference [RIPE ENUM]. As provided in the list list contained in [IANA], those protocol parameter registries that refer to registrations related to the allocation of public unicast IPv4 addresses, public unicast IPv6 addresses, public use Autonomous System Numbers (ASNs) and the top level delegations within the Domain Name System, have associated registration mechanisms that have been delegated to the IANA function operated under the auspices of ICANN, as defined in [RFC 2860]. In these cases other bodies are responsible for the development of policies to manage the registrations of allocations performed as part this aspect of the registration function. Registrations that refer to reservations (e.g., IP address blocks for documentation purposes or ASNs defined for documentation purposes) and all other use cases within those registries must be prescribed by the IETF. 7. Roles and Responsibilities concerning IETF Protocol Registries This section describes the operation and role of a delegated IETF Protocol Parameter Registry Operator, to be selected and administered by the IETF Administrative Support Activity (IASA) [RFC 4071]. This section also includes a description of the roles of related bodies with reference to this function. This generic description is being provided for clarity, in order to document the protocol parameter registry administrative function that has evolved over time as intrinsic aspects of the IANA culture. McPherson, Huston Section 7. [Page 7] INTERNET-DRAFT Expires: April 2009 October 2008 7.1. Introduction Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by a delegated Protocol Parameter Registry operator. For any particular protocol parameter there is a single delegated registry operator. 7.2. Protocol Parameter Registry Operator Role A IETF Protocol Parameter registry function is undertaken under the auspices of the Internet Architecture Board. The roles of the Protocol Parameter registry operator are as follows: o Review and Advise * The registry operator may be requested to review Internet-Drafts that are being considered by the Internet Engineering Task Force Steering Group (IESG), with the objective of offering advice to the IESG regarding the need for an "IANA Considerations" section, whether such a section, when required, is clear in terms of direction to the registry operator and whether the section is consistent with the current published registry operator guidelines. o Registry * To operate a registry of protocol parameter assignments. * The delegated registry operator registers values for Internet protocol parameters only as directed by the criteria and procedures specified in RFCs, including Proposed, Draft and full Internet Standards, Best Current Practice documents, and other RFCs that call for protocol parameter assignment, and only for those protocol parameters specified by the IETF. If they are not so specified, or in case of ambiguity, the registry operator will continue to McPherson, Huston Section 7.2. [Page 8] INTERNET-DRAFT Expires: April 2009 October 2008 assign and register only those protocol parameters that have already been delegated to the operator, following past and current practice for such assignments, unless otherwise directed in terms of operating practice by the IESG. In the case of the current IANA operation, requirements are provided in the MoU with ICANN [RFC 2860] and associated supplements outlining service level agreements for IETF protocol parameter registry functions. * For each protocol parameter, the associated registry includes: + a reference to the RFC document that describes the parameter and the associated "IANA Considerations" concerning the parameter, and + for each registration of a protocol parameter value, the source of the registration and the date of the registration, if the date of registration is known. * If in doubt or in case of a technical dispute, the registry operator will seek and follow technical guidance exclusively from the IESG. Where appropriate the IESG will appoint an expert to advise the registry operator. * The registry operator will work with the IETF to develop any missing criteria and procedures over time, which the registry operator will adopt when so instructed by the IESG. * Each protocol parameter registry operates as a public registry, and the contents of the registry are openly available to the public, on-line and free of charge. Any related intellectual property rights associated with the registry and its contents are held by the IETF Trust [RFC 4748]. * The registry operator assigns protocol parameter values in accordance with the policy associated with the protocol parameter. Some policies are listed in [RFC 5226]. o Mailing Lists * The registry operator maintains public mailing lists as specified in IANA Considerations [RFC 5226]. Such lists are designated for the purpose of review of assignment proposals in conjunction with a designated expert review function. In addition, each protocol parameter registry operator should maintain a mailing list that enables the registry staff of each registry operator to be contacted by email. For example, McPherson, Huston Section 7.2. [Page 9] INTERNET-DRAFT Expires: April 2009 October 2008 iana@iana.org currently provides this function for IANA. o Liaison Activity * The registry operator will nominate a liaison point of contact. The registry operator, though this liaison, may be requested to provide advice to the IESG on IETF protocol parameters as well as the IANA Considerations section of Internet-drafts that are being reviewed for publication as an RFC. Where appropriate the IESG will appoint an expert to advise IANA. o Reporting * The registry operator will submit periodic reports to the IAB concerning the operational performance of the registry function. As an exmaple of the requirements for such reports the reader is referred to a supplement to the MoU outlined in [RFC 2860], which was established by the IASA [RFC 4071] and provides SLA guidelines under which IANA, as implemented by ICANN, must operate. * At the request of the chair of the IETF, the registry operator will undertake periodic reports to the IETF Plenary concerning the status of the registry function. * The registry operator will publish an annual report describing the status of the function and a summary of performance indicators. o Intellectual Property Rights and the Registry Operator * All assigned values are to be published and made available free of any charges and free of any constraints relating to further redistribution, with the caveat that the assignment information may not be modified in any redistributed copy. * Any intellectual property rights of the IETF Protocol Parameter assignment information, including the IETF Protocol Parameter registry and its contents, are to be held by the IETF Trust [RFC 4748], and all IETF Protocol Parameter registry publications relating to assignment information are to be published under the terms of Section 10 of [RFC 2026], and are to include the copyright notice as documented in Section 10.4 (C) of [RFC 2026]. McPherson, Huston Section 7.2. [Page 10] INTERNET-DRAFT Expires: April 2009 October 2008 7.3. IAB Role An operator of an IETF Protocol Parameter registry undertakes the role as a delegated function under the auspices of the Internet Architecture Board (IAB). The IAB has the responsibility to, from time to time, review the current description of the registry function and direct the registry operator to adopt amendments relating to its role and mode of operation of the registry according to the best interests of the IETF. The IAB has the responsibility to select an organization to undertake the delegated functions of the Protocol Parameter registry for each IETF protocol parameter. The IAB has the responsibility to determine the terms and conditions of this delegated role. Such terms and conditions should ensure that the registry operates in a manner that is fully conformant to the functions described in this document. In addition, such terms and conditions must not restrict the rights and interests of the IETF with respect to the registry function. 7.4. IESG Role The IESG is responsible for the technical direction of the IETF Protocol Parameter registries. Such technical direction is provided through the adoption of IETF RFC documents within the "IANA Considerations" section of such documents, or as stand-alone "IANA Considerations" RFC documents. The IESG shall ensure that the review of Internet-Drafts that are offered for publications as RFCs ensures that IANA Considerations sections are present when needed, and that IANA Considerations sections conform to the current published guidelines. At the discretion of the IESG, the registry operator may be required to designate a non-voting liaison to the IESG to facilitate clear communications and effective operation of the registry function. McPherson, Huston Section 7.4. [Page 11] INTERNET-DRAFT Expires: April 2009 October 2008 7.5. Role of the IETF Trust Any intellectual property rights of IETF Protocol Parameter assignment information, including the registry and its contents, and all registry publications, are to be held by the IETF Trust on behalf of the IETF. The IETF Trust [RFC 4748] was recently formed to act as the administrative custodian of all copyrights and other intellectual property rights relating to the IETF Standards Process that had previously been held by ISOC and the Corporation for National Research Initiatives (CNRI). 8. Miscellaneous Considerations The IESG provides technical guidance for IETF created registries. For registries created by non-IETF stream documents the policies set by the IESG apply unless there are solid arguments to follow a different policy in which case the IAB has the final word. 9. Acknowledgements This document is adapted from [RFC 5226], and has been modified to include explicit reference to Intellectual Property Rights, and the roles of the IAB and IESG in relation to the IETF Protocol Parameter registry function. The Internet Architecture Board acknowledges the assistance provided by reviewers of earlier drafts of this document, including Scott Bradner, Leslie Daigle and Thomas Narten. 10. Security Considerations This document does not propose any new protocols, and therefore does not involve any security considerations in that sense. McPherson, Huston Section 10. [Page 12] INTERNET-DRAFT Expires: April 2009 October 2008 11. IANA Considerations This document requires no direct IANA actions. 12. References 12.1. Normative References 12.2. Informative References [RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, STD 2, October 1994. [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [RFC 2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", RFC 2780, BCP 37, March 2000. [RFC 2850] Carpenter, B., "Charter of the Internet Architecture Board", RFC 2850, BCP 39, May 2000. [RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC 2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", RFC 2939, BCP 43, September 2000. [RFC 2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", RFC 2978, BCP 19, October 2000. [RFC 3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. McPherson, Huston Section 12.2. [Page 13] INTERNET-DRAFT Expires: April 2009 October 2008 [RFC 4071] Austein, R., Wijnen, B., "Structure of the IETF Administrative Support Activity (IASA)", RFC 4071, April 2005. [RFC 4748] Bradner, S., "RFC 3978 Update to Recognize the IETF Trust", RFC 4748, BCP 78, October 2006. [RFC 5226] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. [IANA] Reynolds, J., "IANA Protocol Numbers and Assignment Services", October 1994, . [CORR] Dyson, E., "Correspondence from Esther Dyson, Interim Chairman, ICANN to Scott Bradner, Brian Carpenter and Fred Baker of the IETF", February 1999, . [RIPE NCC] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC", September 2002, . [RIPE ENUM] RIPE NCC, "ENUM Registry", September 2002, . 13. Authors' Addresses Danny McPherson, Editor Arbor Networks, Inc. Email: danny@arbor.net Geoff Huston, Editor APNIC Email: gih@apnic.net Internet Architecture Board Email: iab@iab.org McPherson, Huston Section 13. [Page 14] INTERNET-DRAFT Expires: April 2009 October 2008 14. Appendix A: IAB Members Internet Architecture Board Members at the time this document was published were: Loa Andersson Gonzalo Camarillo Stuart Cheshire Aaron Falk Russ Housley Olaf Kolkman Gregory Lebovitz Barry Leiba Kurtis Lindqvist Andrew Malis Danny McPherson David Oran Dave Thaler Lixia Zhang 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. Copyright Statement McPherson, Huston Section 14. [Page 15] INTERNET-DRAFT Expires: April 2009 October 2008 Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). McPherson, Huston Section 14. [Page 16]