Summary
- RFC 9907 says an IANA-maintained YANG module represents a companion registry; it does not become a second registry. The registry remains the unique authoritative source.
- A validator can truthfully approve old bytes. Operational proof must bind registry time, exact module revision and digest, validation inputs, the server's YANG Library state, the actual operation and its observed result.
The pipeline was green. The module parsed, imports resolved and the IETF checks returned no blocking error. Yet the value that triggered the deployment had already changed in the companion IANA registry. The validator had done its job. The evidence claim had asked it to prove something outside that job.
RFC 9907, published in March 2026 as BCP 216, replaces RFC 8407 and updates the registration guidance in RFC 8126. Its RFC Editor record fixes that status. The document is guidance for authors and reviewers of YANG-bearing specifications. It is not a new protocol for changing a device.
Its rule for IANA-maintained modules is unusually direct. A YANG or MIB module that represents an IANA registry is another representation format, not an independent registry. New values enter through the companion registry. IANA then reflects authoritative changes in the maintained module. The IANA YANG Parameters registry is the distribution surface; it publishes versioned module artifacts and maintenance notes.
RFC 9907 also removes a tempting shortcut. An Internet-Draft may include a generation script and the complete initial module so reviewers can inspect the design. Before RFC publication, however, the authors must ask the RFC Editor to remove the initial-module appendix. The published specification must say that its module was only the initial version and direct readers to IANA for the authoritative version. A convenient copy inside an immutable document would soon acquire an authority it no longer deserved.
“Get it from IANA” still leaves an evidence choice. A latest URL answers where to fetch the current projection now; a revision-specific URL identifies a historical artifact. Neither, by itself, records the bytes a particular pipeline consumed. A reproducible review should preserve retrieval time, registry snapshot, module revision, source URL and a digest. Otherwise tomorrow's successful download can silently replace yesterday's reviewed input.
Validation remains essential. RFC 9907 calls for modules to be validated and names tools such as pyang --ietf as an example. YANG 1.1 supplies the language rules. But a validation report is conditional: this tool version, these options, these imported dependencies and these bytes satisfied these checks. It cannot establish that the bytes were newest, that the registry did not change after retrieval, or that a target server advertises the same schema.
The target has its own witness. RFC 8525 lets a server expose YANG Library information: module sets, features, deviations and datastore schemas. Its content-id must change whenever that library information changes. Comparing the reviewed module bundle with the server-advertised set is therefore a separate control. A clean local validation and a mismatched server inventory can both be true.
Deployment then crosses another boundary. RFC 8342 distinguishes intended and operational datastore views. NETCONF and RESTCONF define operations and errors over modeled data. A successful request receipt does not prove the intended state became operational; operational state does not prove the service objective. Each transition needs its own observation.
A defensible record therefore joins, without merging, the registry snapshot and time; exact IANA module revision, URL and digest; generation provenance where relevant; validator version, options and dependency set; server YANG Library module set and content-id; intended operation and protocol receipt; before-and-after datastore views; rollback state; and service-level test. The chain is editorial synthesis, not a field list mandated by one RFC.
Heng Lu's Minimum Initial Specification supports a narrow shared representation while preserving accountable local choice. Running-Code Primacy makes server and operation evidence authoritative only for what they expose. Reality Layers stops a registry, a file, a validator, a datastore and a service result from collapsing into one green badge. These are disclosed editorial principles, not additional IETF rules.
RFC 9907 does not weaken automation by narrowing each proof. It makes automation auditable: the registry can govern the value, the module can carry it, the validator can test it, the server can advertise it, and the operation can use it—without any layer impersonating the next.
Sources
- https://www.rfc-editor.org/rfc/rfc9907.html
- https://www.rfc-editor.org/info/rfc9907/
- https://www.rfc-editor.org/rfc/rfc8407.html
- https://www.rfc-editor.org/rfc/rfc8126.html
- https://www.rfc-editor.org/rfc/rfc7950.html
- https://www.rfc-editor.org/rfc/rfc8525.html
- https://www.rfc-editor.org/rfc/rfc8342.html
- https://www.rfc-editor.org/rfc/rfc6241.html
- https://www.rfc-editor.org/rfc/rfc8040.html
- https://www.iana.org/assignments/yang-parameters
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
