Summary

  • RFC 9997 gives eligible IANA Private Enterprise Number holders deterministic private YANG SID blocks, eliminating a per-block allocation transaction while preserving global numerical separation.
  • The PEN embedded in the calculation is not provenance: it does not authenticate the YANG module, the .sid mapping, its publisher or the meaning assigned to an integer.
  • Operational trust still requires an authoritative distribution channel, exact module and mapping versions, integrity evidence, device capability checks and a running implementation that accepts the schema.

Imagine a controller decoding a compact telemetry message from an industrial gateway. Instead of a long YANG node name, the message carries an integer. The integer lies inside the private block that anyone can calculate from the gateway vendor's IANA Private Enterprise Number. The decoder has a .sid file that turns the integer into a temperature alarm leaf. Everything appears aligned.

Now let an integrator obtain the .sid file from a convenient mirror rather than the vendor's authenticated release channel. The mirror maps the same integer to a reset action. The number remains inside the correct vendor-shaped block. The packet remains valid CBOR. The arithmetic remains flawless. What changed is the authority over meaning.

This is the control problem exposed by RFC 9997, published in July 2026 on the IETF Standards Track. The document reserves enormous private YANG Schema Item Identifier territories and gives PEN holders a formula for locating their own blocks. It removes administrative friction from collision avoidance. It does not make a PEN a signature.

Two ranges, no allocation queue

YANG, defined by RFC 7950, gives network management data a schema: modules, containers, lists, leaves, actions and notifications. Human-readable names are useful in source and APIs, but they are expensive in constrained encodings. RFC 9254 therefore defines YANG-CBOR, where a schema item can be represented by a 63-bit unsigned SID or by a compact delta from a current SID.

The assignment machinery sits in RFC 9595. Public SIDs may be recorded through IANA policy. Private ranges allow another manager to control assignments inside a delegated block. A .sid file preserves the actual association between a module's semantic items and their integers.

RFC 9997 adds a different kind of delegation. IANA has allocated the range from 3,000,000,000 through 3,999,999,999—a billion values that fit in an unsigned 32-bit representation—and the range from 300,000,000,000 through 399,999,999,999—a hundred billion values requiring 64-bit representation. Both are recorded as Private in the YANG SID registry.

A PEN below 1,000,000 deterministically receives a block of 100,000 SIDs in the larger range. A PEN below 100,000 also receives a block of 10,000 in the 32-bit range. The decimal construction makes the boundary inspectable and computable. There is no ticket, expert review or live IANA request for each holder's block. Two parties given the same PEN will calculate the same start and end.

That is an elegant use of existing coordination. IANA has maintained the Private Enterprise Numbers registry, whose registration threshold is intentionally low. RFC 9997 noted roughly 66,000 assigned PENs and projected that numbers below 100,000—the subset eligible for the extra 32-bit block—could run out around 2040. The 64-bit construction has room for far more holders.

Large absolute numbers do not automatically make every YANG-CBOR message large. Delta encoding lets a nearby schema item be carried as a small difference from a current SID. The 64-bit territory buys allocation headroom while the wire form can remain compact. The trade is therefore not simply “more space means eight-byte keys”.

The standards also reserve safe examples. The documentation PEN established by RFC 5612 yields blocks that IANA marks for documentation, reducing the chance that specifications and manuals collide with a real deployment.

The formula delegates territory, not authorship

The attractive wrong conclusion is easy to state: if a SID falls inside the block derived from Vendor A's PEN, Vendor A must have issued it. RFC 9997 rejects that conclusion in its security considerations. The appearance of a PEN in a SID is not provenance and does not guarantee that the model or SID originated with that PEN holder. The authoritative source must still be ascertained.

Why can the arithmetic not prove origin? Because it is public. Anyone can obtain a PEN and calculate its ranges. Anyone can also calculate someone else's ranges and place plausible-looking integers in an unofficial file. The formula prevents two compliant holders from independently selecting the same territory; it does not prevent an attacker, abandoned integration, mistaken contractor or forked toolchain from claiming meanings inside another holder's block.

The distinction mirrors the allocation vocabulary of RFC 8126. A registry policy explains how values are coordinated and reviewed. It cannot, merely by recording or reserving a value, vouch for every later artifact that uses it. In RFC 9997, IANA manages the PEN and mega-range records. The PEN holder manages the internal block. Neither fact authenticates a file delivered to a receiver.

The right mental model is delegated address space. A street address helps separate one property from another. It does not prove that a document found at the address was signed by the owner. The SID block makes clashes avoidable; the publishing chain makes a mapping attributable.

A .sid file is executable meaning

It is tempting to file the .sid artifact under build metadata. That understates its power. RFC 9595 warns that the map joins semantic concepts to integers. If an untrusted party controls it, a receiver can decode syntactically valid data into the wrong node, action or notification.

The risk appears at several points. A build pipeline may import a stale mapping. A package repository may replace a file without preserving the module revision. A gateway may advertise one YANG revision through its capabilities while the controller uses the SIDs for another. A vendor acquisition may split publication channels. A private extension may reuse an assignment after the original team disappears.

The safe object is not “the vendor's range”. It is a tuple: authoritative publisher, YANG module name and revision, exact .sid content, cryptographic integrity evidence, distribution channel and the device capability statement against which it will be used. If one component changes, the relying system has a new trust decision.

RFC 9595 advises developers to import .sid files from authoritative sources. It also notes that management systems in less constrained environments need mapping sources as authoritative as their YANG module sources. A signed release, pinned repository commit or verified package may establish that authority. A number pattern cannot.

Nor should an identifier become an uncontrolled fetch instruction. RFC 9595 warns that dereferenceable identifiers can provoke remote access, with security and privacy consequences. Automatic discovery may reveal which models an operator is using, expose a resolver to tracking, or allow an online source to change the answer between builds. Reproducibility requires preserving the exact bytes and provenance decision, not merely the URL that once returned them.

Discovery is useful and still not authority

RFC 9997 deliberately does not build an infrastructure for discovering the YANG module behind a private SID. A holder can publish a repository. A device can expose module and datastore information through the YANG Library defined by RFC 8525. An ecosystem catalog can index both.

Each mechanism answers a different question. A catalog answers “where might I look?” A YANG Library response answers “what does this device report that it implements?” A release channel answers “what artifact did this publisher distribute?” A verified .sid file answers “what integer mapping was bound to this module revision?” None should silently inherit the authority of another.

This separation matters when obscurity is intentional. A private model may be distributed only to customers or embedded inside a closed product. Its SID block remains calculable. Failure to find a public module does not prove misuse, and finding an unofficial copy does not make the copy authoritative.

The last word belongs to the running system

Even a correctly attributed module and mapping do not prove interoperability. The device may implement another revision, omit an optional feature, expose deviations, reject an action under local policy or accept the schema only on a particular datastore. RFC 8525 supplies capability evidence; it is not a promise that every theoretically valid operation will succeed.

The control chain therefore has five separate records. IANA coordinates the PEN and mega-ranges. The holder allocates inside its block. A publisher releases the model and mapping. A consumer verifies and resolves them. The running device accepts or rejects the resulting operation under its actual implementation and state.

Heng Lu's Minimum Initial Specification gives the architecture a useful description. Put in the common layer only what must be common. RFC 9997 centralizes enough arithmetic to keep namespaces apart and leaves internal modeling decisions local. That is a feature, provided no participant promotes the thin common layer into a universal source of authority.

His essay on Running-Code Primacy supplies the final test. A record and a mapping matter, but operational force appears when implementations accept compatible inputs. A controller that resolves a SID and a device that rejects the operation have not achieved interoperability, however neat the registry evidence looks.

And Reality Layers prevents the layers from collapsing. The PEN record, calculated block, published mapping, device capability statement and observed runtime result are related facts. They are not the same fact. Good governance preserves the joins between them without pretending that one symbol creates the whole reality.