< draft-leiba-cotton-iana-5226bis-05.txt   draft-leiba-cotton-iana-5226bis-06.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: December 5, 2014 IBM Corporation Expires: January 02, 2015 IBM Corporation
June 3, 2014 July 03, 2014
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-05 draft-leiba-cotton-iana-5226bis-06
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 December 5, 2014. This Internet-Draft will expire on January 02, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 Provisions Relating to IETF Documents (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
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 . . . . . . . . . . . . 4 1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 3
1.2. For More Information . . . . . . . . . . . . . . . . . . 4 1.2. For More Information . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology Used In This Document . . . . . . . . . . . . 5 1.3. Terminology Used In This Document . . . . . . . . . . . . 4
2. Creating and Revising Registries . . . . . . . . . . . . . . 5 2. Creating and Revising Registries . . . . . . . . . . . . . . . 4
2.1. Hierarchical Registry Structure . . . . . . . . . . . . . 5 2.1. Hierarchical Registry Structure . . . . . . . . . . . . . 5
2.2. Documentation Requirements for Registries . . . . . . . . 7 2.2. Documentation Requirements for Registries . . . . . . . . 6
2.3. Defining an Appropriate Registry Policy . . . . . . . . . 9 2.3. Defining an Appropriate Registry Policy . . . . . . . . . 8
2.3.1. Using the Well-Known Registration Policies . . . . . 11 2.3.1. Using the Well-Known Registration Policies . . . . . . 10
2.3.2. Using Multiple Policies in Combination . . . . . . . 13 2.3.2. Using Multiple Policies in Combination . . . . . . . . 11
2.3.3. Specifying Change Control for a Registry . . . . . . 13 2.3.3. Specifying Change Control for a Registry . . . . . . . 12
2.4. Revising Existing Registries . . . . . . . . . . . . . . 14 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 12
3. Registering New Values in an Existing Registry . . . . . . . 14 3. Registering New Values in an Existing Registry . . . . . . . . 13
3.1. Documentation Requirements for Registrations . . . . . . 14 3.1. Documentation Requirements for Registrations . . . . . . . 13
3.2. Updating Existing Registrations . . . . . . . . . . . . . 16 3.2. Updating Existing Registrations . . . . . . . . . . . . . 14
3.3. Overriding Registration Procedures . . . . . . . . . . . 16 3.3. Overriding Registration Procedures . . . . . . . . . . . . 15
3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 17 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15
4. Well-Known Registration Policies . . . . . . . . . . . . . . 17 4. Well-Known Registration Policies . . . . . . . . . . . . . . . 15
4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . 18 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 17
4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 18 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17
4.4. First Come First Served . . . . . . . . . . . . . . . . . 19 4.4. First Come First Served . . . . . . . . . . . . . . . . . 17
4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 19 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17
4.6. Specification Required . . . . . . . . . . . . . . . . . 20 4.6. Specification Required . . . . . . . . . . . . . . . . . . 18
4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . 20 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19
4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 20 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19
4.9. Standards Action . . . . . . . . . . . . . . . . . . . . 21 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 19
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 21 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 19
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . 22 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 20
5.1. The Motivation for Designated Experts . . . . . . . . . . 22 5.1. The Motivation for Designated Experts . . . . . . . . . . 20
5.2. The Role of the Designated Expert . . . . . . . . . . . . 23 5.2. The Role of the Designated Expert . . . . . . . . . . . . 21
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 22
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 26 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 24
6. Well-Known Registration Status Terminology . . . . . . . . . 26 6. Well-Known Registration Status Terminology . . . . . . . . . . 24
7. Documentation References in IANA Registries . . . . . . . . . 27 7. Documentation References in IANA Registries . . . . . . . . . 25
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 25
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 29 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 26
9.1. When There Are No IANA Actions . . . . . . . . . . . . . 29 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 26
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . 29 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 27
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . 30 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 27
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . 30 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 28
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 31 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 28
9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . 31 9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 29
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 32 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . 32 13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 30
13.1. 2013: Changes in This Document Relative to RFC 5226 . . 32 13.1. 2014: Changes in This Document Relative to RFC 5226 . . . 30
13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 33 13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Acknowledgments for This Document (2013) . . . . . . . . 34 14.1. Acknowledgments for This Document (2014) . . . . . . . . 32
14.2. Acknowledgments from the second edition (2008) . . . . . 35 14.2. Acknowledgments from the second edition (2008) . . . . . 32
14.3. Acknowledgments from the first edition (1998) . . . . . 35 14.3. Acknowledgments from the first edition (1998) . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 35 15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 35 15.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
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 19 skipping to change at page 4, line 4
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.
Typically, this information is recorded in a dedicated section of the Typically, this information is recorded in a dedicated section of the
specification with the title "IANA Considerations". specification with the title "IANA Considerations".
1.1. Keep IANA Considerations for IANA 1.1. Keep IANA Considerations for IANA
The purpose of having a dedicated IANA Considerations section is to The purpose of having a dedicated IANA Considerations section is to
provide a single place to collect clear and concise information and provide a single place to collect clear and concise information and
instructions for IANA. Technical documentation should reside in instructions for IANA. Technical documentation should reside in
other parts of the document, and should be included by reference other parts of the document, and should be included by reference
only. Using the IANA Considerations section as primary technical only. Using the IANA Considerations section as primary technical
documentation both hides it from the target audience of the document documentation both hides it from the target audience of the document
and interferes with IANA's review of the actions they need to take. and interferes with IANA's review of the actions they need to take.
If, for example, the registration of an item in a registry includes a If, for example, the registration of an item in a registry includes a
short description of the item being registered, that should be placed short description of the item being registered, that should be placed
in the IANA Considerations directly. But if it's necessary to in the IANA Considerations directly. But if it's necessary to
include a longer technical explanation of the purpose and use of the include a longer technical explanation of the purpose and use of the
item, the IANA Considerations should refer to a technical section of item, the IANA Considerations should refer to a technical section of
the document where that information resides. the document where that information resides. Similarly, if the
document is pointing out the use of an existing assignment in a
registry, but makes no modification to the registration, that should
be in a technical section of the document, reserving the IANA
Considerations section for instructions to IANA.
An ideal IANA Considerations section clearly enumerates and specifies An ideal IANA Considerations section clearly enumerates and specifies
each requested IANA action; includes all information IANA needs, such each requested IANA action; includes all information IANA needs, such
as the full names of all applicable registries; and includes clear as the full names of all applicable registries; and includes clear
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>.
[[CREF1: ***** The URI above is not yet ready. Make sure IANA sets [[***** The URI above is not yet ready. IANA is setting it up.
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 7, line 42 skipping to change at page 7, line 11
easily confused with the name of another registry. easily confused with the name of another registry.
When creating a sub-registry, the registry that it is a part of When creating a sub-registry, the registry that it is a part of
must be identified using its full name, exactly as it appears in must be identified using its full name, exactly as it appears in
the IANA registry list. the IANA registry list.
Providing a URL to precisely identify the registry helps IANA Providing a URL to precisely identify the registry helps IANA
understand the request. Such URLs can be removed from the RFC understand the request. Such URLs can be removed from the RFC
prior to final publication. If they are to be left in, it is prior to final publication. If they are to be left in, it is
important that they be permanent links -- IANA intends to include important that they be permanent links -- IANA intends to include
the permalink for each registry in the registry header. the permalink for each registry in the registry header. [[*****
This is not yet done, but is planned. *****]]
For example, a document could contain something like this: For example, a document could contain something like this:
This registration should be made in the Foobar Operational This registration should be made in the Foobar Operational
Parameters registry, located at <http://www.iana.org/ Parameters registry, located at <http://www.iana.org/
assignments/foobar-registry>. assignments/foobar-registry>.
It might be tempting to use the URL that appears in your web It might be tempting to use the URL that appears in your web
browser's address bar, which might look something like this for browser's address bar, which might look something like this for
the example above: the example above:
skipping to change at page 8, line 39 skipping to change at page 7, line 54
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 14, line 6 skipping to change at page 12, line 39
outside the IETF and IESG, and clear specification of change control outside the IETF and IESG, and clear specification of change control
policies is always helpful. policies is always helpful.
It is advised, therefore, that all registries that are created It is advised, therefore, that all registries that are created
clearly specify a change control policy and a change controller. It clearly specify a change control policy and a change controller. It
is also advised that registries that allow registrations from outside is also advised that registries that allow registrations from outside
the IETF stream include, for each value, the designation of a change the IETF stream include, for each value, the designation of a change
controller for that value. If the definition or reference for a controller for that value. If the definition or reference for a
registered value ever needs to change, or if a registered value needs registered value ever needs to change, or if a registered value needs
to be deprecated, it is critical that IANA know who is authorized to to be deprecated, it is critical that IANA know who is authorized to
make the change. make the change. See also Section 9.5.
2.4. Revising Existing Registries 2.4. Revising Existing Registries
Updating the registration process for an already existing (previously Updating the registration process or making changes to the format of
created) namespace (whether created explicitly or implicitly) follows an already existing (previously created) registry (whether created
a process similar to that used when creating a new namespace. That explicitly or implicitly) follows a process similar to that used when
is, a document is produced that makes reference to the existing creating a new registry. That is, a document is produced that makes
namespace and then provides detailed guidelines for handling reference to the existing namespace and then provides detailed
assignments in each individual namespace. Such documents are guidance for handling assignments in the registry, or detailed
normally processed as Best Current Practices (BCPs) [RFC2026]. instructions about the changes required.
If a change requires a new column in the registry, the instructions
need to be clear about how to populate that column for the existing
entries. Other changes may require similar clarity. Remember to
check this, and give clear instructions to IANA.
Such documents are normally processed with the same document status
as the document that created the registry, or as Best Current
Practices (BCPs) [RFC2026].
Example documents that updated the guidelines for assignments in pre- Example documents that updated the guidelines for assignments in pre-
existing registries include: [RFC6195], [RFC3228], and [RFC3575]. existing registries include: [RFC6195], [RFC3228], and [RFC3575].
3. Registering New Values in an Existing Registry 3. Registering New Values in an Existing Registry
3.1. Documentation Requirements for Registrations 3.1. Documentation Requirements for Registrations
Often, documents request an assignment from an already existing Often, documents request an assignment from an already existing
namespace (one created by a previously published document). namespace (one created by a previously published document).
skipping to change at page 15, line 13 skipping to change at page 13, line 48
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 17, line 21 skipping to change at page 15, line 52
3.4. Early Allocations 3.4. Early Allocations
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 [RFC7120] 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 19, line 31 skipping to change at page 18, line 4
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 20, line 32 skipping to change at page 19, line 4
necessary review for interoperability, though the designated expert necessary review for interoperability, though the designated expert
may be a particularly well-qualified person to perform such a review. may be a particularly well-qualified person to perform such a review.
When specifying this policy, just use the term "Specification When specifying this policy, just use the term "Specification
Required". Some specifications have chosen to refer to it as "Expert Required". Some specifications have chosen to refer to it as "Expert
Review with Specification Required", and that only causes confusion. Review with Specification Required", and that only causes confusion.
Examples: Examples:
Diffserv-aware TE Bandwidth Constraints Model Identifiers Diffserv-aware TE Bandwidth Constraints Model Identifiers
[RFC4124] [RFC4124]
TLS ClientCertificateType Identifiers 64-223 [RFC5246] TLS ClientCertificateType Identifiers 64-223 [RFC5246]
ROHC Profile Identifiers [RFC5795] ROHC Profile Identifiers [RFC5795]
4.7. RFC Required 4.7. RFC Required
With the RFC Required policy, the registration request, along with With the RFC Required policy, the registration request, along with
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 24, line 22 skipping to change at page 22, line 35
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.
A designated expert that is conflicted for a particular review (is, If a designated expert is conflicted for a particular review (is, for
for example, an authors or significant proponent of a specification example, an author or significant proponent of a specification
related to the registration under review), that expert should recuse related to the registration under review), that expert should recuse
himself. In the event that all the designated experts are himself. In the event that all the designated experts are
conflicted, they should ask the IESG to designate a temporary expert conflicted, they should ask the IESG to designate a temporary expert
for the conflicted review. for the conflicted review.
As the designated experts are appointed by the IESG, they may be 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
skipping to change at page 26, line 33 skipping to change at page 24, line 37
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: Not assigned and not available for assignment. Reserved
Reserved values are held for special uses, such as to extend values are held for special uses, such as to extend the
the namespace when it becomes exhausted. Note that this is 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
skipping to change at page 28, line 20 skipping to change at page 26, line 12
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]].
If information for registered items has been or is being moved to If information for registered items has been or is being moved to
other documents, then, of course, the registration information should other documents, then, of course, the registration information should
be changed to point to those other documents. In no case is it be changed to point to those other documents. In no case is it
reasonable to leave documentation pointers to the obsoleted document reasonable to leave documentation pointers to the obsoleted document
for any registries or registered items that are still in current use. for any registries or registered items that are still in current use.
It is extremely important to be clear in your instructions regarding
updating references, especially in cases where some references need
to be updated and others do not.
9. Miscellaneous Issues 9. Miscellaneous Issues
9.1. When There Are No IANA Actions 9.1. When There Are No IANA Actions
Before an Internet-Draft can be published as an RFC, IANA needs to Before an Internet-Draft can be published as an RFC, IANA needs to
know what actions (if any) it needs to perform. Experience has shown know what actions (if any) it needs to perform. Experience has shown
that it is not always immediately obvious whether a document has no that it is not always immediately obvious whether a document has no
IANA actions, without reviewing the document in some detail. In IANA actions, without reviewing the document in some detail. In
order to make it clear to IANA that it has no actions to perform (and order to make it clear to IANA that it has no actions to perform (and
that the author has consciously made such a determination), such that the author has consciously made such a determination), such
skipping to change at page 29, line 51 skipping to change at page 27, line 44
or or
[RFC Editor: please do not remove this section.] [RFC Editor: please do not remove this section.]
9.2. Namespaces Lacking Documented Guidance 9.2. Namespaces Lacking Documented Guidance
For all existing RFCs that either explicitly or implicitly rely on For all existing RFCs that either explicitly or implicitly rely on
IANA to make assignments without specifying a precise assignment IANA to make assignments without specifying a precise assignment
policy, IANA (in consultation with the IESG) will continue to decide policy, IANA (in consultation with the IESG) will continue to decide
what policy is appropriate. Changes to existing policies can always what policy is appropriate. Changes to existing policies can always
be initiated through the normal IETF consensus process. be initiated through the normal IETF consensus process, or through
the IESG when appropriate.
All future RFCs that either explicitly or implicitly rely on IANA to All future RFCs that either explicitly or implicitly rely on IANA to
register or otherwise administer namespace assignments MUST provide register or otherwise administer namespace assignments MUST provide
guidelines for administration of the namespace. guidelines for administration of the namespace.
9.3. After-the-Fact Registrations 9.3. After-the-Fact Registrations
Occasionally, the IETF becomes aware that an unassigned value from a Occasionally, the IETF becomes aware that an unassigned value from a
namespace is in use on the Internet or that an assigned value is namespace is in use on the Internet or that an assigned value is
being used for a different purpose than it was registered for. The being used for a different purpose than it was registered for. The
IETF does not condone such misuse; procedures of the type described IETF does not condone such misuse; procedures of the type described
in this document MUST be applied to such cases. In the absence of in this document MUST be applied to such cases. In the absence of
specifications to the contrary, values may only be reassigned for a specifications to the contrary, values may only be reassigned for a
different purpose with the consent of the original assignee (when different purpose with the consent of the original assignee (when
possible) and with due consideration of the impact of such a possible) and with due consideration of the impact of such a
reassignment. In cases of likely controversy, consultation with the reassignment. In cases of likely controversy, consultation with the
IESG is advised. IESG is advised.
skipping to change at page 31, line 14 skipping to change at page 29, line 4
9.5. Contact Person vs Assignee or Owner 9.5. Contact Person vs Assignee or Owner
Many registries include designation of a technical or administrative Many registries include designation of a technical or administrative
contact associated with each entry. Often, this is recorded as contact associated with each entry. Often, this is recorded as
contact information for an individual. It is unclear, though, what contact information for an individual. It is unclear, though, what
role the individual has with respect to the registration: is this role the individual has with respect to the registration: is this
item registered on behalf of the individual, the company the item registered on behalf of the individual, the company the
individual worked for, or perhaps another organization the individual individual worked for, or perhaps another organization the individual
was acting for? was acting for?
This matters because some time later, when the individual has changed This matters because some time later, when the individual has changed
jobs or roles, and perhaps can no longer be contacted, someone might jobs or roles, and perhaps can no longer be contacted, someone might
want to update the registration. IANA has no way to know what want to update the registration. IANA has no way to know what
company, organization, or individual should be allowed to take the company, organization, or individual should be allowed to take the
registration over. For registrations rooted in RFCs, the stream registration over. For registrations rooted in RFCs, the stream
owner (such as the IESG or the IAB) can make an overriding decision. owner (such as the IESG or the IAB) can make an overriding decision.
But in other cases, there is no recourse. But in other cases, there is no recourse.
Registries can include, in addition to a "Contact" field, an Registries can include, in addition to a "Contact" field, an
"Assignee" or "Owner" field that can be used to address this "Assignee" or "Owner" field that can be used to address this
situation, giving IANA clear guidance as to the actual owner of the situation, giving IANA clear guidance as to the actual owner of the
registration. Alternatively, organizations can put an organizational registration. This is strongly advised especially for registries
role into the "Contact" field in order to make their ownership clear. that do not require RFCs to manage their information (registries with
policies such as First Come First Served Section 4.4, Expert Review
Section 4.5, and Specification Required Section 4.6). Alternatively,
organizations can put an organizational role into the "Contact" field
in order to make their ownership clear.
9.6. Closing or Obsoleting a Registry 9.6. Closing or Obsoleting a Registry
Sometimes there is a request to "close" a registry to further Sometimes there is a request to "close" a registry to further
registrations. When a registry is closed, no further registrations registrations. When a registry is closed, no further registrations
will be accepted. The information in the registry will still be will be accepted. The information in the registry will still be
valid and registrations already in the registry can still be updated. valid and registrations already in the registry can still be updated.
A closed registry can also be marked as "obsolete", as an indication A closed registry can also be marked as "obsolete", as an indication
that the information in the registry is no longer in current use. that the information in the registry is no longer in current use.
skipping to change at page 32, line 41 skipping to change at page 30, line 29
protocols that make use of parameters (data types, operation codes, protocols that make use of parameters (data types, operation codes,
keywords, etc.) used in IETF protocols or registered by IANA. Such keywords, etc.) used in IETF protocols or registered by IANA. Such
security considerations are usually included in the protocol document security considerations are usually included in the protocol document
[RFC3552]. It is the responsibility of the IANA considerations [RFC3552]. It is the responsibility of the IANA considerations
associated with a particular registry to specify what (if any) associated with a particular registry to specify what (if any)
security considerations must be provided when assigning new values, security considerations must be provided when assigning new values,
and the process for reviewing such claims. and the process for reviewing such claims.
13. Changes Relative to Earlier Editions of BCP 26 13. Changes Relative to Earlier Editions of BCP 26
13.1. 2013: Changes in This Document Relative to RFC 5226 13.1. 2014: Changes in This Document Relative to RFC 5226
Significant additions: Significant additions:
o Added Section 1.1, Keep IANA Considerations for IANA o Added Section 1.1, Keep IANA Considerations for IANA
o Added Section 1.2, For More Information o Added Section 1.2, For More Information
o Added Section 2.1, Hierarchical Registry Structure o Added Section 2.1, Hierarchical Registry Structure
o Added Section 2.3, Best Practice for Selecting an Appropriate o Added Section 2.3, Best Practice for Selecting an Appropriate
Policy. Policy.
o Added Section 2.3.2, Using Multiple Policies in Combination. o Added Section 2.3.2, Using Multiple Policies in Combination.
o Added Section 2.3.3, Specifying Change Control for a Registry o Added Section 2.3.3, Specifying Change Control for a Registry
o Added Section 3.4, Early Allocations o Added Section 3.4, Early Allocations
o Moved well-known policies into a separate section for each, o Moved well-known policies into a separate section for each,
skipping to change at page 33, line 49 skipping to change at page 31, line 31
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 34, line 39 skipping to change at page 32, line 18
o Added a section about reclaiming unused value. o Added a section about reclaiming unused value.
o Added a section on after-the-fact registrations. o Added a section on after-the-fact registrations.
o Added a section indicating that mailing lists used to evaluate o Added a section indicating that mailing lists used to evaluate
possible assignments (such as by a Designated Expert) are subject possible assignments (such as by a Designated Expert) are subject
to normal IETF rules. to normal IETF rules.
14. Acknowledgments 14. Acknowledgments
14.1. Acknowledgments for This Document (2013) 14.1. Acknowledgments for This Document (2014)
Thomas Narten and Harald Tveit Alvestrand edited the two earlier Thomas Narten and Harald Tveit Alvestrand edited the two earlier
editions of this document (RFCs 2434 and 5226), and Thomas continues editions of this document (RFCs 2434 and 5226), and Thomas continues
his role in this third edition. Much of the text from RFC 5226 his role in this third edition. Much of the text from RFC 5226
remains in this edition. remains in this edition.
Thank you to Amanda Baber and Pearl Liang for their multiple reviews
and suggestions for making this document as thorough as possible.
This document has benefited from thorough review and comments by John This document has benefited from thorough review and comments by John
Klensin and Mark Nottingham. Klensin and Mark Nottingham.
Special thanks to Mark Nottingham for reorganizing some of the text Special thanks to Mark Nottingham for reorganizing some of the text
for better organization and readability. for better organization and readability.
14.2. Acknowledgments from the second edition (2008) 14.2. Acknowledgments from the second edition (2008)
The original acknowledgments section in RFC 5226 was: The original acknowledgments section in RFC 5226 was:
skipping to change at page 35, line 38 skipping to change at page 33, line 13
15.1. Normative References 15.1. Normative References
[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]
Cotton, M., "Early IANA Allocation of Standards Track Code
Points", draft-cotton-rfc4020bis-02 (work in progress),
October 2013.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [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.
[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.
skipping to change at page 36, line 20 skipping to change at page 33, line 39
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, [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
"Diameter Network Access Server Application", RFC 4005, Network Access Server Application", RFC 4005, August 2005.
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", RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 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 37, line 48 skipping to change at page 35, line 9
[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", RFC 6195, March 2011. Considerations", BCP 42, 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.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014.
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
skipping to change at page 38, line 37 skipping to change at page 36, line 4
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. 59 change blocks. 
150 lines changed or deleted 168 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/