< draft-leiba-cotton-iana-5226bis-16.txt   draft-leiba-cotton-iana-5226bis-17.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 07, 2016 IBM Corporation Expires: January 26, 2017 IBM Corporation
June 07, 2016 July 27, 2016
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-16 draft-leiba-cotton-iana-5226bis-17
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 07, 2016. This Internet-Draft will expire on January 26, 2017.
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 Updated Information . . . . . . . . . . . . . . . . . 4 1.2. For Updated Information . . . . . . . . . . . . . . . . . 4
2. Creating and Revising Registries . . . . . . . . . . . . . . . 4 1.3. A Quick Checklist Up Front . . . . . . . . . . . . . . . . 4
2.1. Organization of Registries . . . . . . . . . . . . . . . . 5 2. Creating and Revising Registries . . . . . . . . . . . . . . . 6
2.2. Documentation Requirements for Registries . . . . . . . . 5 2.1. Organization of Registries . . . . . . . . . . . . . . . . 7
2.3. Specifying Change Control for a Registry . . . . . . . . . 7 2.2. Documentation Requirements for Registries . . . . . . . . 7
2.4. Revising Existing Registries . . . . . . . . . . . . . . . 8 2.3. Specifying Change Control for a Registry . . . . . . . . . 9
3. Registering New Values in an Existing Registry . . . . . . . . 8 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 10
3.1. Documentation Requirements for Registrations . . . . . . . 8 3. Registering New Values in an Existing Registry . . . . . . . . 10
3.2. Updating Existing Registrations . . . . . . . . . . . . . 10 3.1. Documentation Requirements for Registrations . . . . . . . 10
3.3. Overriding Registration Procedures . . . . . . . . . . . . 11 3.2. Updating Existing Registrations . . . . . . . . . . . . . 12
3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 12 3.3. Overriding Registration Procedures . . . . . . . . . . . . 13
4. Choosing a Registration Policy, and Well-Known Policies . . . 12 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 13
4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 14 4. Choosing a Registration Policy, and Well-Known Policies . . . 14
4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 14 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 15 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 16
4.4. First Come First Served . . . . . . . . . . . . . . . . . 15 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17
4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 16 4.4. First Come First Served . . . . . . . . . . . . . . . . . 17
4.6. Specification Required . . . . . . . . . . . . . . . . . . 17 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 18
4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 18 4.6. Specification Required . . . . . . . . . . . . . . . . . . 19
4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 18 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 20
4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 19 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 20
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 19 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 21
4.11. Using the Well-Known Registration Policies . . . . . . . . 20 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 21
4.12. Using Multiple Policies in Combination . . . . . . . . . . 21 4.11. Using the Well-Known Registration Policies . . . . . . . . 22
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 22 4.12. Using Multiple Policies in Combination . . . . . . . . . . 23
5.1. The Motivation for Designated Experts . . . . . . . . . . 22 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 24
5.2. The Role of the Designated Expert . . . . . . . . . . . . 22 5.1. The Motivation for Designated Experts . . . . . . . . . . 24
5.2.1. Managing Designated Experts in the IETF . . . . . . . 23 5.2. The Role of the Designated Expert . . . . . . . . . . . . 24
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24 5.2.1. Managing Designated Experts in the IETF . . . . . . . 26
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 26
6. Well-Known Registration Status Terminology . . . . . . . . . . 26 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 27
7. Documentation References in IANA Registries . . . . . . . . . 27 6. Well-Known Registration Status Terminology . . . . . . . . . . 28
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27 7. Documentation References in IANA Registries . . . . . . . . . 29
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 29 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 29
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 29 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 31
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 29 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 31
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 29 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 31
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 30 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 31
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 31 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 32
9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 31 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 33
9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 33
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 32 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 33 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 35
14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 33 14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 35
14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 34 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 36
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
15.1. Acknowledgments for This Document (2016) . . . . . . . . 34 15.1. Acknowledgments for This Document (2016) . . . . . . . . 36
15.2. Acknowledgments from the second edition (2008) . . . . . 35 15.2. Acknowledgments from the second edition (2008) . . . . . 37
15.3. Acknowledgments from the first edition (1998) . . . . . . 35 15.3. Acknowledgments from the first edition (1998) . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . 35 16.1. Normative References . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . 35 16.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
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 43 skipping to change at page 4, line 43
[[(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
URL above set to redirect to it. ]] URL above set to redirect to it. ]]
1.3. A Quick Checklist Up Front
It's useful to be familiar with this document as a whole. But when
you return for quick reference, here are checklists for the most
common things you'll need to do, and references to help with the less
common ones.
In general...
1. Put all the information that IANA will need to know into the
"IANA Considerations" section of your document (see Section 1.1).
2. Try to keep that section only for information to IANA and to
designated expert reviewers, and put significant technical
information in the appropriate technical sections of the document
(see Section 1.1).
3. Note that the IESG has the authority to resolve issues with IANA
registrations, and if you have any questions or problems you
should consult an Area Director (see Section 3.3).
If you are creating a new registry...
1. Give the registry a descriptive name, and provide a brief
description of its use (see Section 2.2).
2. Identify any registry grouping that it should be part of (see
Section 2.1).
3. Clearly specify what information is required in order to register
new items (see Section 2.2). Be sure to specify data types,
lengths, and valid ranges for fields.
4. Specify the initial set of items for the registry, if applicable
(see Section 2.2).
5. Make sure it's clear to IANA what the change control policy is
for the registry, in case changes to the format or policies need
to be made later (see Section 2.3 and Section 9.5).
6. Select a registration policy -- or a set of policies -- to use
for future registrations (see Section 4, and especially note
Section 4.11 and Section 4.12).
7. If you're using a policy that requires a Designated Expert
(Expert Review or Specification Required), understand Section 5
Section 5, and provide review guidance to the Designated Expert
(see Section 5.3).
8. If any items or ranges in your registry need to be reserved for
special use or are otherwise unavailable for assignment, see
Section 6.
If you are registering into an existing registry...
1. Clearly identify the registry by its exact name, and optionally
by its URL (see Section 3.1).
2. If the registry has multiple ranges from which assignments can be
made, make it clear which range is requested (see Section 3.1).
3. Avoid using specific values for numeric or bit assignments, and
let IANA pick a suitable value at registration time (see Section
3.1). This will avoid registration conflicts among multiple
documents.
4. For "reference" fields, use the document that provides the best,
most current documentation for the item being registered, and
include section numbers to make it easier for readers to locate
the relevant documentation (see Section 3.1 and Section 7).
5. Look up (in the registry's reference document) what information
is required for the registry and accurately provide all the
necessary information (see Section 3.1).
6. Look up (in the registry's reference document) any special rules
or processes there may be for the registry, such as posting to a
particular mailing list for comment, and be sure to follow the
process (see Section 3.1).
7. Make sure it's clear to IANA what the change control policy is
for the item, in case changes to the registration need to be made
later (see Section 9.5).
If you're writing a "bis" document or otherwise making older
documents obsolete, see Section 8.
If you need to make an early registration, such as for supporting
test implementations during document development, rather than waiting
for your document to be finished and approved, see [RFC7120].
If you need to change the format/contents or policies for an existing
registry, see Section 2.4.
If you need to update an existing registration, see Section 3.2.
If you need to close down a registry because it is no longer needed,
see Section 9.6.
2. Creating and Revising Registries 2. Creating and Revising Registries
Defining a registry involves describing the namespaces to be created, Defining a registry involves describing the namespaces to be created,
listing an initial set of assignments (if applicable), and listing an initial set of assignments (if applicable), and
documenting guidelines on how future assignments are to be made. documenting guidelines on how future assignments are to be made.
When defining a registry, consider structuring the namespace in such When defining a registry, consider structuring the namespace in such
a way that only top-level assignments need to be made with central a way that only top-level assignments need to be made with central
coordination, and those assignments can delegate lower-level coordination, and those assignments can delegate lower-level
assignments so coordination for them can be distributed. This assignments so coordination for them can be distributed. This
skipping to change at page 7, line 42 skipping to change at page 9, line 38
0 Reserved 0 Reserved
1 Frobnitz RFCXXXX, Section y.1 1 Frobnitz RFCXXXX, Section y.1
2 NitzFrob RFCXXXX, Section y.2 2 NitzFrob RFCXXXX, 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
[RFC3575], [RFC3968], and [RFC4520]. [RFC3575], [RFC3968], and [RFC4520].
Any time IANA includes names and contact information in the public
registry, some individuals might prefer that their contact
information not be made public. In such cases, arrangements can be
made with IANA to keep the contact information private.
2.3. Specifying Change Control for a Registry 2.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.
skipping to change at page 8, line 16 skipping to change at page 10, line 16
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. Example: the Media Types registry [RFC6838] make the change. Example: the Media Types registry [RFC6838]
includes a "Change Controller" in its registration template. See includes a "Change Controller" in its registration template. See
also Section 9.5. also Section 9.5.
While IANA normally includes information about change control in the
public registry, some change controllers might prefer that their
identities or contact information not be made public. In such cases,
arrangements can be made with IANA to keep the information private,
to use an alias or role-based contact address, or to otherwise
protect the change controller's privacy.
2.4. Revising Existing Registries 2.4. Revising Existing Registries
Updating the registration process or making changes to the format of Updating the registration process or making changes to the format of
an already existing (previously created) registry (whether created an already existing (previously created) registry (whether created
explicitly or implicitly) follows a process similar to that used when explicitly or implicitly) follows a process similar to that used when
creating a new registry. That is, a document is produced that makes creating a new registry. That is, a document is produced that makes
reference to the existing namespace and then provides detailed reference to the existing namespace and then provides detailed
guidance for handling assignments in the registry, or detailed guidance for handling assignments in the registry, or detailed
instructions about the changes required. instructions about the changes required.
skipping to change at page 9, line 19 skipping to change at page 11, line 13
identify the registry is helpful (see Section 2.2). 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.
Be sure to provide all the information required for a registration,
and follow any special processes that are set out for the registry.
Registries sometimes require the completion of a registration
template for registration, or ask registrants to post their request
to a particular mailing list for discussion prior to registration.
Look up the registry's reference document: the required information
and special processes should be documented there.
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
 End of changes. 8 change blocks. 
66 lines changed or deleted 171 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/