< draft-leiba-cotton-iana-5226bis-15.txt   draft-leiba-cotton-iana-5226bis-16.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 01, 2016 IBM Corporation Expires: December 07, 2016 IBM Corporation
June 01, 2016 June 07, 2016
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-15 draft-leiba-cotton-iana-5226bis-16
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
record keeper. For IETF protocols, that role is filled by the record keeper. For IETF protocols, that role is filled by the
Internet Assigned Numbers Authority (IANA). Internet Assigned Numbers Authority (IANA).
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 01, 2016. This Internet-Draft will expire on December 07, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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. Keep IANA Considerations for IANA . . . . . . . . . . . . 3 1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 3
1.2. For More Information . . . . . . . . . . . . . . . . . . . 4 1.2. For Updated Information . . . . . . . . . . . . . . . . . 4
2. Creating and Revising Registries . . . . . . . . . . . . . . . 4 2. Creating and Revising Registries . . . . . . . . . . . . . . . 4
2.1. Organization of Registries . . . . . . . . . . . . . . . . 4 2.1. Organization of Registries . . . . . . . . . . . . . . . . 5
2.2. Documentation Requirements for Registries . . . . . . . . 6 2.2. Documentation Requirements for Registries . . . . . . . . 5
2.3. Specifying Change Control for a Registry . . . . . . . . . 8 2.3. Specifying Change Control for a Registry . . . . . . . . . 7
2.4. Revising Existing Registries . . . . . . . . . . . . . . . 9 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 8
3. Registering New Values in an Existing Registry . . . . . . . . 9 3. Registering New Values in an Existing Registry . . . . . . . . 8
3.1. Documentation Requirements for Registrations . . . . . . . 9 3.1. Documentation Requirements for Registrations . . . . . . . 8
3.2. Updating Existing Registrations . . . . . . . . . . . . . 11 3.2. Updating Existing Registrations . . . . . . . . . . . . . 10
3.3. Overriding Registration Procedures . . . . . . . . . . . . 12 3.3. Overriding Registration Procedures . . . . . . . . . . . . 11
3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 12 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 12
4. Choosing a Registration Policy, and Well-Known Policies . . . 13 4. Choosing a Registration Policy, and Well-Known Policies . . . 12
4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 15 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 14
4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 16 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 15
4.4. First Come First Served . . . . . . . . . . . . . . . . . 16 4.4. First Come First Served . . . . . . . . . . . . . . . . . 15
4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 16
4.6. Specification Required . . . . . . . . . . . . . . . . . . 18 4.6. Specification Required . . . . . . . . . . . . . . . . . . 17
4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 18
4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 18
4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 20 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 19
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 19
4.11. Using the Well-Known Registration Policies . . . . . . . . 21 4.11. Using the Well-Known Registration Policies . . . . . . . . 20
4.12. Using Multiple Policies in Combination . . . . . . . . . . 22 4.12. Using Multiple Policies in Combination . . . . . . . . . . 21
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 23 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 22
5.1. The Motivation for Designated Experts . . . . . . . . . . 23 5.1. The Motivation for Designated Experts . . . . . . . . . . 22
5.2. The Role of the Designated Expert . . . . . . . . . . . . 23 5.2. The Role of the Designated Expert . . . . . . . . . . . . 22
5.2.1. Managing Designated Experts in the IETF . . . . . . . 24 5.2.1. Managing Designated Experts in the IETF . . . . . . . 23
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 25 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 26 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25
6. Well-Known Registration Status Terminology . . . . . . . . . . 27 6. Well-Known Registration Status Terminology . . . . . . . . . . 26
7. Documentation References in IANA Registries . . . . . . . . . 28 7. Documentation References in IANA Registries . . . . . . . . . 27
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 28 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 30 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 29
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 30 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 29
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 30 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 29
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 30 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 29
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 31 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 30
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 31 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 31
9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 32 9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 31
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 33 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 33
14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 33 14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 33
14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 34 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 34
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Acknowledgments for This Document (2016) . . . . . . . . 35 15.1. Acknowledgments for This Document (2016) . . . . . . . . 34
15.2. Acknowledgments from the second edition (2008) . . . . . 35 15.2. Acknowledgments from the second edition (2008) . . . . . 35
15.3. Acknowledgments from the first edition (1998) . . . . . . 36 15.3. Acknowledgments from the first edition (1998) . . . . . . 35
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
16.1. Normative References . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . 35
16.2. Informative References . . . . . . . . . . . . . . . . . 36 16.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Many protocols make use of points of extensibility that use constants Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central interoperability, their allocation is often coordinated by a central
record keeper. For IETF protocols, that role is filled by the record keeper. For IETF protocols, that role is filled by the
Internet Assigned Numbers Authority (IANA) [RFC2860]. Internet Assigned Numbers Authority (IANA) [RFC2860].
skipping to change at page 4, line 17 skipping to change at page 4, line 17
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.
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 The IANA actions are normally phrased as requests for IANA (such as,
"IANA is asked to assign the value TBD1 from the Frobozz
Registry..."); the RFC Editor will change those sentences to reflect
the actions taken ("IANA has assigned the value 83 from the Frobozz
Registry...").
1.2. For Updated 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: current clarifications,
minor updates, and summary guidance. Any significant updates to the
best current practice will have to feed into updates to BCP 26 (this
document), which is definitive.
<https://iana.org/help/protocol-registration>. <https://iana.org/help/protocol-registration>.
[[(RFC Editor: Please remove this paragraph.) The initial version of [[(RFC Editor: Please remove this paragraph.) The initial version of
this should contain the bits that are salient to most document this should contain the bits that are salient to most document
authors -- perhaps a table of required elements to create a new authors -- perhaps a table of required elements to create a new
registry or update one, a bit about sub-registries, and the listing registry or update one, a bit about sub-registries, and the listing
of well-known registration policies. IANA has text for this, but of well-known registration policies. IANA has text for this, but
they need to work on their process to put the page up (transition they need to work on their process to put the page up (transition
issues). We might host the first version on the IETF site, with the issues). We might host the first version on the IETF site, with the
skipping to change at page 4, line 55 skipping to change at page 5, line 14
particularly useful in situations where distributed coordinators have particularly useful in situations where distributed coordinators have
better knowledge of their portion of the namespace and are better better knowledge of their portion of the namespace and are better
suited to handling those assignments. suited to handling those assignments.
2.1. Organization of Registries 2.1. Organization of Registries
All registries are anchored from the IANA "Protocol Registries" page: All registries are anchored from the IANA "Protocol Registries" page:
<https://www.iana.org/protocols>. <https://www.iana.org/protocols>.
That page lists registries in protocol category groups, like this: That page lists registries in protocol category groups, placing
related registries together and making it easier for users of the
--------------------------------------------------------------- registries to find the necessary information. Clicking on the title
Author Domain Signing Practices (ADSP) Parameters of one of the registries on the IANA Protocol Registries page will
take the reader to the details page for that registry.
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, all registries related to
the ADSP protocol are 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 Unfortunately, we have been inconsistent in how we refer to these
entities. The group names, as they are referred to here, have been entities. The group names, as they are referred to here, have been
variously called "protocol category groups", "groups", "top-level variously called "protocol category groups", "groups", "top-level
registries", or just "registries". The registries under them have registries", or just "registries". The registries under them have
been called "registries" or "sub-registries". been called "registries" or "sub-registries".
Regardless of the terminology used, document authors should pay Regardless of the terminology used, document authors should pay
attention to the registry groupings, should request that related attention to the registry groupings, should request that related
registries be grouped together to make related registries easier to registries be grouped together to make related registries easier to
skipping to change at page 6, line 20 skipping to change at page 5, line 45
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 The name of the registry
This name will appear on the IANA web page and will be referred to This name will appear on the IANA web page and will be referred to
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 registry, the group that it is a part of must be When creating a registry, the group that it is a part of must be
identified using its full name, exactly as it appears in the IANA identified using its full name, exactly as it appears in the IANA
registry list. 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, or left in the document for reference.
important that they be permanent links. IANA can answer questions If you include IANA URLs, IANA will provide corrections, if
about the correct URLs to use. necessary, during their review.
For example, a document could contain something like this:
This registration should be made in the Foobar Operational
Parameters registry, located at <https://www.iana.org/
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:
https://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 tells registrants what information they have to include in This tells registrants what information they have to include in
their registration requests. Some registries require only the their registration requests. Some registries require only the
requested value and a reference to a document where use of the requested value and a reference to a document where use of the
value is defined. Other registries require a more detailed value is defined. Other registries require a more detailed
registration template that describes relevant security registration template that describes relevant security
considerations, internationalization considerations, and other considerations, internationalization considerations, and other
such information. such information.
Applicable registration policy Applicable registration policy
skipping to change at page 9, line 12 skipping to change at page 8, line 12
control 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. control 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. See also Section 9.5. make the change. Example: the Media Types registry [RFC6838]
includes a "Change Controller" in its registration template. See
also Section 9.5.
While IANA normally includes information about change control in the While IANA normally includes information about change control in the
public registry, some change controllers might prefer that their public registry, some change controllers might prefer that their
identities or contact information not be made public. In such cases, identities or contact information not be made public. In such cases,
arrangements can be made with IANA to keep the information private, arrangements can be made with IANA to keep the information private,
to use an alias or role-based contact address, or to otherwise to use an alias or role-based contact address, or to otherwise
protect the change controller's privacy. protect the change controller's privacy.
2.4. Revising Existing Registries 2.4. Revising Existing Registries
skipping to change at page 10, line 4 skipping to change at page 9, line 8
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 in an existing registry (one Often, documents request an assignment in an existing registry (one
created by a previously published document). created by a previously published document).
Such documents should clearly identify the registry into which each Such documents should clearly identify the registry into which each
value is to be registered. Use the exact registry name as listed on value is to be registered. Use the exact registry name as listed on
the IANA web page, and cite the RFC where the registry is defined. the IANA web page, and cite the RFC where the registry is defined.
When referring to an existing registry, providing a URL to precisely
identify the registry is helpful (see Section 2.2).
There is no need to mention what the assignment policy is when making There is no need to mention what the assignment policy is when making
new assignments in existing registries, as that should be clear from new assignments in existing registries, as that should be clear from
the references. However, if multiple assignment policies might the references. However, if multiple assignment policies might
apply, as in registries with different ranges that have different apply, as in registries with different ranges that have different
policies, it is important to make it clear which range is being policies, it is important to make it clear which range is being
requested, so that IANA will know which policy applies and can assign requested, so that IANA will know which policy applies and can assign
a value in the correct range. a value in the correct range.
When referring to an existing registry, providing a URL to precisely
identify the registry is helpful. See Section 2.2 for details on
specifying the correct URL.
For example, a document could contain something like this:
This registration should be made in the Foobar Operational
Parameters registry, located at <https://www.iana.org/assignments/
foobar-registry>.
Normally, numeric values to be used are chosen by IANA when the Normally, numeric values to be used are chosen by IANA when the
document is approved, and drafts should not specify final values. document is approved, and drafts should not specify final values.
Instead, placeholders such as "TBD1" and "TBD2" should be used Instead, placeholders such as "TBD1" and "TBD2" should be used
consistently throughout the document, giving each item to be consistently throughout the document, giving each item to be
registered a different placeholder. The IANA Considerations should registered a different placeholder. The IANA Considerations should
ask the RFC Editor to replace the placeholder names with the IANA- ask the RFC Editor to replace the placeholder names with the IANA-
assigned values. When drafts need to specify numeric values for assigned values. When drafts need to specify numeric values for
testing or early implementations, they will either request early testing or early implementations, they will either request early
allocation (see Section 3.4) or use values that have already been set allocation (see Section 3.4) or use values that have already been set
aside for testing or experimentation (if the registry in question aside for testing or experimentation (if the registry in question
skipping to change at page 11, line 5 skipping to change at page 9, line 49
consult with the authors if there is, in fact, a collision, and a consult with the authors if there is, in fact, a collision, and a
different value has to be used. When drafts need to specify string different value has to be used. When drafts need to specify string
values for testing or early implementations, they sometimes use the values for testing or early implementations, they sometimes use the
expected final value. But it is often useful to use a draft value expected final value. But it is often useful to use a draft value
instead, possibly including the draft version number. This allows instead, possibly including the draft version number. This allows
the early implementations to be distinguished from those implementing the early implementations to be distinguished from those implementing
the final version. A document that intends to use "foobar" in the the final version. A document that intends to use "foobar" in the
final version might use "foobar-testing-draft-05" for the -05 version final version might use "foobar-testing-draft-05" for the -05 version
of the draft, for example. of the draft, for example.
For some registries, IANA has a long-standing policy prohibiting For some registries, there is 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 might always be assigned sequentially unless there For example, codes might always be assigned sequentially unless there
is a strong reason for making an exception. Nothing in this document is a strong reason for making an exception. Nothing in this document
is intended to change those policies or prevent their future is intended to change those policies or prevent their future
application. application.
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 is asked to assign an option code value of TBD1 to the DNS IANA is asked to assign an option code value of TBD1 to the DNS
skipping to change at page 14, line 26 skipping to change at page 13, line 26
(e.g., for limited resources such as bits in a byte, or for items for (e.g., for limited resources such as bits in a byte, or for items for
which unsupported values can be damaging to protocol operation), in which unsupported values can be damaging to protocol operation), in
many cases having what's in use represented in the registry is more many cases having what's in use represented in the registry is more
important. Overly strict review criteria and excessive cost (in time important. Overly strict review criteria and excessive cost (in time
and effort) discourage people from even attempting to make a and effort) discourage people from even attempting to make a
registration. If a registry fails to reflect the protocol elements registration. If a registry fails to reflect the protocol elements
actually in use, it can adversely affect deployment of protocols on actually in use, it can adversely affect deployment of protocols on
the Internet, and the registry itself is devalued. the Internet, and the registry itself is devalued.
Therefore, it is important to think specifically about the Therefore, it is important to think specifically about the
registration policy, and not just pick one arbitrarily or nor copy registration policy, and not just pick one arbitrarily nor copy text
text from another document. Working groups and other document from another document. Working groups and other document developers
developers should use care in selecting appropriate registration should use care in selecting appropriate registration policies when
policies when their documents create registries. They should select their documents create registries. They should select the least
the least strict policy that suits a registry's needs, and look for strict policy that suits a registry's needs, and look for specific
specific justification for policies that require significant justification for policies that require significant community
community involvement (those stricter than Expert Review or involvement (those stricter than Expert Review or Specification
Specification Required, in terms of the well-known policies). The Required, in terms of the well-known policies). The needs here will
needs here will vary from registry to registry, and, indeed, over vary from registry to registry, and, indeed, over time, and this BCP
time, and this BCP will not be the last word on the subject. will not be the last word on the subject.
The following policies are defined for common usage. These cover a The following policies are defined for common usage. These cover a
range of typical policies that have been used to describe the range of typical policies that have been used to describe the
procedures for assigning new values in a namespace. It is not procedures for assigning new values in a namespace. It is not
strictly required that documents use these terms; the actual strictly required that documents use these terms; the actual
requirement is that the instructions to IANA be clear and 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. Newly minted policies, because their meanings are widely understood. Newly minted policies,
including ones that combine the elements of procedures associated including ones that combine the elements of procedures associated
with these terms in novel ways, may be used if none of these policies with these terms in novel ways, may be used if none of these policies
skipping to change at page 19, line 40 skipping to change at page 18, line 41
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]). Independent Submission [RFC5742]).
Unless otherwise specified, any type of RFC is sufficient (currently Unless otherwise specified, any type of RFC is sufficient (currently
Standards Track, BCP, Informational, Experimental, or Historic). Standards Track, BCP, Informational, Experimental, or Historic).
Examples:
DNSSEC DNS Security Algorithm Numbers [RFC6014]
Media Control Channel Framework registries [RFC6230]
DANE TLSA Certificate Usages [RFC6698]
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], have gone through IETF last call, and that the [RFC2026] [RFC5378], have gone through IETF last call, and that the
IESG has approved as having IETF consensus. IESG has approved as having IETF consensus.
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.
review, such documents will always undergo an IETF Last Call.
Unless otherwise specified, any type of RFC is sufficient (currently Unless otherwise specified, any type of RFC is sufficient (currently
Standards Track, BCP, Informational, Experimental, or Historic). Standards Track, BCP, Informational, Experimental, or Historic).
Examples: Examples:
IPSECKEY Algorithm Types [RFC4025] IPSECKEY Algorithm Types [RFC4025]
Accounting-Auth-Method AVP values in DIAMETER [RFC4005] Accounting-Auth-Method AVP values in DIAMETER [RFC4005]
TLS Extension Types [RFC5246] TLS Extension Types [RFC5246]
skipping to change at page 21, line 18 skipping to change at page 20, line 16
IPv4 IGMP Type and Code values [RFC3228] IPv4 IGMP Type and Code values [RFC3228]
Mobile IPv6 Mobility Header Type and Option values [RFC6275] Mobile IPv6 Mobility Header Type and Option values [RFC6275]
4.11. Using the Well-Known Registration Policies 4.11. Using the Well-Known Registration Policies
Because the well-known policies benefit from both community Because the well-known policies benefit from both community
experience and wide understanding, their use is encouraged, and the experience and wide understanding, their use is encouraged, and the
making up of new policies needs to be accompanied by reasonable making up of new policies needs to be accompanied by reasonable
justification. justification.
It is also acceptable to cite one of the well-known policies and It is also acceptable to cite one or more 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, for media-type registrations [RFC6838], a number of
Expert, but includes specific additional criteria the Designated different situations are covered that involve the use of IETF Review
Expert should follow. and Specification Required, while also including specific additional
criteria the Designated Expert should follow. This is not meant to
represent a registration procedures, but shows an example of what can
be done when special circumstances need to be covered.
The well-known policies from "First Come First Served" to "Standards The well-known policies from "First Come First Served" to "Standards
Action" specify a range of policies in increasing order of strictness Action" specify a range of policies in increasing order of strictness
(using the numbering from the full list in Section 4): (using the numbering from the full list in Section 4):
4. First Come First Served 4. First Come First Served
No review, minimal documentation. No review, minimal documentation.
5/6. Expert Review / Specification Required 5/6. Expert Review / Specification Required
Expert review with sufficient documentation for review. / Expert review with sufficient documentation for review. /
skipping to change at page 24, line 38 skipping to change at page 23, line 37
specify how the group should work -- for example, it might be specify how the group should work -- for example, it might be
appropriate to specify rough consensus on a mailing list, within a appropriate to specify rough consensus on a mailing list, within a
related working group, or among a pool of designated experts. related working group, or among a pool of designated experts.
In cases of disagreement among multiple experts, it is the In cases of disagreement among multiple 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 designating experts. In extreme situations, such as deadlock, the designating
body may need to step in to resolve the problem. body may need to step in to resolve the problem.
If a designated expert is conflicted for a particular review (is, for If a designated expert has a conflict of interest for a particular
example, an author or significant proponent of a specification review (is, for example, an author or significant proponent of a
related to the registration under review), that expert should recuse specification related to the registration under review), that expert
himself. In the event that all the designated experts are should recuse himself. In the event that all the designated experts
conflicted, they should ask that a temporary expert be designated for are conflicted, they should ask that a temporary expert be designated
the conflicted review. for the conflicted review. The responsible AD may then appoint
someone, or the AD may handle the review.
This document defines the designated expert mechanism with respect to This document defines the designated expert mechanism with respect to
documents in the IETF stream only. Documents in other streams may documents in the IETF stream only. If other streams want to use
use a registration policy that requires a designated expert only if registration policies that require designated experts, it is up to
those streams (or those documents) specify how designated experts are those streams (or those documents) to specify how those designated
appointed and managed. What is described below, with management by experts are appointed and managed. What is described below, with
the IESG, is only appropriate for the IETF stream. management by the IESG, is only appropriate for the IETF stream.
5.2.1. Managing Designated Experts in the IETF 5.2.1. Managing Designated Experts in the IETF
Designated experts for registries created by the IETF are appointed Designated experts for registries created by the IETF are appointed
by the IESG, normally upon recommendation by the relevant Area by the IESG, normally upon recommendation by the relevant Area
Director. They may be appointed at the time a document creating or Director. They may be appointed at the time a document creating or
updating a namespace is approved by the IESG, or subsequently, when updating a namespace is approved by the IESG, or subsequently, when
the first registration request is received. Because experts the first registration request is received. Because experts
originally appointed may later become unavailable, the IESG will originally appointed may later become unavailable, the IESG will
appoint replacements as necessary. The IESG may remove any appoint replacements as necessary. The IESG may remove any
designated expert that it appointed, at its discretion. designated expert that it appointed, at its discretion.
skipping to change at page 26, line 5 skipping to change at page 25, line 4
appropriate. In the case that a request is denied, and rejecting appropriate. In the case that a request is denied, and rejecting
the request is likely to be controversial, the expert should have the request is likely to be controversial, the expert should have
the support of other subject matter experts. That is, the expert the support of other subject matter experts. That is, the expert
must be able to defend a decision to the community as a whole. must be able to defend a decision to the community as a whole.
When a designated expert is used, the documentation should give clear When a designated expert is used, the documentation should give clear
guidance to the designated expert, laying out criteria for performing guidance to the designated expert, laying out criteria for performing
an evaluation and reasons for rejecting a request. In the case where an evaluation and reasons for rejecting a request. In the case where
there are no specific documented criteria, the presumption should be there are no specific documented criteria, the presumption should be
that a code point should be granted unless there is a compelling that a code point should be granted unless there is a compelling
reason to the contrary. Reasons that have been used to deny requests reason to the contrary (and see also Section 5.4). Reasons that have
have included these: been used to deny requests have included these:
o Scarcity of code points, where the finite remaining code points o Scarcity of code points, where the finite remaining code points
should be prudently managed, or where a request for a large number should be prudently managed, or where a request for a large number
of code points is made and a single code point is the norm. of code points is made and a single code point is the norm.
o Documentation is not of sufficient clarity to evaluate or ensure o Documentation is not of sufficient clarity to evaluate or ensure
interoperability. interoperability.
o The code point is needed for a protocol extension, but the o The code point is needed for a protocol extension, but the
extension is not consistent with the documented (or generally extension is not consistent with the documented (or generally
skipping to change at page 26, line 33 skipping to change at page 25, line 32
type or operation, requiring unwarranted changes in deployed type or operation, requiring unwarranted changes in deployed
systems (compared with alternate ways of achieving a similar systems (compared with alternate ways of achieving a similar
result), etc. result), etc.
o The extension would cause problems with existing deployed systems. o The extension would cause problems with existing deployed systems.
o The extension would conflict with one under active development by o The extension would conflict with one under active development by
the IETF, and having both would harm rather than foster the IETF, and having both would harm rather than foster
interoperability. interoperability.
When a designated expert is used, documents must not name the Documents must not name the designated expert(s) in the document
designated expert in the document itself; instead, any suggested itself; instead, any suggested names should be relayed to the
names should be relayed to the appropriate Area Director at the time appropriate Area Director at the time the document is sent to the
the document is sent to the IESG for approval. This is usually done IESG for approval. This is usually done in the document shepherd
in the document shepherd writeup. writeup.
If the request should also be reviewed on a specific public mailing If the request should also be reviewed on a specific public mailing
list, its address should be specified. list, its address should be specified.
5.4. Expert Reviews and the Document Lifecycle 5.4. Expert Reviews and the Document Lifecycle
Review by the designated expert is necessarily done at a particular Review by the designated expert is necessarily done at a particular
point in time, and represents review of a particular version of the point in time, and represents review of a particular version of the
document. While reviews are generally done around the time of IETF document. While reviews are generally done around the time of IETF
last call, deciding when the review should take place is a question last call, deciding when the review should take place is a question
skipping to change at page 29, line 48 skipping to change at page 29, line 6
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 4637, IANA is asked to change Because this document obsoletes RFC 4637, IANA is asked to change
all registration information that references [RFC4637] to instead all registration information that references [RFC4637] 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 the registration information should be changed
be changed to point to those other documents. In no case is it to point to those other documents. In most cases, documentation
reasonable to leave documentation pointers to the obsoleted document references should not be left pointing to the obsoleted document for
for any registries or registered items that are still in current use. registries or registered items that are still in current use. For
registries or registered items that are no longer in current use, it
will usually make sense to leave the references pointing to the old
document -- the last current reference for the obsolete items. The
main point is to make sure that the reference pointers are as useful
and current as is reasonable, and authors should consider that as
they write the IANA Considerations for the new document. As always:
do the right thing, and there is flexibility to allow for that.
It is extremely important to be clear in your instructions regarding It is extremely important to be clear in your instructions regarding
updating references, especially in cases where some references need updating references, especially in cases where some references need
to be updated and others do not. 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
skipping to change at page 30, line 31 skipping to change at page 29, line 48
in the document for the record: it makes it clear later on that the in the document for the record: it makes it clear later on that the
document explicitly said that no IANA actions were needed (and that document explicitly said that no IANA actions were needed (and that
it wasn't just omitted). This is a change from the prior practice of it wasn't just omitted). This is a change from the prior practice of
requesting that such sections be removed by the RFC Editor, and requesting that such sections be removed by the RFC Editor, and
authors are asked to accommodate this change. authors are asked to accommodate this change.
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 will work with the IESG to decide what policy is
what policy is appropriate. Changes to existing policies can always appropriate. Changes to existing policies can always be initiated
be initiated through the normal IETF consensus process, or through through the normal IETF consensus process, or through the IESG when
the IESG when appropriate. 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
skipping to change at page 35, line 40 skipping to change at page 35, line 4
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 15. Acknowledgments
15.1. Acknowledgments for This Document (2016) 15.1. Acknowledgments for This Document (2016)
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 Thank you to Amanda Baber and Pearl Liang for their multiple reviews
and suggestions for making this document as thorough as possible. and suggestions for making this document as thorough as possible.
This document has benefited from thorough review and comments by Tony This document has benefited from thorough review and comments by many
Hansen, John Klensin, and Mark Nottingham. people, including Benoit Claise, Alissa Cooper, Adrian Farrel,
Stephen Farrell, Tony Hansen, John Klensin, Kathleen Moriarty, Mark
Nottingham, Pete Resnick, and Joe Touch.
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, and to Tony Hansen for for better organization and readability, to Tony Hansen for acting as
acting as document shepherd. document shepherd, and to Brian Haberman and Terry Manderson for
acting as sponsoring ADs.
15.2. Acknowledgments from the second edition (2008) 15.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) 15.3. Acknowledgments from the first edition (1998)
skipping to change at page 38, line 43 skipping to change at page 38, line 9
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.
[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,
November 2010, <http://www.rfc-editor.org/info/rfc6014>.
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6195, March 2011. Considerations", BCP 42, RFC 6195, March 2011.
[RFC6230] Boulton, C., Melanchuk, T. and S. McGlashan, "Media
Control Channel Framework", RFC 6230, DOI 10.17487/
RFC6230, May 2011, <http://www.rfc-editor.org/info/
rfc6230>.
[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.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
[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.
[RFC6838] Freed, N., Klensin, J. and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J. and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13, RFC
6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc- 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-
editor.org/info/rfc6838>. editor.org/info/rfc6838>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC
 End of changes. 38 change blocks. 
171 lines changed or deleted 158 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/