Summary

  • RFC 5237 removed the confidential Expert Review path for allocating IPv4 Protocol and IPv6 Next Header values. IESG Approval and Standards Action remained, but the specification had to be public enough to review.
  • A protocol-number entry coordinates uniqueness. It does not certify implementation, interoperability, security, deployment or use. Public review is evidence for consuming the namespace, not proof of what happens after allocation.

The request asked others to reserve ignorance

RFC 2780 had allowed a narrow exception. Values in the IPv4 Protocol namespace could be allocated through Expert Review when non-disclosure information was involved. The expert would see material that the rest of the technical community could not.

That arrangement protected the applicant's secrecy, but it moved the cost outward. Once a value was assigned, other protocol designers, operating-system authors, firewall maintainers, packet analysts and future standards work had to treat it as occupied. They received the coordination consequence without access to the reason.

RFC 5237 withdrew that bargain. A confidential proposal could remain confidential. What it could no longer do through that route was consume a permanent value in this particular shared field.

The distinction matters. Refusing a scarce public identifier is not the same as prohibiting a product. It means the product's confidentiality preference does not automatically become a claim on common namespace capacity.

Scarcity changed the burden of proof

The field offers 256 values. RFC 5237 reported that 55 percent were in use when it was written in 2008. That figure is a historical observation, not a current registry count. Its importance lies in the decision it supported: allocation required a sanity check because the space was limited.

The RFC retained two routes. Standards Action remained necessary for protocols developed through the standards process. IESG Approval remained available for non-Standards-Track or non-IETF uses that justified a value.

The possible questions were practical. Is there a stable protocol specification? Is there a constituency that wants to use it? Would the assignment duplicate an existing purpose? Does the design really need an IP Protocol value, or would a TCP or UDP port fit the boundary better?

None of those questions asks whether the applicant has an impressive roadmap. They ask whether the shared coordination cost is necessary, inspectable and proportionate.

Public does not mean standardized

RFC 5237 required public specifications that could be reviewed. It did not say that every allocation becomes an IETF standard. IESG Approval specifically preserves a route for appropriate non-Standards-Track and non-IETF uses.

Public review and standardization are separate receipts. A specification can disclose enough for the allocation decision without gaining IETF consensus, implementation maturity or market adoption. Conversely, a public document can still fail to justify a protocol number if it duplicates an existing mechanism or places the boundary at the wrong layer.

The same caution applies to intellectual property. Making a specification reviewable does not, by itself, settle licensing, ownership or commercial rights. RFC 5237 changed an allocation prerequisite, not every legal relationship around the design.

IANA records the result; it does not invent the policy

The IANA Protocol Numbers registry is the public ledger of assignments and references. RFC 5237 changed the policy under which an entry could be made. IANA administers that policy; the registry row is not evidence that IANA authored the protocol, endorsed its business case or guaranteed its engineering quality.

This is the directory-centered distinction applied to a protocol namespace. The registry entry is the coordination object. Specifications and later reports are evidence linked to it. Neither an article nor an applicant's private dossier should be mistaken for the authoritative allocation record.

The reverse inflation is equally dangerous. A registry row says that a value has an assigned meaning under the governing record. It does not prove that interoperable code exists, that packets traverse current networks, that security claims hold, or that anyone uses the protocol.

Experiments have a different exit

The withdrawal of confidential Expert Review did not make experimentation impossible. RFC 4727 reserved protocol values 253 and 254 for experimentation and testing. That path avoids consuming a new permanent value before the experiment has earned one.

Experimental values carry their own limits. Competing experiments can interfere. Middleboxes and analyzers may treat the values specially or not support them. A successful local trial does not create a globally unique permanent meaning.

That separation is useful governance. Experiment first in a space designed for temporary ambiguity; request durable global coordination when the protocol and its constituency can support a public decision.

The rule is narrower than its principle

RFC 5237 explicitly took no position on allocation under non-disclosure agreements in other parameter spaces. Different registries have different sizes, collision costs, delegation structures and operational consequences. The specific rule should not be copied mechanically into every namespace.

The broader principle still travels: confidentiality is a private benefit, while occupation of a shared identifier creates a public coordination cost. The allocation policy must decide who bears that mismatch. In RFC 5237's field, the answer became clear. The applicant could not externalize secrecy into a permanent opaque reservation.

RFC 8126 later refined the vocabulary for registration policies. That later framework helps describe review, approval and specification requirements, but it should not blur the historical act. RFC 5237, published in February 2008 as BCP 37, removed one particular option from RFC 2780.

Keep allocation below operational proof

The evidence chain should be explicit. A proposal arrives. A specification becomes publicly inspectable. The authorized policy route reaches a decision. IANA records an assignment. Implementers may then build code, test interoperability, deploy it and generate observable traffic.

Each stage can fail after the previous one succeeds. Publication may reveal a poor design. Allocation may never attract an implementation. Two implementations may not interoperate. A working implementation may never be deployed. Deployed packets may have no useful operational effect.

Lu Heng's reality discipline is especially useful here. Public visibility is better than private assurance, but a visible specification is still not running code. A registry assignment is a uniqueness receipt, not a performance report.

The protocol field belongs to coordination because collisions would make interpretation ambiguous. That does not make the coordinator the owner of every design, and it does not make the applicant the owner of the remaining namespace. A neutral ledger works only when both claims stay bounded.

Sources

Additional standards record

  1. RFC 5237 plain text
  2. RFC 5237 information record
  3. RFC 5237 Datatracker record
  4. RFC 5237 history
  5. RFC 5237 errata
  6. RFC 5237 referenced-by record