Summary

  • RFC 9997 reserves two private YANG SID mega-ranges and lets eligible PEN holders calculate their own blocks without requesting every allocation from IANA. The mechanism separates number space efficiently; it does not authenticate the material placed inside a block.
  • The RFC says plainly that a PEN embedded in a SID is not an indicator of provenance. RFC 9595 separately requires authoritative sources for .sid files because a false integer-to-schema mapping can change the meaning of compactly encoded data.
  • Daniel Kade proposes a privacy-minimized provenance-binding receipt that joins registry state, range derivation, repository authority, module and SID-file digests, mapping lifecycle, integrity checks, deployed YANG Library context and the acceptance outcome.

The arithmetic works even when the story does not

Suppose a management application encounters an unfamiliar integer in a compact payload. The number falls inside the block mathematically associated with a well-known enterprise's PEN. An engineer recognizes the digits, finds a plausible YANG module in a repository and imports the accompanying .sid file. Every number is collision-free. The decoder works. The object names look reasonable.

None of that proves the repository belongs to the PEN holder, that the module is the revision expected by the device, or that the mapping file was authorized by anyone entitled to speak for the enterprise. A deterministic calculation has answered “which block?” The operator has allowed it to answer “whose software?”

That is precisely the inference RFC 9997 refuses. Published in July 2026 on the IETF Standards Track as a Proposed Standard, the document extends the YANG SID allocation model with PEN-derived ranges for private use. Its purpose is to make private number space practical at scale, especially where seeking a centrally registered block for every experiment, proprietary model or closed deployment would create friction.

YANG SIDs are globally unique unsigned 63-bit integers. They map YANG schema items—modules, identities, nodes and related constructs—to compact numbers suitable for constrained encodings such as YANG-CBOR. A SID saves bytes because a small integer can stand where a longer schema name would otherwise appear. Its semantic power therefore comes from a mapping: the sender and recipient must agree that the integer refers to the same schema item.

Global uniqueness protects that agreement from one kind of failure. If two allocation authorities stay within their assigned ranges, they should not accidentally allocate the same number as independent identifiers. Yet uniqueness does not establish authenticity. A forged passport number can have the right length and jurisdictional prefix. In the same way, a number can sit inside the correct enterprise-derived interval while arriving in an unauthoritative module or manipulated mapping file.

Two mega-ranges remove a queue, not a verification duty

RFC 9997 assigns two large intervals under the Private registration policy. The first runs from 3,000,000,000 through 3,999,999,999. The second runs from 300,000,000,000 through 399,999,999,999. These are public facts in the IANA YANG SID registry. “Private” describes allocation policy; it does not mean that the ranges or their use are confidential.

For a PEN below 100,000, the RFC defines a 10,000-SID block in the smaller interval, which can be represented compactly within the 32-bit-oriented range discussed by the document. For a PEN below 1,000,000, it defines a 100,000-SID block in the larger interval. The PEN holder calculates the starting point from its enterprise number. No additional IANA interaction is required for that derived block.

This is elegant delegation. The central registries publish the mega-ranges and the PEN number space; arithmetic partitions the private SID resource among qualifying holders. Each holder can manage its portion without submitting a new request for every internal allocation. Other holders performing the same calculation land elsewhere.

The documentation example is a useful sign of protocol discipline. PEN 32473 is reserved by RFC 5612 for examples and documentation. RFC 9997 uses that number and reserves the two derived example blocks for documentation as well. A reader can repeat the calculation without accidentally treating an actual enterprise's allocation as disposable sample data.

The mechanism is intentionally low-threshold. The RFC describes PEN registration as low-overhead and the derived SID block as zero-interaction once the PEN exists. Those are benefits for experimentation and private deployment. They are also reasons not to treat possession of a compatible number as a high-assurance identity check. A process designed to avoid repeated vetting cannot silently serve as repeated vetting.

Allocation authority and publication authority are different controls

RFC 9997 delegates management of a derived block to the corresponding PEN holder. That tells us who is entitled to allocate within the block under the registry policy. It does not prove that an arbitrary file found on a package mirror, code host, email attachment or device image came from that holder.

The Security Considerations leave no room for the comforting shortcut: the presence of a specific PEN in a SID is not an indicator of provenance, and it does not guarantee that the SID or the underlying YANG model originated from the PEN holder. This is not a minor caveat appended to otherwise identity-bearing numbers. It defines the boundary of the mechanism.

The distinction has at least four layers. The PEN registry records a number assignment. The YANG SID registry records allocation ranges and policies. A repository or distribution channel supplies a module and mapping file. A running system declares which schemas it currently uses. Each layer can be accurate while a different layer is false or stale.

A PEN record, for example, is not a trademark adjudication, a software-signing certificate or proof that a particular person still controls a repository. A correctly derived range is not a list of modules. A module carrying a familiar namespace is not necessarily the revision a device implements. A .sid file matching a module name may still assign integers differently from the file used to encode the data.

RFC 9595, which defines the YANG SID allocation framework, explains why source authority matters. SID files translate semantic schema items into integers. Importing an untrusted mapping can cause a system to associate received values with the wrong concepts. The document therefore advises developers to import .sid files only from authoritative sources and says management systems need a source as authoritative as the one used for the YANG modules themselves.

That instruction cannot be satisfied by checking the interval alone. Range membership proves that a number is eligible to be allocated by one authority. Source verification proves that the particular allocation statement actually came through a channel entitled to make it. The first is arithmetic; the second is provenance.

Discovery is deliberately outside the calculation

RFC 9997 does not create a global discovery service that tells an operator which module stands behind every PEN-derived SID. Where obscurity is not intended, it encourages PEN holders to expose the relevant YANG models and SID files through a public repository and/or through YANG Library on implementations.

That advice supplies possible places to look, not a universal trust anchor. “Public repository” still raises questions: which repository is official, how was control established, what revision was retrieved, what digest did the reviewer approve, and what happens after a transfer or compromise? YANG Library answers another set of questions about a running server, but it does not sign the history of the file that reached that server.

RFC 8525 defines YANG Library's inventory model. A server can report modules, revisions, namespaces, supported features, deviations, schemas and datastores. A server-specific content-id must change when that library information changes. Identical information, however, need not generate the same identifier at different times or on different servers. The identifier is a change signal in a particular operational context, not a universal content digest.

This makes YANG Library valuable evidence at the deployment plane. It can show that server A declared module revision R, feature set F and schema context C when a payload was processed. It cannot by itself establish that repository B was authorized by the PEN holder, that the file downloaded earlier was unchanged, or that a similarly named module on server D has the same contents.

The control surface is therefore a chain rather than a lookup. Registry policy bounds the number space. Repository authority bounds the source. Digests bind named artifacts to bytes. Integrity mechanisms bind a transfer or release to an accountable publisher. YANG Library binds a declared schema set to a server context. An acceptance decision binds those facts to an operator's actual reliance.

SID lifecycle makes yesterday's valid mapping insufficient

Provenance is not only about the first import. RFC 9595 distinguishes unstable, stable and obsolete SID assignments. During development, unstable mappings may change. Once stable, an assignment has stronger continuity expectations. If it becomes obsolete, the number remains recorded so it is not recycled for a different semantic item.

That lifecycle prevents an especially dangerous form of compact ambiguity: a retired number returning later with a new meaning. But the protection depends on retaining the correct mapping history. A clean current file cannot explain an older payload if the prior stable and obsolete states were discarded. Conversely, an old authoritative file may be genuine and still be unsuitable for decoding a payload built against a newer revision.

An operator therefore needs two separate statements: the artifact was obtained through an authoritative path, and its lifecycle state was appropriate for the specific encoding or deployment. One without the other is incomplete. Authentic obsolete data does not become current; current-looking unauthenticated data does not become trustworthy.

RFC 9254 provides the YANG-CBOR context in which compact identifiers carry so much operational meaning. Compression is valuable precisely because both sides omit repeated names and rely on shared schema knowledge. When that knowledge is wrong, compactness hides the disagreement rather than making it self-evident. A human inspecting an integer such as a SID has less semantic warning than one reading a descriptive path.

A provenance-binding receipt can preserve the joins without collecting the system

The repair should not be a warehouse of device configurations, proprietary models or decoded traffic. Those materials may be sensitive and are unnecessary for proving the bounded decision. What is missing is a small, tamper-evident receipt joining eight evidence planes.

First, record the IANA registry snapshot or version used to recognize the private mega-range. Second, preserve the PEN number, the applicable eligibility bound and the deterministic range calculation. This proves why the number fell within a particular delegated block; it does not label the artifact authentic.

Third, identify the authoritative repository or distribution root and the evidence by which the organization accepted that authority. Fourth, bind the YANG module's name, namespace, revision and cryptographic digest. Names assist discovery; the digest identifies the reviewed bytes.

Fifth, bind the .sid file by digest and record its mapping lifecycle—unstable, stable, obsolete or another state defined by the governing process—together with the relevant assignment history. Sixth, record integrity or signature validation: what mechanism was checked, against which trusted identity, at what time, and with what result.

Seventh, attach the deployed context from YANG Library: server scope, observed module set, revision, features, deviations, schema or datastore reference and content-id. Do not misdescribe content-id as a cross-server hash. Eighth, preserve the operational outcome: accepted, rejected, superseded or retired, with reason class, decision owner and the systems or policy versions to which it applied.

The planes should remain distinguishable. A registry operator is not asked to vouch for a repository. A repository owner is not asked to attest to every server's active schema. A device report is not treated as historical supply-chain evidence. An operator cannot convert a successful decode into retrospective proof that the source was authorized.

This receipt is Daniel Kade's editorial proposal, not an RFC 9997, RFC 9595 or RFC 8525 field. It stores no configuration payload, credential, private module body, device secret or unrelated activity. Its purpose is narrower: prevent a useful allocation shortcut from becoming an invisible authentication shortcut.

Why BTW Media Exists supplies the discipline: report what the system can actually establish. Here it can establish range membership, artifact identity, source authority, deployed declaration and acceptance as separate facts. It cannot turn one fact into all the others merely because a number looks official.

Sources