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

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:

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