WDIFF

draft-iab-iana-03.txt --> draft-iab-iana-04.txt

Geoff Huston, Ed.

Internet Architecture Board G. Huston, Ed.
Internet-Draft IAB
Expires: March 10, 2004 September 10, 2003 April 2009 October 2008
Intended Status: Best Current Practice

Defining the Role and Function of IETF Protocol
Parameter Registry Operators
draft-iab-iana-03.txt
<draft-iab-iana-04.txt>

Status of this Memo

This document

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is an Internet-Draft aware
have been or will be disclosed, and is any of which he or she becomes
aware will be disclosed, in full conformance accordance with
all provisions of Section 10 6 of RFC2026. BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. Internet-
Drafts.

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.
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 10, 2004.
http://www.ietf.org/shadow.html

McPherson, Huston [Page 1]

INTERNET-DRAFT Expires: April 2009 October 2008

Abstract

Many IETF protocols make use of commonly defined values that are
passed within protocol objects. To ensure consistent interpretation
of these values between independent implementations, there is a need
to ensure that the values and associated semantic intent are uniquely
defined. The IETF uses a registry function functions to record assigned
protocol parameter values and their associated semantic intent. For
each IETF protocol parameter It it is current practice for the IETF to
delegate the role of protocol parameter registry operator to a
nominated entity. This document describes provides a description of this and the
requirements for these delegated function.

Huston, Ed. Expires March 10, 2004 functions.

McPherson, Huston [Page 1]

Internet-Draft IETF-IANA September 2003 2]

INTERNET-DRAFT Expires: April 2009 October 2008

Table of Contents

1. Introduction Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definition of an IETF Protocol Parameter
Registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Publication of Protocol Parameter Registry
Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The Procedures related to IETF Protocol Parameter
Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. The Operation of IETF Protocol Parameter Reg-
istries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Current IETF Protocol Parameter Assignments . . . . . . . . . 7
7. Roles and Responsibilities concerning IETF Proto-
col Registries. . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Protocol Parameter Registry Operator Role . . . . . . . . . 8
7.3. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.5. Role of the IETF Trust. . . . . . . . . . . . . . . . . . . 12
8. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14
14. Appendix A: IAB Members . . . . . . . . . . . . . . . . . . . 15

McPherson, Huston [Page 3]

INTERNET-DRAFT Expires: April 2009 October 2008

1. Overview

Many IETF protocols make use of commonly defined values that are
passed within protocol objects. To ensure consistent interpretation
of these values between independent implementations, there is a need
to ensure that the values and associated semantic intent are uniquely
defined. The IETF uses a registry registries to register record each of the possible
values of a protocol parameter and their associated semantic intent.
The document describes this registry the function of these registries as it applies they apply
to individual protocol parameters defined by the IETF Internet
Standards Process [1]. [RFC 2026].

At the time of writing this document (June 2003) (October 2008) the operation of
the majority of the protocol parameter registries is delegated to the
Internet Corporation for Assigned Names and Numbers (ICANN) according
to the terms and conditions described in RFC 2860 [2]. [RFC 2860] and
supplements developed thereafter. Not all IETF protocol parameter
registries are delegated to ICANN, and at present the operation of
the 'e164.arpa' registry has been delegated to the RIPE Network
Coordination Center (RIPE NCC) [12]. [RIPE NCC].

The term "Internet Assigned Numbers Authority" (IANA), has been used
historically to refer to the entire collection of protocol parameter
registries. It is noted that there is current general use of this
term to refer specifically to the set of registries operated by ICANN
under terms of this delegation of function. While IETF documents
continue to use the term "IANA Considerations" when referring to
specific functions to be performed with respect to a protocol
parameter registry [4], [RFC 5226], 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 operation to the particular protocol parameter so described.

2. Definition of an body managed by ICANN.

This IETF Protocol Parameter Registry

Using the term 'IANA' - IANA organizational separation is one that appears to be
a relatively unique arrangement in the sense context of the entire set standards
development organizations (SDOs), and similar arrangements of IETF
structural separation are not generally used by SDOs. Other SDOs that
undertake a similar protocol parameter registries, the Internet Standards document, STD 2,
published in October 1994, defined the role registration function
generally do so as part of the IANA their secretariat service functions or
their equivalent, thereby avoiding the overheads of detailed
coordination of activity across multiple distinct organizations.
However, as follows:

The Internet Assigned Numbers Authority already noted, this structural separation of roles exists
within several places in the IETF framework (e.g., to include the RFC
Editor function) and the IETF has the responsibility to define and
manage the relationship with the IANA role. This IETF responsibility
includes the selection and management of the protocol parameter
registry operator(s), as well as management of the parameter
registration process and the guidelines for parameter allocation.

McPherson, Huston Section 1. [Page 4]

INTERNET-DRAFT Expires: April 2009 October 2008

Furthermore, as with other SDO's, the IETF asserts full authority
over the management of all the IETF protocol parameter registries.

2. Definition of an IETF Protocol Parameter Registry

Using the term 'IANA' in the sense of the entire set of IETF protocol
parameter registries, the Internet Standards document, STD 2,
published in October 1994, defined the role of the IANA as follows:

The Internet Assigned Numbers Authority (IANA) is the central
coordinator for the assignment of unique parameter values for
Internet protocols. The IANA is chartered by the Internet
Society (ISOC) and the Federal Network Council (FNC) to act as
the clearinghouse to assign and coordinate the use of numerous
Internet protocol parameters.

The Internet protocol suite, as defined by the Internet
Engineering Task Force (IETF) and its steering group (the IESG),
contains numerous parameters, such as Internet protocol addresses,

Huston, Ed. Expires March 10, 2004 [Page 2]

Internet-Draft IETF-IANA September 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 unique assignments as requested and to maintain
a registry of the currently assigned values. [3] 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 BCP 26: [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 algorithm transform for IPSec). IPsec). To insure ensure that such
quantities have consistent values and interpretations in different 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). [4]

McPherson, Huston Section 2. [Page 5]

INTERNET-DRAFT Expires: April 2009 October 2008

3. Publication of Protocol Parameter Registry Assignments

The current mode of publication of protocol parameter registry
assignments undertaken within registries whose operation is currently
delegated to ICANN is described in the Informational Document RFC
3232 [5], [RFC
3232], published in January 2002:

From November 1977 through October 1994, the Internet
Assigned Numbers Authority (IANA) periodically published
tables of the Internet protocol parameter assignments in
RFCs entitled, "Assigned Numbers". The most current of these
Assigned Numbers RFCs had Standard status and carried the
designation: STD 2. At this time, the latest STD 2 is
RFC 1700.

Since 1994, this sequence of RFCs have been replaced
by an online database accessible through a web page
(currently, www.iana.org). The purpose of the present RFC
is to note this fact and to officially obsolete RFC 1700,
whose status changes to Historic. RFC 1700 is obsolete, and
its values are incomplete and in some cases may be wrong. [5] wrong
[RFC 3232].

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

Huston, Ed. Expires March 10, 2004 [Page 3]

Internet-Draft IETF-IANA September 2003
operated by the RIPE NCC is documented in reference [13]. [RIPE ENUM].

4. The Procedures related to IETF Protocol Parameter Management

IETF Protocol Parameter registry actions are defined through the
inclusion of an "IANA Considerations" section in Internet Standards
documents, as described in RFC 2434 [4]. [RFC 5226]. There are also RFCs that
specifically address IETF protocol parameter considerations for
particular protocols, such as RFC 2780 [6], RFC 2939 [7], [RFC 2780], [RFC 2939], and RFC
2978 [8]. [RFC 2978].

5. The Operation of IETF Protocol Parameter Registries

As documented in the IAB Charter [9], [RFC 2850], the role of the Internet
Architecture Board includes responsibility for the IETF Protocol
Parameter registration function (referred to in the charter as
'IANA'). The IAB, acting on behalf of the IETF, approves the

McPherson, Huston Section 5. [Page 6]

INTERNET-DRAFT Expires: April 2009 October 2008

appointment of an organization to act as a protocol parameter
registry operator on behalf of the IETF, and also approves the terms
and conditions of this delegation of this function.

The technical direction of the IETF Protocol Parameter registry
function is provided by the Internet Engineering Steering Group
(IESG) [9]. [RFC 2850].

6. Current IETF Protocol Parameter Assignments

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

With reference to [RIPE ENUM].

As provided in the list list contained in reference [10], [IANA], those protocol
parameter registries that refer to registrations related to the
allocation of public unicast IPv4 address space, addresses, public unicast IPv6 address space,
addresses, public use Autonomous System Numbers (ASNs) and the top
level delegations within the Domain Name System all use allocation System, have associated
registration mechanisms that have been delegated to the IANA function
operated under the auspices of ICANN. Other ICANN, as defined in [RFC 2860]. In
these cases other bodies are responsible for the development of
policies to manage the registrations of allocations performed as part
this allocation function.

7. A Description aspect of the Role registration function. Registrations that refer to
reservations (e.g., IP address blocks for documentation purposes or
ASNs defined for documentation purposes) and all other use cases
within those registries must be prescribed by the IETF.

7. Roles and Responsibilities of an concerning IETF Protocol
Parameter Registry Operator Registries

This section describes the operation and role of a delegated IETF
Protocol Parameter Registry Operator. Operator, to be selected and administered
by the IETF Administrative Support Activity (IASA) [RFC 4071]. This
section also includes a description of the roles of related bodies
with reference to this function.

Huston, Ed. Expires March 10, 2004

This generic description is being provided for clarity, in order to
document the protocol parameter registry administrative function that
has evolved over time as intrinsic aspects of the IANA culture.

McPherson, Huston Section 7. [Page 4]

Internet-Draft IETF-IANA September 2003

7.1 7]

INTERNET-DRAFT Expires: April 2009 October 2008

7.1. Introduction

Many protocols make use of identifiers consisting of constants and
other well-known values. Even after a protocol has been defined and
deployment has begun, new values may need to be assigned (e.g., for a
new option type in DHCP, or a new encryption or authentication
algorithm for IPSec). To insure that such quantities have consistent
values and interpretations in different implementations, their
assignment must be administered by a central authority. For IETF
protocols, that role is provided by a delegated Protocol Parameter
Registry operator. For any particular protocol parameter there is a
single delegated registry operator.

7.2

7.2. Protocol Parameter Registry Operator Role

A IETF Protocol Parameter registry function is undertaken under the
auspices of the Internet Architecture Board (IAB). Board.

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

o Review and Advise

* The registry operator may be requested to review
Internet-Drafts that are being considered by the Internet
Engineering Task Force Steering Group (IESG), with the
objective of offering advice to the IESG regarding the
need for an "IANA Considerations" section, whether such
a section, when required, is clear in terms of direction
to the registry operator and whether the section is
consistent with the current published registry operator
guidelines.

o Registry

* To operate a registry of protocol parameter assignments.

* The delegated registry operator registers values for 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 Standards, Best Current
Practice documents, and any other RFC RFCs that calls call for protocol
parameter assignment, and only for those protocol parameters
specified by the IAB. IETF. If they are not so specified, or in
case of ambiguity, the registry operator will continue to

McPherson, Huston Section 7.2. [Page 8]

INTERNET-DRAFT Expires: April 2009 October 2008

assign and register only those protocol parameters that have
already been delegated to the operator, following past and
current practice for such assignments, unless otherwise
directed in terms of operating practice by the IESG.

Huston, Ed. Expires March 10, 2004 [Page 5]

Internet-Draft IETF-IANA September 2003 In
the case of the current IANA operation, requirements are
provided in the MoU with ICANN [RFC 2860] and associated
supplements outlining service level agreements for IETF
protocol parameter registry functions.

* For each protocol parameter, the associated registry
includes:

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

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

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

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

* Each protocol parameter registry operates as a public registry,
and the contents of the registry are openly available to the
public, on-line and free of charge. Any related intellectual
property rights associated with the registry and its contents
are held by the IETF Trust [RFC 4748].

* The registry operator assigns protocol parameter values in
accordance with the policy associated with the protocol
parameter. (Some Some policies are listed in RFC2434 [4]). [RFC 5226].

o Mailing Lists

* The registry operator maintains public mailing lists as
specified in IANA Considerations. Considerations [RFC 5226]. Such lists are
designated for the purpose of review of assignment proposals
in conjunction with a designated expert review function. In
addition, each protocol parameter registry operator should
maintain a mailing list that enables the registry staff of
each registry operator to be contacted by email. For example,

McPherson, Huston Section 7.2. [Page 9]

INTERNET-DRAFT Expires: April 2009 October 2008

iana@iana.org currently provides this function for IANA.

o Liaison to IESG Activity

* The registry operator will nominate a liaison point of contact.
The registry operator, though this liaison, may be requested to
provide advice to the IESG on IETF protocol parameters as well
as the IANA Considerations section of Internet-drafts that are
being reviewed for publication as an RFC. Where appropriate the
IESG will appoint an expert to advise IANA.

o Reporting

* The registry operator will submit periodic reports to the IAB
concerning the operational performance of the registry function.
As an exmaple of the requirements for such reports the reader is
referred to a supplement to the MoU outlined in [RFC 2860], which
was established by the IASA [RFC 4071] and provides SLA
guidelines under which IANA, as implemented by ICANN, must
operate.

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

Huston, Ed. Expires March 10, 2004 [Page 6]

Internet-Draft IETF-IANA September 2003
will undertake periodic reports to the IETF Plenary concerning
the status of the registry function.

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

o Intellectual Property Rights and the Registry Operator

* All assigned values are to be published and made available free
of any charges and free of any constraints relating to further
redistribution, with the caveat that the assignment information
may not be modified in any redistributed copy.

* Any intellectual property rights of the IETF Protocol Parameter
assignment information, including the IETF Protocol Parameter
registry and its contents, are to be held by the IETF and ISOC, 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 RFC2026, [RFC 2026], and are to include the
copyright notice as documented in Section 10.4 (C) of RFC2026 [1].

7.3 [RFC 2026].

McPherson, Huston Section 7.2. [Page 10]

INTERNET-DRAFT Expires: April 2009 October 2008

7.3. IAB role Role

An operator of an IETF Protocol Parameter registry undertakes the
role as a delegated function under the auspices of the Internet
Architecture Board (IAB).

The IAB has the responsibility to, from time to time, review the
current description of the registry function and direct the registry
operator to adopt amendments relating to its role and mode of
operation of the registry according to the best interests of the
IETF.

The IAB has the responsibility to select an organization to undertake
the delegated functions of the Protocol Parameter registry for each
IETF protocol parameter.

The IAB has the responsibility to determine the terms and conditions
of this delegated role. Such terms and conditions should ensure that
the registry operates in a manner that is fully conformant to the
functions described in this document. In addition, such terms and
conditions must not restrict the rights and interests of the IETF
with respect to the registry function.

7.4

7.4. IESG Role

Huston, Ed. Expires March 10, 2004 [Page 7]

Internet-Draft IETF-IANA September 2003

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.

7.5 Internet Society

McPherson, Huston Section 7.4. [Page 11]

INTERNET-DRAFT Expires: April 2009 October 2008

7.5. Role of the IETF Trust

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

8. Acknowledgement

This document is adapted from RFC2434 [4], and has been modified to
include explicit reference

The IETF Trust [RFC 4748] was recently formed to Intellectual Property Rights, and act as the
roles
administrative custodian of the IAB all copyrights and IESG in relation other intellectual
property rights relating to the IETF Protocol Parameter
registry function.

The Internet Architecture Board acknowledges the assistance provided
by reviewers of Standards Process that had
previously been held by ISOC and the Corporation for National
Research Initiatives (CNRI).

8. Miscellaneous Considerations

The IESG provides technical guidance for IETF created registries.
For registries created by non-IETF stream documents the policies set
by the IESG apply unless there are solid arguments to follow a
different policy in which case the IAB has the final word.

9. Acknowledgements

This document is adapted from [RFC 5226], and has been modified to
include explicit reference to Intellectual Property Rights, and the
roles of the IAB and IESG in relation to the IETF Protocol Parameter
registry function.

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

9.
Bradner, Leslie Daigle and Thomas Narten.

10. Security Considerations

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

McPherson, Huston Section 10. [Page 12]

INTERNET-DRAFT Expires: April 2009 October 2008

11. IANA Considerations

This document requires no direct IANA actions.

12. References

12.1. Normative References

12.2. Informative References

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

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

Huston, Ed. Expires March 10, 2004 [Page 8]

Internet-Draft IETF-IANA September 2003 2, October 1994.

[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs",

[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2434, 2026, BCP 26, 9, October
1998.

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

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

[7]

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

[8]

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

[9] Carpenter,

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

McPherson, Huston Section 12.2. [Page 13]

INTERNET-DRAFT Expires: April 2009 October 2008

[RFC 4071] Austein, R., Wijnen, B., "Charter "Structure of the Internet Architecture Board", IETF
Administrative Support Activity (IASA)", RFC 2850, 4071,
April 2005.

[RFC 4748] Bradner, S., "RFC 3978 Update to Recognize the IETF
Trust", RFC 4748, BCP 39, 78, October 2006.

[RFC 5226] Narten, T., Alvestrand, H., "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226,
May 2000.

[10] 2008.

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

[11]

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

[12]
<http://www.icann.org/correspondence/bradner-dyson-25feb99.htm>.

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

[13]
<http://www.iab.org/Documents/sg2-liaison-e164-sep-02.html>.

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

Author's Address
<http://www.ripe.net/enum>.

13. Authors' Addresses

Danny McPherson, Editor
Arbor Networks, Inc.
Email: danny@arbor.net

Geoff Huston, Editor. Editor
APNIC
Email: gih@apnic.net

Internet Architecture Board
Email: iab@iab.org

McPherson, Huston Section 13. [Page 14]

INTERNET-DRAFT Expires: April 2009 October 2008

14. Appendix A. A: IAB Members

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

Huston, Ed. Expires March 10, 2004 [Page 9]

Internet-Draft IETF-IANA September 2003

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

Huston, Ed. Expires March 10, 2004 [Page 10]

Internet-Draft IETF-IANA September 2003

Loa Andersson
Gonzalo Camarillo
Stuart Cheshire
Aaron Falk
Russ Housley
Olaf Kolkman
Gregory Lebovitz
Barry Leiba
Kurtis Lindqvist
Andrew Malis
Danny McPherson
David Oran
Dave Thaler
Lixia Zhang

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation RFC documents can be
found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors implementers or users of this
specification can be obtained from the IETF Secretariat. on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which that may cover technology that may be required to practice implement
this standard. Please address the information to the IETF Executive
Director.

Full at
ietf-ipr@ietf.org.

McPherson, Huston Section 14. [Page 15]

INTERNET-DRAFT Expires: April 2009 October 2008

This document and translations of it may be copied and furnished is subject 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 rights, licenses and derivative works. However, this
document itself may not be modified restrictions
contained in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, BCP 78, and 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 set forth therein, the Internet Society or its successors or assignees. authors
retain all their rights.

This document and the information contained herein is are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY SOCIETY, THE IETF TRUST
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION

Huston, Ed. Expires March 10, 2004 [Page 11]

Internet-Draft IETF-IANA September 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.

Acknowledgment

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

Huston, Ed. Expires March 10, 2004 IETF
Administrative Support Activity (IASA).

McPherson, Huston Section 14. [Page 12] 16]
----