diff options
Diffstat (limited to 'doc/rfc/rfc8126.txt')
| -rw-r--r-- | doc/rfc/rfc8126.txt | 2635 |
1 files changed, 2635 insertions, 0 deletions
diff --git a/doc/rfc/rfc8126.txt b/doc/rfc/rfc8126.txt new file mode 100644 index 0000000..8db09ea --- /dev/null +++ b/doc/rfc/rfc8126.txt @@ -0,0 +1,2635 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Cotton +Request for Comments: 8126 PTI +BCP: 26 B. Leiba +Obsoletes: 5226 Huawei Technologies +Category: Best Current Practice T. Narten +ISSN: 2070-1721 IBM Corporation + June 2017 + + + Guidelines for Writing an IANA Considerations Section in RFCs + +Abstract + + Many protocols make use of points of extensibility that use constants + to identify various protocol parameters. To ensure that the values + in these fields do not have conflicting uses and to promote + interoperability, their allocations are often coordinated by a + central record keeper. For IETF protocols, that role is filled by + the Internet Assigned Numbers Authority (IANA). + + To make assignments in a given registry prudently, guidance + describing the conditions under which new values should be assigned, + as well as when and how modifications to existing values can be made, + is needed. This document defines a framework for the documentation + of these guidelines by specification authors, in order to assure that + the provided guidance for the IANA Considerations is clear and + addresses the various issues that are likely in the operation of a + registry. + + This is the third edition of this document; it obsoletes RFC 5226. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8126. + + + + + + + +Cotton, et al. Best Current Practice [Page 1] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 4 + 1.2. For Updated Information . . . . . . . . . . . . . . . . . 5 + 1.3. A Quick Checklist Upfront . . . . . . . . . . . . . . . . 5 + 2. Creating and Revising Registries . . . . . . . . . . . . . . 7 + 2.1. Organization of Registries . . . . . . . . . . . . . . . 8 + 2.2. Documentation Requirements for Registries . . . . . . . . 8 + 2.3. Specifying Change Control for a Registry . . . . . . . . 11 + 2.4. Revising Existing Registries . . . . . . . . . . . . . . 11 + 3. Registering New Values in an Existing Registry . . . . . . . 12 + 3.1. Documentation Requirements for Registrations . . . . . . 12 + 3.2. Updating Existing Registrations . . . . . . . . . . . . . 14 + 3.3. Overriding Registration Procedures . . . . . . . . . . . 14 + 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15 + 4. Choosing a Registration Policy and Well-Known Policies . . . 15 + 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . 18 + 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 19 + 4.4. First Come First Served . . . . . . . . . . . . . . . . . 19 + 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 20 + 4.6. Specification Required . . . . . . . . . . . . . . . . . 21 + 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . 22 + 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 22 + 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . 23 + 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 23 + 4.11. Using the Well-Known Registration Policies . . . . . . . 24 + 4.12. Using Multiple Policies in Combination . . . . . . . . . 26 + 4.13. Provisional Registrations . . . . . . . . . . . . . . . . 26 + + + + + + +Cotton, et al. Best Current Practice [Page 2] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . 27 + 5.1. The Motivation for Designated Experts . . . . . . . . . . 27 + 5.2. The Role of the Designated Expert . . . . . . . . . . . . 27 + 5.2.1. Managing Designated Experts in the IETF . . . . . . . 29 + 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 29 + 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 31 + 6. Well-Known Registration Status Terminology . . . . . . . . . 31 + 7. Documentation References in IANA Registries . . . . . . . . . 32 + 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 33 + 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 34 + 9.1. When There Are No IANA Actions . . . . . . . . . . . . . 34 + 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . 35 + 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . 35 + 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . 35 + 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 36 + 9.6. Closing or Obsoleting a Registry/Registrations . . . . . 37 + 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 37 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . 38 + 14.1. 2016: Changes in This Document Relative to RFC 5226 . . 38 + 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 39 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 40 + 15.2. Informative References . . . . . . . . . . . . . . . . . 40 + Acknowledgments for This Document (2017) . . . . . . . . . . . . 46 + Acknowledgments from the Second Edition (2008) . . . . . . . . . 46 + Acknowledgments from the First Edition (1998) . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 + + + + + + + + + + + + + + + + + + + + + +Cotton, et al. Best Current Practice [Page 3] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +1. Introduction + + Many protocols make use of points of extensibility that use constants + to identify various protocol parameters. To ensure that the values + in these fields do not have conflicting uses and to promote + interoperability, their allocations are often coordinated by a + central record keeper. The Protocol field in the IP header [RFC791] + and MIME media types [RFC6838] are two examples of such + coordinations. + + The IETF selects an IANA Functions Operator (IFO) for protocol + parameters defined by the IETF. In the contract between the IETF and + the current IFO (ICANN), that entity is referred to as the IANA + PROTOCOL PARAMETER SERVICES Operator, or IPPSO. For consistency with + past practice, the IFO or IPPSO is referred to in this document as + "IANA" [RFC2860]. + + In this document, we call the range of possible values for such a + field a "namespace". The binding or association of a specific value + with a particular purpose within a namespace is called an assignment + (or, variously: an assigned number, assigned value, code point, + protocol constant, or protocol parameter). The act of assignment is + called a registration, and it takes place in the context of a + registry. The terms "assignment" and "registration" are used + interchangeably throughout this document. + + To make assignments in a given namespace prudently, guidance + describing the conditions under which new values should be assigned, + as well as when and how modifications to existing values can be made, + is needed. This document defines a framework for the documentation + of these guidelines by specification authors, in order to assure that + the guidance for the IANA Considerations is clear and addresses the + various issues that are likely in the operation of a registry. + + Typically, this information is recorded in a dedicated section of the + specification with the title "IANA Considerations". + +1.1. Keep IANA Considerations for IANA + + The purpose of having a dedicated IANA Considerations section is to + provide a single place to collect clear and concise information and + instructions for IANA. Technical documentation should reside in + other parts of the document; the IANA Considerations should refer to + these other sections by reference only (as needed). Using the IANA + Considerations section as primary technical documentation both hides + it from the target audience of the document and interferes with + IANA's review of the actions they need to take. + + + + +Cotton, et al. Best Current Practice [Page 4] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + An ideal IANA Considerations section clearly enumerates and specifies + each requested IANA action; includes all information IANA needs, such + as the full names of all applicable registries; and includes clear + references to elsewhere in the document for other information. + + The IANA actions are normally phrased as requests for IANA (such as, + "IANA is asked to assign the value TBD1 from the Frobozz + Registry..."); the RFC Editor will change those sentences to reflect + the actions taken ("IANA has assigned the value 83 from the Frobozz + Registry..."). + +1.2. For Updated Information + + IANA maintains a web page that includes additional clarification + information beyond what is provided here, such as minor updates and + summary guidance. Document authors should check that page. Any + significant updates to the best current practice will have to feed + into updates to BCP 26 (this document), which is definitive. + + <https://iana.org/help/protocol-registration> + +1.3. A Quick Checklist Upfront + + 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; 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. If you have any questions or problems, you should + consult your document shepherd and/or working group chair, who + may ultimately involve an Area Director (see Section 3.3). + + + + + + + + + +Cotton, et al. Best Current Practice [Page 5] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + 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 the change control policy for the registry is clear to + IANA, in case changes to the format or policies need to be made + later (see Sections 2.3 and 9.5). + + 6. Select a registration policy -- or a set of policies -- to use + for future registrations (see Section 4, and especially note + Sections 4.11 and 4.12). + + 7. If you're using a policy that requires a designated expert + (Expert Review or Specification Required), understand 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. + + + + + + + +Cotton, et al. Best Current Practice [Page 6] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + 4. For "reference" fields, use the document that provides the best + and most current documentation for the item being registered. + Include section numbers to make it easier for readers to locate + the relevant documentation (see Sections 3.1 and 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. If the registration policy for the registry does not already + dictate the change control policy, 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 + + Defining a registry involves describing the namespaces to be created, + listing an initial set of assignments (if applicable), and + documenting guidelines on how future assignments are to be made. + + When defining a registry, consider structuring the namespace in such + a way that only top-level assignments need to be made with central + coordination, and those assignments can delegate lower-level + assignments so coordination for them can be distributed. This + lessens the burden on IANA for dealing with assignments, and is + particularly useful in situations where distributed coordinators have + better knowledge of their portion of the namespace and are better + suited to handling those assignments. + + + +Cotton, et al. Best Current Practice [Page 7] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +2.1. Organization of Registries + + All registries are anchored from the IANA "Protocol Registries" page: + + <https://www.iana.org/protocols> + + That page lists registries in protocol category groups, placing + related registries together and making it easier for users of the + registries to find the necessary information. Clicking on the title + of one of the registries on the IANA Protocol Registries page will + take the reader to the details page for that registry. + + Unfortunately, we have been inconsistent in how we refer to these + entities. The group names, as they are referred to here, have been + variously called "protocol category groups", "groups", "top-level + registries", or just "registries". The registries under them have + been called "registries" or "sub-registries". + + Regardless of the terminology used, document authors should pay + attention to the registry groupings, should request that related + registries be grouped together to make related registries easier to + find, and, when creating a new registry, should check whether that + registry might best be included in an existing group. That grouping + information should be clearly communicated to IANA in the registry + creation request. + +2.2. Documentation Requirements for Registries + + Documents that create a new namespace (or modify the definition of an + existing space) and that expect IANA to play a role in maintaining + that space (serving as a repository for registered values) must + provide clear instructions on details of the namespace, either in the + IANA Considerations section or referenced from it. + + In particular, such instructions must include: + + The name of the registry + + This name will appear on the IANA web page and will be referred to + in future documents that need to allocate a value from the new + space. The full name (and abbreviation, if appropriate) should be + provided. It is highly desirable that the chosen name not be + easily confused with the name of another registry. + + 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 + Protocol Registries list. + + + + +Cotton, et al. Best Current Practice [Page 8] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Providing a URL to precisely identify the registry helps IANA + understand the request. Such URLs can be removed from the RFC + prior to final publication or left in the document for reference. + If you include iana.org URLs, IANA will provide corrections, if + necessary, during their review. + + Required information for registrations + + This tells registrants what information they have to include in + their registration requests. Some registries require only the + requested value and a reference to a document where use of the + value is defined. Other registries require a more detailed + registration template that describes relevant security + considerations, internationalization considerations, and other + such information. + + Applicable registration policy + + The policy that will apply to all future requests for + registration. See Section 4. + + Size, format, and syntax of registry entries + + What fields to record in the registry, any technical requirements + on registry entries (valid ranges for integers, length limitations + on strings, and such), and the exact format in which registry + values should be displayed. For numeric assignments, one should + specify whether values are to be recorded in decimal, in + hexadecimal, or in some other format. + + Strings are expected to be ASCII, and it should be clearly + specified whether case matters, and whether, for example, strings + should be shown in the registry in uppercase or lowercase. + + Strings that represent protocol parameters will rarely, if ever, + need to contain non-ASCII characters. If non-ASCII characters are + really necessary, instructions should make it very clear that they + are allowed and that the non-ASCII characters should be + represented as Unicode characters using the "(U+XXXX)" convention. + Anyone creating such a registry should think carefully about this + and consider internationalization advice such as that in + [RFC7564], Section 10. + + + + + + + + + +Cotton, et al. Best Current Practice [Page 9] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Initial assignments and reservations + + Any initial assignments or registrations to be included. In + addition, any ranges that are to be reserved for "Private Use", + "Reserved", "Unassigned", etc. (see Section 6) should be + indicated. + + For example, a document might specify a new registry by including: + + --------------------------------------------------------------- + + X. IANA Considerations + + This document defines a new DHCP option, entitled "FooBar" (see + Section y), and assigns a value of TBD1 from the DHCP Option space + <https://www.iana.org/assignments/bootp-dhcp-parameters> + [RFC2132] [RFC2939]: + Data + Tag Name Length Meaning + ---- ---- ------ ------- + TBD1 FooBar N FooBar server + + The FooBar option also defines an 8-bit FooType field, for which + IANA is to create and maintain a new registry entitled + "FooType values" used by the FooBar option. Initial values for the + DHCP FooBar FooType registry are given below; future assignments + are to be made through Expert Review [BCP26]. Assignments consist + of a DHCP FooBar FooType name and its associated value. + + Value DHCP FooBar FooType Name Definition + ---- ------------------------ ---------- + 0 Reserved + 1 Frobnitz RFCXXXX, Section y.1 + 2 NitzFrob RFCXXXX, Section y.2 + 3-254 Unassigned + 255 Reserved + --------------------------------------------------------------- + + For examples of documents that establish registries, consult + [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. + + + + + + +Cotton, et al. Best Current Practice [Page 10] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +2.3. Specifying Change Control for a Registry + + Registry definitions and registrations within registries often need + to be changed after they are created. The process of making such + changes is complicated when it is unclear who is authorized to make + the changes. For registries created by RFCs in the IETF stream, + change control for the registry lies by default with the IETF, via + the IESG. The same is true for value registrations made in IETF- + stream RFCs. + + Because registries can be created and registrations can be made + outside the IETF stream, it can sometimes be desirable to have change + control outside the IETF and IESG, and clear specification of change + control policies is always helpful. + + It is advised, therefore, that all registries that are created + clearly specify a change control policy and a change controller. It + is also advised that registries that allow registrations from outside + the IETF stream include, for each value, the designation of a change + controller for that value. If the definition or reference for a + 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 + make the change. For example, the Media Types registry [RFC6838] + includes a "Change Controller" in its registration template. See + also Section 9.5. + +2.4. Revising Existing Registries + + Updating the registration process or making changes to the format of + an already existing (previously created) registry (whether created + explicitly or implicitly) follows a process similar to that used when + creating a new registry. That is, a document is produced that makes + reference to the existing namespace and then provides detailed + guidance for handling assignments in the registry or detailed + instructions about the changes required. + + 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 + entries. Other changes may require similar clarity. + + Such documents are normally processed with the same document status + 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. + + + + + +Cotton, et al. Best Current Practice [Page 11] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Example documents that updated the guidelines for assignments in + pre-existing registries include: [RFC6895], [RFC3228], and [RFC3575]. + +3. Registering New Values in an Existing Registry + +3.1. Documentation Requirements for Registrations + + Often, documents request an assignment in an existing registry (one + created by a previously published document). + + Such documents should clearly identify the registry into which each + value is to be registered. Use the exact registry name as listed on + the IANA web page, and cite the RFC where the registry is defined. + When referring to an existing registry, providing a URL to precisely + identify the registry is helpful (see Section 2.2). + + There is no need to mention what the assignment policy is when making + new assignments in existing registries, as that should be clear from + the references. However, if multiple assignment policies might + apply, as in registries with different ranges that have different + policies, it is important to make it clear which range is being + requested, so that IANA will know which policy applies and can assign + 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 + document is approved; drafts should not specify final values. + Instead, placeholders such as "TBD1" and "TBD2" should be used + consistently throughout the document, giving each item to be + registered a different placeholder. The IANA Considerations should + ask the RFC Editor to replace the placeholder names with the IANA- + assigned values. When drafts need to specify numeric values for + testing or early implementations, they will either request early + allocation (see Section 3.4) or use values that have already been set + aside for testing or experimentation (if the registry in question + allows that without explicit assignment). 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 + + + + + +Cotton, et al. Best Current Practice [Page 12] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + accommodate such requests when possible, but the proposed number + might have been assigned to some other use by the time the draft is + approved. + + Normally, text-string values to be used are specified in the + document, as collisions are less likely with text strings. IANA will + consult with the authors if there is, in fact, a collision, and a + different value has to be used. When drafts need to specify string + values for testing or early implementations, they sometimes use the + expected final value. But it is often useful to use a draft value + instead, possibly including the draft version number. This allows + the early implementations to be distinguished from those implementing + the final version. A document that intends to use "foobar" in the + final version might use "foobar-testing-draft-05" for the -05 version + of the draft, for example. + + For some registries, there is a long-standing policy prohibiting + assignment of names or codes on a vanity or organization-name basis. + For example, codes might always be assigned sequentially unless there + is a strong reason for making an exception. Nothing in this document + is intended to change those policies or prevent their future + application. + + As an example, the following text could be used to request assignment + of a DHCPv6 option number: + + IANA is asked to assign an option code value of TBD1 to the DNS + Recursive Name Server option and an option code value of TBD2 to + the Domain Search List option from the DHCP option code space + defined in Section 24.3 of RFC 3315. + + The IANA Considerations section should summarize all of the IANA + actions, with pointers to the relevant sections elsewhere in the + document as appropriate. Including section numbers is especially + useful when the reference document is large; the section numbers will + make it easier for those searching the reference document to find the + relevant information. + + When multiple values are requested, it is generally helpful to + 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 + on the IANA web site. For example: + + Value Description Reference + -------- ------------------- --------- + TBD1 Foobar this RFC, Section 3.2 + TBD2 Gumbo this RFC, Section 3.3 + TBD3 Banana this RFC, Section 3.4 + + + +Cotton, et al. Best Current Practice [Page 13] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Note: In cases where authors feel that including the full table of + changes is too verbose or repetitive, authors should still include + the table in the draft, but may include a note asking that the table + be removed prior to publication of the final RFC. + +3.2. Updating Existing Registrations + + Even after a number has been assigned, some types of registrations + contain additional information that may need to be updated over time. + + For example, MIME media types, character sets, and language tags + typically include more information than just the registered value + itself, and may need updates to items such as point-of-contact + information, security issues, pointers to updates, and literature + references. + + In such cases, the document defining the namespace must clearly state + who is responsible for maintaining and updating a registration. + Depending on the registry, it may be appropriate to specify one or + more of: + + o Letting registrants and/or nominated change controllers update + their own registrations, subject to the same constraints and + review as with new registrations. + + o Allowing attachment of comments to the registration. This can be + useful in cases where others have significant objections to a + registration, but the author does not agree to change the + registration. + + o Designating the IESG, a designated expert, or another entity as + having the right to change the registrant associated with a + registration and any requirements or conditions on doing so. This + is mainly to get around the problem when a registrant cannot be + reached in order to make necessary updates. + +3.3. Overriding Registration Procedures + + Experience has shown that the documented IANA considerations for + individual protocols do not always adequately cover the reality of + registry operation or are not sufficiently clear. In addition, + documented IANA considerations are sometimes found to be too + stringent to allow even working group documents (for which there is + strong consensus) to perform a registration in advance of actual RFC + publication. + + + + + + +Cotton, et al. Best Current Practice [Page 14] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + In order to allow assignments in such cases, the IESG is granted + authority to override registration procedures and approve assignments + on a case-by-case basis. + + The intention here is not to overrule properly documented procedures + or to obviate the need for protocols to properly document their IANA + considerations. Rather, it is to permit assignments in specific + cases where it is obvious that the assignment should just be made, + but updating the IANA process beforehand is too onerous. + + When the IESG is required to take action as described above, it is a + strong indicator that the applicable registration procedures should + be updated, possibly in parallel with the work that instigated it. + + IANA always has the discretion to ask the IESG for advice or + intervention when they feel it is needed, such as in cases where + policies or procedures are unclear to them, where they encounter + issues or questions they are unable to resolve, or where registration + requests or patterns of requests appear to be unusual or abusive. + +3.4. Early Allocations + + IANA normally takes its actions when a document is approved for + publication. There are times, though, when early allocation of a + value is important for the development of a technology, for example, + when early implementations are created while the document is still + under development. + + IANA has a mechanism for handling such early allocations in some + cases. See [RFC7120] for details. It is usually not necessary to + explicitly mark a registry as allowing early allocation, because the + general rules will apply. + +4. Choosing a Registration Policy and Well-Known Policies + + A registration policy is the policy that controls how new assignments + in a registry are accepted. There are several issues to consider + when defining the registration policy. + + If the registry's namespace is limited, assignments will need to be + made carefully to prevent exhaustion. + + + + + + + + + + +Cotton, et al. Best Current Practice [Page 15] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Even when the space is essentially unlimited, it is still often + desirable to have at least a minimal review prior to assignment in + order to: + + o prevent the hoarding of or unnecessary wasting of values. For + example, if the space consists of text strings, it may be + desirable to prevent entities from obtaining large sets of strings + that correspond to desirable names (existing company names, for + example). + + o provide a sanity check that the request actually makes sense and + is necessary. Experience has shown that some level of minimal + review from a subject matter expert is useful to prevent + assignments in cases where the request is malformed or not + actually needed (for example, an existing assignment for an + essentially equivalent service already exists). + + Perhaps most importantly, unreviewed extensions can impact + interoperability and security. See [RFC6709]. + + When the namespace is essentially unlimited and there are no + potential interoperability or security issues, assigned numbers can + usually be given out to anyone without any subjective review. In + such cases, IANA can make assignments directly, provided that IANA is + given detailed instructions on what types of requests it should + grant, and it is able to do so without exercising subjective + judgment. + + When this is not the case, some level of review is required. + However, it's important to balance adequate review and ease of + registration. In many cases, those making registrations will not be + IETF participants; requests often come from other standards + organizations, from organizations not directly involved in standards, + from ad-hoc community work (from an open-source project, for + example), and so on. Registration must not be unnecessarily + difficult, unnecessarily costly (in terms of time and other + resources), nor unnecessarily subject to denial. + + While it is sometimes necessary to restrict what gets registered + (e.g., for limited resources such as bits in a byte, or for items for + which unsupported values can be damaging to protocol operation), in + many cases having what's in use represented in the registry is more + important. Overly strict review criteria and excessive cost (in time + and effort) discourage people from even attempting to make a + registration. If a registry fails to reflect the protocol elements + actually in use, it can adversely affect deployment of protocols on + the Internet, and the registry itself is devalued. + + + + +Cotton, et al. Best Current Practice [Page 16] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Therefore, it is important to think specifically about the + registration policy, and not just pick one arbitrarily nor copy text + from another document. Working groups and other document developers + should use care in selecting appropriate registration policies when + their documents create registries. They should select the least + strict policy that suits a registry's needs, and look for specific + justification for policies that require significant community + involvement (those stricter than Expert Review or Specification + Required, in terms of the well-known policies). The needs here will + vary from registry to registry, and, indeed, over time, and this BCP + will not be the last word on the subject. + + The following policies are defined for common usage. These cover a + range of typical policies that have been used to describe the + procedures for assigning new values in a namespace. It is not + strictly required that documents use these terms; the actual + requirement is that the instructions to IANA be clear and + unambiguous. However, use of these terms is strongly recommended + because their meanings are widely understood. Newly minted policies, + including ones that combine the elements of procedures associated + with these terms in novel ways, may be used if none of these policies + are suitable; it will help the review process if an explanation is + included as to why that is the case. The terms are fully explained + in the following subsections. + + 1. Private Use + 2. Experimental Use + 3. Hierarchical Allocation + 4. First Come First Served + 5. Expert Review + 6. Specification Required + 7. RFC Required + 8. IETF Review + 9. Standards Action + 10. IESG Approval + + It should be noted that it often makes sense to partition a namespace + into multiple categories, with assignments within each category + handled differently. Many protocols now partition namespaces into + two or more parts, with one range reserved for Private or + Experimental Use while other ranges are reserved for globally unique + assignments assigned following some review process. Dividing a + namespace into ranges makes it possible to have different policies in + place for different ranges and different use cases. + + Similarly, it will often be useful to specify multiple policies in + parallel, with each policy being used under different circumstances. + For more discussion of that topic, see Section 4.12. + + + +Cotton, et al. Best Current Practice [Page 17] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Examples of RFCs that specify multiple policies in parallel: + + LDAP [RFC4520] + TLS ClientCertificateType Identifiers [RFC5246] (as detailed in + the subsections below) + MPLS Pseudowire Types Registry [RFC4446] + +4.1. Private Use + + Private Use is 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 using the same value in different (and + incompatible) ways. IANA does not record assignments from registries + or ranges with this policy (and therefore there is no need for IANA + to review them) and assignments are not generally useful for broad + interoperability. It is the responsibility of the sites making use + of the Private Use range to ensure that no conflicts occur (within + the intended scope of use). + + Examples: + + Site-specific options in DHCP [RFC2939] + Fibre Channel Port Type Registry [RFC4044] + TLS ClientCertificateType Identifiers 224-255 [RFC5246] + +4.2. Experimental Use + + Experimental Use is similar to Private Use, but with the purpose + being to facilitate experimentation. See [RFC3692] for details. + IANA does not record assignments from registries or ranges with this + policy (and therefore there is no need for IANA to review them) and + assignments are not generally useful for broad interoperability. + Unless the registry explicitly allows it, it is not appropriate for + documents to select explicit values from registries or ranges with + this policy. Specific experiments will select a value to use during + the experiment. + + When code points are set aside for Experimental Use, it's important + to make clear any expected restrictions on experimental scope. For + example, say whether it's acceptable to run experiments using those + code points over the open Internet or whether such experiments should + be confined to more closed environments. See [RFC6994] for an + example of such considerations. + + Example: + + Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP + Headers [RFC4727] + + + +Cotton, et al. Best Current Practice [Page 18] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +4.3. Hierarchical Allocation + + With Hierarchical Allocation, delegated administrators are given + control over part of the namespace and can assign values in that part + of the namespace. IANA makes allocations in the higher levels of the + namespace according to one of the other policies. + + Examples: + + o DNS names - IANA manages the top-level domains (TLDs), and, as + [RFC1591] says: + + Under each TLD may be created a hierarchy of names. Generally, + under the generic TLDs the structure is very flat. That is, + many organizations are registered directly under the TLD, and + any further structure is up to the individual organizations. + + o Object Identifiers - defined by ITU-T recommendation X.208. + According to <http://www.alvestrand.no/objectid/>, some registries + include + + * IANA, which hands out OIDs under the "Private Enterprises" + branch, + * ANSI, which hands out OIDs under the "US Organizations" branch, + and + * BSI, which hands out OIDs under the "UK Organizations" branch. + + o URN namespaces - IANA registers URN Namespace IDs (NIDs + [RFC8141]), and the organization registering an NID is responsible + for allocations of URNs within that namespace. + +4.4. First Come First Served + + For the First Come First Served policy, assignments are made to + 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 + and doesn't duplicate an existing assignment. However, requests must + include a minimal amount of clerical information, such as a point of + contact (including an email address, and sometimes a postal address) + and a brief description of how the value will be used. Additional + information specific to the type of value requested may also need to + be provided, as defined by the namespace. For numbers, IANA + generally assigns the next in-sequence unallocated value, but other + values may be requested and assigned if an extenuating circumstance + exists. With names, specific text strings can usually be requested. + + + + + + +Cotton, et al. Best Current Practice [Page 19] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + 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. + + It is important that changes to the registration of a First Come + First Served code point retain compatibility with the current usage + of that code point, so changes need to be made with care. The change + controller should not, in most cases, be requesting incompatible + changes nor repurposing a registered code point. See also Sections + 9.4 and 9.5. + + A working group or any other entity that is developing a protocol + based on a First Come First Served code point has to be extremely + careful that the protocol retains wire compatibility with current use + of the code point. Once that is no longer true, the new work needs + to change to a different code point (and register that use at the + appropriate time). + + It is also important to understand that First Come First Served + really has no filtering. Essentially, any well-formed request is + accepted. + + Examples: + + SASL mechanism names [RFC4422] + LDAP Protocol Mechanisms and LDAP Syntax [RFC4520] + +4.5. Expert Review + + For the Expert Review policy, review and approval by a designated + expert (see Section 5) is required. While this does not necessarily + require formal documentation, information needs to be provided with + the request for the designated expert to evaluate. The registry's + definition needs to make clear to registrants what information is + necessary. The actual process for requesting registrations is + administered by IANA (see Section 1.2 for details). + + (This policy was also called "Designated Expert" in earlier editions + of this document. The current term is "Expert Review".) + + The required documentation and review criteria, giving clear guidance + to the designated expert, should be provided when defining the + registry. It is particularly important to lay out what should be + considered when performing an evaluation and reasons for rejecting a + request. It is also a good idea to include, when possible, a sense + + + +Cotton, et al. Best Current Practice [Page 20] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + of whether many registrations are expected over time, or if the + registry is expected to be updated infrequently or in exceptional + circumstances only. + + Thorough understanding of Section 5 is important when deciding on an + Expert Review policy and designing the guidance to the designated + expert. + + Good examples of guidance to designated experts: + + Extensible Authentication Protocol (EAP) [RFC3748], Sections 6 and + 7.2 + North-Bound Distribution of Link-State and TE Information Using + BGP [RFC7752], Section 5.1 + + 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. + + Examples: + + EAP Method Types [RFC3748] + HTTP Digest AKA algorithm versions [RFC4169] + URI schemes [RFC7595] + GEOPRIV Location Types [RFC4589] + +4.6. Specification Required + + For the Specification Required policy, review and approval by a + designated expert (see Section 5) is required, and the values and + their meanings must be documented in a permanent and readily + available public specification, in sufficient detail so that + interoperability between independent implementations is possible. + This policy is the same as Expert Review, with the additional + requirement of a formal public specification. In addition to the + normal review of such a request, the designated expert will review + the public specification and evaluate whether it is sufficiently + stable and permanent, and sufficiently clear and technically sound to + allow interoperable implementations. + + The intention behind "permanent and readily available" is that a + document can reasonably be expected to be findable and retrievable + long after IANA assignment of the requested value. Publication of an + RFC is an ideal means of achieving this requirement, but + Specification Required is intended to also cover the case of a + + + +Cotton, et al. Best Current Practice [Page 21] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + document published outside of the RFC path, including informal + documentation. + + For RFC publication, formal review by the designated expert is still + requested, but the normal RFC review process is expected to provide + the necessary review for interoperability. The designated expert's + 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 + expert should be provided when defining the registry, and thorough + understanding of Section 5 is important. + + When specifying this policy, just use the term "Specification + Required". Some specifications have chosen to refer to it as "Expert + Review with Specification Required", and that only causes confusion. + + Examples: + + Diffserv-aware TE Bandwidth Constraints Model Identifiers + [RFC4124] + TLS ClientCertificateType Identifiers 64-223 [RFC5246] + ROHC Profile Identifiers [RFC5795] + +4.7. RFC Required + + With the RFC Required policy, the registration request, along with + associated documentation, must be published in an RFC. The RFC need + not be in the IETF stream, but may be in any RFC stream (currently an + RFC may be in the IETF, IRTF, IAB, or Independent Submission streams + [RFC5742]). + + Unless otherwise specified, any type of RFC is sufficient (currently + Standards Track, BCP, Informational, Experimental, or Historic). + + Examples: + + DNSSEC DNS Security Algorithm Numbers [RFC6014] + Media Control Channel Framework registries [RFC6230] + DANE TLSA Certificate Usages [RFC6698] + +4.8. IETF Review + + (Formerly called "IETF Consensus" in the first edition of this + document.) With the IETF Review policy, new values are assigned only + through RFCs in the IETF Stream -- those that have been shepherded + through the IESG as AD-Sponsored or IETF working group documents + + + +Cotton, et al. Best Current Practice [Page 22] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + [RFC2026] [RFC5378], have gone through IETF Last Call, and have been + approved by the IESG as having IETF consensus. + + The intent is that the document and proposed assignment will be + reviewed by the IETF community (including appropriate IETF working + groups, directorates, and other experts) and by the IESG, to ensure + that the proposed assignment will not negatively affect + interoperability or otherwise extend IETF protocols in an + inappropriate or damaging manner. + + Unless otherwise specified, any type of RFC is sufficient (currently + Standards Track, BCP, Informational, Experimental, or Historic). + + Examples: + + IPSECKEY Algorithm Types [RFC4025] + TLS Extension Types [RFC5246] + +4.9. Standards Action + + For the Standards Action policy, values are assigned only through + Standards Track or Best Current Practice RFCs in the IETF Stream. + + Examples: + + BGP message types [RFC4271] + Mobile Node Identifier option types [RFC4283] + TLS ClientCertificateType Identifiers 0-63 [RFC5246] + DCCP Packet Types [RFC4340] + +4.10. IESG Approval + + New assignments may be approved by the IESG. Although there is no + requirement that the request be documented in an RFC, the IESG has + the discretion to request documents or other supporting materials on + a case-by-case basis. + + IESG Approval is not intended to be used often or as a "common case"; + indeed, it has seldom been used in practice. Rather, it is intended + to be available in conjunction with other policies as a fall-back + mechanism in the case where one of the other allowable approval + mechanisms cannot be employed in a timely fashion or for some other + compelling reason. IESG Approval is not intended to circumvent the + public review processes implied by other policies that could have + been employed for a particular assignment. IESG Approval would be + appropriate, however, in cases where expediency is desired and there + is strong consensus (such as from a working group) for making the + assignment. + + + +Cotton, et al. Best Current Practice [Page 23] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Before approving a request, the IESG might consider consulting the + community, via a "call for comments" that provides as much + information as is reasonably possible about the request. + + Examples: + + IPv4 Multicast address assignments [RFC5771] + IPv4 IGMP Type and Code values [RFC3228] + Mobile IPv6 Mobility Header Type and Option values [RFC6275] + +4.11. Using the Well-Known Registration Policies + + Because the well-known policies benefit from both community + experience and wide understanding, their use is encouraged, and the + creation of new policies needs to be accompanied by reasonable + justification. + + It is also acceptable to cite one or more well-known policies and + include additional guidelines for what kind of considerations should + be taken into account by the review process. + + For example, for media-type registrations [RFC6838], a number of + different situations are covered that involve the use of IETF Review + and Specification Required, while also including specific additional + criteria the designated expert should follow. This is not meant to + represent a registration procedure, but to show an example of what + can be done when special circumstances need to be covered. + + The well-known policies from "First Come First Served" to "Standards + Action" specify a range of policies in increasing order of strictness + (using the numbering from the full list in Section 4): + + 4. First Come First Served + No review, minimal documentation. + + 5 and 6 (of equal strictness). + + 5. Expert Review + Expert review with sufficient documentation for review. + + 6. Specification Required + Significant stable public documentation sufficient for + interoperability. + + 7. RFC Required + Any RFC publication, IETF or a non-IETF Stream. + + 8. IETF Review + + + +Cotton, et al. Best Current Practice [Page 24] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + RFC publication, IETF Stream only, but need not be Standards + Track. + + 9. Standards Action + RFC publication, IETF Stream, Standards Track or BCP only. + + Examples of situations that might merit IETF Review or Standards + Action include the following: + + o When a resource is limited, such as bits in a byte (or in two + bytes, or four), or numbers in a limited range. In these cases, + allowing registrations that haven't been carefully reviewed and + agreed to by community consensus could too quickly deplete the + allowable values. + + o When thorough community review is necessary to avoid extending or + modifying the protocol in ways that could be damaging. One + example is in defining new command codes, as opposed to options + that use existing command codes: the former might require a strict + policy, where a more relaxed policy could be adequate for the + latter. Another example is in defining protocol elements that + change the semantics of existing operations. + + o When there are security implications with respect to the resource, + and thorough review is needed to ensure that the new usage is + sound. Examples of this include lists of acceptable hashing and + cryptographic algorithms, and assignment of transport ports in the + system range. + + When reviewing a document that asks IANA to create a new registry or + change a registration policy to any policy more stringent than Expert + Review or Specification Required, the IESG should ask for + justification to ensure that more relaxed policies have been + considered and that the more strict policy is the right one. + + Accordingly, document developers need to anticipate this and document + their considerations for selecting the specified policy (ideally, in + the document itself; failing that, in the shepherd writeup). + Likewise, the document shepherd should ensure that the selected + policies have been justified before sending the document to the IESG. + + When specifications are revised, registration policies should be + reviewed in light of experience since the policies were set. + +4.12. Using Multiple Policies in Combination + + In some situations, it is necessary to define multiple registration + policies. For example, registrations through the normal IETF process + + + +Cotton, et al. Best Current Practice [Page 25] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + might use one policy, while registrations from outside the process + would have a different policy applied. + + Thus, a particular registry might want to use a policy such as "RFC + Required" or "IETF Review" sometimes, with a designated expert + checking a "Specification Required" policy at other times. + + The alternative to using a combination requires either that all + requests come through RFCs or that requests in RFCs go through review + by the designated expert, even though they already have IETF review + and consensus. + + This can be documented in the IANA Considerations section when the + registry is created, for example: + + IANA is asked to create the registry "Fruit Access Flags" under + the "Fruit Parameters" group. New registrations will be permitted + through either the IETF Review policy or the Specification + Required policy [BCP26]. The latter should be used only for + registrations requested by SDOs outside the IETF. Registrations + requested in IETF documents will be subject to IETF review. + + Such combinations will commonly use one of {Standards Action, IETF + Review, RFC Required} in combination with one of {Specification + Required, Expert Review}. Guidance should be provided about when + each policy is appropriate, as in the example above. + +4.13. Provisional Registrations + + Some existing registries have policies that allow provisional + registration: see URI Schemes [RFC7595] and Email Header Fields + [RFC3864]. Registrations that are designated as provisional are + usually defined as being more readily created, changed, reassigned, + moved to another status, or removed entirely. URI Schemes, for + example, allow provisional registrations to be made with incomplete + information. + + Allowing provisional registration ensures that the primary goal of + maintaining a registry -- avoiding collisions between incompatible + semantics -- is achieved without the side effect of "endorsing" the + protocol mechanism the provisional value is used for. Provisional + registrations for codepoints that are ultimately standardized can be + promoted to permanent status. The criteria that are defined for + converting a provisional registration to permanent will likely be + more strict than those that allowed the provisional registration. + + If your registry does not have a practical limit on codepoints, + perhaps adding the option for provisional registrations might be + + + +Cotton, et al. Best Current Practice [Page 26] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + right for that registry as well. + +5. Designated Experts + +5.1. The Motivation for Designated Experts + + Discussion on a mailing list can provide valuable technical feedback, + but opinions often vary and discussions may continue for some time + without clear resolution. In addition, IANA cannot participate in + all of these mailing lists and cannot determine if or when such + discussions reach consensus. Therefore, IANA relies on a "designated + expert" for advice regarding the specific question of whether an + assignment should be made. The designated expert is an individual + who is responsible for carrying out an appropriate evaluation and + returning a recommendation to IANA. + + It should be noted that a key motivation for having designated + experts is for the IETF to provide IANA with a subject matter expert + to whom the evaluation process can be delegated. IANA forwards + requests for an assignment to the expert for evaluation, and the + expert (after performing the evaluation) informs IANA as to whether + or not to make the assignment or registration. In most cases, the + registrants do not work directly with the designated experts. The + list of designated experts for a registry is listed in the registry. + + It will often be useful to use a designated expert only some of the + time, as a supplement to other processes. For more discussion of + that topic, see Section 4.12. + +5.2. The Role of the Designated Expert + + The designated expert is responsible for coordinating the appropriate + review of an assignment request. The review may be wide or narrow, + depending on the situation and the judgment of the designated expert. + This may involve consultation with a set of technology experts, + discussion on a public mailing list, consultation with a working + group (or its mailing list if the working group has disbanded), etc. + Ideally, the designated expert follows specific review criteria as + documented with the protocol that creates or uses the namespace. See + the IANA Considerations sections of [RFC3748] and [RFC3575] for + specific examples. + + Designated experts are expected to be able to defend their decisions + to the IETF community, and the evaluation process is not intended to + be secretive or bestow unquestioned power on the expert. Experts are + expected to apply applicable documented review or vetting procedures, + or in the absence of documented criteria, follow generally accepted + norms such as those in Section 5.3. Designated experts are generally + + + +Cotton, et al. Best Current Practice [Page 27] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + not expected to be "gatekeepers", setting out to make registrations + difficult to obtain, unless the guidance in the defining document + specifies that they should act as such. Absent stronger guidance, + the experts should be evaluating registration requests for + completeness, interoperability, and conflicts with existing protocols + and options. + + It has proven useful to have multiple designated experts for some + registries. Sometimes those experts work together in evaluating a + request, while in other cases additional experts serve as backups, + acting only when the primary expert is unavailable. In registries + with a pool of experts, the pool often has a single chair responsible + for defining how requests are to be assigned to and reviewed by + experts. In other cases, IANA might assign requests to individual + members in sequential or approximate random order. The document + defining the registry can, if it's appropriate for the situation, + specify how the group should work -- for example, it might be + appropriate to specify rough consensus on a mailing list, within a + related working group or among a pool of designated experts. + + In cases of disagreement among multiple 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. + + If a designated expert has a conflict of interest for a particular + review (is, for example, an author or significant proponent of a + specification related to the registration under review), that expert + should recuse himself. In the event that all the designated experts + are conflicted, they should ask that a temporary expert be designated + for the conflicted review. The responsible AD may then appoint + someone or the AD may handle the review. + + This document defines the designated expert mechanism with respect to + documents in the IETF stream only. If other streams want to use + registration policies that require designated experts, it is up to + those streams (or those documents) to specify how those 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 + + + +Cotton, et al. Best Current Practice [Page 28] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + 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 + + In the years since [RFC2434] was published and put to use, experience + has led to the following observations: + + o A designated expert must respond in a timely fashion, normally + within a week for simple requests to a few weeks for more complex + ones. Unreasonable delays can cause significant problems for + those needing assignments, such as when products need code points + to ship. This is not to say that all reviews can be completed + under a firm deadline, but they must be started, and the requester + and IANA should have some transparency into the process if an + answer cannot be given quickly. + + o If a designated expert does not respond to IANA's requests within + a reasonable period of time, either with a response or with a + reasonable explanation for the delay (some requests may be + particularly complex), and if this is a recurring event, IANA must + raise the issue with the IESG. Because of the problems caused by + delayed evaluations and assignments, the IESG should take + appropriate actions to ensure that the expert understands and + accepts his or her responsibilities, or appoint a new expert. + + o The designated expert is not required to personally bear the + burden of evaluating and deciding all requests, but acts as a + shepherd for the request, enlisting the help of others as + appropriate. In the case that a request is denied, and rejecting + the request is likely to be controversial, the expert should have + the support of other subject matter experts. That is, the expert + must be able to defend a decision to the community as a whole. + + When a designated expert is used, the documentation should give clear + guidance to the designated expert, laying out criteria for performing + an evaluation and reasons for rejecting a request. In the case where + there are no specific documented criteria, the presumption should be + that a code point should be granted unless there is a compelling + reason to the contrary (and see also Section 5.4). Reasons that have + been used to deny requests have included these: + + + + +Cotton, et al. Best Current Practice [Page 29] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + o Scarcity of code points, where the finite remaining code points + should be prudently managed, or where a request for a large number + of code points is made and a single code point is the norm. + + o Documentation is not of sufficient clarity to evaluate or ensure + interoperability. + + o The code point is needed for a protocol extension, but the + extension is not consistent with the documented (or generally + understood) architecture of the base protocol being extended and + would be harmful to the protocol if widely deployed. It is not + the intent that "inconsistencies" refer to minor differences "of a + personal preference nature". Instead, they refer to significant + differences such as inconsistencies with the underlying security + model, implying a change to the semantics of an existing message + type or operation, requiring unwarranted changes in deployed + systems (compared with alternate ways of achieving a similar + result), etc. + + o The extension would cause problems with existing deployed systems. + + o The extension would conflict with one under active development by + the IETF, and having both would harm rather than foster + interoperability. + + Documents must not name the designated expert(s) in the document + itself; instead, any suggested names should be relayed to the + appropriate Area Director at the time the document is sent to the + IESG for approval. This is usually done in the document shepherd + writeup. + + If the request should also be reviewed on a specific public mailing + list, its address should be specified. + + + + + + + + + + + + + + + + + + +Cotton, et al. Best Current Practice [Page 30] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +5.4. Expert Reviews and the Document Lifecycle + + Review by the designated expert is necessarily done at a particular + point in time and represents review of a particular version of the + document. While reviews are generally done around the time of IETF + Last Call, deciding when the review should take place is a question + of good judgment. And while rereviews might be done when it's + acknowledged that the documentation of the registered item has + changed substantially, making sure that rereview happens requires + attention and care. + + It is possible, through carelessness, accident, inattentiveness, or + even willful disregard, that changes might be made after the + designated expert's review and approval that would, if the document + were rereviewed, cause the expert not to approve the registration. + It is up to the IESG, with the token held by the responsible Area + Director, to be alert to such situations and to recognize that such + changes need to be checked. + + For registrations made from documents on the Standards Track, there + is often expert review required (by the registration policy) in + addition to IETF consensus (for approval as a Standards Track RFC). + In such cases, the review by the designated expert needs to be + timely, submitted before the IESG evaluates the document. The IESG + should generally not hold the document up waiting for a late review. + It is also not intended for the expert review to override IETF + consensus: the IESG should consider the review in its own evaluation, + as it would do for other Last Call reviews. + +6. Well-Known Registration Status Terminology + + The following labels describe the status of an assignment or range of + assignments: + + Private Use: Private use only (not assigned), as described in + Section 4.1. + + Experimental: Available for general experimental use as described + in [RFC3692]. IANA does not record specific assignments for + any particular use. + + Unassigned: Not currently assigned, and available for assignment + via documented procedures. While it's generally clear that + any values that are not registered are unassigned and + available for assignment, it is sometimes useful to + explicitly specify that situation. Note that this is + distinctly different from "Reserved". + + + + +Cotton, et al. Best Current Practice [Page 31] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Reserved: Not assigned and not available for assignment. + Reserved values are held for special uses, such as to extend + the 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". + + Reserved values can be released for assignment by the change + controller for the registry (this is often the IESG, for + registries created by RFCs in the IETF stream). + + Known Unregistered Use: It's known that the assignment or range + is in use without having been defined in accordance with + reasonable practice. Documentation for use of the + assignment or range may be unavailable, inadequate, or + conflicting. This is a warning against use, as well as an + alert to network operators who might see these values in use + on their networks. + +7. Documentation References in IANA Registries + + Usually, registries and registry entries include references to + documentation (RFCs or other documents). The purpose of these + references is to provide pointers for implementors to find details + necessary for implementation, NOT to simply note what document + created the registry or entry. Therefore: + + o If a document registers an item that is defined and explained + elsewhere, the registered reference should be to the document + containing the definition, not to the document that is merely + performing the registration. + + o If the registered item is defined and explained in the current + document, it is important to include sufficient information to + enable implementors to understand the item and to create a proper + implementation. + + o If the registered item is explained primarily in a specific + section of the reference document, it is useful to include a + section reference. For example, "[RFC4637], Section 3.2", rather + than just "[RFC4637]". + + o For documentation of a new registry, the reference should provide + information about the registry itself, not just a pointer to the + creation of it. Useful information includes the purpose of the + registry, a rationale for its creation, documentation of the + process and policy for new registrations, guidelines for new + + + +Cotton, et al. Best Current Practice [Page 32] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + registrants or designated experts, and other such related + information. But note that, while it's important to include this + information in the document, it needn't all be in the IANA + Considerations section. See Section 1.1. + +8. What to Do in "bis" Documents + + On occasion, an RFC is issued that obsoletes a previous edition of + the same document. We sometimes call these "bis" documents, such as + when RFC 4637 is to be obsoleted by draft-ietf-foo-rfc4637bis. When + the original document created registries and/or registered entries, + there is a question of how to handle the IANA Considerations section + in the "bis" document. + + If the registrations specify the original document as a reference, + those registrations should be updated to point to the current (not + obsolete) documentation for those items. Usually, that will mean + changing the reference to be the "bis" document. + + There will, though, be times when a document updates another, but + does not make it obsolete, and the definitive reference is changed + for some items but not for others. Be sure that the references + always point to the correct, current documentation for each item. + + For example, suppose RFC 4637 registered the "BANANA" flag in the + "Fruit Access Flags" registry, and the documentation for that flag is + in Section 3.2. + + The current registry might look, in part, like this: + + Name Description Reference + -------- ------------------- --------- + BANANA Flag for bananas [RFC4637], Section 3.2 + + If draft-ietf-foo-rfc4637bis obsoletes RFC 4637 and, because of some + rearrangement, now documents the flag in Section 4.1.2, the IANA + Considerations of the bis document might contain text such as this: + + IANA is asked to change the registration information for the + BANANA flag in the "Fruit Access Flags" registry to the + following: + + Name Description Reference + -------- ------------------- --------- + BANANA Flag for bananas [[this RFC]], Section 4.2.1 + + + + + + +Cotton, et al. Best Current Practice [Page 33] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + In many cases, if there are a number of registered references to the + original RFC and the document organization has not changed the + registered section numbering much, it may simply be reasonable to do + this: + + Because this document obsoletes RFC 4637, IANA is asked to change + all registration information that references [RFC4637] to instead + reference [[this RFC]]. + + If information for registered items has been or is being moved to + other documents, then the registration information should be changed + to point to those other documents. In most cases, documentation + references should not be left pointing to the obsoleted document for + registries or registered items that are still in current use. For + registries or registered items that are no longer in current use, it + will usually make sense to leave the references pointing to the old + document -- the last current reference for the obsolete items. The + main point is to make sure that the reference pointers are as useful + and current as is reasonable, and authors should consider that as + they write the IANA Considerations for the new document. As always: + do the right thing, and there is flexibility to allow for that. + + It is extremely important to be clear in your instructions regarding + updating references, especially in cases where some references need + to be updated and others do not. + +9. Miscellaneous Issues + +9.1. When There Are No IANA Actions + + Before an Internet-Draft can be published as an RFC, IANA needs to + know what actions (if any) it needs to perform. Experience has shown + that it is not always immediately obvious whether a document has no + IANA actions, without reviewing the document in some detail. In + order to make it clear to IANA that it has no actions to perform (and + that the author has consciously made such a determination), such + documents should, after the authors confirm that this is the case, + include an IANA Considerations section that states: + + This document has no IANA actions. + + IANA prefers that these "empty" IANA Considerations sections be left + in the document for the record: it makes it clear later on that the + document explicitly said that no IANA actions were needed (and that + it wasn't just omitted). This is a change from the prior practice of + requesting that such sections be removed by the RFC Editor, and + authors are asked to accommodate this change. + + + + +Cotton, et al. Best Current Practice [Page 34] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +9.2. Namespaces Lacking Documented Guidance + + For all existing RFCs that either explicitly or implicitly rely on + IANA to make assignments without specifying a precise assignment + policy, IANA will work with the IESG to decide what policy is + appropriate. Changes to existing policies can always be initiated + through the normal IETF consensus process, or through the IESG when + appropriate. + + All future RFCs that either explicitly or implicitly rely on IANA to + register or otherwise administer namespace assignments must provide + guidelines for administration of the namespace. + +9.3. After-the-Fact Registrations + + Occasionally, the IETF becomes aware that an unassigned value from a + namespace is in use on the Internet or that an assigned value is + being used for a different purpose than it was registered for. The + IETF does not condone such misuse; procedures of the type described + in this document need to be applied to such cases, and it might not + always be possible to formally assign the desired value. In the + absence of specifications to the contrary, values may only be + reassigned for a different purpose with the consent of the original + assignee (when possible) and with due consideration of the impact of + such a reassignment. In cases of likely controversy, consultation + with the IESG is advised. + + This is part of the reason for the advice in Section 3.1 about using + placeholder values, such as "TBD1", during document development: + problems are often caused by the open use of unregistered values + after results from well-meant, early implementations, where the + implementations retained the use of developmental code points that + never proceeded to a final IANA assignment. + +9.4. Reclaiming Assigned Values + + Reclaiming previously assigned values for reuse is tricky, because + doing so can lead to interoperability problems with deployed systems + still using the assigned values. Moreover, it can be extremely + difficult to determine the extent of deployment of systems making use + of a particular value. However, in cases where the namespace is + running out of unassigned values and additional ones are needed, it + may be desirable to attempt to reclaim unused values. When + reclaiming unused values, the following (at a minimum) should be + considered: + + + + + + +Cotton, et al. Best Current Practice [Page 35] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + o Attempts should be made to contact the original party to which a + value is assigned, to determine if the value was ever used, and if + so, the extent of deployment. (In some cases, products were never + shipped or have long ceased being used. In other cases, it may be + known that a value was never actually used at all.) + + o Reassignments should not normally be made without the concurrence + of the original requester. Reclamation under such conditions + should only take place where there is strong evidence that a value + is not widely used, and the need to reclaim the value outweighs + the cost of a hostile reclamation. IESG Approval is needed in + this case. + + o It may be appropriate to write up the proposed action and solicit + comments from relevant user communities. In some cases, it may be + appropriate to write an RFC that goes through a formal IETF + process (including IETF Last Call) as was done when DHCP reclaimed + some of its "Private Use" options [RFC3942]. + + o It may be useful to differentiate between revocation, release, and + transfer. Revocation occurs when IANA removes an assignment, + release occurs when the assignee initiates that removal, and + transfer occurs when either revocation or release is coupled with + immediate reassignment. It may be useful to specify procedures + for each of these or to explicitly prohibit combinations that are + not desired. + +9.5. Contact Person vs Assignee or Owner + + Many registries include designation of a technical or administrative + contact associated with each entry. Often, this is recorded as + contact information for an individual. It is unclear, though, what + role the individual has with respect to the registration: is this + item registered on behalf of the individual, the company the + individual worked for, or perhaps another organization the individual + was acting for? + + This matters because some time later, when the individual has changed + jobs or roles, and perhaps can no longer be contacted, someone might + want to update the registration. IANA has no way to know what + company, organization, or individual should be allowed to take the + registration over. For registrations rooted in RFCs, the stream + owner (such as the IESG or the IAB) can make an overriding decision. + But in other cases, there is no recourse. + + Registries can include, in addition to a "Contact" field, an + "Assignee" or "Owner" field (also referred to as "Change Controller") + that can be used to address this situation, giving IANA clear + + + +Cotton, et al. Best Current Practice [Page 36] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + guidance as to the actual owner of the registration. This is + strongly advised, especially for registries that do not require RFCs + to manage their information (e.g., registries with policies such as + First Come First Served (Section 4.4), Expert Review (Section 4.5), + and Specification Required (Section 4.6)). Alternatively, + organizations can put an organizational role into the "Contact" field + in order to make their ownership clear. + +9.6. Closing or Obsoleting a Registry/Registrations + + Sometimes there is a request to "close" a registry to further + registrations. When a registry is closed, no further registrations + will be accepted. The information in the registry will still be + valid and registrations already in the registry can still be updated. + + A closed registry can also be marked as "obsolete", as an indication + that the information in the registry is no longer in current use. + + Specific entries in a registry can be marked as "obsolete" (no longer + in use) or "deprecated" (use is not recommended). + + Such changes to registries and registered values are subject to + normal change controls (see Section 2.3). Any closure, obsolescence, + or deprecation serves to annotate the registry involved; the + information in the registry remains there for informational and + historic purposes. + +10. Appeals + + Appeals of protocol parameter registration decisions can be made + using the normal IETF appeals process as described in [RFC2026], + Section 6.5. That is, an initial appeal should be directed to the + IESG, followed (if necessary) by an appeal to the IAB. + +11. Mailing Lists + + All IETF mailing lists associated with evaluating or discussing + assignment requests as described in this document are subject to + whatever rules of conduct and methods of list management are + currently defined by best current practices or by IESG decision. + +12. Security Considerations + + Information that creates or updates a registration needs to be + authenticated and authorized. IANA updates registries according to + instructions in published RFCs and from the IESG. It may also accept + clarifications from document authors, relevant working group chairs, + designated experts, and mail list participants. + + + +Cotton, et al. Best Current Practice [Page 37] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + Information concerning possible security vulnerabilities of a + protocol may change over time. Likewise, security vulnerabilities + related to how an assigned number is used may change as well. As new + vulnerabilities are discovered, information about such + vulnerabilities may need to be attached to existing registrations so + that users are not misled as to the true security issues surrounding + the use of a registered number. + + Security needs to be considered as part of the selection of a + registration policy. For some protocols, registration of certain + parameters will have security implications, and registration policies + for the relevant registries must ensure that requests get appropriate + review with those security implications in mind. + + An analysis of security issues is generally required for all + protocols that make use of parameters (data types, operation codes, + keywords, etc.) documented in IETF protocols or registered by IANA. + Such security considerations are usually included in the protocol + document [BCP72]. It is the responsibility of the IANA + considerations associated with a particular registry to specify + whether value-specific security considerations must be provided when + assigning new values and the process for reviewing such claims. + +13. IANA Considerations + + Sitewide, IANA has replaced references to RFC 5226 with references to + this document. + +14. Changes Relative to Earlier Editions of BCP 26 + +14.1. 2016: Changes in This Document Relative to RFC 5226 + + Significant additions: + + o Removed RFC 2119 key words, boilerplate, and reference, preferring + plain English -- this is not a protocol specification. + + o Added Section 1.1, Keep IANA Considerations for IANA + + o Added Section 1.2, For Updated Information + + o Added Section 2.1, Organization of Registries + + o Added best practice for selecting an appropriate policy into + Section 4. + + o Added Section 4.12, Using Multiple Policies in Combination + + + + +Cotton, et al. Best Current Practice [Page 38] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + o Added Section 2.3, Specifying Change Control for a Registry + + o Added Section 3.4, Early Allocations + + o Moved each well-known policy into a separate subsection of + Section 4. + + o Added Section 5.4, Expert Reviews and the Document Lifecycle + + o Added Section 7, Documentation References in IANA Registries + + o Added Section 8, What to Do in "bis" Documents + + o Added Section 9.5, Contact Person vs Assignee or Owner + + o Added Section 9.6, Closing or Obsoleting a Registry/Registrations + + Clarifications and such: + + o Some reorganization -- moved text around for clarity and easier + reading. + + o Made clarifications about identification of IANA registries and + use of URLs for them. + + o Clarified the distinction between "Unassigned" and "Reserved". + + o Made some clarifications in "Expert Review" about instructions to + the designated expert. + + o Made some clarifications in "Specification Required" about how to + declare this policy. + + o Assorted minor clarifications and editorial changes throughout. + +14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 + + Changes include: + + o Major reordering of text to expand descriptions and to better + group topics such as "updating registries" vs. "creating new + registries", in order to make it easier for authors to find the + text most applicable to their needs. + + o Numerous editorial changes to improve readability. + + + + + + +Cotton, et al. Best Current Practice [Page 39] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + o Changed the term "IETF Consensus" to "IETF Review" and added more + clarifications. History has shown that people see the words "IETF + Consensus" (without consulting the actual definition) and are + quick to make incorrect assumptions about what the term means in + the context of IANA Considerations. + + o Added "RFC Required" to list of defined policies. + + o Much more explicit directions and examples of "what to put in + RFCs". + + o "Specification Required" now implies use of a designated expert to + evaluate specs for sufficient clarity. + + o Added a section describing provisional registrations. + + o Significantly changed the wording in the "Designated Experts" + section. Main purpose is to make clear that Expert Reviewers are + accountable to the community, and to provide some guidance for + review criteria in the default case. + + o Changed wording to remove any special appeals path. The normal + RFC 2026 appeals path is used. + + o Added a section about reclaiming unused values. + + o Added a section on after-the-fact registrations. + + o Added a section indicating that mailing lists used to evaluate + possible assignments (such as by a designated expert) are subject + to normal IETF rules. + +15. References + +15.1. Normative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, + <http://www.rfc-editor.org/info/rfc2026>. + +15.2. Informative References + + [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, July + 2003, <http://www.rfc-editor.org/info/bcp72>. + + + + + + +Cotton, et al. Best Current Practice [Page 40] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + DOI 10.17487/RFC0791, September 1981, + <http://www.rfc-editor.org/info/rfc791>. + + [RFC1591] Postel, J., "Domain Name System Structure and Delegation", + RFC 1591, DOI 10.17487/RFC1591, March 1994, + <http://www.rfc-editor.org/info/rfc1591>. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", RFC 2434, + DOI 10.17487/RFC2434, October 1998, + <http://www.rfc-editor.org/info/rfc2434>. + + [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of + Understanding Concerning the Technical Work of the + Internet Assigned Numbers Authority", RFC 2860, + DOI 10.17487/RFC2860, June 2000, + <http://www.rfc-editor.org/info/rfc2860>. + + [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition + of New DHCP Options and Message Types", BCP 43, RFC 2939, + DOI 10.17487/RFC2939, September 2000, + <http://www.rfc-editor.org/info/rfc2939>. + + [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group + Management Protocol (IGMP)", BCP 57, RFC 3228, + DOI 10.17487/RFC3228, February 2002, + <http://www.rfc-editor.org/info/rfc3228>. + + [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote + Authentication Dial In User Service)", RFC 3575, + DOI 10.17487/RFC3575, July 2003, + <http://www.rfc-editor.org/info/rfc3575>. + + [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, + DOI 10.17487/RFC3692, January 2004, + <http://www.rfc-editor.org/info/rfc3692>. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, Ed., "Extensible Authentication Protocol + (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, + <http://www.rfc-editor.org/info/rfc3748>. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + DOI 10.17487/RFC3864, September 2004, + <http://www.rfc-editor.org/info/rfc3864>. + + + +Cotton, et al. Best Current Practice [Page 41] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration + Protocol version 4 (DHCPv4) Options", RFC 3942, + DOI 10.17487/RFC3942, November 2004, + <http://www.rfc-editor.org/info/rfc3942>. + + [RFC3968] Camarillo, G., "The Internet Assigned Number Authority + (IANA) Header Field Parameter Registry for the Session + Initiation Protocol (SIP)", BCP 98, RFC 3968, + DOI 10.17487/RFC3968, December 2004, + <http://www.rfc-editor.org/info/rfc3968>. + + [RFC4025] Richardson, M., "A Method for Storing IPsec Keying + Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March + 2005, <http://www.rfc-editor.org/info/rfc4025>. + + [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, + DOI 10.17487/RFC4044, May 2005, + <http://www.rfc-editor.org/info/rfc4044>. + + [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of + Diffserv-aware MPLS Traffic Engineering", RFC 4124, + DOI 10.17487/RFC4124, June 2005, + <http://www.rfc-editor.org/info/rfc4124>. + + [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext + Transfer Protocol (HTTP) Digest Authentication Using + Authentication and Key Agreement (AKA) Version-2", + RFC 4169, DOI 10.17487/RFC4169, November 2005, + <http://www.rfc-editor.org/info/rfc4169>. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + <http://www.rfc-editor.org/info/rfc4271>. + + [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. + Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 + (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005, + <http://www.rfc-editor.org/info/rfc4283>. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, + DOI 10.17487/RFC4340, March 2006, + <http://www.rfc-editor.org/info/rfc4340>. + + + + + + + +Cotton, et al. Best Current Practice [Page 42] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + DOI 10.17487/RFC4422, June 2006, + <http://www.rfc-editor.org/info/rfc4422>. + + [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge + Emulation (PWE3)", BCP 116, RFC 4446, + DOI 10.17487/RFC4446, April 2006, + <http://www.rfc-editor.org/info/rfc4446>. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, DOI 10.17487/RFC4520, + June 2006, <http://www.rfc-editor.org/info/rfc4520>. + + [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types + Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, + <http://www.rfc-editor.org/info/rfc4589>. + + [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, + ICMPv6, UDP, and TCP Headers", RFC 4727, + DOI 10.17487/RFC4727, November 2006, + <http://www.rfc-editor.org/info/rfc4727>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <http://www.rfc-editor.org/info/rfc5246>. + + [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights + Contributors Provide to the IETF Trust", BCP 78, RFC 5378, + DOI 10.17487/RFC5378, November 2008, + <http://www.rfc-editor.org/info/rfc5378>. + + [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for + Handling of Independent and IRTF Stream Submissions", + BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, + <http://www.rfc-editor.org/info/rfc5742>. + + [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for + IPv4 Multicast Address Assignments", BCP 51, RFC 5771, + DOI 10.17487/RFC5771, March 2010, + <http://www.rfc-editor.org/info/rfc5771>. + + [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust + Header Compression (ROHC) Framework", RFC 5795, + DOI 10.17487/RFC5795, March 2010, + <http://www.rfc-editor.org/info/rfc5795>. + + + +Cotton, et al. Best Current Practice [Page 43] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier + Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, + November 2010, <http://www.rfc-editor.org/info/rfc6014>. + + [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media + Control Channel Framework", RFC 6230, + DOI 10.17487/RFC6230, May 2011, + <http://www.rfc-editor.org/info/rfc6230>. + + [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July + 2011, <http://www.rfc-editor.org/info/rfc6275>. + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August + 2012, <http://www.rfc-editor.org/info/rfc6698>. + + [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design + Considerations for Protocol Extensions", RFC 6709, + DOI 10.17487/RFC6709, September 2012, + <http://www.rfc-editor.org/info/rfc6709>. + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + <http://www.rfc-editor.org/info/rfc6838>. + + [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, + April 2013, <http://www.rfc-editor.org/info/rfc6895>. + + [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", + RFC 6994, DOI 10.17487/RFC6994, August 2013, + <http://www.rfc-editor.org/info/rfc6994>. + + [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code + Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January + 2014, <http://www.rfc-editor.org/info/rfc7120>. + + [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: + Preparation, Enforcement, and Comparison of + Internationalized Strings in Application Protocols", + RFC 7564, DOI 10.17487/RFC7564, May 2015, + <http://www.rfc-editor.org/info/rfc7564>. + + + + + + +Cotton, et al. Best Current Practice [Page 44] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + + [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines + and Registration Procedures for URI Schemes", BCP 35, + RFC 7595, DOI 10.17487/RFC7595, June 2015, + <http://www.rfc-editor.org/info/rfc7595>. + + [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and + S. Ray, "North-Bound Distribution of Link-State and + Traffic Engineering (TE) Information Using BGP", RFC 7752, + DOI 10.17487/RFC7752, March 2016, + <http://www.rfc-editor.org/info/rfc7752>. + + [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names + (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, + <http://www.rfc-editor.org/info/rfc8141>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cotton, et al. Best Current Practice [Page 45] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +Acknowledgments for This Document (2017) + + Thomas Narten and Harald Tveit Alvestrand edited the two earlier + editions of this document (RFCs 2434 and 5226), and Thomas continues + his role in this third edition. Much of the text from RFC 5226 + remains in this edition. + + Thank you to Amanda Baber and Pearl Liang for their multiple reviews + and suggestions for making this document as thorough as possible. + + This document has benefited from thorough review and comments by many + people, including Benoit Claise, Alissa Cooper, Adrian Farrel, + Stephen Farrell, Tony Hansen, John Klensin, Kathleen Moriarty, Mark + Nottingham, Pete Resnick, and Joe Touch. + + Special thanks to Mark Nottingham for reorganizing some of the text + for better organization and readability, to Tony Hansen for acting as + document shepherd, and to Brian Haberman and Terry Manderson for + acting as sponsoring ADs. + +Acknowledgments from the Second Edition (2008) + + The original acknowledgments section in RFC 5226 was: + + This document has benefited from specific feedback from Jari Arkko, + Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer + Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, + John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus + Westerlund, and Bert Wijnen. + +Acknowledgments from the First Edition (1998) + + The original acknowledgments section in RFC 2434 was: + + Jon Postel and Joyce Reynolds provided a detailed explanation on what + IANA needs in order to manage assignments efficiently, and patiently + provided comments on multiple versions of this document. Brian + Carpenter provided helpful comments on earlier versions of the + document. One paragraph in the Security Considerations section was + borrowed from RFC 4288. + + + + + + + + + + + +Cotton, et al. Best Current Practice [Page 46] + +RFC 8126 IANA Considerations Section in RFCs June 2017 + + +Authors' Addresses + + Michelle Cotton + PTI, an affiliate of ICANN + 12025 Waterfront Drive, Suite 300 + Los Angeles, CA 90094-2536 + United States of America + + Phone: +1-424-254-5300 + Email: michelle.cotton@iana.org + URI: https://www.iana.org/ + + + Barry Leiba + Huawei Technologies + + Phone: +1 646 827 0648 + Email: barryleiba@computer.org + URI: http://internetmessagingtechnology.org/ + + + Thomas Narten + IBM Corporation + 3039 Cornwallis Ave., PO Box 12195 - BRQA/502 + Research Triangle Park, NC 27709-2195 + United States of America + + Phone: +1 919 254 7798 + Email: narten@us.ibm.com + + + + + + + + + + + + + + + + + + + + + + +Cotton, et al. Best Current Practice [Page 47] + |