Summary

  • RFC 5226 delegated a narrow question to a designated expert: should IANA make this assignment? It did not turn the expert into the owner of the namespace, make IANA the author of policy or convert mailing-list participation into authority.
  • The label Expert Review is incomplete without required evidence, review criteria and defensible rejection reasons. RFC 8126, which replaced RFC 5226, makes that contract more explicit and adds change control, conflict recusal, replacement, version awareness and the normal appeals path.
  • Leaders should preserve a dated review object binding request version, evidence, criteria version, reasoned recommendation and later registry history. An assignment then proves that a defined procedure accepted a defined request; it does not certify security, implementation, deployment or operational effect.

The appointment letter had a blank page

Consider a constructed governance exercise, not a report about any current registry. A new protocol registry says that future values require Expert Review. The IESG appoints an accomplished engineer. IANA forwards a request. The request includes a name, a short description and a link. The engineer asks for a threat model, two independent implementations and evidence that the extension will not exhaust a scarce range.

The requester objects. None of those requirements appears in the defining specification. A second requester, months later, receives a different list. Both reviews may be technically intelligent. The process still has a constitutional gap: the institution appointed a reviewer but did not finish defining the review.

That gap is the central problem. Expertise can improve a decision. It cannot tell us, by itself, what the expert is entitled to demand, what counts as a disqualifying defect, whose interests the reviewer may bind, which version was approved or how a refusal can be challenged.

RFC 5226 is unusually useful because it refuses the myth of an omnipotent registry operator. It says IANA does not create assignment policy; IANA carries out policy defined elsewhere and published in RFCs. The plain-text edition makes the delegation chain visible. The Datatracker rendering, RFC Editor status record, document history and errata index also preserve an important temporal fact: RFC 5226 is historical. RFC 8126 replaced it in 2017.

The correct question is therefore not whether an expert is respected. It is whether the mandate makes the expert's judgment bounded, explainable and reviewable.

IANA operates the channel; the defining document supplies the rule

The institutional roles are easy to collapse because they meet at one registry row.

The defining RFC identifies the namespace, the request fields, the review procedure, entry format, initial assignments and reserved ranges. IANA administers the request channel and records the result. The IESG appoints experts for IETF-stream registries and can replace them. The designated expert coordinates review and recommends whether the specific assignment should be made. The normal process supplies appeal.

Current IANA author guidance asks authors to name the exact registry, provide every required field and use the governing reference. The protocol registration forms page tells requesters to inspect the registry's procedure before applying. The Datatracker IANA-review help exposes another operational stage in document processing. These are valuable interfaces. They do not silently replace the policy that the registry's defining document was required to state.

That separation is not administrative trivia. If the operator's intake form becomes the unwritten source of substantive rules, a thin coordination service has acquired power without the public act that was supposed to authorize it. If an expert invents mandatory evidence after seeing a requester, technical judgment becomes retrospective legislation. If a mailing list's loudest participants are treated as the principal, participation is laundered into mandate.

A clean audit therefore asks three different questions: who wrote the policy, who administered the request and who made the technical recommendation. “IANA approved it” is often too coarse to answer any of them.

The working group was never a permanent court

Why use an individual expert at all? RFC 5226 gives a practical answer. Mailing lists produce useful technical discussion, but opinions can remain unresolved. IANA cannot monitor every list or decide when conversation has become consensus. Working groups eventually close, so they cannot be permanent evaluators for registries that may outlive them.

RFC 2418 supplies the working-group lifecycle context. RFC 7282 explains rough consensus as an engineering discipline, not a vote-counting shortcut. RFC 3935 places useful technical work and the Internet's operation at the center of the IETF mission. None turns an extinct working group, an open microphone or a head count into a perpetual decision body.

The designated expert closes that operational gap. IANA sends the request to a named reviewer; the reviewer conducts an appropriate evaluation and returns a clear recommendation. The expert may consult specialists, a public list, an active working group or the archive and community around a closed group. The expert is a shepherd of review, not necessarily the only analyst.

This delegation remains narrow. The expert answers whether the assignment should be made under the registry's rule. The expert does not acquire ownership of the namespace, general jurisdiction over the requester's product or authority to certify the resulting deployment.

A review label is not a decision rule

The most important sentence in this system is not “an expert will review.” It is “the expert will review against these criteria.”

RFC 5226 says the expert should ideally follow specific criteria documented with the protocol. It expects experts to defend their decisions and says the process is not intended to be secretive or to bestow unquestioned power. Where criteria are missing, the default is permissive: grant the code point unless a compelling reason supports denial.

The current successor, RFC 8126, strengthens the point. Its plain-text version says the registry should tell applicants what information is necessary, give the expert clear review guidance and identify reasons for rejection. The Datatracker copy, RFC Editor record, history and errata index establish the successor's publication and maintenance record.

The bounded reasons matter. Scarcity may justify refusing an excessive request. Documentation may be too unclear to assess interoperability. An extension may contradict the base protocol's architecture or security model, damage deployed systems or collide with active work in a way that harms interoperability. Personal taste is not equivalent to those grounds.

This reverses a common instinct. Vague criteria do not give the reviewer freedom to be more protective. They weaken the authorization for restrictive judgment. If a registry genuinely needs a gatekeeper, the defining specification should say so and explain the risks the gate is meant to control.

Reasons turn discretion into inspectable work

A yes/no answer is enough to move a queue. It is not enough to govern a durable namespace.

A defensible decision record should identify the request version, evidence submitted, criteria applied, consultations performed, conflicts disclosed and reasons for the recommendation. If the request changes materially after review, the approval may no longer attach to the same object. RFC 8126 warns that expert review occurs at a point in time against a particular document version and that substantive later changes may require renewed attention.

This is the same discipline engineers already apply to code review. Approval of one commit is not approval of an unexamined successor. A registration review without a version fingerprint invites the institution to claim continuity where the reviewed object has changed.

The reason record also protects the expert. Without it, every acceptance can be described as favoritism and every refusal as obstruction. With it, the community can distinguish a scarcity judgment, an interoperability defect, a security-model conflict, an incomplete request and a mere disagreement over style.

A useful five-part receipt binds:

  1. request version;
  2. supplied evidence;
  3. applicable criteria version;
  4. reasoned recommendation and conflict state;
  5. registry action and later change history.

This receipt is Daniel Kade/BTW analysis, not an RFC-defined schema. Its purpose is to keep the delegation legible after personnel and working groups change.

Recusal, replacement and appeal are part of the protocol

Expertise creates a predictable conflict surface. The best-qualified reviewer may also have authored the proposal, promoted a competing design or advised an affected implementer. Silence about that possibility does not remove it.

RFC 8126 says a conflicted expert should recuse. If every expert is conflicted, a temporary expert should be requested and the responsible Area Director can appoint one or conduct the review. Experts who become unavailable can be replaced; experts appointed by the IESG can be removed by it.

Multiple experts do not eliminate the need for a decision rule. If they disagree, they must return one clear recommendation. IANA is not supposed to arbitrate the experts' technical dispute. In deadlock, the designating body may have to step in.

Finally, review is contestable. RFC 5226 and RFC 8126 point registration disputes to the normal process in RFC 2026: first the IESG and, if necessary, the IAB. Appeal is not an insult to expertise. It is evidence that the expert's recommendation exists inside a larger delegated system.

Change control begins after allocation

A registry row persists after the original exchange ends. Someone may need to correct a reference, update contact information, mark an entry deprecated or revise a specification. RFC 8126 therefore recommends a change-controller field for policies such as First Come First Served, Expert Review and Specification Required.

That field answers a different question from the original review: who can authorize a later change? A requester entitled to obtain a coordinate is not necessarily entitled to repurpose it incompatibly years later. A reviewer entitled to approve the initial registration is not automatically the owner of every future edit.

The historical record should remain visible even when an entry is deprecated, obsolete or a registry is closed. Annotation preserves coordination memory. Deletion would erase the evidence that makes reuse and compatibility judgments possible.

Early allocation makes the time problem sharper. RFC 7120 defines temporary allocations for work in progress. A temporary coordinate can help implementations develop without pretending that the document has completed its standards path. Temporary, permanent, deprecated and obsolete are lifecycle states, not decorative labels.

Similar policy names return different proofs

RFC 5226 inherited and revised the policy vocabulary of RFC 2434. RFC 8126 keeps the labels but makes their practical boundaries clearer.

First Come First Served performs no substantive technical review beyond a well-formed, non-duplicate request. Expert Review adds a designated reviewer operating under the registry's evidence and criteria. Specification Required adds a stable, permanent and publicly accessible specification detailed enough to support independent interoperability. RFC Required requires an RFC but, unless narrowed, accepts any RFC stream and multiple document statuses. IETF Review requires an IETF-stream RFC through the IESG path.

These are allocation procedures, not interchangeable quality badges. A code point obtained through Expert Review does not certify a product. An RFC Required registration is not necessarily an IETF standard. IETF Review is not evidence that two deployed systems interoperate. The row proves a narrower fact: the specified process accepted a specified request at a specified time.

Heng Lu's analysis helps explain why this restraint is structural rather than rhetorical. The Multi-Stakeholder Mirage separates participation from authorization. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption argues for a thin common layer and localized later choices. When the Bookkeeper Auditions for Olympus warns against turning a recording function into a claim of higher power. Running-Code Primacy keeps specification and registry symbols separate from implementation and observed use.

The designated expert is most valuable when those layers remain distinct. The role can prevent collisions and harmful extensions without pretending to govern everything downstream.

Sources

  1. RFC 5226
  2. RFC 5226 plain text
  3. RFC 5226 on IETF Datatracker
  4. RFC 5226 status
  5. RFC 5226 history
  6. RFC 5226 errata
  7. RFC 8126
  8. RFC 8126 plain text
  9. RFC 8126 on IETF Datatracker
  10. RFC 8126 status
  11. RFC 8126 history
  12. RFC 8126 errata
  13. IANA guidance for RFC authors
  14. IANA protocol registration forms
  15. Datatracker IANA-review state
  16. RFC 7120
  17. RFC 2026
  18. RFC 2418
  19. RFC 2434
  20. RFC 3935
  21. RFC 7282
  22. Lu Heng — The Multi-Stakeholder Mirage
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — When the Bookkeeper Auditions for Olympus
  25. Lu Heng — Running-Code Primacy