< draft-leiba-cotton-iana-5226bis-03.txt   draft-leiba-cotton-iana-5226bis-04.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: January 31, 2014 IBM Corporation Expires: May 14, 2014 IBM Corporation
August 01, 2013 November 12, 2013
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-03 draft-leiba-cotton-iana-5226bis-04
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).
skipping to change at page 2, line 4 skipping to change at page 1, line 47
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 January 31, 2014.
Copyright Notice This Internet-Draft will expire on May 14, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used In This Document . . . . . . . . . . . . 3 1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 3
1.2. For More Information . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology Used In This Document . . . . . . . . . . . . 4
2. Creating and Revising Registries . . . . . . . . . . . . . . . 4 2. Creating and Revising Registries . . . . . . . . . . . . . . . 4
2.1. Documentation Requirements for Registries . . . . . . . . 4 2.1. Hierarchical Registry Structure . . . . . . . . . . . . . 5
2.2. Defining an Appropriate Registry Policy . . . . . . . . . 6 2.2. Documentation Requirements for Registries . . . . . . . . 6
2.2.1. Using the Well-Known Registration Policies . . . . . . 8 2.3. Defining an Appropriate Registry Policy . . . . . . . . . 8
2.2.2. Using Multiple Policies in Combination . . . . . . . . 9 2.3.1. Using the Well-Known Registration Policies . . . . . . 10
2.3. Revising Existing Registries . . . . . . . . . . . . . . . 10 2.3.2. Using Multiple Policies in Combination . . . . . . . . 11
3. Registering New Values in an Existing Registry . . . . . . . . 10 2.3.3. Specifying Change Control for a Registry . . . . . . . 12
3.1. Documentation Requirements for Registrations . . . . . . . 10 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 12
3.2. Updating Existing Registrations . . . . . . . . . . . . . 12 3. Registering New Values in an Existing Registry . . . . . . . . 12
3.3. Overriding Registration Procedures . . . . . . . . . . . . 12 3.1. Documentation Requirements for Registrations . . . . . . . 12
4. Well-Known Registration Policies . . . . . . . . . . . . . . . 13 3.2. Updating Existing Registrations . . . . . . . . . . . . . 14
4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Overriding Registration Procedures . . . . . . . . . . . . 15
4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 14 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15
4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 14 4. Well-Known Registration Policies . . . . . . . . . . . . . . . 15
4.4. First Come First Served . . . . . . . . . . . . . . . . . 14 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 17
4.6. Specification Required . . . . . . . . . . . . . . . . . . 15 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17
4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. First Come First Served . . . . . . . . . . . . . . . . . 17
4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 16 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17
4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 16 4.6. Specification Required . . . . . . . . . . . . . . . . . . 18
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 17 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 17 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. The Motivation for Designated Experts . . . . . . . . . . 17 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 19
5.2. The Role of the Designated Expert . . . . . . . . . . . . 18 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 19
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 19 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 20
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 21 5.1. The Motivation for Designated Experts . . . . . . . . . . 20
6. Well-Known Registration Status Terminology . . . . . . . . . . 21 5.2. The Role of the Designated Expert . . . . . . . . . . . . 21
7. Documentation References in IANA Registries . . . . . . . . . 22 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 22
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 22 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 24
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 23 6. Well-Known Registration Status Terminology . . . . . . . . . . 24
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 23 7. Documentation References in IANA Registries . . . . . . . . . 24
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 24 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 25
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 24 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 26
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 25 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 26
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 25 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 27
9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 26 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 27
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 27
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 26 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 29
13. To-Do List; resolve and remove before requesting publication . 27 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 27 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1. 2013: Changes in This Document Relative to RFC 5226 . . . 27 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 28 13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 30
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. 2013: Changes in This Document Relative to RFC 5226 . . . 30
15.1. Acknowledgments for This Document (2013) . . . . . . . . 28 13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 31
15.2. Acknowledgments from the second edition (2008) . . . . . 29 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
15.3. Acknowledgments from the first edition (1998) . . . . . . 29 14.1. Acknowledgments for This Document (2013) . . . . . . . . 31
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14.2. Acknowledgments from the second edition (2008) . . . . . 32
16.1. Normative References . . . . . . . . . . . . . . . . . . 29 14.3. Acknowledgments from the first edition (1998) . . . . . . 32
16.2. Informative References . . . . . . . . . . . . . . . . . 29 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 32
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 protocol constant, or protocol parameter). The act of assignment is
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
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. Terminology Used In This Document 1.1. Keep IANA Considerations for IANA
The purpose of having a dedicated IANA Considerations section is to
provide a single place to collect clear and concise information and
instructions for IANA. Technical documentation should reside in
other parts of the document, and should be included by reference
only. Using the IANA Considerations section as primary technical
documentation both hides it from the target audience of the document
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
short description of the item being registered, that should be placed
in the IANA Considerations directly. But if it's necessary to
include a longer technical explanation of the purpose and use of the
item, the IANA Considerations should refer to a technical section of
the document where that information resides.
An ideal IANA Considerations section clearly enumerates and specifies
each requested IANA action; includes all information IANA needs, such
as the full names of all applicable registries; and includes clear
references to elsewhere in the document for other information.
1.2. For More Information
IANA maintains a web page that includes current important information
from IANA. Document authors should check that page for additional
information, beyond what is provided here.
<http://www.iana.org/important-information>.
[[***** The URI above is not yet ready. Make sure IANA sets it up.
*****]]
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.
2. Creating and Revising Registries 2. Creating and Revising Registries
Defining a registry involves describing the namespace(s) to be Defining a registry involves describing the namespace(s) to be
skipping to change at page 4, line 31 skipping to change at page 5, line 14
In particular, not all namespaces require a registry; in some cases, In particular, not all namespaces require a registry; in some cases,
assignments can be made independently and with no further (central) assignments can be made independently and with no further (central)
coordination. In the Domain Name System, for example, IANA only coordination. In the Domain Name System, for example, IANA only
deals with assignments at the higher levels, while subdomains are deals with assignments at the higher levels, while subdomains are
administered by the organization to which the space has been administered by the organization to which the space has been
delegated. When a namespace is delegated in this manner, the scope delegated. When a namespace is delegated in this manner, the scope
of IANA is limited to the parts of the namespace where IANA has of IANA is limited to the parts of the namespace where IANA has
authority. authority.
2.1. Documentation Requirements for Registries 2.1. Hierarchical 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:
<http://www.iana.org/protocols>.
That page lists registries in groups, like this:
---------------------------------------------------------------
Author Domain Signing Practices (ADSP) Parameters
ADSP Outbound Signing Practices RFC 5617
IETF Review
ADSP Specification Tags RFC 5617
IETF Review
Automatic Responses to Electronic Mail Parameters
Auto-Submitted Header Field RFC 5436
Keywords Specification Required
Auto-Submitted header field RFC 3834
optional parameters IETF Consensus
Autonomous System (AS) Numbers
16-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6996
RIR request to the IANA
or IETF Review
32-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6793,
RFC 6996
RIR request to the IANA
or IETF Review
---------------------------------------------------------------
The grouping allows related registries to be placed together, making
it easier for users of the registries to find the necessary
information. In the example section above, there are two registries
related to the ADSP protocol, and they are both placed in the "ADSP
Parameters" group.
Within the "ADSP Parameters" group are two registries: "ADSP Outbound
Signing Practices" and "ADSP Specification Tags". Clicking on the
title of one of these registries on the IANA Protocol Registries page
will take the reader to the details page for that registry. Often,
multiple registries are shown on the same details page.
Unfortunately, we have been inconsistent in how we refer to these
entities. The group names, as they are referred to here, have been
variously called "groups", "top-level registries", or just
"registries". The registries under them have been called
"registries" or "sub-registries". And when new registries are
created, the documents that define them often don't specify the
grouping at all, but only name the new registry. This results in
questions from IANA and delays in processing, or, worse, in related
registries that should have been grouped together, but that are
instead scattered about and hard to find and correlate.
Regardless of the terminology used, document authors should pay
attention to the registry groupings, should request that related
registries be grouped together, and, when creating a new registry,
should check whether that registry might best be included in an
existing group. That grouping information should be clearly
communicated to IANA in the registry creation request.
2.2. Documentation Requirements for Registries
Documents that create a new namespace (or modify the definition of an Documents that create a new namespace (or modify the definition of an
existing space) and that expect IANA to play a role in maintaining existing space) and that expect IANA to play a role in maintaining
that space (serving as a repository for registered values) MUST that space (serving as a repository for registered values) MUST
provide clear instructions on details of the namespace, either in the provide clear instructions on details of the namespace, either in the
IANA Considerations section, or referenced from it. IANA Considerations section, or referenced from it.
In particular, such instructions MUST include: In particular, such instructions MUST include:
The name of the registry (or sub-registry) The name of the registry (or sub-registry)
skipping to change at page 4, line 53 skipping to change at page 6, line 53
in future documents that need to allocate a value from the new in future documents that need to allocate a value from the new
space. The full name (and abbreviation, if appropriate) should be space. The full name (and abbreviation, if appropriate) should be
provided. It is highly desirable that the chosen name not be provided. It is highly desirable that the chosen name not be
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 are usually removed from the understand the request. Such URLs can be removed from the RFC
RFC prior to final publication. prior to final publication. If they are to be left in, it is
important that they be permanent links -- IANA intends to include
the permalink for each registry in the registry header.
For example, a document could contain something like this: For example, a document could contain something like this:
[TO BE REMOVED: This registration should be made in the Foobar This registration should be made in the Foobar Operational
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
browser's address bar, which might look something like this for
the example above:
http://www.iana.org/assignments/foobar-registry/foobar-
registry.xml
...but that is not the permanent link to the registry.
Required information for registrations Required information for registrations
This information may include the need to document relevant This information may include the need to document relevant
Security Considerations, if any. Security Considerations, if any.
Applicable review process Applicable review process
The review process that will apply to all future requests for The review process that will apply to all future requests for
registration. See Section 2.2. registration. See Section 2.3.
Size, format and syntax of registry entries Size, format and syntax of registry entries
What fields to record in the registry., and any technical What fields to record in the registry., and any technical
requirements upon registry entries (e.g., valid ranges for requirements upon registry entries (e.g., valid ranges for
integers, length limitations on strings, etc.) as well as the integers, length limitations on strings, etc.) as well as the
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,
skipping to change at page 6, line 39 skipping to change at page 8, line 39
0 Reserved 0 Reserved
1 Frobnitz See Section y.1 1 Frobnitz See Section y.1
2 NitzFrob See Section y.2 2 NitzFrob See Section y.2
3-254 Unassigned 3-254 Unassigned
255 Reserved 255 Reserved
--------------------------------------------------------------- ---------------------------------------------------------------
For examples of documents that establish registries, consult For examples of documents that establish registries, consult
[RFC6195], [RFC3575], [RFC3968], and [RFC4520]. [RFC6195], [RFC3575], [RFC3968], and [RFC4520].
2.2. Defining an Appropriate Registry Policy 2.3. Defining an Appropriate Registry Policy
There are several issues to consider when defining the policy for the There are several issues to consider when defining the policy for the
new assignments in a registry. new assignments in a registry.
If the registry's namespace is limited, assignments will need to be If the registry's namespace is limited, assignments will need to be
made carefully to prevent exhaustion. made carefully to prevent exhaustion.
Even when the space is essentially unlimited, however, it is usually Even when the space is essentially unlimited, however, it is usually
desirable to have at least a minimal review prior to assignment in desirable to have at least a minimal review prior to assignment in
order to: order to:
skipping to change at page 8, line 16 skipping to change at page 10, line 13
review and action by IANA, and RFC-Editor processing. review and action by IANA, and RFC-Editor processing.
Therefore, Working Groups and other document developers should use Therefore, Working Groups and other document developers should use
care in selecting appropriate registration policies when their care in selecting appropriate registration policies when their
documents create registries. They should select the least strict documents create registries. They should select the least strict
policy that suits a registry's needs, and look for specific policy that suits a registry's needs, and look for specific
justification for policies that require significant community justification for policies that require significant community
involvement (Specification Required, in terms of the well-known involvement (Specification Required, in terms of the well-known
policies). policies).
2.2.1. Using the Well-Known Registration Policies 2.3.1. Using the Well-Known Registration Policies
This document defines a number of registration policies in Section 4. This document defines a number of registration policies in Section 4.
Because they benefit from both community experience and wide Because they benefit from both community experience and wide
understanding, their use is encouraged when appropriate. understanding, their use is encouraged when appropriate.
It is also acceptable to cite one of the well-known policies and It is also acceptable to cite one of the well-known policies and
include additional guidelines for what kind of considerations should include additional guidelines for what kind of considerations should
be taken into account by the review process. be taken into account by the review process.
For example, RADIUS [RFC3575] specifies the use of a Designated For example, RADIUS [RFC3575] specifies the use of a Designated
skipping to change at page 9, line 41 skipping to change at page 11, line 34
the document itself; failing that, in the shepherd writeup). the document itself; failing that, in the shepherd writeup).
Likewise, the document shepherd should ensure that the selected Likewise, the document shepherd should ensure that the selected
policies have been justified before sending the document to the IESG. policies have been justified before sending the document to the IESG.
When specifications are revised, registration policies should be When specifications are revised, registration policies should be
reviewed in light of experience since the policies were set. reviewed in light of experience since the policies were set.
Note that the well-known policies are not exclusive; there are Note that the well-known policies are not exclusive; there are
situations where a different policy might be more appropriate. situations where a different policy might be more appropriate.
2.2.2. Using Multiple Policies in Combination 2.3.2. Using Multiple Policies in Combination
In some situations, it is necessary to define multiple registration In some situations, it is necessary to define multiple registration
policies. For example, registrations through the normal IETF process policies. For example, registrations through the normal IETF process
might use one policy, while registrations from outside the process might use one policy, while registrations from outside the process
would have a different policy applied. would have a different policy applied.
Thus, a particular registry might want to use a policy such as "RFC Thus, a particular registry might want to use a policy such as "RFC
Required" or "IETF Review" sometimes, with a designated expert Required" or "IETF Review" sometimes, with a designated expert
checking a "Specification Required" policy at other times. checking a "Specification Required" policy at other times.
skipping to change at page 10, line 17 skipping to change at page 12, line 11
IANA is asked to create the registry "Fruit Access Flags" as a IANA is asked to create the registry "Fruit Access Flags" as a
sub-registry of "Fruit Parameters". New registrations will be sub-registry of "Fruit Parameters". New registrations will be
permitted through either the IETF Review policy or the permitted through either the IETF Review policy or the
Specification Required policy [BCP26]. Specification Required policy [BCP26].
Such combinations will commonly use one of {Standards Action, IETF Such combinations will commonly use one of {Standards Action, IETF
Review, RFC Required} in combination with one of {Specification Review, RFC Required} in combination with one of {Specification
Required, Expert Review}. Required, Expert Review}.
2.3. Revising Existing Registries 2.3.3. Specifying Change Control for a Registry
Registry definitions and registrations within registries often need
to be changed after they are created. The process of making such
changes is complicated when it is unclear who is authorized to make
the changes. For registries created by RFCs in the IETF stream,
change control for the registry lies by default with the IETF, via
the IESG. The same is true for value registrations made in IETF-
stream RFCs.
But registries can be created and registrations can be made outside
the IETF stream, it can sometimes be desired to have change control
outside the IETF and IESG, and clear specification of change control
policies is always helpful.
It is advised, therefore, that all registries that are created
clearly specify a change control policy and a change controller. It
is also advised that registries that allow registrations from outside
the IETF stream include, for each value, the designation of a change
controller for that value. If the definition or reference for a
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
make the change.
2.4. Revising Existing Registries
Updating the registration process for an already existing (previously Updating the registration process for an already existing (previously
created) namespace (whether created explicitly or implicitly) follows created) namespace (whether created explicitly or implicitly) follows
a process similar to that used when creating a new namespace. That a process similar to that used when creating a new namespace. That
is, a document is produced that makes reference to the existing is, a document is produced that makes reference to the existing
namespace and then provides detailed guidelines for handling namespace and then provides detailed guidelines for handling
assignments in each individual namespace. Such documents are assignments in each individual namespace. Such documents are
normally processed as Best Current Practices (BCPs) [RFC2026]. normally processed 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-
skipping to change at page 10, line 31 skipping to change at page 13, line 4
a process similar to that used when creating a new namespace. That a process similar to that used when creating a new namespace. That
is, a document is produced that makes reference to the existing is, a document is produced that makes reference to the existing
namespace and then provides detailed guidelines for handling namespace and then provides detailed guidelines for handling
assignments in each individual namespace. Such documents are assignments in each individual namespace. Such documents are
normally processed as Best Current Practices (BCPs) [RFC2026]. normally processed 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).
Such documents should clearly identify the namespace in which each Such documents should clearly identify the namespace in which each
value is to be registered. If the registration goes into a sub- value is to be registered. If the registration goes into a sub-
registry, the author should clearly describe where the assignment or registry, the author should clearly describe where the assignment or
registration should go. Use the exact namespace name as listed on registration should go. Use the exact namespace name as listed on
the IANA web page, and cite the RFC where the namespace is defined. the IANA web page, and cite the RFC where the namespace is defined.
There is no need to mention what the assignment policy for new There is no need to mention what the assignment policy for new
assignments is, as that should be clear from the references. assignments is, as that should be clear from the references.
When referring to an existing registry, providing a URL to precisely When referring to an existing registry, providing a URL to precisely
identify the registry is helpful. Such URLs, however, should usually identify the registry is helpful. See Section 2.2 for details on
be removed from the RFC prior to final publication, since IANA URLs specifying the correct URL.
are not guaranteed to be stable in the future. In cases where it is
important to include a URL in the document, IANA should concur on its
inclusion.
For example, a document could contain something like this: For example, a document could contain something like this:
[TO BE REMOVED: This registration should be made in the Foobar This registration should be made in the Foobar Operational
Operational Parameters registry, located at http://www.iana.org/ Parameters registry, located at <http://www.iana.org/assignments/
assignments/foobar-registry] foobar-registry>.
Each value requested should be given a unique reference. When the Each value requested should be given a unique reference. When the
value is numeric, use the notation: TBD1, TBD2, etc. Throughout the value is numeric, use the notation: TBD1, TBD2, etc. Throughout the
document where an actual IANA-assigned value should be filled in, use document where an actual IANA-assigned value should be filled in, use
the "TBDx" notation. This helps ensure that the final RFC has the the "TBDx" notation. This helps ensure that the final RFC has the
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.
skipping to change at page 13, line 13 skipping to change at page 15, line 43
or to obviate the need for protocols to properly document their IANA or to obviate the need for protocols to properly document their IANA
considerations. Rather, it is to permit assignments in specific considerations. Rather, it is to permit assignments in specific
cases where it is obvious that the assignment should just be made, cases where it is obvious that the assignment should just be made,
but updating the IANA process beforehand is too onerous. but updating the IANA process beforehand is too onerous.
When the IESG is required to take action as described in this When the IESG is required to take action as described in this
section, it is a strong indicator that the applicable registration section, it is a strong indicator that the applicable registration
procedures should be updated, possibly in parallel with the work that procedures should be updated, possibly in parallel with the work that
instigated it. instigated it.
4. Well-Known Registration Policies 3.4. Early Allocations
IANA normally takes its actions when a document is approved for
publication. There are times, though, when early allocation of a
value is important for the development of a technology: for example,
when early implementations are created while the document is still
under development.
IANA has a mechanism for handling such early allocations in some
cases. See [I-D.cotton-rfc4020bis] for details.
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
skipping to change at page 13, line 46 skipping to change at page 16, line 35
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.
Similarly, it will often be useful to specify multiple policies in Similarly, it will often be useful to specify multiple policies in
parallel, with each policy being used under different circumstances. parallel, with each policy being used under different circumstances.
For more discussion of that topic, see Section 2.2.2. For more discussion of that topic, see Section 2.3.2.
Examples: Examples:
LDAP [RFC4520] LDAP [RFC4520]
TLS ClientCertificateType Identifiers [RFC5246] (as detailed in TLS ClientCertificateType Identifiers [RFC5246] (as detailed in
the subsections below) the subsections below)
Pseudowire Edge to Edge Emulation (PWE3) [RFC4446] Pseudowire Edge to Edge Emulation (PWE3) [RFC4446]
4.1. Private Use 4.1. Private Use
For private or local use only, with the type and purpose defined by For private or local use only, with the type and purpose defined by
the local site. No attempt is made to prevent multiple sites from the local site. No attempt is made to prevent multiple sites from
using the same value in different (and incompatible) ways. There is using the same value in different (and incompatible) ways. There is
no need for IANA to review such assignments (since IANA does not no need for IANA to review such assignments (since IANA does not
record them) and assignments are not generally useful for broad record them) and assignments are not generally useful for broad
interoperability. It is the responsibility of the sites making use interoperability. It is the responsibility of the sites making use
of the Private Use range to ensure that no conflicts occur (within of the Private Use range to ensure that no conflicts occur (within
the intended scope of use). the intended scope of use).
Examples: Examples:
skipping to change at page 18, line 44 skipping to change at page 21, line 31
It should be noted that a key motivation for having designated It should be noted that a key motivation for having designated
experts is for the IETF to provide IANA with a subject matter expert experts is for the IETF to provide IANA with a subject matter expert
to whom the evaluation process can be delegated. IANA forwards to whom the evaluation process can be delegated. IANA forwards
requests for an assignment to the expert for evaluation, and the requests for an assignment to the expert for evaluation, and the
expert (after performing the evaluation) informs IANA as to whether expert (after performing the evaluation) informs IANA as to whether
or not to make the assignment or registration. or not to make the assignment or registration.
It will often be useful to use a designated expert only some of the It will often be useful to use a designated expert only some of the
time, as a supplement to other processes. For more discussion of time, as a supplement to other processes. For more discussion of
that topic, see Section 2.2.2. that topic, see Section 2.3.2.
5.2. The Role of the Designated Expert 5.2. The Role of the Designated Expert
The designated expert is responsible for coordinating the appropriate The designated expert is responsible for coordinating the appropriate
review of an assignment request. The review may be wide or narrow, review of an assignment request. The review may be wide or narrow,
depending on the situation and the judgment of the designated expert. depending on the situation and the judgment of the designated expert.
This may involve consultation with a set of technology experts, This may involve consultation with a set of technology experts,
discussion on a public mailing list, consultation with a working discussion on a public mailing list, consultation with a working
group (or its mailing list if the working group has disbanded), etc. group (or its mailing list if the working group has disbanded), etc.
Ideally, the designated expert follows specific review criteria as Ideally, the designated expert follows specific review criteria as
skipping to change at page 19, line 15 skipping to change at page 22, line 5
the IANA Considerations sections of [RFC3748] and [RFC3575] for the IANA Considerations sections of [RFC3748] and [RFC3575] for
specific examples. specific examples.
Designated experts are expected to be able to defend their decisions Designated experts are expected to be able to defend their decisions
to the IETF community, and the evaluation process is not intended to to the IETF community, and the evaluation process is not intended to
be secretive or bestow unquestioned power on the expert. Experts are be secretive or bestow unquestioned power on the expert. Experts are
expected to apply applicable documented review or vetting procedures, expected to apply applicable documented review or vetting procedures,
or in the absence of documented criteria, follow generally accepted or in the absence of documented criteria, follow generally accepted
norms such as those in Section 5.3. norms such as those in Section 5.3.
Section 3.2 discusses disputes and appeals in more detail. Designated experts are appointed by the IESG, normally upon
recommendation by the relevant Area Director, either at the time a
Designated experts are appointed by the IESG (normally upon document creating or updating a namespace is approved by the IESG or
recommendation by the relevant Area Director). They are typically subsequently, when the first registration request is received.
named at the time a document creating or updating a namespace is Because experts originally appointed may later become unavailable,
approved by the IESG, but as experts originally appointed may later the IESG will appoint replacements as necessary.
become unavailable, the IESG will appoint replacements if necessary.
For some registries, it has proven useful to have multiple designated For some registries, it has proven useful to have multiple designated
experts. Sometimes those experts work together in evaluating a experts. Sometimes those experts work together in evaluating a
request, while in other cases additional experts serve as backups. request, while in other cases additional experts serve as backups.
In cases of disagreement among those experts, it is the In cases of disagreement among those experts, it is the
responsibility of those experts to make a single clear recommendation responsibility of those experts to make a single clear recommendation
to IANA. It is not appropriate for IANA to resolve disputes among to IANA. It is not appropriate for IANA to resolve disputes among
experts. In extreme situations, such as deadlock, the IESG may need experts. In extreme situations, such as deadlock, the IESG may need
to step in to resolve the problem. to step in to resolve the problem.
skipping to change at page 22, line 15 skipping to change at page 24, line 51
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. Reserved
values are held for special uses, such as to extend the values are held for special uses, such as to extend 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".
7. Documentation References in IANA Registries Reserved values can be released for assignment by the change
controller for the registry (this is often the IESG, for
registries created by RFCs in the IETF stream).
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 22, line 44 skipping to change at page 25, line 31
section of the reference document, it is useful to include a section of the reference document, it is useful to include a
section reference. For example, "[RFC9876], Section 3.2", rather section reference. For example, "[RFC9876], Section 3.2", rather
than just "[RFC9876]". than just "[RFC9876]".
o For documentation of a new registry, the reference should provide o For documentation of a new registry, the reference should provide
information about the registry itself, not just a pointer to the information about the registry itself, not just a pointer to the
creation of it. Useful information includes the purpose of the creation of it. Useful information includes the purpose of the
registry, a rationale for its creation, documentation of the registry, a rationale for its creation, documentation of the
process and policy for new registrations, guidelines for new process and policy for new registrations, guidelines for new
registrants or designated experts, and other such related registrants or designated experts, and other such related
information. information. But note that, while it's important to include this
information in the document, it needn't (and shouldn't) all be in
the IANA Considerations section. See Section 1.1.
8. What to Do in "bis" Documents 8. What to Do in "bis" Documents
On occaison, an RFC is issued that obsoletes a previous edition of On occaison, an RFC is issued that obsoletes a previous edition of
the same document. We sometimes call these "bis" documents, such as the same document. We sometimes call these "bis" documents, such as
when RFC 9876 is updated by draft-ietf-foo-rfc9876bis. When the when RFC 9876 is updated by draft-ietf-foo-rfc9876bis. When the
original document created registries and/or registered entries, there original document created registries and/or registered entries, there
is a question of how to handle the IANA Considerations section in the is a question of how to handle the IANA Considerations section in the
"bis" document. "bis" document.
If the registrations specify the original document as a reference, If the registrations specify the original document as a reference,
those registrations should be updated to point to the current (not those registrations should be updated to point to the current (not
obsolete) documentation for those items. Usually, that will mean obsolete) documentation for those items. Usually, that will mean
changing the reference to be the "bis" document. changing the reference to be the "bis" document. There will, though,
be times when a document updates another, and changes the definitive
reference for some items, but not for others. Be sure that the
references are always set to point to the correct, current
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
skipping to change at page 26, line 13 skipping to change at page 29, line 7
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. Alternatively, organizations can put an organizational
role into the "Contact" field in order to make their ownership clear. 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
[[This section needs to be resolved before publication.]] Sometimes there is a request to "close" a registry to further
registrations. When a registry is closed, no further registrations
will be accepted. The information in the registry will still be
valid and registrations already in the registry can still be updated.
Sometimes there is a request to "close" a registry. Registries can A closed registry can also be marked as "obsolete", as an indication
only be marked as closed, obsoleted or historical through publication that the information in the registry is no longer in current use.
of an RFC. o Closing a registry When closing a registry, no further
registrations will be accepted. The information in the registry will Specific entries in a registry can be marked as "obsolete" (no longer
still be valid and if needed, registrations already in the registry in use) or "deprecated" (use is not recommended).
can be updated. o Making a registry Historical When a registry is
made Historical???? o Obsoleting a registry This means the Such changes to registries and registered values are subject to
information in the registry is no longer used or applicable??? normal change controls (see Section 2.3.3). Any closure,
Whether the registry is closed, obsoleted or made historical, the obsolescence, or deprecation serves to annotate the registry
information will remain in the registry for informational purposes involved; the information in the registry remains there for
unless specifically requested to be removed. all registrations informational and historic purposes.
cancelled and existing values deprecated/ inoperative? values no
longer accessible to public view?
10. Appeals 10. Appeals
Appeals of protocol parameter registration decisions can be made Appeals of protocol parameter registration decisions can be made
using the normal IETF appeals process as described in [RFC2026], using the normal IETF appeals process as described in [RFC2026],
Section 6.5. That is, an initial appeal should be directed to the Section 6.5. That is, an initial appeal should be directed to the
IESG, followed (if necessary) by an appeal to the IAB. IESG, followed (if necessary) by an appeal to the IAB.
11. Mailing Lists 11. Mailing Lists
skipping to change at page 27, line 14 skipping to change at page 30, line 14
An analysis of security issues is generally required for all An analysis of security issues is generally required for all
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. To-Do List; resolve and remove before requesting publication 13. Changes Relative to Earlier Editions of BCP 26
Just was speaking with someone at the IANA office hours. I was 13.1. 2013: Changes in This Document Relative to RFC 5226
looking through the 5226bis draft and there is nothing in there about
how to deprecate values in registries. Might be something good to
add.
14. Changes Relative to Earlier Editions of BCP 26 Significant additions:
14.1. 2013: Changes in This Document Relative to RFC 5226 o Added Section 1.1, Keep IANA Considerations for IANA
Significant additions: o Added Section 1.2, For More Information
o Added Section 5.4, Expert Reviews and the Document Lifecycle o Added Section 2.1, Hierarchical Registry Structure
o Added Section 2.3, Best Practice for Selecting an Appropriate
Policy.
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 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,
subsections of Section 4. subsections of Section 4.
o Added Section 2.2, Best Practice for Selecting an Appropriate o Added Section 5.4, Expert Reviews and the Document Lifecycle
Policy.
o Added Section 2.2.2, Using Multiple Policies in Combination.
o Added Section 7, Documentation References in IANA Registries o Added Section 7, Documentation References in IANA Registries
o Added Section 8, What to Do in "bis" Documents o Added Section 8, What to Do in "bis" Documents
o Added Section 9.5, Contact Person vs Assignee or Owner o Added Section 9.5, Contact Person vs Assignee or Owner
o Added Section 9.6, Closing or Obsoleting a Registry o Added Section 9.6, Closing or Obsoleting a Registry
Clarifications and such: Clarifications and such:
skipping to change at page 28, line 10 skipping to change at page 31, line 13
o Clarified the distinction between "Unassigned" and "Reserved". o Clarified the distinction between "Unassigned" and "Reserved".
o Made some clarifications in "Expert Review" about instructions to o Made some clarifications in "Expert Review" about instructions to
the designated expert. the designated expert.
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.
14.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.
skipping to change at page 28, line 51 skipping to change at page 31, line 54
RFC 2026 appeals path is used. RFC 2026 appeals path is used.
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.
15. Acknowledgments 14. Acknowledgments
15.1. Acknowledgments for This Document (2013) 14.1. Acknowledgments for This Document (2013)
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.
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.
15.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:
This document has benefited from specific feedback from Jari Arkko, This document has benefited from specific feedback from Jari Arkko,
Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer
Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley,
John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus
Westerlund, and Bert Wijnen. Westerlund, and Bert Wijnen.
15.3. Acknowledgments from the first edition (1998) 14.3. Acknowledgments from the first edition (1998)
The original acknowledgments section in RFC 2434 was: The original acknowledgments section in RFC 2434 was:
Jon Postel and Joyce Reynolds provided a detailed explanation on what Jon Postel and Joyce Reynolds provided a detailed explanation on what
IANA needs in order to manage assignments efficiently, and patiently IANA needs in order to manage assignments efficiently, and patiently
provided comments on multiple versions of this document. Brian provided comments on multiple versions of this document. Brian
Carpenter provided helpful comments on earlier versions of the Carpenter provided helpful comments on earlier versions of the
document. One paragraph in the Security Considerations section was document. One paragraph in the Security Considerations section was
borrowed from [RFC4288]. borrowed from [RFC4288].
16. References 15. References
16.1. Normative References 15.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
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.
16.2. Informative References 15.2. Informative References
[I-D.cotton-rfc4020bis]
Cotton, M., "Early IANA Allocation of Standards Track Code
Points", Internet-Draft draft-cotton-rfc4020bis-02,
October 2013.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[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.
[RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain
Name System (DNS) IANA Considerations", RFC 2929, Name System (DNS) IANA Considerations", RFC 2929,
September 2000. September 2000.
 End of changes. 48 change blocks. 
131 lines changed or deleted 295 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/