< draft-leiba-cotton-iana-5226bis-17.txt   draft-leiba-cotton-iana-5226bis-18.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 26, 2017 IBM Corporation Expires: March 24, 2017 IBM Corporation
July 27, 2016 September 22, 2016
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-17 draft-leiba-cotton-iana-5226bis-18
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 January 26, 2017. This Internet-Draft will expire on March 24, 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1.3. A Quick Checklist Up Front . . . . . . . . . . . . . . . . 4 1.3. A Quick Checklist Up Front . . . . . . . . . . . . . . . . 4
2. Creating and Revising Registries . . . . . . . . . . . . . . . 6 2. Creating and Revising Registries . . . . . . . . . . . . . . . 6
2.1. Organization of Registries . . . . . . . . . . . . . . . . 7 2.1. Organization of Registries . . . . . . . . . . . . . . . . 7
2.2. Documentation Requirements for Registries . . . . . . . . 7 2.2. Documentation Requirements for Registries . . . . . . . . 7
2.3. Specifying Change Control for a Registry . . . . . . . . . 9 2.3. Specifying Change Control for a Registry . . . . . . . . . 9
2.4. Revising Existing Registries . . . . . . . . . . . . . . . 10 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 10
3. Registering New Values in an Existing Registry . . . . . . . . 10 3. Registering New Values in an Existing Registry . . . . . . . . 10
3.1. Documentation Requirements for Registrations . . . . . . . 10 3.1. Documentation Requirements for Registrations . . . . . . . 10
3.2. Updating Existing Registrations . . . . . . . . . . . . . 12 3.2. Updating Existing Registrations . . . . . . . . . . . . . 12
3.3. Overriding Registration Procedures . . . . . . . . . . . . 13 3.3. Overriding Registration Procedures . . . . . . . . . . . . 13
3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 13 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 14
4. Choosing a Registration Policy, and Well-Known Policies . . . 14 4. Choosing a Registration Policy, and Well-Known Policies . . . 14
4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 16 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Specification Required . . . . . . . . . . . . . . . . . . 19 4.6. Specification Required . . . . . . . . . . . . . . . . . . 19
4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 20 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 20
4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 20 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 20
4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 21 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 21
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 21 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 21
4.11. Using the Well-Known Registration Policies . . . . . . . . 22 4.11. Using the Well-Known Registration Policies . . . . . . . . 22
4.12. Using Multiple Policies in Combination . . . . . . . . . . 23 4.12. Using Multiple Policies in Combination . . . . . . . . . . 23
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 24 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 24
5.1. The Motivation for Designated Experts . . . . . . . . . . 24 5.1. The Motivation for Designated Experts . . . . . . . . . . 24
5.2. The Role of the Designated Expert . . . . . . . . . . . . 24 5.2. The Role of the Designated Expert . . . . . . . . . . . . 24
5.2.1. Managing Designated Experts in the IETF . . . . . . . 26 5.2.1. Managing Designated Experts in the IETF . . . . . . . 25
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 26 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 26
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 27 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 27
6. Well-Known Registration Status Terminology . . . . . . . . . . 28 6. Well-Known Registration Status Terminology . . . . . . . . . . 28
7. Documentation References in IANA Registries . . . . . . . . . 29 7. Documentation References in IANA Registries . . . . . . . . . 29
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 29 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 29
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 31 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 30
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 31 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 30
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 31 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 31
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 31 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 31
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 32 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 32
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 33 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 32
9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 33 9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 33
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 34 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 35 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 34
14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 35 14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 34
14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 36 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 35
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
15.1. Acknowledgments for This Document (2016) . . . . . . . . 36 15.1. Acknowledgments for This Document (2016) . . . . . . . . 36
15.2. Acknowledgments from the second edition (2008) . . . . . 37 15.2. Acknowledgments from the second edition (2008) . . . . . 36
15.3. Acknowledgments from the first edition (1998) . . . . . . 37 15.3. Acknowledgments from the first edition (1998) . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . 37 16.1. Normative References . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 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
skipping to change at page 4, line 25 skipping to change at page 4, line 25
references to elsewhere in the document for other information. references to elsewhere in the document for other information.
The IANA actions are normally phrased as requests for IANA (such as, The IANA actions are normally phrased as requests for IANA (such as,
"IANA is asked to assign the value TBD1 from the Frobozz "IANA is asked to assign the value TBD1 from the Frobozz
Registry..."); the RFC Editor will change those sentences to reflect Registry..."); the RFC Editor will change those sentences to reflect
the actions taken ("IANA has assigned the value 83 from the Frobozz the actions taken ("IANA has assigned the value 83 from the Frobozz
Registry..."). Registry...").
1.2. For Updated Information 1.2. For Updated Information
IANA maintains a web page that includes current important information IANA maintains a web page that includes additional clarification
from IANA. Document authors should check that page for additional information, beyond what is provided here, such as minor updates and
information, beyond what is provided here: current clarifications, summary guidance. Document authors should check that page. Any
minor updates, and summary guidance. Any significant updates to the significant updates to the best current practice will have to feed
best current practice will have to feed into updates to BCP 26 (this into updates to BCP 26 (this document), which is definitive.
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). ]]
URL above set to redirect to it. ]]
1.3. A Quick Checklist Up Front 1.3. A Quick Checklist Up Front
It's useful to be familiar with this document as a whole. But when 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 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 things you'll need to do, and references to help with the less
common ones. common ones.
In general... In general...
1. Put all the information that IANA will need to know into the 1. Put all the information that IANA will need to know into the
"IANA Considerations" section of your document (see Section 1.1). "IANA Considerations" section of your document (see Section 1.1).
2. Try to keep that section only for information to IANA and to 2. Try to keep that section only for information to IANA and to
designated expert reviewers, and put significant technical designated expert reviewers, and put significant technical
information in the appropriate technical sections of the document information in the appropriate technical sections of the document
(see Section 1.1). (see Section 1.1).
3. Note that the IESG has the authority to resolve issues with IANA 3. Note that the IESG has the authority to resolve issues with IANA
registrations, and if you have any questions or problems you registrations, and if you have any questions or problems you
should consult an Area Director (see Section 3.3). should consult your document shepherd and/or working group chair,
who may ultimately involve an Area Director (see Section 3.3).
If you are creating a new registry... If you are creating a new registry...
1. Give the registry a descriptive name, and provide a brief 1. Give the registry a descriptive name, and provide a brief
description of its use (see Section 2.2). description of its use (see Section 2.2).
2. Identify any registry grouping that it should be part of (see 2. Identify any registry grouping that it should be part of (see
Section 2.1). Section 2.1).
3. Clearly specify what information is required in order to register 3. Clearly specify what information is required in order to register
skipping to change at page 6, line 25 skipping to change at page 6, line 24
5. Look up (in the registry's reference document) what information 5. Look up (in the registry's reference document) what information
is required for the registry and accurately provide all the is required for the registry and accurately provide all the
necessary information (see Section 3.1). necessary information (see Section 3.1).
6. Look up (in the registry's reference document) any special rules 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 or processes there may be for the registry, such as posting to a
particular mailing list for comment, and be sure to follow the particular mailing list for comment, and be sure to follow the
process (see Section 3.1). process (see Section 3.1).
7. Make sure it's clear to IANA what the change control policy is 7. If the registration policy for the registry does not already
for the item, in case changes to the registration need to be made dictate the change control policy, make sure it's clear to IANA
later (see Section 9.5). 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 If you're writing a "bis" document or otherwise making older
documents obsolete, see Section 8. documents obsolete, see Section 8.
If you need to make an early registration, such as for supporting If you need to make an early registration, such as for supporting
test implementations during document development, rather than waiting test implementations during document development, rather than waiting
for your document to be finished and approved, see [RFC7120]. for your document to be finished and approved, see [RFC7120].
If you need to change the format/contents or policies for an existing If you need to change the format/contents or policies for an existing
registry, see Section 2.4. registry, see Section 2.4.
 End of changes. 14 change blocks. 
27 lines changed or deleted 27 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/