Summary

  • RFC 8126 defines ten registration policies for IANA-managed protocol registries, and for two of them — Private Use and Experimental Use — IANA records no values at all.
  • The challenge runs on a fixed clock: an appeal must be initiated within two months of public knowledge. The decision runs on an unfixed one: "a reasonable period", with no universal deadline, and predictability defined as the absence of unexpected steps rather than a promised number of days.
  • The IAB may annul an IESG decision and restore the prior situation, but it cannot make a decision reserved to the IESG, and no reviewed provision expressly lets it order the registration. The IESG is the body that appoints, and may remove at its discretion, the expert whose judgement is being challenged.

Start with a request rather than a principle. Someone wants a value written into an IANA-managed protocol registry. The registry, the field names and the policy are three different things, and IANA's own guidance, displayed as revised on 13 July 2026, says so plainly: different ranges inside one registry may use different registration procedures, so naming the registry does not by itself name the rule (IANA, Guidance for RFC Authors). The same page asks a requester to identify the exact registry and supply the required field information, and warns that the registry's reference RFC may demand a template carrying fields the registry display never shows.

Who actually decides is settled by instrument, not by habit. RFC 8722, an IAB informational document from February 2020, puts the registry operator's job at registration according to RFC-defined criteria and procedures and the applicable registry policy, with ambiguities referred for clarification (RFC 8722, §2.1). The same document removes the technical judgement from the operator's shoulders: "the Registry Operator will seek and follow technical guidance exclusively from the IESG", and technical assessment generally is not the operator's responsibility (RFC 8722, §2.3). Appointment and termination of the registry-operator organisation sits with the IAB working with the IETF LLC — a distinct act from appointing the individual experts (RFC 8722, §2.2).

The policy menu itself is a closed set of ten. RFC 8126, published June 2017, sets out Private Use, Experimental Use, Hierarchical Allocation, First Come First Served, Expert Review, Specification Required, RFC Required, IETF Review, Standards Action and IESG Approval (RFC 8126, §§4.1–4.10). Two of those categories are silent by design: Private Use and Experimental Use values are not recorded by IANA at all. Specification Required adds a documentation test to Expert Review — a permanent, publicly retrievable specification, clear and technically sound, sufficient for independent interoperability, not necessarily an RFC (RFC 8126, §4.6).

Where the expert works from published criteria, the expert applies them. Where the registry has none, RFC 8126 asks the expert to assess completeness of documentation, interoperability and conflicts, and to presume grant absent a compelling objection (RFC 8126, §§5.1–5.3). Denial has named grounds — scarcity of the resource, unclear documentation, harmful architectural or deployment effects, harmful conflicts with IETF work — and no others are listed (RFC 8126, §5.3).

Now the clock. RFC 2026, October 1996 and still the procedural backstop, says this and means it: "All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged" (RFC 2026, §6.5.4). The same section holds decision-makers to procedure, requires them to decide and communicate within a reasonable period, and supplies no universal fixed deadline. The IAB's principles for IANA registry operation say the same thing in a different register: predictable processing means avoiding unexpected steps, not guaranteeing that expert decisions arrive inside a predetermined number of days (RFC 8720, §3.1). Read those two provisions side by side and an apparent asymmetry stands out: the party with a grievance is timed; the party with the pen is given no number. Whether the drafting is deliberate is not established here.

The ladder starts where the refusal happened. RFC 8126 routes a challenge to a registration decision to the IESG, then to the IAB, and applies the RFC 2026 §6.5.1 dispute procedure to disputes involving expert teams (RFC 8126, §10). That incorporated procedure runs through working-group chairs, then responsible Area Directors, then the full IESG, then the IAB, with each body required to review and attempt resolution and the IAB final on procedural compliance and technical merit (RFC 2026, §6.5.1). Where a process failure is found, the IESG re-examines its action and reports to the IETF; the IAB may annul the IESG's decision and restore the prior situation, or recommend action, but cannot make decisions reserved to the IESG (RFC 2026, §6.5.2).

That last clause carries more weight than its length suggests, and the conclusion drawn from it here is this article's reading rather than a sentence either document writes: if the strongest outcome identified in the reviewed ladder is annulment that restores the prior situation, and the top of the ladder cannot make a decision reserved to the IESG, then the reviewed provisions do not expressly confer a power to order that the registration be made. That leaves open a recommendation, annulment followed by reconsideration, or a case-specific route to a later registration. Undoing is not the same as ordering.

A requester can win the argument without the appeal itself recording the value.

One more structural fact, and it is the one worth pinning above the desk. RFC 8126 §5.2.1 states, verbatim, that "The IESG may remove any designated expert that it appointed, at its discretion", and the same section describes the IESG appointing and replacing experts for IETF registries, normally on an Area Director's recommendation (RFC 8126, §5.2.1). Section 10 sends the challenge to the same body first. Neither document reconciles the appointment role with the appellate role, and no separation between them is stated in the provisions reviewed. The first named institutional stage in the chain is the body that appoints the expert; §10's route runs through working-group chairs and responsible Area Directors before the full IESG, and who hears any particular appeal, and whether the same individuals act, is not established here.

Other provisions soften the edges without changing the shape. The IESG may exceptionally override registration procedures case by case (RFC 8126, §3.3). Repeated unexplained delays in expert review oblige IANA to escalate to the IESG, which should correct the situation or replace the expert (RFC 8126, §5.3) — a remedy aimed at the delay, not at the requester's value. And the transparency principle is explicit: "the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal" (RFC 8720, §3.3). Visibility is promised. A decision date is not.

The record around the instrument is live, and drifting. RFC 9907, March 2026, updates RFC 8126 and obsoletes RFC 8407, requiring instructions that connect changes in an authoritative registry to maintenance of the corresponding IANA-maintained YANG module, with new values belonging in the registry rather than dropped straight into the module (RFC 9907). The errata file shows what the community has already tried: technical erratum 6522, rejected on 8 April 2021, would have expressly allowed specified Internet-Draft versions to satisfy the §4.6 specification test, and the verifier treated it as a policy proposal needing discussion and consensus rather than as a correction of an error; editorial erratum 5772, held for document update on 3 July 2019, concerns an acknowledgments reference and nothing else (RFC 8126 errata). The rejection records a refusal of one proposed wording. It does not establish that no Internet-Draft has ever been accepted in practice under any registry's rules, and §4.6 as written does not name Internet-Drafts among the acceptable forms.

A replacement text exists and is not in force. draft-ietf-ianabis-rfc8126bis-05 was published on 2 November 2026; its abstract says it obsoletes RFC 8126, while its own header conditions that on approval and its status identifies it as an Internet-Draft, work in progress (draft-ietf-ianabis-rfc8126bis-05). RFC 8126 is read here as the operative text; the replacement is recorded as conditional, not as an accomplished supersession.

Three boundaries belong beside the claims rather than at the end. No actual registration request, refusal, appeal filing or disposition was inspected, so everything above describes the published framework, not how any particular request was handled. Which policies bind any particular registry was not established — one registry may carry several. The IESG's internal handling of an appeal, and any unpublished history of past appeals, were not obtained.

One retrieval limit, stated once: three research attempts on the IANA naming-function instrument class failed at the provider before that line was closed, and the naming-function contract, the Customer Standing Committee charter and the Naming Function Review report remain unread in this review. That is a gap in this desk's retrieval. It is not a finding about those documents.

What would change the reading? A published appeal disposition that ends with a value recorded under the IAB's direction rather than the IESG's, or a registry that writes its own criteria down and thus converts a presumptive grant into a testable one. Until one of those appears, the honest summary for anyone relying on an IANA registry entry is narrower than it looks: the framework publishes the standard, publishes the transparency promise, and hands the timing and the last word to the same small set of people.