INTERNET-DRAFT Danny McPherson, Ed. Geoff Huston, Ed. Olaf M. Kolkman, Ed. Internet Architecture Board Expires: August 2011 February 9, 2011 Intended Status: Best Current Practice Defining the Role and Function of IETF Protocol Parameter Registry Operators Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as McPherson, Huston, Kolkman [Page 1] INTERNET-DRAFT Expires: August 2011 February 2011 described in the Simplified BSD License. Abstract Many IETF protocols make use of commonly-defined values that are passed in messages or packets. 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, Kolkman [Page 2] INTERNET-DRAFT Expires: August 2011 February 2011 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Roles and Responsibilities Concerning IETF Proto- col Parameter Registries. . . . . . . . . . . . . . . . . . . . . 5 2.1. Protocol Parameter Registry Operator Role . . . . . . . . . 5 2.2. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Role of the IETF Trust. . . . . . . . . . . . . . . . . . . 9 2.5. Role of the IAOC. . . . . . . . . . . . . . . . . . . . . . 10 3. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 10 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References. . . . . . . . . . . . . . . . . . . 11 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 9. Appendix A: Considerations on the term IANA. . . . . . . . . . 13 10. Appendix B: IANA registries in context. . . . . . . . . . . . 15 10.1. Definition of an IETF Protocol Parameter Reg- istry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.2. Publication of Protocol Parameter Registry Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.3. Procedures Related to IETF Protocol Parameter Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.4. Registries for IETF Protocol Parameters. . . . . . . . . . 17 10.5. Current IETF Protocol Parameter Assignments. . . . . . . . 17 11. Appendix C: IAB Members . . . . . . . . . . . . . . . . . . . 18 McPherson, Huston, Kolkman [Page 3] INTERNET-DRAFT Expires: August 2011 February 2011 1. Overview Many IETF protocols make use of commonly-defined values that are passed within messages or packets. 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. These registries, their registration policy, and the layout of their content are defined in the so called "IANA Consideration" sections of IETF documents. The organizational separation between the IETF and its registry operators 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 other SDOs. 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, this structural separation of roles exists within several places in the IETF framework (e.g., the RFC Editor function) and the Internet Architecture Board (IAB), on behalf of the IETF, has the responsibility to define and manage the relationship with the protocol registry operator role. This responsibility includes the selection and management of the protocol parameter registry operator, as well as management of the parameter registration process and the guidelines for parameter allocation. As with other SDOs, the IETF asserts full authority over the management of all its protocol parameters and their registries. This document describes the function of these registries as they apply to individual protocol parameters defined by the IETF Internet Standards Process [RFC2026] as to allow for an orderly implementation by the Internet Administrative Oversight Committee (IAOC) under guidance from the IAB. Below we provide a description of the requirement for these delegated functions, which the IETF traditionally refers to as the Internet Assigned Numbers Authority (IANA) function. McPherson, Huston, Kolkman Section 1. [Page 4] INTERNET-DRAFT Expires: August 2011 February 2011 2. Roles and Responsibilities Concerning IETF Protocol Parameter Registries The IETF's longstanding practice is to outsource the management and implementation of some important functions (e.g., [RFC5620]). The protocol parameter registry function falls into this category of outsourced functions, and what follows here the comprehensive and normative description of the roles and responsibilities with respect to the registration of IETF protocol parameters. Specifically, this document 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) [RFC4071]. While there is generally a single Protocol Parameter Registry Operator, additional Operators may be selected to implement specific registries. This document also includes a description of the roles of other bodies that interact with IETF protocol parameter registry operators. 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 ensure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority in a mechanical manner. 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. In the case of IP addresses and AS numbers, the IANA function resides at the root of the number space, and a subsequent allocation hierarchy exists below IANA. The next step in the hierarchy below IANA is the Regional Internet Registries (RIR), which make further allocations of those resources using policies established through the RIRs' bottom- up policy development process. 2.1. Protocol Parameter Registry Operator Role The IETF Protocol Parameter registry function is undertaken under the auspices of the Internet Architecture Board. The roles of a Protocol Parameter registry operator are as follows: McPherson, Huston, Kolkman Section 2.1. [Page 5] INTERNET-DRAFT Expires: August 2011 February 2011 o Review and Advise * A registry operator may be requested to review Internet-Drafts that are being considered by the Internet Engineering Steering Group (IESG), with the objective of offering advice to the IESG regarding the contents of the "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 require protocol parameter assignment. If values for Internet protocol parameters were not specified, or in case of ambiguity, the registry operator will continue to 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 ambiguity, the registry operator is expected to express the ambiguity and either suggest better text or ask the appropriate parties for clarification. * 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 McPherson, Huston, Kolkman Section 2.1. [Page 6] INTERNET-DRAFT Expires: August 2011 February 2011 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. * The registry operator assigns protocol parameter values in accordance with the policy associated with the protocol parameter, such as "First Come First Served" or "Expert Review" [RFC5226]. o Mailing Lists * The registry operator maintains public mailing lists as specified in IANA Considerations [RFC5226]. 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 the registry operator to be contacted by email. For example, 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, through 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 the registry operator. o Reporting * The registry operator will submit periodic reports to the IAB concerning the operational performance of the registry function. As an example of the requirements for such reports the reader is referred to a supplement to the "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority" [RFC2860] that was established by the IETF Administrative Support Activity (IASA) [RFC4071] and provides service level agreement (SLA) guidelines under which the protocol parameter registry, as implemented by ICANN, must operate. * At the request of the chair of the IETF, IAB, or IAOC the McPherson, Huston, Kolkman Section 2.1. [Page 7] INTERNET-DRAFT Expires: August 2011 February 2011 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. * The assignment values may be redistributed without modification. * 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 [RFC4748]. 2.2. IAB Role An operator of an IETF Protocol Parameter registry undertakes the role as a delegated function under the authority of the 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, and the Internet community in general. The IAB has the responsibility to appoint an organization to undertake the delegated functions of the Protocol Parameter registry operator for each IETF protocol parameter. Specifically, the IAB defines the role and requirements for the desired functions (e.g., as with the "RFC Editor Model" [RFC5620], and the IAB, the IAOC is responsible for identifying a potential vendor, and once under agreement managing the various aspects of the relationships with that vendor. To be clear, the IAB is in the deciding role (e.g., for appointment and termination), but must work in close consultation with the IAOC. 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 conforment to the functions described in this document. In addition, such terms and McPherson, Huston, Kolkman Section 2.2. [Page 8] INTERNET-DRAFT Expires: August 2011 February 2011 conditions must not restrict the rights and interests of the IETF with respect to the registry contents and maintenance. 2.3. IESG Role The IESG is responsible for the technical direction regarding entries into IETF Protocol Parameter registries and maintaining the policies by which such technical directions are given (e.g., see Appendix B). Technical direction itself is provided through the adoption of directives within the "IANA Considerations" section of IETF RFC documents, or through stand-alone "IANA Considerations" RFC documents. The IESG shall verify that Internet-Drafts that are offered for publication as IETF-stream RFCs [RFC4844] include IANA Considerations sections when needed, and that IANA Considerations sections conform to the current published guidelines. Since technical assessment is not a responsibility of the registry operator the IESG is, as part of providing the technical direction, responsible for identifying the technical experts that are required to, where appropriate, review registration requests or resolve open technical questions that relate to the registration of parameters. The IESG will at its discretion organize the liaison activities with the registry operator's liaison point of contact as to facilitate clear communications and effective operation of the registry function. 2.4. Role of the IETF Trust The IETF Trust [RFC4748] was formed to act as the administrative custodian of all copyrights and other intellectual property rights relating to the IETF Standards Process, a function that had previously been performed by ISOC and the Corporation for National Research Initiatives (CNRI). 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. McPherson, Huston, Kolkman Section 2.4. [Page 9] INTERNET-DRAFT Expires: August 2011 February 2011 The IETF Trust may make such regulations as appropriate for the assignment values redistribution and registry publications. 2.5. Role of the IAOC The IAOC is responsible for identifying a potential vendor in a manner of their choosing based on IAB consultation, and managing the various aspects of the relationships with that vendor. In addition, the IAOC has the responsibility to ensure long-term access, stability, and uniqueness across all such registries . This responsibility is of particular significance in the event that a relation with a protocol parameter registry operator is terminated. 3. Miscellaneous Considerations The IESG is responsible for the technical direction of the IETF Protocol Parameter registries and maintaining the policies by which such technical directions are given. The IESG is responsible, as part of the document approval process for the IETF-stream RFCs [RFC4844], for 'IANA Considerations' verification. For the other RFC streams the approval bodies are responsible for verifying that the documents include IANA Considerations sections when needed, and that IANA Considerations sections conform to the current published guidelines. In the case the that IANA considerations in non-IETF document streams lead to a dispute the IAB has the final word. 4. Acknowledgements This document is adapted from "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], 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 McPherson, Huston, Kolkman Section 4. [Page 10] INTERNET-DRAFT Expires: August 2011 February 2011 by reviewers of earlier drafts of this document, including Scott Bradner, Leslie Daigle, Thomas Narten, Ray Pelletier, and Alfred Hoenes. 5. Security Considerations This document does not propose any new protocols, and does not introduce any new security considerations. 6. IANA Considerations This document requires no direct IANA actions in terms of the creation or operation of a protocol parameter registry. However, this document does define the roles and responsibilities of various bodies who are responsible for, and associated with, the operation of the protocol parameter registration functions for the IETF. 7. References 7.1. Normative References 7.2. Informative References [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, STD 2, October 1994. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", RFC 2780, BCP 37, March 2000. McPherson, Huston, Kolkman Section 7.2. [Page 11] INTERNET-DRAFT Expires: August 2011 February 2011 [RFC2850] Carpenter, B., "Charter of the Internet Architecture Board", RFC 2850, BCP 39, May 2000. [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", RFC 2939, BCP 43, September 2000. [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", RFC 2978, BCP 19, October 2000. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC4071] Austein, R., Wijnen, B., "Structure of the IETF Administrative Support Activity (IASA)", RFC 4071, April 2005. [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF Trust", RFC 4748, BCP 78, October 2006. [RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC Editor", RFC 4844, July 2007. [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. [RFC5620] Kolkman, O., IAB, "RFC Editor Model (Version 1)", RFC 5620, August 2009. [IANA] Reynolds, J., "IANA Protocol Numbers and Assignment Services", October 1994, . [IAOC_SUPP] ICANN/IANA-IETF MoU Supplemental Agreement [CORR] Dyson, E., "Correspondence from Esther Dyson, Interim Chairman, ICANN to Scott Bradner, Brian Carpenter and Fred Baker of the IETF", February 1999, McPherson, Huston, Kolkman Section 7.2. [Page 12] INTERNET-DRAFT Expires: August 2011 February 2011 . [ENUM_INSTR] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC", September 2002, . [RIPE_ENUM] RIPE NCC, "ENUM Registry", September 2002, . 8. Authors' Addresses Danny McPherson, Editor Verisign, Inc. Email: dmcpherson@verisign.com Geoff Huston, Editor APNIC Email: gih@apnic.net Olaf M. Kolkman, Editor NLnet Labs Email: olaf@NLnetLabs.nl Internet Architecture Board Email: iab@iab.org 9. Appendix A: Considerations on the term IANA The term "Internet Assigned Numbers Authority (IANA)" has been used historically in different contexts. Specifically: 1) "IANA" has commonly referred to the set of protocol, DNS, and Address registry functions currently operated by ICANN: It is noted that there is current general use of the term "IANA" or "IANA function" to refer specifically to the set of McPherson, Huston, Kolkman Section 9. [Page 13] INTERNET-DRAFT Expires: August 2011 February 2011 registries currently operated by ICANN funded through a contract [DoC_IANA] between ICANN and the U.S. Government's National Telecommunications and Information Administration (NTIA). 2) Within the IETF context "IANA" has been referred to as the set of registry operators of the IETF protocol parameters: At the time of writing this document (February 2011) the operation of the majority of the protocol parameter registries are delegated to the Internet Corporation for Assigned Names and Numbers (ICANN). 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) [ENUM_INSTR]. 3) Additionally, and also within IETF context, "IANA" has been referred to as the entire set of IETF protocol parameter registries: IETF specifications continue to use the term "IANA Considerations" when referring to specific functions to be performed with respect to a protocol parameter registry, as provided in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. 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 functions operated by ICANN. In addition to the multiple contexts of the use of the term "IANA", the structure and association of the U.S. Government's contractual relationship with ICANN over the performance of a protocol parameter registry operation that is commonly known as the "IANA" role, is a source of some common confusion regarding the question as to who maintains ultimate authority over the protocol parameter registries themselves. ICANN undertakes these "mechanical" tasks on behalf of the IETF at the discretion of the IAB, as defined in the Memorandum of Understanding [RFC2860] between the IETF Administrative Support Activity (IASA) and ICANN, and in supplements [IAOC_SUPP] provided thereafter. McPherson, Huston, Kolkman Section 9. [Page 14] INTERNET-DRAFT Expires: August 2011 February 2011 10. Appendix B: IANA registries in context 10.1. 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 [RFC1700], 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 [RFC1700]. 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 "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]: 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, Kolkman Section 10.1. [Page 15] INTERNET-DRAFT Expires: August 2011 February 2011 This text appears to confuse two of the three (1 and 3) contexts presented in Appendix A with which the "IANA" term is used. 10.2. Publication of Protocol Parameter Registry Assignments Currently there are two registry operators that publicize protocol parameter registry assignments: the IANA registry as operated by ICANN, and the RIPE NCC. 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 "Assigned Numbers: RFC 1700 is Replaced by an On-line Database" [RFC3232], 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 [RFC3232]. The mode of publication of the e164.arpa protocol parameter registry operated by the RIPE NCC is documented in the ENUM Registry [RIPE_ENUM]. 10.3. Procedures Related to IETF Protocol Parameter Management IETF Protocol Parameter registry actions are defined through the inclusion of an "IANA Considerations" section in IESG-approved RFC documents [RFC5226]. Within these considerations the IETF defines the policies through which a registry operator manages assignments McPherson, Huston, Kolkman Section 10.3. [Page 16] INTERNET-DRAFT Expires: August 2011 February 2011 within the registry. There are also RFCs that specifically address IETF protocol parameter considerations for particular protocols [RFC2780][RFC2939] [RFC2978]. 10.4. Registries for IETF Protocol Parameters As documented in the IAB Charter [RFC2850], the role of the IAB 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 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) [RFC2850]. 10.5. 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 appears on the IANA web site [IANA]. In addition there is the e164.arpa registry function [RIPE_ENUM]. 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 currently operated under the auspices of ICANN [RFC2860]. In these cases other bodies are responsible for the development of policies to manage the registrations of allocations performed as part of 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 performed under the exclusive direction of the IETF. McPherson, Huston, Kolkman Section 10.5. [Page 17] INTERNET-DRAFT Expires: August 2011 February 2011 11. Appendix C: IAB Members Internet Architecture Board Members at the time this document was published were: Marcelo Bagnulo Gonzalo Camarillo Stuart Cheshire Vijay Gill Russ Housley John Klensin Olaf Kolkman Gregory Lebovitz Andrew Malis Danny McPherson David Oran Jon Peterson Dave Thaler McPherson, Huston, Kolkman Section 11. [Page 18]