WDIFF

draft-iab-iana-01.txt --> draft-iab-iana-02.txt

Internet Architecture Board G. IAB Huston, Ed.
Internet-Draft Internet Architecture Board
Document: draft-iab-iana-01.txt February 14, 2003
Category: BCP IAB
Expires: August 15, December 23, 2003 June 24, 2003

Defining the Role and Function of the IETF-IANA IETF Protocol Parameter Registry
Operators
draft-iab-iana-02

Status of this Memo

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.

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 August 15, December 23, 2003.

Abstract

IAB

Huston, Ed. Expires August 15, December 23, 2003 [Page 1]

Internet-Draft IETF-IANA February June 2003

1. Introduction

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 single registry to register these protocol
values and their associated semantic intent. Historically, this
registry is referred to as the Internet Assigned Numbers Authority
(IANA). In this context the IANA function has included both the
registration each of protocol-specific identifier values (e.g. TCP
parameters) as well as the registration possible
values of various numbering and name
resources that are used within public Internet networks (e.g. IPv4
address allocations). In this document a distinction is drawn
between the registration of protocol parameters for protocols defined
in IETF RFCs, parameter and other IANA functions. The new term to describe the
IETF-related activity is the "IETF-IANA". their associated semantic intent.
The document describes this IETF-IANA registry function as it applies to
individual protocol parameters defined by the IETF Internet Standards
Process. [1]
Process [1].

At the time of writing this document (February (June 2003) the IANA-IETF
function 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]

2. Definition of IETF-IANA

The Internet Standards document, STD 2, published in October 1994,
defined [2]. Not all IETF
protocol parameter registries are delegated to ICANN, and at present
the role operation of the IANA as follows: 'e164.arpa' registry has been delegated to the
RIPE Network Coordination Center (RIPE NCC) [12].

The Internet term "Internet Assigned Numbers Authority (IANA) is the central
coordinator for Authority" (IANA), has been used
historically to refer to the assignment entire collection of unique protocol parameter values for
Internet protocols. The IANA
registries. It is chartered by the Internet Society
(ISOC) and the Federal Network Council (FNC) noted that there is current general use of this
term to act as the
clearinghouse refer specifically to assign and coordinate the use set of numerous
Internet protocol parameters.

The Internet protocol suite, as defined registries operated by the Internet
Engineering Task Force (IETF) and its steering group 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], 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.

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 Internet protocol addresses,

Huston, Ed. Expires December 23, 2003 [Page 2]

Internet-Draft IETF-IANA June 2003

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

IAB Expires August 15, 2003 [Page 2]

Internet-Draft IETF-IANA February 2003
unique assignments as requested and to maintain a registry of the
currently assigned values. [3]

The

Again using the term 'IANA' in the sense of the entire set of IETF
protocol parameter registries, the definition of the IETF-IANA 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]

3. Publication of IETF-IANA Protocol Parameter Registry Assignments

The current mode of publication of IETF-IANA protocol parameter registry
assignments undertaken within registries whose operation is currently
delegated to ICANN is described in the Informational Document RFC
3232 [5], 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]

The mode of publication of the e164.arpa protocol parameter registry

Huston, Ed. Expires December 23, 2003 [Page 3]

Internet-Draft IETF-IANA June 2003

operated by the RIPE NCC is documented in reference [13].

4. The Procedures related to IETF-IANA IETF Protocol Parameter Management

IETF-IANA

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]. There are also RFCs that
specifically address IANA IETF protocol parameter considerations for
particular protocols, such as RFC 2780 [6], RFC 2939 [7], and RFC
2978 [8].

5. The Operation of the IETF-IANA IETF Protocol Parameter Registries

As documented in the IAB Charter [9], the role of the Internet

IAB Expires August 15, 2003 [Page 3]

Internet-Draft IETF-IANA February 2003
Architecture Board includes responsibility for the IANA function.
Specifically, 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 IANA a protocol parameter
registry operator on behalf of the IETF, and also approves the terms
and conditions of this delegation of the
IANA function.

The IANA has a non-voting liaison with the IAB to facilitate clear
communications and effective operation of the IETF-IANA this function.

The technical direction of the IANA with respect to IETF-IANA IETF Protocol Parameter registry
function is provided by the Internet Engineering Steering Group (IESG). [9] The
IANA has a non-voting liaison with the IESG to facilitate clear
communications and effective operation of the IETF-IANA function.
(IESG) [9].

6. Current IETF-IANA IETF Protocol Parameter Assignments

The list of current IETF-IANA protocols IETF protocol parameters for which parameter
value assignments are registered by IANA within registries whose operation is
currently delegated to ICANN is listed in reference [10]. In addition
there is the e164.arpa registry function, which is listed in
reference [13].

With reference to the IETF-IANA, the list contained in reference [10], protocol parameters
parameter registries that are
excluded from the scope of the IETF-IANA role are refer to the registration of unicast IPv4 address blocks, space,
unicast IPv6 address blocks, space, Autonomous System blocks, Numbers and the top
level delegations within the Domain Name
System, as they are considered System all use allocation
mechanisms that have been delegated to be outside the scope IANA function operated
under the auspices of ICANN. Other bodies are responsible for the IETF-
IANA as defined in Section 2
development of policies to manage this document. allocation function.

7. A Description of the Operation Role and Responsibilities of the IETF-IANA an IETF Protocol
Parameter Registry Operator

This section describes the operation and role of the Internet
Engineering Task Force - Internet Assigned Numbers Authority (IETF-
IANA). a delegated IETF
Protocol Parameter Registry Operator. This section also includes a
description of the roles of related bodies with reference to the IETF-IANA this
function.

Huston, Ed. Expires December 23, 2003 [Page 4]

Internet-Draft IETF-IANA June 2003

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 the IETF-IANA.

7.2 IETF-IANA Role

The IETF-IANA 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 (IAB).

IAB Expires August 15, 2003 [Page 4]

Internet-Draft IETF-IANA February 2003

The roles of the IETF-IANA Protocol Parameter registry operator are as follows:

o Review and Advise

* The IETF-IANA reviews 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 "IANA Considerations" section, whether such a section, when
required, is clear in terms of direction to IETF-
IANA the registry
operator and whether the section is consistent with the current
published IETF-IANA Guidelines. registry operator guidelines.

o Registry

* The IETF-IANA operates To operate a registry of protocol parameter assignments.

* The IETF-IANA delegated registry operator registers values for the
protocol parameter Internet protocol parameters only as
directed by the criteria and procedures specified in RFCs,
including Proposed, Draft and full Internet Standards and Best
Current Practice documents, and any other RFC that calls for
IANA assignment.
protocol parameter assignment, and only for those protocol
parameters specified by the IAB. If they are not so specified,
or in case of ambiguity, IETF-IANA the registry operator will continue to
assign and register
Internet only those protocol parameters that have traditionally
already been
registered by IANA in delegated to the past, operator, following past and
current practice for such assignments, unless otherwise
directed in terms of operating practice by the IESG.

Huston, Ed. Expires December 23, 2003 [Page 5]

Internet-Draft IETF-IANA June 2003

* This registry includes:

+ all protocol parameters that are managed by IETF-IANA,

+ for For each protocol parameter, the associated registry includes:

+ a reference to the RFC document that describes the parameter
and the associated IANA
Considerations "IANA Considerations" concerning the
parameter, and

+ for each registration of a protocol parameter, parameter value, the
source of the registration and the date of the registration.

* If in doubt or in case of a technical dispute, the IETF-IANA registry
operator will seek and follow technical guidance exclusively
from the IESG. Where appropriate the IESG will appoint an
expert to advise IANA. the registry operator.

* The IETF=IANA registry operator will work with the IETF to develop any
missing criteria and procedures over time, which the IETF-IANA registry
operator will adopt when so instructed by the IESG.

IAB Expires August 15, 2003 [Page 5]

Internet-Draft IETF-IANA February 2003

* The 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 IETF-IANA registry operator assigns protocol parameter values in
accordance with the policy associated with the protocol
parameter. (Some policies are listed in RFC2434. [4]) RFC2434 [4]).

o Mailing Lists

* The IETF-IANA operates registry operator maintains public mailing lists as
specified in IANA Considerations. Such lists are designated for
the purpose of review of assignment proposals in conjunction
with a designated expert review function.

o Liaison Review and Advise

* The IETF-IANA designates an individual to act as registry operator will nominate a non-voting liaison to the IAB.

* point of contact.
The IETF-IANA designates an individual to act as a non-voting
liaison registry operator, though this liaison, may be requested to the IESG. The IETF-IANA liases with the IESG
regarding the provision of
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.

o Reporting

* The IETF-IANA registry operator will submit periodic reports to the IAB
concerning IETF-IANA the operational performance of the registry
function.

* The At the request of the chair of the IETF, the registry operator

Huston, Ed. Expires December 23, 2003 [Page 6]

Internet-Draft IETF-IANA June 2003

will undertake periodic reports to the IETF Plenary concerning
the status of the IETF- IANA role. registry function.

* The IETF-IANA registry operator will publish an annual report describing
the status of the IETF-IANA function and a summary of performance
indicators.

o Intellectual Property Rights and the IETF-IANA Registry Operator

* IETF-IANA 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 IETF-IANA assignment information
may not be modified in any redistributed copy.

* Any intellectual property rights of IETF-IANA the IETF Protocol Parameter
assignment

IAB Expires August 15, 2003 [Page 6]

Internet-Draft IETF-IANA February 2003 information, including the IETF-IANA IETF Protocol Parameter
registry and its contents, are to be held by the IETF and ISOC,
and all IETF-IANA IETF Protocol Parameter registry publications relating
to assignment information are to be published under the terms
of Section 10 of RFC2026, and are to include the copyright
notice as documented in Section 10.4 (C) of RFC2026. [1] RFC2026 [1].

7.3 IAB role

The IETF-IANA is

An operator of an IETF Protocol Parameter registry undertakes the
role as a delegated function undertaken 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 IETF-IANA registry function and direct the registry
operator to adopt amendments relating to its role and mode of
operation of the IETF-IANA 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 IETF-IANA. 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 IETF-IANA 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 IETF-IANA function.

The IETF-IANA designates a non-voting liaison to the IAB to
facilitate clear communications and effective operation of the IETF-
IANA registry function.

7.4 IESG Role

Huston, Ed. Expires December 23, 2003 [Page 7]

Internet-Draft IETF-IANA June 2003

The IESG is responsible for the technical direction of the IETF-IANA. 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.

The IETF-IANA designates

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 IETF-
IANA registry function.

IAB Expires August 15, 2003 [Page 7]

Internet-Draft IETF-IANA February 2003

7.5 Internet Society Role

Any intellectual property rights of IETF-IANA IETF Protocol Parameter
assignment information, including the IETF-IANA registry and its contents, and
all IETF-IANA registry publications, are to be held by the Internet Society on
behalf of the IETF.

8. Acknowledgements Acknowledgement

This document is adapted from RFC2434 [4], 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-IANA IETF Protocol Parameter
registry function.

The Internet Architecture Board acknowledges the assistance provided
by reviewers of earlier drafts of this document, including Scott
Bradner.

9. Security Considerations

This document does not propose any new protocols, and therefore does
not involve any security considerations in that sense.

References

[1] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.

[2] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Internet
Assigned Numbers Authority", RFC 2860, June 2000.

[3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, STD

Huston, Ed. Expires December 23, 2003 [Page 8]

Internet-Draft IETF-IANA June 2003

2, October 1994.

[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, BCP 26, October
1998.

[5] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line
On-line Database", RFC 3232, January 2002.

[6] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", RFC 2780,
BCP 37, March 2000.

[7] Droms, R., "Procedures and IANA Guidelines for Definition of
New DHCP Options and Message Types", RFC 2939, BCP 43,
September 2000.

IAB Expires August 15, 2003 [Page 8]

Internet-Draft IETF-IANA February 2003

[8] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", RFC 2978, BCP 19, October 2000.

[9] Carpenter, B., "Charter of the Internet Architecture Board",
RFC 2850, BCP 39, May 2000.

[10] Reynolds, J., "IANA Protocol Numbers and Assignment Services",
October 1994, <http://www.iana.org/numbers.htm>.

[11] 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>.

[12] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC", September
2002, <http://www.iab.org/Documents/
sg2-liaison-e164-sep-02.html>.

[13] RIPE NCC, "ENUM Registry", September 2002, <http://
www.ripe.net/enum>.

Author's Address

Geoff Huston, Editor.
Internet Architecture Board
EMail: iab@iab.org

Appendix A. IAB Membership Members

Internet Architecture Board Members at the time this document was completed:
published were:

Huston, Ed. Expires December 23, 2003 [Page 9]

Internet-Draft IETF-IANA June 2003

Bernard Aboba
Harald Alvestrand
Ran Atkinson
Rob Austein
Fred Baker
Leslie Daigle Daigle, Chair
Patrik Faltstrom
Sally Floyd
Ted Hardie
Jun-ichiro Itojun Hagino
Mark Handley
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Mike St. Johns

IAB
Michael StJohns

Huston, Ed. Expires August 15, December 23, 2003 [Page 9] 10]

Internet-Draft IETF-IANA February June 2003

Intellectual Property Statement

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.

Full Copyright Statement

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 assigns. 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

Huston, Ed. Expires December 23, 2003 [Page 11]

Internet-Draft IETF-IANA June 2003

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

IAB

Huston, Ed. Expires August 15, December 23, 2003 [Page 10] 12]

----