Skip to main content

4. Choosing a Registration Policy and Well-Known Policies

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.

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:

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

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

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.

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]
Last updated on