< draft-leiba-cotton-iana-5226bis-04.txt   draft-leiba-cotton-iana-5226bis-05.txt >
Network Working Group M. Cotton Network Working Group M. Cotton
Internet-Draft ICANN Internet-Draft ICANN
BCP: 26 B. Leiba BCP: 26 B. Leiba
Obsoletes: 5226 (if approved) Huawei Technologies Obsoletes: 5226 (if approved) Huawei Technologies
Intended status: Best Current Practice T. Narten Intended status: Best Current Practice T. Narten
Expires: May 14, 2014 IBM Corporation Expires: December 5, 2014 IBM Corporation
November 12, 2013 June 3, 2014
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-04 draft-leiba-cotton-iana-5226bis-05
Abstract Abstract
Many protocols make use of points of extensibility that use constants Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central interoperability, their allocation is often coordinated by a central
authority. For IETF protocols, that role is filled by the Internet authority. For IETF protocols, that role is filled by the Internet
Assigned Numbers Authority (IANA). Assigned Numbers Authority (IANA).
To make assignments in a given namespace prudently, IANA needs To make assignments in a given namespace prudently, IANA needs
guidance describing the conditions under which new values should be guidance describing the conditions under which new values should be
assigned, as well as when and how modifications to existing values assigned, as well as when and how modifications to existing values
can be made. This document defines a framework for the documentation can be made. This document defines a framework for the documentation
of these guidelines by specification authors, in order to assure that of these guidelines by specification authors, in order to assure that
the guidance given to IANA is clear and addresses the various issues the guidance given to IANA is clear and addresses the various issues
that are likely in the operation of a registry. that are likely in the operation of a registry.
This is the third edition, and obsoletes RFC 5226. This is the third edition, and obsoletes RFC 5226.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 14, 2014. This Internet-Draft will expire on December 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 3 1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 4
1.2. For More Information . . . . . . . . . . . . . . . . . . . 4 1.2. For More Information . . . . . . . . . . . . . . . . . . 4
1.3. Terminology Used In This Document . . . . . . . . . . . . 4 1.3. Terminology Used In This Document . . . . . . . . . . . . 5
2. Creating and Revising Registries . . . . . . . . . . . . . . . 4 2. Creating and Revising Registries . . . . . . . . . . . . . . 5
2.1. Hierarchical Registry Structure . . . . . . . . . . . . . 5 2.1. Hierarchical Registry Structure . . . . . . . . . . . . . 5
2.2. Documentation Requirements for Registries . . . . . . . . 6 2.2. Documentation Requirements for Registries . . . . . . . . 7
2.3. Defining an Appropriate Registry Policy . . . . . . . . . 8 2.3. Defining an Appropriate Registry Policy . . . . . . . . . 9
2.3.1. Using the Well-Known Registration Policies . . . . . . 10 2.3.1. Using the Well-Known Registration Policies . . . . . 11
2.3.2. Using Multiple Policies in Combination . . . . . . . . 11 2.3.2. Using Multiple Policies in Combination . . . . . . . 13
2.3.3. Specifying Change Control for a Registry . . . . . . . 12 2.3.3. Specifying Change Control for a Registry . . . . . . 13
2.4. Revising Existing Registries . . . . . . . . . . . . . . . 12 2.4. Revising Existing Registries . . . . . . . . . . . . . . 14
3. Registering New Values in an Existing Registry . . . . . . . . 12 3. Registering New Values in an Existing Registry . . . . . . . 14
3.1. Documentation Requirements for Registrations . . . . . . . 12 3.1. Documentation Requirements for Registrations . . . . . . 14
3.2. Updating Existing Registrations . . . . . . . . . . . . . 14 3.2. Updating Existing Registrations . . . . . . . . . . . . . 16
3.3. Overriding Registration Procedures . . . . . . . . . . . . 15 3.3. Overriding Registration Procedures . . . . . . . . . . . 16
3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 17
4. Well-Known Registration Policies . . . . . . . . . . . . . . . 15 4. Well-Known Registration Policies . . . . . . . . . . . . . . 17
4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 17 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . 18
4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 18
4.4. First Come First Served . . . . . . . . . . . . . . . . . 17 4.4. First Come First Served . . . . . . . . . . . . . . . . . 19
4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 19
4.6. Specification Required . . . . . . . . . . . . . . . . . . 18 4.6. Specification Required . . . . . . . . . . . . . . . . . 20
4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . 20
4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 20
4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 19 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . 21
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 19 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 21
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 20 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . 22
5.1. The Motivation for Designated Experts . . . . . . . . . . 20 5.1. The Motivation for Designated Experts . . . . . . . . . . 22
5.2. The Role of the Designated Expert . . . . . . . . . . . . 21 5.2. The Role of the Designated Expert . . . . . . . . . . . . 23
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 22 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 24 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 26
6. Well-Known Registration Status Terminology . . . . . . . . . . 24 6. Well-Known Registration Status Terminology . . . . . . . . . 26
7. Documentation References in IANA Registries . . . . . . . . . 24 7. Documentation References in IANA Registries . . . . . . . . . 27
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 25 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 26 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 29
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 26 9.1. When There Are No IANA Actions . . . . . . . . . . . . . 29
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 27 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . 29
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 27 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . 30
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 27 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . 30
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 28 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 31
9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 29 9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . 31
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 30 13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . 32
13.1. 2013: Changes in This Document Relative to RFC 5226 . . . 30 13.1. 2013: Changes in This Document Relative to RFC 5226 . . 32
13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 31 13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 33
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Acknowledgments for This Document (2013) . . . . . . . . 31 14.1. Acknowledgments for This Document (2013) . . . . . . . . 34
14.2. Acknowledgments from the second edition (2008) . . . . . 32 14.2. Acknowledgments from the second edition (2008) . . . . . 35
14.3. Acknowledgments from the first edition (1998) . . . . . . 32 14.3. Acknowledgments from the first edition (1998) . . . . . 35
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
15.1. Normative References . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Many protocols make use of points of extensibility that use constants Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central interoperability, their allocation is often coordinated by a central
authority. For IETF protocols, that role is filled by the Internet authority. For IETF protocols, that role is filled by the Internet
Assigned Numbers Authority (IANA) [RFC2860]. IANA services are Assigned Numbers Authority (IANA) [RFC2860]. IANA services are
currently provided by the International Corporation for Assigned currently provided by the International Corporation for Assigned
Names and Numbers (ICANN). Names and Numbers (ICANN).
The Protocol field in the IP header [RFC0791] and MIME media types The Protocol field in the IP header [RFC0791] and MIME media types
[RFC4288] are two examples of such coordinations. [RFC4288] are two examples of such coordinations.
In this document, we call the range of possible values for such a In this document, we call the range of possible values for such a
field a "namespace". The binding or association of a specific value field a "namespace". The binding or association of a specific value
with a particular purpose within a namespace is called an assignment with a particular purpose within a namespace is called an assignment
(or, variously: an assigned number, assigned value, code point, (or, variously: an assigned number, assigned value, code point,
protocol constant, or protocol parameter). The act of assignment is protocol constant, or protocol parameter). The act of assignment is
called a registration, and it takes place in the context of a called a registration, and it takes place in the context of a
registry. The terms "assignment" and "registration" are used registry. The terms "assignment" and "registration" are used
interchangably throughout this document. interchangably throughout this document.
To make assignments in a given namespace prudently, IANA needs To make assignments in a given namespace prudently, IANA needs
guidance describing the conditions under which new values should be guidance describing the conditions under which new values should be
assigned, as well as when and how modifications to existing values assigned, as well as when and how modifications to existing values
can be made. This document defines a framework for the documentation can be made. This document defines a framework for the documentation
of these guidelines by specification authors, in order to assure that of these guidelines by specification authors, in order to assure that
the guidance given to IANA is clear and addresses the various issues the guidance given to IANA is clear and addresses the various issues
skipping to change at page 4, line 32 skipping to change at page 4, line 48
references to elsewhere in the document for other information. references to elsewhere in the document for other information.
1.2. For More Information 1.2. For More Information
IANA maintains a web page that includes current important information IANA maintains a web page that includes current important information
from IANA. Document authors should check that page for additional from IANA. Document authors should check that page for additional
information, beyond what is provided here. information, beyond what is provided here.
<http://www.iana.org/important-information>. <http://www.iana.org/important-information>.
[[***** The URI above is not yet ready. Make sure IANA sets it up. [[CREF1: ***** The URI above is not yet ready. Make sure IANA sets
*****]] it up. *****]]
1.3. Terminology Used In This Document 1.3. Terminology Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
For this document, "the specification" as used by RFC 2119 refers to For this document, "the specification" as used by RFC 2119 refers to
the processing of protocol documents within the IETF standards the processing of protocol documents within the IETF standards
process. process.
skipping to change at page 5, line 26 skipping to change at page 6, line 10
It's important to start with a word on the IANA registry structure. It's important to start with a word on the IANA registry structure.
All registries are anchored from the IANA "Protocol Registries" page: All registries are anchored from the IANA "Protocol Registries" page:
<http://www.iana.org/protocols>. <http://www.iana.org/protocols>.
That page lists registries in groups, like this: That page lists registries in groups, like this:
--------------------------------------------------------------- ---------------------------------------------------------------
Author Domain Signing Practices (ADSP) Parameters Author Domain Signing Practices (ADSP) Parameters
ADSP Outbound Signing Practices RFC 5617 ADSP Outbound Signing Practices RFC 5617
IETF Review IETF Review
ADSP Specification Tags RFC 5617 ADSP Specification Tags RFC 5617
IETF Review IETF Review
Automatic Responses to Electronic Mail Parameters Automatic Responses to Electronic Mail Parameters
Auto-Submitted Header Field RFC 5436 Auto-Submitted Header Field RFC 5436
Keywords Specification Required Keywords Specification Required
Auto-Submitted header field RFC 3834 Auto-Submitted header field RFC 3834
optional parameters IETF Consensus optional parameters IETF Consensus
Autonomous System (AS) Numbers Autonomous System (AS) Numbers
16-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6996 16-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6996
RIR request to the IANA RIR request to the IANA
or IETF Review or IETF Review
32-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6793, 32-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6793,
RFC 6996 RFC 6996
RIR request to the IANA RIR request to the IANA
or IETF Review or IETF Review
--------------------------------------------------------------- ---------------------------------------------------------------
The grouping allows related registries to be placed together, making The grouping allows related registries to be placed together, making
it easier for users of the registries to find the necessary it easier for users of the registries to find the necessary
information. In the example section above, there are two registries information. In the example section above, there are two registries
related to the ADSP protocol, and they are both placed in the "ADSP related to the ADSP protocol, and they are both placed in the "ADSP
Parameters" group. Parameters" group.
Within the "ADSP Parameters" group are two registries: "ADSP Outbound Within the "ADSP Parameters" group are two registries: "ADSP Outbound
Signing Practices" and "ADSP Specification Tags". Clicking on the Signing Practices" and "ADSP Specification Tags". Clicking on the
skipping to change at page 7, line 47 skipping to change at page 8, line 39
exact format in which registry values should be displayed. For exact format in which registry values should be displayed. For
numeric assignments, one should specify whether values are to be numeric assignments, one should specify whether values are to be
recorded in decimal, hexadecimal, or some other format. For recorded in decimal, hexadecimal, or some other format. For
strings, the encoding format should be specified (ASCII, UTF8, strings, the encoding format should be specified (ASCII, UTF8,
etc.). etc.).
Initial assignments and reservations Initial assignments and reservations
Any initial assignments or registrations to be included. In Any initial assignments or registrations to be included. In
addition, any ranges that are to be reserved for "Private Use", addition, any ranges that are to be reserved for "Private Use",
"Reserved", "Unassigned", etc. should be indicated. "Reserved", "Unassigned", etc. should be indicated.
For example, a document might specify a new registry by including: For example, a document might specify a new registry by including:
--------------------------------------------------------------- ---------------------------------------------------------------
X. IANA Considerations X. IANA Considerations
This document defines a new DHCP option, entitled "FooBar" (see This document defines a new DHCP option, entitled "FooBar" (see
Section y), assigned a value of TBD1 from the DHCP Option space Section y), assigned a value of TBD1 from the DHCP Option space
[to be removed upon publication: [to be removed upon publication:
skipping to change at page 13, line 42 skipping to change at page 15, line 13
correct assigned values inserted in all of the relevant places where correct assigned values inserted in all of the relevant places where
the value is expected to appear in the final document. For values the value is expected to appear in the final document. For values
that are text strings, a specific name can be suggested. IANA will that are text strings, a specific name can be suggested. IANA will
normally assign the name, unless it conflicts with a name already in normally assign the name, unless it conflicts with a name already in
use. use.
Normally, the values to be used are chosen by IANA and documents Normally, the values to be used are chosen by IANA and documents
should specify values of "TBD". However, in some cases, a value may should specify values of "TBD". However, in some cases, a value may
have been used for testing or in early implementations. In such have been used for testing or in early implementations. In such
cases, it is acceptable to include text suggesting what specific cases, it is acceptable to include text suggesting what specific
value should be used (together with the reason for the choice). For value should be used (together with the reason for the choice). For
example, one might include the text "the value XXX is suggested as it example, one might include the text "the value XXX is suggested as it
is used in implementations". However, it should be noted that is used in implementations". However, it should be noted that
suggested values are just that; IANA will attempt to assign them, but suggested values are just that; IANA will attempt to assign them, but
may find that impossible, if the proposed number has already been may find that impossible, if the proposed number has already been
assigned for some other use. assigned for some other use.
For some registries, IANA has a long-standing policy prohibiting For some registries, IANA has a long-standing policy prohibiting
assignment of names or codes on a vanity or organization-name basis. assignment of names or codes on a vanity or organization-name basis.
For example, codes are always assigned sequentially unless there is a For example, codes are always assigned sequentially unless there is a
strong reason for making an exception. Nothing in this document is strong reason for making an exception. Nothing in this document is
intended to change those policies or prevent their future intended to change those policies or prevent their future
application. application.
The IANA Considerations section should summarize all of the IANA The IANA Considerations section should summarize all of the IANA
actions, with pointers to the relevant sections elsewhere in the actions, with pointers to the relevant sections elsewhere in the
document as appropriate. When multiple values are requested, it is document as appropriate. When multiple values are requested, it is
generally helpful to include a summary table. It is also helpful for generally helpful to include a summary table. It is also helpful for
this table to be in the same format as it appears or will appear on this table to be in the same format as it appears or will appear on
the IANA web site. For example: the IANA web site. For example:
Value Description Reference Value Description Reference
-------- ------------------- --------- -------- ------------------- ---------
TBD1 Foobar [[this RFC]] TBD1 Foobar [[this RFC]]
Note: In cases where authors feel that including the full table is Note: In cases where authors feel that including the full table is
too verbose or repetitive, authors should still include the table in too verbose or repetitive, authors should still include the table in
the draft, but may include a note asking that the table be removed the draft, but may include a note asking that the table be removed
prior to publication of the final RFC. prior to publication of the final RFC.
As an example, the following text could be used to request assignment As an example, the following text could be used to request assignment
of a DHCPv6 option number: of a DHCPv6 option number:
IANA has assigned an option code value of TBD1 to the DNS IANA has assigned an option code value of TBD1 to the DNS
skipping to change at page 16, line 4 skipping to change at page 17, line 24
IANA normally takes its actions when a document is approved for IANA normally takes its actions when a document is approved for
publication. There are times, though, when early allocation of a publication. There are times, though, when early allocation of a
value is important for the development of a technology: for example, value is important for the development of a technology: for example,
when early implementations are created while the document is still when early implementations are created while the document is still
under development. under development.
IANA has a mechanism for handling such early allocations in some IANA has a mechanism for handling such early allocations in some
cases. See [I-D.cotton-rfc4020bis] for details. cases. See [I-D.cotton-rfc4020bis] for details.
4. Well-Known Registration Policies 4. Well-Known Registration Policies
The following are some defined policies, most of which are in use The following are some defined policies, most of which are in use
today. These cover a range of typical policies that have been used today. These cover a range of typical policies that have been used
to describe the procedure for assigning new values in a namespace. to describe the procedure for assigning new values in a namespace.
It is not strictly required that documents use these terms; the It is not strictly required that documents use these terms; the
actual requirement is that the instructions to IANA be clear and actual requirement is that the instructions to IANA be clear and
unambiguous. However, use of these terms is strongly RECOMMENDED, unambiguous. However, use of these terms is strongly RECOMMENDED,
because their meanings are widely understood. The terms are fully because their meanings are widely understood. The terms are fully
explained in the following subsections. explained in the following subsections.
1. Private Use 1. Private Use
2. Experimental Use 2. Experimental Use
3. Hierarchical Allocation 3. Hierarchical Allocation
4. First Come First Served 4. First Come First Served
5. Expert Review 5. Expert Review
6. Specification Required 6. Specification Required
7. RFC Required 7. RFC Required
8. IETF Review 8. IETF Review
9. Standards Action 9. Standards Action
10. IESG Approval 10. IESG Approval
It should be noted that it often makes sense to partition a namespace It should be noted that it often makes sense to partition a namespace
into multiple categories, with assignments within each category into multiple categories, with assignments within each category
handled differently. Many protocols now partition namespaces into handled differently. Many protocols now partition namespaces into
two or more parts, with one range reserved for Private or two or more parts, with one range reserved for Private or
Experimental Use while other ranges are reserved for globally unique Experimental Use while other ranges are reserved for globally unique
assignments assigned following some review process. Dividing a assignments assigned following some review process. Dividing a
namespace into ranges makes it possible to have different policies in namespace into ranges makes it possible to have different policies in
place for different ranges and different use cases. place for different ranges and different use cases.
skipping to change at page 18, line 4 skipping to change at page 19, line 31
be provided, as defined by the namespace. For numbers, the exact be provided, as defined by the namespace. For numbers, the exact
value is generally assigned by IANA; with names, specific text value is generally assigned by IANA; with names, specific text
strings can usually be requested. strings can usually be requested.
Examples: Examples:
SASL mechanism names [RFC4422] SASL mechanism names [RFC4422]
LDAP Protocol Mechanisms and LDAP Syntax [RFC4520] LDAP Protocol Mechanisms and LDAP Syntax [RFC4520]
4.5. Expert Review 4.5. Expert Review
(Also called "Designated Expert" in earlier editions of this (Also called "Designated Expert" in earlier editions of this
document.) For the Expert Review policy, review and approval by a document.) For the Expert Review policy, review and approval by a
designated expert (see Section 5) is required. The required designated expert (see Section 5) is required. The required
documentation and review criteria for use by the designated expert documentation and review criteria for use by the designated expert
should be provided when defining the registry. For example, see should be provided when defining the registry. For example, see
Sections 6 and 7.2 in [RFC3748]. Sections 6 and 7.2 in [RFC3748].
It is particularly important, when using a designated expert, to give It is particularly important, when using a designated expert, to give
clear guidance to the expert, laying out criteria for performing an clear guidance to the expert, laying out criteria for performing an
evaluation and reasons for rejecting a request. When specifying a evaluation and reasons for rejecting a request. When specifying a
policy that involves a designated expert, the IANA Considerations policy that involves a designated expert, the IANA Considerations
SHOULD contain such guidance. It is also a good idea to include, SHOULD contain such guidance. It is also a good idea to include,
skipping to change at page 19, line 18 skipping to change at page 20, line 49
associated documentation, must be published in an RFC. The RFC need associated documentation, must be published in an RFC. The RFC need
not be in the IETF stream, but may be in any RFC stream (currently an not be in the IETF stream, but may be in any RFC stream (currently an
RFC may be in the IETF, IRTF, or IAB stream, or an RFC Editor RFC may be in the IETF, IRTF, or IAB stream, or an RFC Editor
Independent Submission [RFC5742]). Unless otherwise specified, any Independent Submission [RFC5742]). Unless otherwise specified, any
type of RFC is sufficient (currently Standards Track, BCP, type of RFC is sufficient (currently Standards Track, BCP,
Informational, Experimental, or Historic). Informational, Experimental, or Historic).
4.8. IETF Review 4.8. IETF Review
(Formerly called "IETF Consensus" in the first edition of this (Formerly called "IETF Consensus" in the first edition of this
document.) With the IETF Review policy, new values are assigned only document.) With the IETF Review policy, new values are assigned only
through RFCs in the IETF Stream -- those that have been shepherded through RFCs in the IETF Stream -- those that have been shepherded
through the IESG as AD-Sponsored or IETF working group Documents through the IESG as AD-Sponsored or IETF working group Documents
[RFC2026] [RFC5378]. [RFC2026] [RFC5378].
The intent is that the document and proposed assignment will be The intent is that the document and proposed assignment will be
reviewed by the IETF community (including appropriate IETF working reviewed by the IETF community (including appropriate IETF working
groups, directorates, and other experts) and by the IESG, to ensure groups, directorates, and other experts) and by the IESG, to ensure
that the proposed assignment will not negatively affect that the proposed assignment will not negatively affect
interoperability or otherwise extend IETF protocols in an interoperability or otherwise extend IETF protocols in an
inappropriate or damaging manner. To ensure adequate community inappropriate or damaging manner. To ensure adequate community
skipping to change at page 22, line 32 skipping to change at page 24, line 22
should have a single chair responsible for defining how requests are should have a single chair responsible for defining how requests are
to be assigned to and reviewed by experts. In some cases, the expert to be assigned to and reviewed by experts. In some cases, the expert
pool may consist of a primary and backups, with the backups involved pool may consist of a primary and backups, with the backups involved
only when the primary expert is unavailable. In other cases, IANA only when the primary expert is unavailable. In other cases, IANA
might assign requests to individual members in sequential or might assign requests to individual members in sequential or
approximate random order. In the event that IANA finds itself having approximate random order. In the event that IANA finds itself having
received conflicting advice from its experts, it is the received conflicting advice from its experts, it is the
responsibility of the pool's chair to resolve the issue and provide responsibility of the pool's chair to resolve the issue and provide
IANA with clear instructions. IANA with clear instructions.
Since the designated experts are appointed by the IESG, they may be A designated expert that is conflicted for a particular review (is,
for example, an authors or significant proponent of a specification
related to the registration under review), that expert should recuse
himself. In the event that all the designated experts are
conflicted, they should ask the IESG to designate a temporary expert
for the conflicted review.
As the designated experts are appointed by the IESG, they may be
removed by the IESG. removed by the IESG.
5.3. Designated Expert Reviews 5.3. Designated Expert Reviews
In the years since RFC 2434 was published and has been put to use, In the years since RFC 2434 was published and has been put to use,
experience has led to the following observations: experience has led to the following observations:
o A designated expert must respond in a timely fashion, normally o A designated expert must respond in a timely fashion, normally
within a week for simple requests to a few weeks for more complex within a week for simple requests to a few weeks for more complex
ones. Unreasonable delays can cause significant problems for ones. Unreasonable delays can cause significant problems for
skipping to change at page 24, line 32 skipping to change at page 26, line 33
were re-reviewed, cause the expert not to approve the registration. were re-reviewed, cause the expert not to approve the registration.
It is up to the IESG, with the token held by the responsible Area It is up to the IESG, with the token held by the responsible Area
Director, to be alert to such situations and to recognize that such Director, to be alert to such situations and to recognize that such
changes need to be checked. changes need to be checked.
6. Well-Known Registration Status Terminology 6. Well-Known Registration Status Terminology
The following labels describe the status of an assignment or range of The following labels describe the status of an assignment or range of
assignments: assignments:
Private Use: Private use only (not assigned), as described in Private Use: Private use only (not assigned), as described in
Section 4.1. Section 4.1.
Experimental: Available for general experimental use as described Experimental: Available for general experimental use as described
in [RFC3692]. IANA does not record specific assignments for in [RFC3692]. IANA does not record specific assignments for
any particular use. any particular use.
Unassigned: Not currently assigned, and available for assignment Unassigned: Not currently assigned, and available for assignment
via documented procedures. While it's generally clear that via documented procedures. While it's generally clear that
any values that are not registered are unassigned and any values that are not registered are unassigned and
available for assignment, it is sometimes useful to available for assignment, it is sometimes useful to
explicitly specify that situation. Note that this is explicitly specify that situation. Note that this is
distinctly different from "Reserved". distinctly different from "Reserved".
Reserved: Not assigned and not available for assignment. Reserved Reserved: Not assigned and not available for assignment.
values are held for special uses, such as to extend the Reserved values are held for special uses, such as to extend
namespace when it becomes exhausted. Note that this is the namespace when it becomes exhausted. Note that this is
distinctly different from "Unassigned". distinctly different from "Unassigned".
Reserved values can be released for assignment by the change Reserved values can be released for assignment by the change
controller for the registry (this is often the IESG, for controller for the registry (this is often the IESG, for
registries created by RFCs in the IETF stream). registries created by RFCs in the IETF stream).
7. Documentation References in IANA Registries 7. Documentation References in IANA Registries
Usually, registries and registry entries include references to Usually, registries and registry entries include references to
documentation (RFCs or other documents). The purpose of these documentation (RFCs or other documents). The purpose of these
references is to provide pointers for implementors to find details references is to provide pointers for implementors to find details
necessary for implementation, NOT to simply note what document necessary for implementation, NOT to simply note what document
created the registry or entry. Therefore: created the registry or entry. Therefore:
o If a document registers an item that is defined and explained o If a document registers an item that is defined and explained
elsewhere, the registered reference should be to that document, elsewhere, the registered reference should be to that document,
and not to the document that is merely performing the and not to the document that is merely performing the
registration. registration.
skipping to change at page 26, line 7 skipping to change at page 28, line 20
reference for some items, but not for others. Be sure that the reference for some items, but not for others. Be sure that the
references are always set to point to the correct, current references are always set to point to the correct, current
documentation for each item. documentation for each item.
For example, suppose RFC 9876 registered the "BANANA" flag in the For example, suppose RFC 9876 registered the "BANANA" flag in the
"Fruit Access Flags" registry, and the documentation for that flag is "Fruit Access Flags" registry, and the documentation for that flag is
in Section 3.2. in Section 3.2.
The current registry might look, in part, like this: The current registry might look, in part, like this:
Name Description Reference Name Description Reference
-------- ------------------- --------- -------- ------------------- ---------
BANANA Flag for bananas [RFC9876], Section 3.2 BANANA Flag for bananas [RFC9876], Section 3.2
If draft-ietf-foo-rfc9876bis obsoletes RFC 9876 and, because of some If draft-ietf-foo-rfc9876bis obsoletes RFC 9876 and, because of some
rearrangement, now documents the flag in Section 4.1.2, the IANA rearrangement, now documents the flag in Section 4.1.2, the IANA
Considerations of the bis document might contain text such as this: Considerations of the bis document might contain text such as this:
IANA is asked to change the registration information for the IANA is asked to change the registration information for the
BANANA flag in the "Fruit Access Flags" registry to the following: BANANA flag in the "Fruit Access Flags" registry to the following:
Name Description Reference Name Description Reference
-------- ------------------- --------- -------- ------------------- ---------
BANANA Flag for bananas [[this RFC]], Section 4.2.1 BANANA Flag for bananas [[this RFC]], Section 4.2.1
In many cases, if there are a number of registered references to the In many cases, if there are a number of registered references to the
original RFC and the document organization has not changed the original RFC and the document organization has not changed the
registered section numbering much, it may simply be reasonable to do registered section numbering much, it may simply be reasonable to do
this: this:
Because this document obsoletes RFC 9876, IANA is asked to change Because this document obsoletes RFC 9876, IANA is asked to change
all registration information that references [RFC9876] to instead all registration information that references [RFC9876] to instead
reference [[this RFC]]. reference [[this RFC]].
skipping to change at page 31, line 18 skipping to change at page 33, line 49
o Made some clarifications in "Specification Required" about how to o Made some clarifications in "Specification Required" about how to
declare this policy. declare this policy.
o Assorted minor clarifications and editorial changes throughout. o Assorted minor clarifications and editorial changes throughout.
13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 13.2. 2008: Changes in RFC 5226 Relative to RFC 2434
Changes include: Changes include:
o Major reordering of text to expand descriptions and to better o Major reordering of text to expand descriptions and to better
group topics such as "updating registries" vs. "creating new group topics such as "updating registries" vs. "creating new
registries", in order to make it easier for authors to find the registries", in order to make it easier for authors to find the
text most applicable to their needs. text most applicable to their needs.
o Numerous editorial changes to improve readability. o Numerous editorial changes to improve readability.
o Changed the term "IETF Consensus" to "IETF Review" and added more o Changed the term "IETF Consensus" to "IETF Review" and added more
clarifications. History has shown that people see the words "IETF clarifications. History has shown that people see the words "IETF
Consensus" (without consulting the actual definition) and are Consensus" (without consulting the actual definition) and are
quick to make incorrect assumptions about what the term means in quick to make incorrect assumptions about what the term means in
the context of IANA Considerations. the context of IANA Considerations.
skipping to change at page 32, line 50 skipping to change at page 35, line 40
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References 15.2. Informative References
[I-D.cotton-rfc4020bis] [I-D.cotton-rfc4020bis]
Cotton, M., "Early IANA Allocation of Standards Track Code Cotton, M., "Early IANA Allocation of Standards Track Code
Points", Internet-Draft draft-cotton-rfc4020bis-02, Points", draft-cotton-rfc4020bis-02 (work in progress),
October 2013. October 2013.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Extensions", RFC 2132, March 1997.
[RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000. Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain
Name System (DNS) IANA Considerations", RFC 2929,
September 2000.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939, of New DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000. September 2000.
[RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group
Management Protocol (IGMP)", BCP 57, RFC 3228, February Management Protocol (IGMP)", BCP 57, RFC 3228, February
2002. 2002.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July Text on Security Considerations", BCP 72, RFC 3552, July
2003. 2003.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July Authentication Dial In User Service)", RFC 3575, July
2003. 2003.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration
Protocol version 4 (DHCPv4) Options", RFC 3942, November Protocol version 4 (DHCPv4) Options", RFC 3942, November
2004. 2004.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, December Initiation Protocol (SIP)", BCP 98, RFC 3968, December
2004. 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
Network Access Server Application", RFC 4005, August 2005. "Diameter Network Access Server Application", RFC 4005,
August 2005.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
[RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044,
May 2005. May 2005.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, June Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
2005. 2005.
[RFC4169] Torvinen, V., Arkko, J. and M. Naslund, "Hypertext [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext
Transfer Protocol (HTTP) Digest Authentication Using Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA) Version-2", RFC Authentication and Key Agreement (AKA) Version-2", RFC
4169, November 2005. 4169, November 2005.
[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", RFC 4288, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4395] Hansen, T., Hardie, T. and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC Registration Procedures for New URI Schemes", BCP 35, RFC
4395, February 2006. 4395, February 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006. Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
skipping to change at page 35, line 9 skipping to change at page 37, line 48
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008. to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for
Handling of Independent and IRTF Stream Submissions", BCP Handling of Independent and IRTF Stream Submissions", BCP
92, RFC 5742, December 2009. 92, RFC 5742, December 2009.
[RFC5771] Cotton, M., Vegoda, L. and D. Meyer, "IANA Guidelines for [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771, IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
March 2010. March 2010.
[RFC5795] Sandlund, K., Pelletier, G. and L-E. Jonsson, "The RObust [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, March Header Compression (ROHC) Framework", RFC 5795, March
2010. 2010.
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6195, March 2011. Considerations", RFC 6195, March 2011.
[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
September 2012. September 2012.
Authors' Addresses Authors' Addresses
Michelle Cotton Michelle Cotton
Internet Corporation for Assigned Names and Numbers Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536 Los Angeles, CA 90094-2536
US US
Phone: +1 310 823 9358 Phone: +1 310 823 9358
Email: michelle.cotton@icann.org Email: michelle.cotton@icann.org
URI: http://www.icann.org/ URI: http://www.icann.org/
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
3039 Cornwallis Ave., PO Box 12195 - BRQA/502 3039 Cornwallis Ave., PO Box 12195 - BRQA/502
Research Triangle Park, NC 27709-2195 Research Triangle Park, NC 27709-2195
US US
Phone: +1 919 254 7798 Phone: +1 919 254 7798
Email: narten@us.ibm.com Email: narten@us.ibm.com
 End of changes. 51 change blocks. 
150 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/