|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
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 March 1, 2004.
Copyright (C) The Internet Society (2003). All Rights Reserved.
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 a registry function 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 describes a description of this delegated function.
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 a registry to register each of the possible values of a protocol parameter and their associated semantic intent. The document describes this registry function as it applies to individual protocol parameters defined by the IETF Internet Standards Process [1]Bradner, S., The Internet Standards Process -- Revision 3, October 1996..
At the time of writing this document (June 2003) 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 [2]Carpenter, B., Baker, F. and M. Roberts, Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority, June 2000.. 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) [12]IAB, ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC, September 2002..
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 [4]Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, October 1998., it is noted that the use of the term 'IANA' in this context does not necessarily imply the delegation to ICANN of the associated role of operation of the protocol parameter registry for the particular protocol parameter so described.
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. [3]Reynolds, J. and J. Postel, Assigned Numbers, October 1994.
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 BCP 26:
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 the Internet Assigned Numbers Authority (IANA). [4]Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, October 1998.
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 [5]Reynolds, J., Assigned Numbers: RFC 1700 is Replaced by an On-line Database, January 2002., 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. [5]Reynolds, J., Assigned Numbers: RFC 1700 is Replaced by an On-line Database, January 2002.
The mode of publication of the e164.arpa protocol parameter registry operated by the RIPE NCC is documented in reference [13]RIPE NCC, ENUM Registry, September 2002..
IETF Protocol Parameter registry actions are defined through the inclusion of an "IANA Considerations" section in Internet Standards documents, as described in RFC 2434 [4]Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, October 1998.. There are also RFCs that specifically address IETF protocol parameter considerations for particular protocols, such as RFC 2780 [6]Bradner, S. and V. Paxson, IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers, March 2000., RFC 2939 [7]Droms, R., Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types, September 2000., and RFC 2978 [8]Freed, N. and J. Postel, IANA Charset Registration Procedures, October 2000..
As documented in the IAB Charter [9]Carpenter, B., Charter of the Internet Architecture Board, May 2000., 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 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) [9]Carpenter, B., Charter of the Internet Architecture Board, May 2000..
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 [10]Reynolds, J., IANA Protocol Numbers and Assignment Services, October 1994.. In addition there is the e164.arpa registry function, which is listed in reference [13]RIPE NCC, ENUM Registry, September 2002..
With reference to the list contained in reference [10]Reynolds, J., IANA Protocol Numbers and Assignment Services, October 1994., protocol parameter registries that refer to the unicast IPv4 address space, unicast IPv6 address space, Autonomous System Numbers and the top level delegations within the Domain Name System all use allocation mechanisms that have been delegated to the IANA function operated under the auspices of ICANN. Other bodies are responsible for the development of policies to manage this allocation function.
This section describes the operation and role of a delegated IETF Protocol Parameter Registry Operator. This section also includes a description of the roles of related bodies with reference to this function.
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.
A IETF Protocol Parameter registry function is undertaken under the auspices of the Internet Architecture Board (IAB).
The roles of the Protocol Parameter registry operator are as follows:
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.
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.
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 Internet Society on behalf of the IETF.
This document is adapted from RFC2434 [4]Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, October 1998., 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.
This document does not propose any new protocols, and therefore does not involve any security considerations in that sense.
| Geoff Huston, Editor. | |
| Internet Architecture Board |
Internet Architecture Board Members at the time this document was published were:
Bernard Aboba
Harald Alvestrand
Rob Austein
Leslie Daigle, Chair
Patrik Faltstrom
Sally Floyd
Jun-ichiro Itojun Hagino
Mark Handley
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Michael StJohns
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Funding for the RFC Editor function is currently provided by the Internet Society.