Update of and Clarification to IANA Policy Definitions in BCP 26

BCP 26 presents a number of guidelines for IANA considerations in RFCs. Section 4.1, in particular, is devoted to registration policies, and the policy terminology it defines is widely used. Whether or not RFCs use the specific terms defined therein, there is a habit of applying the more restrictive policies across the board, resulting in registries that require RFC, and even Standards Track RFCs, for registries for which lighter weight policies might be more appropriate.

BCP 26 section 4.1 defines this set of registration policies: 1. Private Use 2. Experimental Use 3. Hierarchical Allocation 4. First Come First Served 5. Expert Review (or Designated Expert) 6. Specification Required 7. RFC Required 8. IETF Review 9. Standards Action 10. IESG Approval Beginning with "First Come First Served", they are in approximately increasing order of strictness: 4. No review, minimal documentation. 5. Expert review, sufficient documentation for review. 6. Expert review, significant and stable documentation. 7. Any RFC publication, perhaps in Independent stream. 8. RFC publication, IETF stream only. 9. Standards-Track RFC publication. In considering which of policies 4 through 9 to apply, it's important to get the right balance of review and ease of registration. In many cases, those needing to register items 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. We must not make registration policies and procedures unnecessarily difficult to navigate, unnecessarily costly (in terms of time and other resources), nor unnecessarily subject to denial. While it is sometimes necessary to restrict what gets registered (for limited resources such as bits in a byte or numbers within a relatively small range, or for items for which unsupported values can be damaging to protocol operation), in many cases having items registered is more important than putting restrictions on the registration. A pattern of denial through overly strict review criteria, or because of excessive cost in time and effort to get through the process, discourages people from even attempting to register their items. And failure to have in-use items registered adversely affects the protocols in use on the Internet. In particular, because policies 7 through 9 require involvement of working groups, directorates, and/or communities of former working-group participants to be actively involved and to support the effort, requests frequently run into concerns that "it's not worth doing a Standards-Track RFC for something this trivial," when, in fact, that requirement was created by the working group in the first place, with its choice of a Standards Action policy for the registry. Indeed, publishing any RFC is costly, and a Standards Track RFC is especially so, requiring a great deal of community time for review and discussion, IETF-wide last call, involvement of the entire IESG as well a concentrated time and review from the sponsoring AD, review and action by IANA, and RFC-Editor processing.

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 stricter than Specification Required. Examples of situations that might merit RFC Required, IETF Review, or Standards Action include Registries of limited resources, 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 by community consensus could too quickly deplete the allowable values. Registries for which 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 things that change the semantics of existing operations. There will be other cases, as well, of course; must assessment and judgment is needed. It's not the intent, here, to put limits on the applicability of particular registration policies, but to recommend laxity, rather than strictness, in general, and to encourage document developers to think carefully about each registry before deciding on policies. BCP 26, in its description of "IESG Approval", suggests that the IESG "can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason to use that path." The IESG should give similar consideration to any registration policy more stringent than Specification Required, asking for justification and ensuring that more relaxed policies have been considered, and the strict policy is the right one. This is a situation that will -- and should -- involve a substantive discussion between the IESG and the working group, chairs, document editors, and/or document shepherd. The important point, again, is not to relax the registration policy just to get the document through quickly, but to carefully choose the right policy for each registry. Accordingly, document developers need to anticipate this and include a justification for the chosen policy in the document along with the documentation of the choice. At the least, a justification should be included in the shepherd writeup for the document, and in any case 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. It is also possible to produce a small document at any time, which "updates" the original specification and changes registration policies. In either case, a policy can be relaxed or made more strict, as appropriate to the actual situation. The recommendations in this section apply whether the terms defined in BCP 26 are used, or whether the document contains its own policy definitions. The point, again, is not to limit registration policies, but to ensure that the policies selected are appropriate, and that proper consideration has been given to the level of strictness required by them.

See the Security Considerations section in BCP 26 , and note that improper definition and application of IANA registration policies can introduce both interoperability and security issues. It is critical that registration policies be considered carefully and separately for each registry. Overly restrictive policies can result in the lack of registration of code points and parameters that need to be registered, while overly permissive policies can result in inappropriate registrations. Striking the right balance is an important part of document development.

This document has no IANA actions.

Cyrus Daboo, Alexey Melnikov, Pete Resnick, and Peter St. Andre were involved in early discussion of these issues.