INTERNET-DRAFT Danny McPherson, Ed.
Geoff Huston, Ed.
Olaf M. Kolkman, Ed.
Internet Architecture Board
Expires: August 2010 February 4, 2010
Intended Status: Best Current Practice
Defining the Role and Function of IETF Protocol
Parameter Registry Operators
<draft-iab-iana-05.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Copyright (c) 2010 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 described in the Simplified BSD
License.
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
McPherson, Huston, Kolkman [Page 1]
INTERNET-DRAFT Expires: August 2010 February 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) (2010) The IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract
Many IETF protocols make use of commonly defined values that are
passed within protocols. To ensure consistent interpretation of
these values by independent implementations, the values and
associated semantic intent must be 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 2010 February 2010
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Roles and Responsibilities concerning IETF Proto-
col Registries. . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Parameter Registry Operator Role . . . . . . . . . 5
2.2. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Role of the IETF Trust. . . . . . . . . . . . . . . . . . . 9
2.5. Role of the IAOC. . . . . . . . . . . . . . . . . . . . . . 9
3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References. . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References. . . . . . . . . . . . . . . . . . . 11
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
9. Appendix A: Considerations on the term IANA. . . . . . . . . . 13
10. Appendix B: IANA registries in context. . . . . . . . . . . . 14
10.1. IETF Protocol Parameter Registry Definition. . . . . . . . 14
10.2. Publication of Protocol Parameter Registry
Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.3. The Procedures related to IETF Protocol
Parameter Management . . . . . . . . . . . . . . . . . . . . . . 16
10.4. Registries for IETF Protocol Parameters. . . . . . . . . . 16
10.5. Current IETF Protocol Parameter
Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Appendix C: IAB Members . . . . . . . . . . . . . . . . . . . 17
McPherson, Huston, Kolkman [Page 3]
INTERNET-DRAFT Expires: August 2010 February 2010
1. Overview
Many IETF protocols make use of commonly defined values that are
exchanged within protocols. To ensure consistent interpretation of
these values by independent implementations, the values and their
semantic intent must be 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 "IANA Considerations" sections of IETF documents.
The organizational separation between the IETF and its registry
operator(s) 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 overhead
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., to include the RFC
Editor function). The IAB, on behalf of the IETF, has the
responsibility to define and manage the relationship with the
protocol registry operator. This 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.
As with other SDO's, the IETF asserts full authority over the
management of all the IETF protocol parameters. This document
describes the function of these registries as they apply to
individual protocol parameters defined by the IETF Internet Standards
Process [RFC 2026] as to allow for an orderly implementation by the
IAOC under guidance from the IAB.
Below we provide a description of the requirement for these delegated
functions which the IETF has historically referred to as the IANA
function.
2. Roles and Responsibilities concerning IETF Protocol Registries
It has been the longstanding practice of the IETF to outsource the
management and implementation of some important functions (e.g., [RFC
McPherson, Huston, Kolkman Section 2. [Page 4]
INTERNET-DRAFT Expires: August 2010 February 2010
5620]). The protocol parameter registry function falls into this
category of outsourced function, and what follows here is a
comprehensive and normative description of the roles and
responsibility 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)
[RFC 4071]. While there is generally a single Protocol Parameter
Registry Operator, additional Operators may be selected to implement
specific registries. This document also describes the roles of other
bodies that interact with related bodies 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
coordinated and 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, while a
subsequent allocation hierarchy exists below IANA, and the Regional
Internet Registries (RIR) 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:
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
McPherson, Huston, Kolkman Section 2.1. [Page 5]
INTERNET-DRAFT Expires: August 2010 February 2010
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 require protocol
parameter assignment. If they are not so 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.
* 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.
* The registry operator assigns protocol parameter values in
accordance with the policy associated with the protocol
McPherson, Huston, Kolkman Section 2.1. [Page 6]
INTERNET-DRAFT Expires: August 2010 February 2010
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
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, 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 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 MoU outlined in [RFC 2860] that
was established by the IASA [RFC 4071] 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
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
McPherson, Huston, Kolkman Section 2.1. [Page 7]
INTERNET-DRAFT Expires: August 2010 February 2010
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].
2.2. IAB Role
An operator of an IETF Protocol Parameter registry undertakes the
role as a delegated function under the authority of the Internet
Architecture Board (IAB).
The IAB has the responsibility to review the current description of
the registry function on a schedule of its own choosing. The IAB
shall 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 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 [RFC 5620]), and in consultation with the IAB, the IAOC is
responsible for identifying potential vendors and managing 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 fully conforms 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 content and maintenance.
2.3. IESG Role
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 (e.g., see Appendix B).
Technical direction itself is provided through the adoption of IETF
McPherson, Huston, Kolkman Section 2.3. [Page 8]
INTERNET-DRAFT Expires: August 2010 February 2010
RFC documents within the "IANA Considerations" section of such
documents, or as stand-alone "IANA Considerations" RFC documents.
The IESG shall verify that Internet-Drafts that are offered for
publication as IETF-stream RFCs [RFC 4844] include IANA
Considerations sections when needed, and that IANA Considerations
sections conform to the current published guidelines. For other RFC
streams, the respective approval bodies for those streams are
responsible for verifying tha the documents include IANA
consideration when necessary, and that those IANA considerations
conform to the current published guidelines.
Since technical assessment is not a responsibility of the registry
operator, the IESG, as part of providing the technical direction, is
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
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 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).
2.5. Role of the IAOC
In consultation with the IAB, the IAOC is responsible for identifying
a potential vendor based on IAB consultation, and managing the
various aspects of the relationships with that vendor.
McPherson, Huston, Kolkman Section 2.5. [Page 9]
INTERNET-DRAFT Expires: August 2010 February 2010
In addition, the IAOC has the responsibility to ensure long-term
availability and stability across all such registries and their
contents. This responsibility is of particular significance in the
event that a relation with a protocol parameter registry operator is
terminated.
3. Miscellaneous
In it's current incarnation, the IANA function operator also
maintains registries from other SDOs that are of interest to the IETF
community, or add new codepoints to IETF protocols. Some registries
are also specified and used by ICANN itself. Some example registries
include "NLPIDs of Interest", "IEEE 802 Numbers", "Address Family
Numbers", and "Repository of IDN Practices". While these registries
are not specified or expressly requested on behalf of the IETF, and
their contents are not captive to express oversight by the IETF, they
are relevant to IETF work.
4. 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.
5. Security Considerations
This document does not propose any new protocols, and does not
involve any security considerations.
McPherson, Huston, Kolkman Section 5. [Page 10]
INTERNET-DRAFT Expires: August 2010 February 2010
6. IANA Considerations
This document requires no direct IANA actions.
7. References
7.1. Normative References
7.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, Kolkman Section 7.2. [Page 11]
INTERNET-DRAFT Expires: August 2010 February 2010
[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 4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC
Editor", RFC 4844, July 2007.
[RFC 5226] Narten, T., Alvestrand, H., "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226,
May 2008.
[RFC 5620] Kolkman, O., IAB, "RFC Editor Model (Version 1)",
RFC 5620, August 2009.
[IANA] Reynolds, J., "IANA Protocol Numbers and Assignment
Services", October 1994, <http://www.iana.org/numbers.htm>.
[IAOC_SUPP] ICANN/IANA-IETF MoU Supplemental Agreement
<http://iaoc.ietf.org/documents/IETF-
ICANN_Supplemental_Agreement.pdf>
[CORR] Dyson, E., "Correspondence from Esther Dyson, Interim
Chairman, ICANN to Scott Bradner, Brian Carpenter and
Fred Baker of the IETF", February 1999,
<http://www.icann.org/correspondence/bradner-dyson-25feb99.htm>.
[ENUM_INSTR] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC",
September 2002,
<http://www.iab.org/Documents/sg2-liaison-e164-sep-02.html>.
[RIPE ENUM] RIPE NCC, "ENUM Registry", September 2002,
<http://www.ripe.net/enum>.
8. Authors' Addresses
McPherson, Huston, Kolkman Section 8. [Page 12]
INTERNET-DRAFT Expires: August 2010 February 2010
Danny McPherson, Editor
Arbor Networks, Inc.
Email: danny@arbor.net
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 is commonly referred to as the set of protocol, DNS,
and Address registry functions 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
registries 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 the writing this document (December 2009) 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].
McPherson, Huston, Kolkman Section 9. [Page 13]
INTERNET-DRAFT Expires: August 2010 February 2010
3) Additionally, and also within IETF context, "IANA" has been
referred to as the entire set of IETF protocol parameter
registries:
The 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 function 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 [RFC 2860] between the IETF Administrative Support
Activity (IASA) and ICANN, and in supplements [IAOC_SUPP] provided
thereafter.
10. Appendix B: IANA registries in context
10.1. IETF Protocol Parameter Registry Definition
Using the term 'IANA' in the sense of the entire set of IETF protocol
parameter registries, the Internet Standards document, STD 2 [RFC
1700], 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
McPherson, Huston, Kolkman Section 10.1. [Page 14]
INTERNET-DRAFT Expires: August 2010 February 2010
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).
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 [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
McPherson, Huston, Kolkman Section 10.2. [Page 15]
INTERNET-DRAFT Expires: August 2010 February 2010
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].
10.3. The 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, as described in [RFC 5226]. Within these considerations
the IETF defines the policies through which a registry operator
manages assignments within the registry. There are also RFCs that
specifically address IETF protocol parameter considerations for
particular protocols, such as [RFC 2780], [RFC 2939], and [RFC 2978].
10.4. Registries for IETF Protocol Parameters
As documented in the IAB Charter [RFC 2850], 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) [RFC 2850].
McPherson, Huston, Kolkman Section 10.4. [Page 16]
INTERNET-DRAFT Expires: August 2010 February 2010
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 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 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 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.
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
McPherson, Huston, Kolkman Section 11. [Page 17]
INTERNET-DRAFT Expires: August 2010 February 2010
David Oran
Jon Peterson
Dave Thaler
Copyright Statement
Copyright (C) (2010) The 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.
McPherson, Huston, Kolkman Section 11. [Page 18]
