< draft-leiba-cotton-iana-5226bis-12.txt   draft-leiba-cotton-iana-5226bis-13.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: October 05, 2016 IBM Corporation Expires: November 24, 2016 IBM Corporation
April 05, 2016 May 25, 2016
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-12 draft-leiba-cotton-iana-5226bis-13
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 October 05, 2016. This Internet-Draft will expire on November 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 44 skipping to change at page 2, line 44
4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17
4.6. Specification Required . . . . . . . . . . . . . . . . . . 18 4.6. Specification Required . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . 19
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20
4.11. Using the Well-Known Registration Policies . . . . . . . . 20 4.11. Using the Well-Known Registration Policies . . . . . . . . 20
4.12. Using Multiple Policies in Combination . . . . . . . . . . 21 4.12. Using Multiple Policies in Combination . . . . . . . . . . 21
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 22 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 22
5.1. The Motivation for Designated Experts . . . . . . . . . . 22 5.1. The Motivation for Designated Experts . . . . . . . . . . 22
5.2. The Role of the Designated Expert . . . . . . . . . . . . 23 5.2. The Role of the Designated Expert . . . . . . . . . . . . 22
5.2.1. Managing Designated Experts in the IETF . . . . . . . 23 5.2.1. Managing Designated Experts in the IETF . . . . . . . 23
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25
6. Well-Known Registration Status Terminology . . . . . . . . . . 26 6. Well-Known Registration Status Terminology . . . . . . . . . . 26
7. Documentation References in IANA Registries . . . . . . . . . 26 7. Documentation References in IANA Registries . . . . . . . . . 27
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 28 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 28
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 28 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 28
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 29 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 29
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 29 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 29
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 30 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 30
9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 30 9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 31
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 31
12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 31 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 32
14.1. 2014: Changes in This Document Relative to RFC 5226 . . . 32 14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 32
14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 33 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 33
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Acknowledgments for This Document (2014) . . . . . . . . 33 15.1. Acknowledgments for This Document (2016) . . . . . . . . 34
15.2. Acknowledgments from the second edition (2008) . . . . . 34 15.2. Acknowledgments from the second edition (2008) . . . . . 34
15.3. Acknowledgments from the first edition (1998) . . . . . . 34 15.3. Acknowledgments from the first edition (1998) . . . . . . 34
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
16.1. Normative References . . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . 35
16.2. Informative References . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Many protocols make use of points of extensibility that use constants Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central interoperability, their allocation is often coordinated by a central
record keeper. For IETF protocols, that role is filled by the record keeper. For IETF protocols, that role is filled by the
Internet Assigned Numbers Authority (IANA) [RFC2860]. Internet Assigned Numbers Authority (IANA) [RFC2860].
skipping to change at page 4, line 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.
1.2. For More Information 1.2. For More Information
IANA maintains a web page that includes current important information IANA maintains a web page that includes current important information
from IANA. Document authors should check that page for additional from IANA. Document authors should check that page for additional
information, beyond what is provided here. information, beyond what is provided here.
<https://iana.org/help/protocol-registration>. <https://iana.org/help/protocol-registration>.
[[The initial version of this should contain the bits that are [[(RFC Editor: Please remove this paragraph.) The initial version of
salient to most document authors -- perhaps a table of required this should contain the bits that are salient to most document
elements to create a new registry or update one, a bit about sub- authors -- perhaps a table of required elements to create a new
registries, and the listing of well-known registration policies. ]] registry or update one, a bit about sub-registries, and the listing
of well-known registration policies. IANA has text for this, but
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
URL above set to redirect to it. ]]
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
skipping to change at page 6, line 31 skipping to change at page 6, line 33
provided. It is highly desirable that the chosen name not be provided. It is highly desirable that the chosen name not be
easily confused with the name of another registry. easily confused with the name of another registry.
When creating a registry, the group that it is a part of must be When creating a registry, the group that it is a part of must be
identified using its full name, exactly as it appears in the IANA identified using its full name, exactly as it appears in the IANA
registry list. registry list.
Providing a URL to precisely identify the registry helps IANA Providing a URL to precisely identify the registry helps IANA
understand the request. Such URLs can be removed from the RFC understand the request. Such URLs can be removed from the RFC
prior to final publication. If they are to be left in, it is prior to final publication. If they are to be left in, it is
important that they be permanent links. IANA intends to include important that they be permanent links. IANA can answer questions
the permalink for each registry in the registry header. Until about the correct URLs to use.
that is done, IANA can answer questions about the correct URLs to
use.
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 <https://www.iana.org/ Parameters registry, located at <https://www.iana.org/
assignments/foobar-registry>. assignments/foobar-registry>.
It might be tempting to use the URL that appears in your web It might be tempting to use the URL that appears in your web
browser's address bar, which might look something like this for browser's address bar, which might look something like this for
the example above: the example above:
skipping to change at page 8, line 26 skipping to change at page 8, line 26
TBD1 FooBar N FooBar server TBD1 FooBar N FooBar server
The FooBar option also defines an 8-bit FooType field, for which The FooBar option also defines an 8-bit FooType field, for which
IANA is to create and maintain a new registry entitled IANA is to create and maintain a new registry entitled
"FooType values" used by the FooBar option. Initial values for the "FooType values" used by the FooBar option. Initial values for the
DHCP FooBar FooType registry are given below; future assignments DHCP FooBar FooType registry are given below; future assignments
are to be made through Expert Review [BCP26]. are to be made through Expert Review [BCP26].
Assignments consist of a DHCP FooBar FooType name and its Assignments consist of a DHCP FooBar FooType name and its
associated value. associated value.
Value DHCP FooBar FooType Name Definition Value DHCP FooBar FooType Name Definition
---- ------------------------ ---------- ---- ------------------------ ----------
0 Reserved 0 Reserved
1 Frobnitz See Section y.1 1 Frobnitz RFCXXXX, Section y.1
2 NitzFrob See 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].
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
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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.
If a change requires a new column in the registry, the instructions If a change requires a new column in the registry, the instructions
need to be clear about how to populate that column for the existing need to be clear about how to populate that column for the existing
entries. Other changes may require similar clarity. entries. Other changes may require similar clarity.
Such documents are normally processed with the same document status Such documents are normally processed with the same document status
as the document that created the registry. as the document that created the registry. Under some circumstances,
such as with a straightforward change that is clearly needed (such as
adding a "status" column), or when an earlier error needs to be
corrected, the IESG may approve an update to a registry without
requiring a new document.
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 in an existing registry (one Often, documents request an assignment in an existing registry (one
created by a previously published document). created by a previously published document).
skipping to change at page 11, line 34 skipping to change at page 11, line 34
make it easier for those searching the reference document to find the make it easier for those searching the reference document to find the
relevant information. relevant information.
When multiple values are requested, it is generally helpful to When multiple values are requested, it is generally helpful to
include a summary table of the additions/changes. It is also helpful include a summary table of the additions/changes. It is also helpful
for this table to be in the same format as it appears or will appear for this table to be in the same format as it appears or will appear
on the IANA web site. For example: on the IANA web site. For example:
Value Description Reference Value Description Reference
-------- ------------------- --------- -------- ------------------- ---------
TBD1 Foobar [[this RFC, Section 3.2]] TBD1 Foobar this RFC, Section 3.2
TBD2 Gumbo [[this RFC, Section 3.3]] TBD2 Gumbo this RFC, Section 3.3
TBD3 Banana [[this RFC, Section 3.4]] TBD3 Banana this RFC, Section 3.4
Note: In cases where authors feel that including the full table of Note: In cases where authors feel that including the full table of
changes is too verbose or repetitive, authors should still include changes is too verbose or repetitive, authors should still include
the table in the draft, but may include a note asking that the table the table in the draft, but may include a note asking that the table
be removed prior to publication of the final RFC. be removed prior to publication of the final RFC.
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.
skipping to change at page 18, line 38 skipping to change at page 18, line 38
sufficiently clear to allow interoperable implementations. sufficiently clear to allow interoperable implementations.
The intention behind "permanent and readily available" is that a The intention behind "permanent and readily available" is that a
document can reasonably be expected to be findable and retrievable document can reasonably be expected to be findable and retrievable
long after IANA assignment of the requested value. Publication of an long after IANA assignment of the requested value. Publication of an
RFC is an ideal means of achieving this requirement, but RFC is an ideal means of achieving this requirement, but
Specification Required is intended to also cover the case of a Specification Required is intended to also cover the case of a
document published outside of the RFC path, including informal document published outside of the RFC path, including informal
documentation. documentation.
For RFC publication, the normal RFC review process is expected to For RFC publication, formal review by the designated expert is still
provide the necessary review for interoperability, though the requested, but the normal RFC review process is expected to provide
designated expert may be a particularly well-qualified person to the necessary review for interoperability. The designated expert's
perform such a review. review is still important, but it's equally important to note that
when there is IETF consensus, the expert can sometimes be "in the
rough" (see also the last paragraph of Section 5.4).
As with Expert Review (Section 4.5), clear guidance to the designated As with Expert Review (Section 4.5), clear guidance to the designated
expert, should be provided when defining the registry. expert, should be provided when defining the registry.
When specifying this policy, just use the term "Specification When specifying this policy, just use the term "Specification
Required". Some specifications have chosen to refer to it as "Expert Required". Some specifications have chosen to refer to it as "Expert
Review with Specification Required", and that only causes confusion. Review with Specification Required", and that only causes confusion.
Examples: Examples:
skipping to change at page 19, line 52 skipping to change at page 19, line 52
Examples: Examples:
IPSECKEY Algorithm Types [RFC4025] IPSECKEY Algorithm Types [RFC4025]
Accounting-Auth-Method AVP values in DIAMETER [RFC4005] Accounting-Auth-Method AVP values in DIAMETER [RFC4005]
TLS Extension Types [RFC5246] TLS Extension Types [RFC5246]
4.9. Standards Action 4.9. Standards Action
For the Standards Action policy, values are assigned only through For the Standards Action policy, values are assigned only through
Standards Track or Best Current Practice RFCs approved by the IESG. Standards Track or Best Current Practice RFCs in the IETF Stream.
Examples: Examples:
BGP message types [RFC4271] BGP message types [RFC4271]
Mobile Node Identifier option types [RFC4283] Mobile Node Identifier option types [RFC4283]
TLS ClientCertificateType Identifiers 0-63 [RFC5246] TLS ClientCertificateType Identifiers 0-63 [RFC5246]
DCCP Packet Types [RFC4340] DCCP Packet Types [RFC4340]
4.10. IESG Approval 4.10. IESG Approval
skipping to change at page 26, line 37 skipping to change at page 26, line 44
Unassigned: Not currently assigned, and available for assignment Unassigned: Not currently assigned, and available for assignment
via documented procedures. While it's generally clear that via documented procedures. While it's generally clear that
any values that are not registered are unassigned and any values that are not registered are unassigned and
available for assignment, it is sometimes useful to available for assignment, it is sometimes useful to
explicitly specify that situation. Note that this is explicitly specify that situation. Note that this is
distinctly different from "Reserved". distinctly different from "Reserved".
Reserved: Not assigned and not available for assignment. Reserved Reserved: Not assigned and not available for assignment. Reserved
values are held for special uses, such as to extend the values are held for special uses, such as to extend the
namespace when it becomes exhausted. Note that this is namespace when it becomes exhausted. "Reserved" is also
sometimes used to designate values that had been assigned
but are no longer in use, keeping them set aside as long as
other unassigned values are available. Note that this is
distinctly different from "Unassigned". distinctly different from "Unassigned".
Reserved values can be released for assignment by the change Reserved values can be released for assignment by the change
controller for the registry (this is often the IESG, for controller for the registry (this is often the IESG, for
registries created by RFCs in the IETF stream). registries created by RFCs in the IETF stream).
7. Documentation References in IANA Registries 7. Documentation References in IANA Registries
Usually, registries and registry entries include references to Usually, registries and registry entries include references to
documentation (RFCs or other documents). The purpose of these documentation (RFCs or other documents). The purpose of these
skipping to change at page 27, line 15 skipping to change at page 27, line 26
containing the definition, not to the document that is merely containing the definition, not to the document that is merely
performing the registration. performing the registration.
o If the registered item is defined and explained in the current o If the registered item is defined and explained in the current
document, it is important to include sufficient information to document, it is important to include sufficient information to
enable implementors to understand the item and to create a proper enable implementors to understand the item and to create a proper
implementation. implementation.
o If the registered item is explained primarily in a specific o If the registered item is explained primarily in a specific
section of the reference document, it is useful to include a section of the reference document, it is useful to include a
section reference. For example, "[RFC9876], Section 3.2", rather section reference. For example, "[RFC4637], Section 3.2", rather
than just "[RFC9876]". than just "[RFC4637]".
o For documentation of a new registry, the reference should provide o For documentation of a new registry, the reference should provide
information about the registry itself, not just a pointer to the information about the registry itself, not just a pointer to the
creation of it. Useful information includes the purpose of the creation of it. Useful information includes the purpose of the
registry, a rationale for its creation, documentation of the registry, a rationale for its creation, documentation of the
process and policy for new registrations, guidelines for new process and policy for new registrations, guidelines for new
registrants or designated experts, and other such related registrants or designated experts, and other such related
information. 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 all be in the IANA information in the document, it needn't all be in the IANA
Considerations section. See Section 1.1. Considerations section. See Section 1.1.
8. What to Do in "bis" Documents 8. What to Do in "bis" Documents
On occasion, 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 obsoleted by draft-ietf-foo-rfc9876bis. When the when RFC 4637 is obsoleted by draft-ietf-foo-rfc4637bis. When the
original document created registries and/or registered entries, there original document created registries and/or registered entries, there
is a question of how to handle the IANA Considerations section in the is a question of how to handle the IANA Considerations section in the
"bis" document. "bis" document.
If the registrations specify the original document as a reference, If the registrations specify the original document as a reference,
those registrations should be updated to point to the current (not those registrations should be updated to point to the current (not
obsolete) documentation for those items. Usually, that will mean obsolete) documentation for those items. Usually, that will mean
changing the reference to be the "bis" document. changing the reference to be the "bis" document.
There will, though, be times when a document updates another, but There will, though, be times when a document updates another, but
does not make it obsolete, and the definitive reference is changed does not make it obsolete, and the definitive reference is changed
for some items but not for others. Be sure that the references are for some items but not for others. Be sure that the references are
always set to point to the correct, current documentation for each always set to point to the correct, current documentation for each
item. item.
For example, suppose RFC 9876 registered the "BANANA" flag in the For example, suppose RFC 4637 registered the "BANANA" flag in the
"Fruit Access Flags" registry, and the documentation for that flag is "Fruit Access Flags" registry, and the documentation for that flag is
in Section 3.2. in Section 3.2.
The current registry might look, in part, like this: The current registry might look, in part, like this:
Name Description Reference Name Description Reference
-------- ------------------- --------- -------- ------------------- ---------
BANANA Flag for bananas [RFC9876], Section 3.2 BANANA Flag for bananas [RFC4637], Section 3.2
If draft-ietf-foo-rfc9876bis obsoletes RFC 9876 and, because of some
If draft-ietf-foo-rfc4637bis obsoletes RFC 4637 and, because of some
rearrangement, now documents the flag in Section 4.1.2, the IANA rearrangement, now documents the flag in Section 4.1.2, the IANA
Considerations of the bis document might contain text such as this: Considerations of the bis document might contain text such as this:
IANA is asked to change the registration information for the IANA is asked to change the registration information for the
BANANA flag in the "Fruit Access Flags" registry to the following: BANANA flag in the "Fruit Access Flags" registry to the following:
Name Description Reference Name Description Reference
-------- ------------------- --------- -------- ------------------- ---------
BANANA Flag for bananas [[this RFC]], Section 4.2.1 BANANA Flag for bananas [[this RFC]], Section 4.2.1
In many cases, if there are a number of registered references to the In many cases, if there are a number of registered references to the
original RFC and the document organization has not changed the original RFC and the document organization has not changed the
registered section numbering much, it may simply be reasonable to do registered section numbering much, it may simply be reasonable to do
this: this:
Because this document obsoletes RFC 9876, IANA is asked to change Because this document obsoletes RFC 4637, IANA is asked to change
all registration information that references [RFC9876] to instead all registration information that references [RFC4637] to instead
reference [[this RFC]]. reference [[this RFC]].
If information for registered items has been or is being moved to If information for registered items has been or is being moved to
other documents, then, of course, the registration information should other documents, then, of course, the registration information should
be changed to point to those other documents. In no case is it be changed to point to those other documents. In no case is it
reasonable to leave documentation pointers to the obsoleted document reasonable to leave documentation pointers to the obsoleted document
for any registries or registered items that are still in current use. for any registries or registered items that are still in current use.
It is extremely important to be clear in your instructions regarding It is extremely important to be clear in your instructions regarding
updating references, especially in cases where some references need updating references, especially in cases where some references need
skipping to change at page 30, line 39 skipping to change at page 31, line 15
Registries can include, in addition to a "Contact" field, an Registries can include, in addition to a "Contact" field, an
"Assignee" or "Owner" field that can be used to address this "Assignee" or "Owner" field that can be used to address this
situation, giving IANA clear guidance as to the actual owner of the situation, giving IANA clear guidance as to the actual owner of the
registration. This is strongly advised especially for registries registration. This is strongly advised especially for registries
that do not require RFCs to manage their information (registries with that do not require RFCs to manage their information (registries with
policies such as First Come First Served Section 4.4, Expert Review policies such as First Come First Served Section 4.4, Expert Review
Section 4.5, and Specification Required Section 4.6). Alternatively, Section 4.5, and Specification Required Section 4.6). Alternatively,
organizations can put an organizational role into the "Contact" field organizations can put an organizational role into the "Contact" field
in order to make their ownership clear. in order to make their ownership clear.
9.6. Closing or Obsoleting a Registry 9.6. Closing or Obsoleting a Registry/Registrations
Sometimes there is a request to "close" a registry to further Sometimes there is a request to "close" a registry to further
registrations. When a registry is closed, no further registrations registrations. When a registry is closed, no further registrations
will be accepted. The information in the registry will still be will be accepted. The information in the registry will still be
valid and registrations already in the registry can still be updated. valid and registrations already in the registry can still be updated.
A closed registry can also be marked as "obsolete", as an indication A closed registry can also be marked as "obsolete", as an indication
that the information in the registry is no longer in current use. that the information in the registry is no longer in current use.
Specific entries in a registry can be marked as "obsolete" (no longer Specific entries in a registry can be marked as "obsolete" (no longer
skipping to change at page 31, line 52 skipping to change at page 32, line 30
protocols that make use of parameters (data types, operation codes, protocols that make use of parameters (data types, operation codes,
keywords, etc.) used in IETF protocols or registered by IANA. Such keywords, etc.) used in IETF protocols or registered by IANA. Such
security considerations are usually included in the protocol document security considerations are usually included in the protocol document
[RFC3552]. It is the responsibility of the IANA considerations [RFC3552]. It is the responsibility of the IANA considerations
associated with a particular registry to specify whether value- associated with a particular registry to specify whether value-
specific security considerations must be provided when assigning new specific security considerations must be provided when assigning new
values, and the process for reviewing such claims. values, and the process for reviewing such claims.
13. IANA Considerations 13. IANA Considerations
In accordance with Section 9.1: IANA is asked to update any references to RFC 5226 to now point to
this document.
This document has no IANA actions.
14. Changes Relative to Earlier Editions of BCP 26 14. Changes Relative to Earlier Editions of BCP 26
14.1. 2014: Changes in This Document Relative to RFC 5226
14.1. 2016: Changes in This Document Relative to RFC 5226
Significant additions: Significant additions:
o Removed RFC 2119 key words, boilerplate, and reference, preferring o Removed RFC 2119 key words, boilerplate, and reference, preferring
plain English -- this is not a protocol specification. plain English -- this is not a protocol specification.
o Added Section 1.1, Keep IANA Considerations for IANA o Added Section 1.1, Keep IANA Considerations for IANA
o Added Section 1.2, For More Information o Added Section 1.2, For More Information
skipping to change at page 33, line 48 skipping to change at page 34, line 26
o Added a section about reclaiming unused values. 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.
15. Acknowledgments 15. Acknowledgments
15.1. Acknowledgments for This Document (2014) 15.1. Acknowledgments for This Document (2016)
Thomas Narten and Harald Tveit Alvestrand edited the two earlier Thomas Narten and Harald Tveit Alvestrand edited the two earlier
editions of this document (RFCs 2434 and 5226), and Thomas continues editions of this document (RFCs 2434 and 5226), and Thomas continues
his role in this third edition. Much of the text from RFC 5226 his role in this third edition. Much of the text from RFC 5226
remains in this edition. remains in this edition.
Thank you to Amanda Baber and Pearl Liang for their multiple reviews Thank you to Amanda Baber and Pearl Liang for their multiple reviews
and suggestions for making this document as thorough as possible. and suggestions for making this document as thorough as possible.
This document has benefited from thorough review and comments by Tony This document has benefited from thorough review and comments by Tony
 End of changes. 27 change blocks. 
52 lines changed or deleted 64 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/