Skip to main content

14. Changes Relative to Earlier Editions of BCP 26

14.1. 2016: Changes in This Document Relative to RFC 5226​

Significant additions:

  • Removed RFC 2119 key words, boilerplate, and reference, preferring plain English -- this is not a protocol specification.

  • Added Section 1.1, Keep IANA Considerations for IANA

  • Added Section 1.2, For Updated Information

  • Added Section 2.1, Organization of Registries

  • Added best practice for selecting an appropriate policy into Section 4.

  • Added Section 4.12, Using Multiple Policies in Combination

  • Added Section 2.3, Specifying Change Control for a Registry

  • Added Section 3.4, Early Allocations

  • Moved each well-known policy into a separate subsection of Section 4.

  • Added Section 5.4, Expert Reviews and the Document Lifecycle

  • Added Section 7, Documentation References in IANA Registries

  • Added Section 8, What to Do in "bis" Documents

  • Added Section 9.5, Contact Person vs Assignee or Owner

  • Added Section 9.6, Closing or Obsoleting a Registry/Registrations

Clarifications and such:

  • Some reorganization -- moved text around for clarity and easier reading.

  • Made clarifications about identification of IANA registries and use of URLs for them.

  • Clarified the distinction between "Unassigned" and "Reserved".

  • Made some clarifications in "Expert Review" about instructions to the designated expert.

  • Made some clarifications in "Specification Required" about how to declare this policy.

  • Assorted minor clarifications and editorial changes throughout.

14.2. 2008: Changes in RFC 5226 Relative to RFC 2434​

Changes include:

  • 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.

  • Numerous editorial changes to improve readability.

  • 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.

  • Added "RFC Required" to list of defined policies.

  • Much more explicit directions and examples of "what to put in RFCs".

  • "Specification Required" now implies use of a designated expert to evaluate specs for sufficient clarity.

  • Added a section describing provisional registrations.

  • 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.

  • Changed wording to remove any special appeals path. The normal RFC 2026 appeals path is used.

  • Added a section about reclaiming unused values.

  • Added a section on after-the-fact registrations.

  • Added a section indicating that mailing lists used to evaluate possible assignments (such as by a designated expert) are subject to normal IETF rules.