< draft-leiba-cotton-iana-5226bis-06.txt   draft-leiba-cotton-iana-5226bis-07.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 02, 2015 IBM Corporation Expires: February 28, 2015 IBM Corporation
July 03, 2014 August 29, 2014
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-06 draft-leiba-cotton-iana-5226bis-07
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 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 January 02, 2015. This Internet-Draft will expire on February 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2.3. Defining an Appropriate Registry Policy . . . . . . . . . 8 2.3. Defining an Appropriate Registry Policy . . . . . . . . . 8
2.3.1. Using the Well-Known Registration Policies . . . . . . 10 2.3.1. Using the Well-Known Registration Policies . . . . . . 10
2.3.2. Using Multiple Policies in Combination . . . . . . . . 11 2.3.2. Using Multiple Policies in Combination . . . . . . . . 11
2.3.3. Specifying Change Control for a Registry . . . . . . . 12 2.3.3. Specifying Change Control for a Registry . . . . . . . 12
2.4. Revising Existing Registries . . . . . . . . . . . . . . . 12 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 12
3. Registering New Values in an Existing Registry . . . . . . . . 13 3. Registering New Values in an Existing Registry . . . . . . . . 13
3.1. Documentation Requirements for Registrations . . . . . . . 13 3.1. Documentation Requirements for Registrations . . . . . . . 13
3.2. Updating Existing Registrations . . . . . . . . . . . . . 14 3.2. Updating Existing Registrations . . . . . . . . . . . . . 14
3.3. Overriding Registration Procedures . . . . . . . . . . . . 15 3.3. Overriding Registration Procedures . . . . . . . . . . . . 15
3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15
4. Well-Known Registration Policies . . . . . . . . . . . . . . . 15 4. Well-Known Registration Policies . . . . . . . . . . . . . . . 16
4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 17 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 17
4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17
4.4. First Come First Served . . . . . . . . . . . . . . . . . 17 4.4. First Come First Served . . . . . . . . . . . . . . . . . 17
4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Specification Required . . . . . . . . . . . . . . . . . . 18 4.6. Specification Required . . . . . . . . . . . . . . . . . . 19
4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19
4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19
4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 19 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 20
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 19 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 20 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 21
5.1. The Motivation for Designated Experts . . . . . . . . . . 20 5.1. The Motivation for Designated Experts . . . . . . . . . . 21
5.2. The Role of the Designated Expert . . . . . . . . . . . . 21 5.2. The Role of the Designated Expert . . . . . . . . . . . . 22
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 22 5.2.1. Managing Designated Experts in the IETF . . . . . . . 23
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 24 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 23
6. Well-Known Registration Status Terminology . . . . . . . . . . 24 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25
7. Documentation References in IANA Registries . . . . . . . . . 25 6. Well-Known Registration Status Terminology . . . . . . . . . . 25
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 25 7. Documentation References in IANA Registries . . . . . . . . . 26
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 26 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 26
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 26 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 27
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 27 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 27
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 27 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 28
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 28 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 28
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 28 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29
9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 29 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 29
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 30
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 30
13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
13.1. 2014: Changes in This Document Relative to RFC 5226 . . . 30 13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 31
13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 31 13.1. 2014: Changes in This Document Relative to RFC 5226 . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 32
14.1. Acknowledgments for This Document (2014) . . . . . . . . 32 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
14.2. Acknowledgments from the second edition (2008) . . . . . 32 14.1. Acknowledgments for This Document (2014) . . . . . . . . 33
14.3. Acknowledgments from the first edition (1998) . . . . . . 32 14.2. Acknowledgments from the second edition (2008) . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 14.3. Acknowledgments from the first edition (1998) . . . . . . 33
15.1. Normative References . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 15.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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
skipping to change at page 5, line 26 skipping to change at page 5, line 26
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. Hierarchical Registry Structure 2.1. Hierarchical Registry Structure
It's important to start with a word on the IANA registry structure. It's important to start with a word on the IANA registry structure.
All registries are anchored from the IANA "Protocol Registries" page: All registries are anchored from the IANA "Protocol Registries" page:
<http://www.iana.org/protocols>. <http://www.iana.org/protocols>.
That page lists registries in groups, like this: That page lists registries in protocol category groups, like this:
--------------------------------------------------------------- ---------------------------------------------------------------
Author Domain Signing Practices (ADSP) Parameters Author Domain Signing Practices (ADSP) Parameters
ADSP Outbound Signing Practices RFC 5617 ADSP Outbound Signing Practices RFC 5617
IETF Review IETF Review
ADSP Specification Tags RFC 5617 ADSP Specification Tags RFC 5617
IETF Review IETF Review
skipping to change at page 6, line 19 skipping to change at page 6, line 19
Parameters" group. Parameters" group.
Within the "ADSP Parameters" group are two registries: "ADSP Outbound Within the "ADSP Parameters" group are two registries: "ADSP Outbound
Signing Practices" and "ADSP Specification Tags". Clicking on the Signing Practices" and "ADSP Specification Tags". Clicking on the
title of one of these registries on the IANA Protocol Registries page title of one of these registries on the IANA Protocol Registries page
will take the reader to the details page for that registry. Often, will take the reader to the details page for that registry. Often,
multiple registries are shown on the same details page. 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 "groups", "top-level registries", or just variously called "protocol category groups", "groups", "top-level
"registries". The registries under them have been called registries", or just "registries". The registries under them have
"registries" or "sub-registries". And when new registries are been called "registries" or "sub-registries". And when new
created, the documents that define them often don't specify the registries are created, the documents that define them often don't
grouping at all, but only name the new registry. This results in specify the grouping at all, but only name the new registry. This
questions from IANA and delays in processing, or, worse, in related results in questions from IANA and delays in processing, or, worse,
registries that should have been grouped together, but that are in related registries that should have been grouped together, but
instead scattered about and hard to find and correlate. that are instead scattered about and hard to find and correlate.
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, and, when creating a new registry, registries be grouped together, and, when creating a new registry,
should check whether that registry might best be included in an should check whether that registry might best be included in an
existing group. That grouping information should be clearly existing group. That grouping information should be clearly
communicated to IANA in the registry creation request. communicated to IANA in the registry creation request.
2.2. Documentation Requirements for Registries 2.2. Documentation Requirements for Registries
skipping to change at page 7, line 41 skipping to change at page 7, line 39
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.3. 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, any technical requirements
requirements upon registry entries (e.g., valid ranges for on registry entries (valid ranges for integers, length limitations
integers, length limitations on strings, etc.) as well as the on strings, and such), and the exact format in which registry
exact format in which registry values should be displayed. For values should be displayed. For numeric assignments, one should
numeric assignments, one should specify whether values are to be specify whether values are to be recorded in decimal, in
recorded in decimal, hexadecimal, or some other format. For hexadecimal, or in some other format. For strings, the encoding
strings, the encoding format should be specified (ASCII, UTF8, format should be specified (ASCII, UTF8, etc.).
etc.).
Initial assignments and reservations Initial assignments and reservations
Any initial assignments or registrations to be included. In Any initial assignments or registrations to be included. In
addition, any ranges that are to be reserved for "Private Use", addition, any ranges that are to be reserved for "Private Use",
"Reserved", "Unassigned", etc. should be indicated. "Reserved", "Unassigned", etc. should be indicated.
For example, a document might specify a new registry by including: For example, a document might specify a new registry by including:
--------------------------------------------------------------- ---------------------------------------------------------------
skipping to change at page 8, line 37 skipping to change at page 8, line 37
Value DHCP FooBar FooType Name Definition Value DHCP FooBar FooType Name Definition
---- ------------------------ ---------- ---- ------------------------ ----------
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]. [RFC3575], [RFC3968], and [RFC4520].
2.3. 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
skipping to change at page 10, line 29 skipping to change at page 10, line 29
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
Expert, but includes specific additional criteria the Designated Expert, but includes specific additional criteria the Designated
Expert should follow. Expert should follow.
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 Action" specify a range of policies in increasing order of strictness
strictness: (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. Expert Review 5. Expert Review
Expert review, sufficient documentation for review. Expert review, sufficient documentation for review.
6. Specification Required 6. Specification Required
Expert review, significant, stable public documentation. Expert review, significant, stable public documentation.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
2.3.3. Specifying Change Control for a Registry 2.3.3. Specifying Change Control for a Registry
Registry definitions and registrations within registries often need Registry definitions and registrations within registries often need
to be changed after they are created. The process of making such to be changed after they are created. The process of making such
changes is complicated when it is unclear who is authorized to make changes is complicated when it is unclear who is authorized to make
the changes. For registries created by RFCs in the IETF stream, the changes. For registries created by RFCs in the IETF stream,
change control for the registry lies by default with the IETF, via change control for the registry lies by default with the IETF, via
the IESG. The same is true for value registrations made in IETF- the IESG. The same is true for value registrations made in IETF-
stream RFCs. stream RFCs.
But registries can be created and registrations can be made outside Because registries can be created and registrations can be made
the IETF stream, it can sometimes be desired to have change control outside the IETF stream, it can sometimes be desired to have change
outside the IETF and IESG, and clear specification of change control control outside the IETF and IESG, and clear specification of change
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. See also Section 9.5.
skipping to change at page 13, line 12 skipping to change at page 13, line 19
as the document that created the registry, or as Best Current as the document that created the registry, or as Best Current
Practices (BCPs) [RFC2026]. 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 in an existing namespace (one
namespace (one created by a previously published document). created by a previously published document).
Such documents should clearly identify the namespace in which each Such documents should clearly identify the namespace into 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 explain that. Use the exact
registration should go. Use the exact namespace name as listed on namespace name as listed on the IANA web page, and cite the RFC where
the IANA web page, and cite the RFC where the namespace is defined. 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 is when making
assignments is, as that should be clear from the references. new assignments in existing registries, 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. See Section 2.2 for details on identify the registry is helpful. See Section 2.2 for details on
specifying the correct URL. specifying the correct URL.
For example, a document could contain something like this: For example, a document could contain something like this:
This registration should be made in the Foobar Operational This registration should be made in the Foobar Operational
Parameters registry, located at <http://www.iana.org/assignments/ Parameters registry, located at <http://www.iana.org/assignments/
foobar-registry>. foobar-registry>.
Each value requested should be given a unique reference. When the Normally, numeric values to be used are chosen by IANA when the
value is numeric, use the notation: TBD1, TBD2, etc. Throughout the document is approved, and drafts should not specify final values.
document where an actual IANA-assigned value should be filled in, use Instead, placeholders such as "TBD1" and "TBD2" should be used
the "TBDx" notation. This helps ensure that the final RFC has the consistently throughout the document, giving each item to be
correct assigned values inserted in all of the relevant places where registered a different placeholder. The IANA Considerations should
the value is expected to appear in the final document. For values ask the RFC Editor to replace the placeholder names with the IANA-
that are text strings, a specific name can be suggested. IANA will assigned values. When drafts need to specify numeric values for
normally assign the name, unless it conflicts with a name already in testing or early implementations, they will either request early
use. allocation (see Section 3.4) or use values that have already been set
aside for testing or experimentation. It is important that drafts
not choose their own values, lest IANA assign one of those values to
another document in the meantime. A draft can request a specific
value in the IANA Considerations section, and IANA will accommodate
such requests when that's possible, but the proposed number might
have been assigned to some other use by the time the draft is
approved.
Normally, the values to be used are chosen by IANA and documents Normally, text-string values to be used are specified in the
should specify values of "TBD". However, in some cases, a value may document, as collisions are less likely with text strings. IANA will
have been used for testing or in early implementations. In such consult with the authors if there is, in fact, a collision, and a
cases, it is acceptable to include text suggesting what specific different value has to be used. When drafts need to specify string
value should be used (together with the reason for the choice). For values for testing or early implementations, they sometimes use the
example, one might include the text "the value XXX is suggested as it expected final value. But it is often useful to use a draft value
is used in implementations". However, it should be noted that instead, possibly including the draft version number. This allows
suggested values are just that; IANA will attempt to assign them, but the early implementations to be distinguished from those implementing
may find that impossible, if the proposed number has already been the final version. A document that intends to use "foobar" in the
assigned for some other use. final version might use "foobar-testing-draft-05" for the -05 version
of the draft, for example.
For some registries, IANA has a long-standing policy prohibiting For some registries, IANA has a long-standing policy prohibiting
assignment of names or codes on a vanity or organization-name basis. assignment of names or codes on a vanity or organization-name basis.
For example, codes are always assigned sequentially unless there is a For example, codes might always be assigned sequentially unless there
strong reason for making an exception. Nothing in this document is is a strong reason for making an exception. Nothing in this document
intended to change those policies or prevent their future is intended to change those policies or prevent their future
application. application.
The IANA Considerations section should summarize all of the IANA The IANA Considerations section should summarize all of the IANA
actions, with pointers to the relevant sections elsewhere in the actions, with pointers to the relevant sections elsewhere in the
document as appropriate. When multiple values are requested, it is document as appropriate. When multiple values are requested, it is
generally helpful to include a summary table. It is also helpful for generally helpful to include a summary table. It is also helpful for
this table to be in the same format as it appears or will appear on this table to be in the same format as it appears or will appear on
the IANA web site. For example: the IANA web site. For example:
Value Description Reference Value Description Reference
skipping to change at page 14, line 43 skipping to change at page 15, line 7
the Domain Search List option from the DHCP option code space the Domain Search List option from the DHCP option code space
defined in Section 24.3 of RFC 3315. defined in Section 24.3 of RFC 3315.
3.2. Updating Existing Registrations 3.2. Updating Existing Registrations
Even after a number has been assigned, some types of registrations Even after a number has been assigned, some types of registrations
contain additional information that may need to be updated over time. contain additional information that may need to be updated over time.
For example, MIME media types, character sets, and language tags For example, MIME media types, character sets, and language tags
typically include more information than just the registered value typically include more information than just the registered value
itself, and may need things such as point-of-contact information, itself, and may need updates to items such as point-of-contact
security issues, pointers to updates, or literature references information, security issues, pointers to updates, and literature
updated. references.
In such cases, the document defining the namespace must clearly state In such cases, the document defining the namespace must clearly state
who is responsible for maintaining and updating a registration. who is responsible for maintaining and updating a registration.
Depending on the registry, it may be appropriate to specify one or Depending on the registry, it may be appropriate to specify one or
more of: more of:
o Letting registrants and/or nominated change controllers update o Letting registrants and/or nominated change controllers update
their own registrations, subject to the same constraints and their own registrations, subject to the same constraints and
review as with new registrations. review as with new registrations.
skipping to change at page 16, line 35 skipping to change at page 17, line 4
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.3.2. For more discussion of that topic, see Section 2.3.2.
Examples: Examples of RFCs that specify multiple policies in parallel:
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
skipping to change at page 17, line 35 skipping to change at page 18, line 4
part of the namespace. IANA makes allocations in the higher levels part of the namespace. IANA makes allocations in the higher levels
of the namespace according to one of the other policies. of the namespace according to one of the other policies.
Examples: Examples:
DNS names DNS names
Object Identifiers Object Identifiers
IP addresses IP addresses
4.4. First Come First Served 4.4. First Come First Served
For the First Come First Served policy, assignments are made to For the First Come First Served policy, assignments are made to
anyone on a first come, first served basis. There is no substantive anyone on a first come, first served basis. There is no substantive
review of the request, other than to ensure that it is well-formed review of the request, other than to ensure that it is well-formed
and doesn't duplicate an existing assignment. However, requests must and doesn't duplicate an existing assignment. However, requests must
include a minimal amount of clerical information, such as a point of include a minimal amount of clerical information, such as a point of
contact (including an email address, and sometimes a postal address) contact (including an email address, and sometimes a postal address)
and a brief description of how the value will be used. Additional and a brief description of how the value will be used. Additional
information specific to the type of value requested may also need to information specific to the type of value requested may also need to
be provided, as defined by the namespace. For numbers, the exact be provided, as defined by the namespace. For numbers, the exact
value is generally assigned by IANA; with names, specific text value is generally assigned by IANA; with names, specific text
strings can usually be requested. strings can usually be requested.
When creating a new registry with First Come First Served as the
registration policy, in addition to the contact person field or
reference, the registry should contain a field for change controller.
Having a change controller for each entry for these types of
registrations makes authorization of future modifications more clear.
See Section 2.3.3
Examples: Examples:
SASL mechanism names [RFC4422] SASL mechanism names [RFC4422]
LDAP Protocol Mechanisms and LDAP Syntax [RFC4520] LDAP Protocol Mechanisms and LDAP Syntax [RFC4520]
4.5. Expert Review 4.5. Expert Review
(Also called "Designated Expert" in earlier editions of this (Also called "Designated Expert" in earlier editions of this
document.) For the Expert Review policy, review and approval by a document.) For the Expert Review policy, review and approval by a
designated expert (see Section 5) is required. The required designated expert (see Section 5) is required. The required
documentation and review criteria for use by the designated expert documentation and review criteria for use by the designated expert
should be provided when defining the registry. For example, see should be provided when defining the registry. For example, see
Sections 6 and 7.2 in [RFC3748]. Sections 6 and 7.2 in [RFC3748].
It is particularly important, when using a designated expert, to give It is particularly important, when using a designated expert, to give
clear guidance to the expert, laying out criteria for performing an clear guidance to the expert, laying out criteria for performing an
evaluation and reasons for rejecting a request. When specifying a evaluation and reasons for rejecting a request. When specifying a
policy that involves a designated expert, the IANA Considerations policy that involves a designated expert, the IANA Considerations
SHOULD contain such guidance. It is also a good idea to include, SHOULD contain such guidance. It is also a good idea to include,
when possible, a sense of whether many registrations are expected when possible, a sense of whether many registrations are expected
over time, or if the registry is expected to be updated infrequently over time, or if the registry is expected to be updated infrequently
or in exceptional circumstances only. or in exceptional circumstances only.
When creating a new registry with Expert Review as the registration
policy, in addition to the contact person field or reference, the
registry should contain a field for change controller. Having a
change controller for each entry for these types of registrations
makes authorization of future modifications more clear. See Section
2.3.3
Examples: Examples:
EAP Method Types [RFC3748] EAP Method Types [RFC3748]
HTTP Digest AKA algorithm versions [RFC4169] HTTP Digest AKA algorithm versions [RFC4169]
URI schemes [RFC4395] URI schemes [RFC4395]
GEOPRIV Location Types [RFC4589] GEOPRIV Location Types [RFC4589]
4.6. Specification Required 4.6. Specification Required
For the Specification Required policy, review and approval by a For the Specification Required policy, review and approval by a
skipping to change at page 22, line 8 skipping to change at page 22, line 36
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.
Designated experts are appointed by the IESG, normally upon
recommendation by the relevant Area Director, either at the time a
document creating or updating a namespace is approved by the IESG or
subsequently, when the first registration request is received.
Because experts originally appointed may later become unavailable,
the IESG will appoint replacements as necessary.
For some registries, it has proven useful to have multiple designated
experts. Sometimes those experts work together in evaluating a
request, while in other cases additional experts serve as backups.
In cases of disagreement among those experts, it is the
responsibility of those experts to make a single clear recommendation
to IANA. It is not appropriate for IANA to resolve disputes among
experts. In extreme situations, such as deadlock, the IESG may need
to step in to resolve the problem.
In registries where a pool of experts evaluates requests, the pool In registries where a pool of experts evaluates requests, the pool
should have a single chair responsible for defining how requests are should have a single chair responsible for defining how requests are
to be assigned to and reviewed by experts. In some cases, the expert to be assigned to and reviewed by experts. In some cases, the expert
pool may consist of a primary and backups, with the backups involved pool may consist of a primary and backups, with the backups involved
only when the primary expert is unavailable. In other cases, IANA only when the primary expert is unavailable. In other cases, IANA
might assign requests to individual members in sequential or might assign requests to individual members in sequential or
approximate random order. In the event that IANA finds itself having approximate random order. In the event that IANA finds itself having
received conflicting advice from its experts, it is the received conflicting advice from its experts, it is the
responsibility of the pool's chair to resolve the issue and provide responsibility of the pool's chair to resolve the issue and provide
IANA with clear instructions. IANA with clear instructions.
If a designated expert is conflicted for a particular review (is, for If a designated expert is conflicted for a particular review (is, for
example, an author or significant proponent of a specification example, an author or significant proponent of a specification
related to the registration under review), that expert should recuse related to the registration under review), that expert should recuse
himself. In the event that all the designated experts are himself. In the event that all the designated experts are
conflicted, they should ask the IESG to designate a temporary expert conflicted, they should ask that a temporary expert be designated for
for the conflicted review. the conflicted review.
As the designated experts are appointed by the IESG, they may be It has proven useful to have multiple designated experts for some
removed by the IESG. registries. Sometimes those experts work together in evaluating a
request, while in other cases additional experts serve as backups.
In cases of disagreement among those experts, it is the
responsibility of those experts to make a single clear recommendation
to IANA. It is not appropriate for IANA to resolve disputes among
experts. In extreme situations, such as deadlock, the designating
body may need to step in to resolve the problem.
This document defines the designated expert mechanism with respect to
documents in the IETF stream only. Documents in other streams may
only use a registration policy that requires a designated expert if
those streams (or those documents) specify how designated experts are
appointed and managed. What is described below, with management by
the IESG, is only appropriate for the IETF stream.
5.2.1. Managing Designated Experts in the IETF
Designated experts for registries created by the IETF are appointed
by the IESG, normally upon recommendation by the relevant Area
Director. They may be appointed at the time a document creating or
updating a namespace is approved by the IESG, or subsequently, when
the first registration request is received. Because experts
originally appointed may later become unavailable, the IESG will
appoint replacements as necessary. The IESG may remove any
designated expert that it appointed, at its discretion.
The normal appeals process, as described in [RFC2026], Section 6.5.1,
applies to issues that arise with the designated expert team. For
this purpose, the designated expert team takes the place of the
working group in that description.
5.3. Designated Expert Reviews 5.3. Designated Expert Reviews
In the years since RFC 2434 was published and has been put to use, In the years since RFC 2434 was published and has been put to use,
experience has led to the following observations: experience has led to the following observations:
o A designated expert must respond in a timely fashion, normally o A designated expert must respond in a timely fashion, normally
within a week for simple requests to a few weeks for more complex within a week for simple requests to a few weeks for more complex
ones. Unreasonable delays can cause significant problems for ones. Unreasonable delays can cause significant problems for
those needing assignments, such as when products need code points those needing assignments, such as when products need code points
skipping to change at page 23, line 35 skipping to change at page 24, line 31
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. Possible reasons to deny a request include reason to the contrary. Possible reasons to deny a request include
these: 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 when a request for a large number should be prudently managed, or where a request for a large number
of code points is made, when 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
understood) architecture of the base protocol being extended, and understood) architecture of the base protocol being extended, and
would be harmful to the protocol if widely deployed. It is not would be harmful to the protocol if widely deployed. It is not
the intent that "inconsistencies" refer to minor differences "of a the intent that "inconsistencies" refer to minor differences "of a
personal preference nature". Instead, they refer to significant personal preference nature". Instead, they refer to significant
skipping to change at page 25, line 44 skipping to change at page 26, line 46
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. But note that, while it's important to include this information. But note that, while it's important to include this
information in the document, it needn't (and shouldn't) all be in information in the document, it needn't (and shouldn't) all be in
the IANA Considerations section. See Section 1.1. 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 occasion, 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. There will, though, changing the reference to be the "bis" document. There will, though,
skipping to change at page 27, line 26 skipping to change at page 28, line 28
actions being performed. actions being performed.
If a specification makes use of values from a namespace in which If a specification makes use of values from a namespace in which
assignments are not made by IANA, it may be useful to note this fact, assignments are not made by IANA, it may be useful to note this fact,
with wording such as this: with wording such as this:
The values of the Foobar parameter are assigned by the Barfoo The values of the Foobar parameter are assigned by the Barfoo
registry on behalf of the Rabfoo Forum. Therefore, this document registry on behalf of the Rabfoo Forum. Therefore, this document
has no IANA actions. has no IANA actions.
In some cases, the absence of IANA-assigned values may be considered IANA prefers that these "empty" IANA Considerations sections be left
valuable information for future readers; in other cases, it may be in the document for the record. This is a change from the prior
considered of no value once the document has been approved, and may practice of requesting that such sections be removed by the RFC
be removed before archival publication. This choice should be made Editor, and authors are asked to accommodate this change.
clear in the draft, for example, by including a sentence such as
[RFC Editor: please remove this section prior to publication.]
or
[RFC Editor: please do not remove this section.]
9.2. Namespaces Lacking Documented Guidance 9.2. Namespaces Lacking Documented Guidance
For all existing RFCs that either explicitly or implicitly rely on For all existing RFCs that either explicitly or implicitly rely on
IANA to make assignments without specifying a precise assignment IANA to make assignments without specifying a precise assignment
policy, IANA (in consultation with the IESG) will continue to decide policy, IANA (in consultation with the IESG) will continue to decide
what policy is appropriate. Changes to existing policies can always what policy is appropriate. Changes to existing policies can always
be initiated through the normal IETF consensus process, or through be initiated through the normal IETF consensus process, or through
the IESG when appropriate. the IESG when appropriate.
skipping to change at page 32, line 8 skipping to change at page 33, line 8
evaluate specs for sufficient clarity. evaluate specs for sufficient clarity.
o Significantly changed the wording in the Designated Experts o Significantly changed the wording in the Designated Experts
section. Main purpose is to make clear that Expert Reviewers are section. Main purpose is to make clear that Expert Reviewers are
accountable to the community, and to provide some guidance for accountable to the community, and to provide some guidance for
review criteria in the default case. review criteria in the default case.
o Changed wording to remove any special appeals path. The normal o Changed wording to remove any special appeals path. The normal
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 values.
o Added a section on after-the-fact registrations. o Added a section on after-the-fact registrations.
o Added a section indicating that mailing lists used to evaluate o Added a section indicating that mailing lists used to evaluate
possible assignments (such as by a Designated Expert) are subject possible assignments (such as by a Designated Expert) are subject
to normal IETF rules. to normal IETF rules.
14. Acknowledgments 14. Acknowledgments
14.1. Acknowledgments for This Document (2014) 14.1. Acknowledgments for This Document (2014)
Thomas Narten and Harald Tveit Alvestrand edited the two earlier Thomas Narten and Harald Tveit Alvestrand edited the two earlier
editions of this document (RFCs 2434 and 5226), and Thomas continues editions of this document (RFCs 2434 and 5226), and Thomas continues
his role in this third edition. Much of the text from RFC 5226 his role in this third edition. Much of the text from RFC 5226
remains in this edition. remains in this edition.
Thank you to Amanda Baber and Pearl Liang for their multiple reviews 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 John This document has benefited from thorough review and comments by Tony
Klensin and Mark Nottingham. Hansen, John 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, and to Tony Hansen for
acting as document shepherd.
14.2. Acknowledgments from the second edition (2008) 14.2. Acknowledgments from the second edition (2008)
The original acknowledgments section in RFC 5226 was: The original acknowledgments section in RFC 5226 was:
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.
 End of changes. 35 change blocks. 
136 lines changed or deleted 167 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/