Summary

  • draft-ietf-netmod-iana-yang-guidance-03 describes how a normative YANG module would move from an IESG-approved prerelease through controlled RFC Editor changes, final revision and YANG Semver selection, repeat validation, and near-synchronous RFC/IANA publication.
  • Exact RFC and IANA bytes would be a strong publication receipt, but not proof that editing preserved meaning, a version bump was correct, a client fetched those bytes, a device loaded them, or running behaviour remained compatible.
  • IETF-published modules and IANA-maintained modules derived from companion registries follow related but distinct update paths; neither registry publication nor tool success is an operational attestation.

Imagine two glass cases opening at almost the same moment. One is labelled by context as the RFC publication; the other is the IANA YANG Module Names copy. The artifacts inside have the same bytes. That symmetry is deliberate, and valuable. It prevents an operator from having to guess which publisher owns the final edition.

But the matching cases stand at the end of a publishing process, not at the end of a deployment process. They can show that two publication surfaces agree. They cannot show what happened in the editor's reasoning, a client's cache, a server's loader, an effective schema, a datastore or a packet path.

That distinction is the real news in revision 03 of Guidance for Managing YANG Modules in RFCs and IANA Registries. The live Datatracker record checked on 11 September lists an active NETMOD WG Internet-Draft, revision 03, with WG Document, I-D Exists and intended status Informational. Its text is dated 6 July 2026 and expires on 7 January 2027. Datatracker's “Last updated” date of 27 August records shepherding-AD and intended-status metadata changes; the latest document revision remains 6 July. The draft has not become an RFC, and none of its proposed handoffs should be reported as a completed production event.

The prerelease marker preserves editorial room

The proposed chain starts at a useful moment: IESG approval would normally find normative modules still carrying prerelease identifiers, such as a zero-major version or a release candidate with a draft-number suffix. That is not untidiness. It says the content has not yet acquired the immutability expected of a published revision.

During RFC Editor processing, descriptions may be clarified without changing meaning, draft references may be replaced by final RFC numbers, typographical faults may be corrected and formatting standardized. Revision 03 draws a jurisdictional line around that work. Editorial changes may proceed as normal; substantive changes require coordination with the authors. If a description might change semantics, or a BC/NBC classification is unclear, the document sends the case to additional human review.

Before publication, the final revision date is set, the prerelease indicator is removed, and the release YANG Semver is chosen. A previously published module also needs comparison with its previous version and, where appropriate, the rev:non-backwards-compatible marker. If later editing changes the module again, the version decision must be revisited. The final identifier is therefore a recorded judgment about the final candidate—not evidence that the judgment was infallible.

Validation is scoped to bytes, dependencies and tools

Revision 03 recommends rerunning validation after editing and formatting, normally with both pyang and yanglint. It also insists on the correct dependency set. Modules published together may need to be extracted and checked together; a clean result against a convenient but different dependency directory answers the wrong question.

The draft is unusually candid about the limit. Tools cannot always decide whether a description change merely clarifies meaning or changes it. Update comparison may find known NBC cases without proving an exact semantic-version choice for every possible change. Bugs and unhandled edge cases can produce false positives or false negatives. A prerelease predecessor may prevent an automatic next-release recommendation. Unexpected output is a reason to ask for review, not a licence to let automation invent intent.

So “no warnings or errors” is a precise receipt: this tool version accepted these bytes with these dependencies and flags. It is not a receipt for semantic preservation, complete compatibility or correct deployment.

IANA waits for final bytes, then publishes beside the RFC

The draft asks IANA not to publish the normative module until RFC Editor work is complete. Once finalized, the RFC would carry the module and IANA would publish the corresponding version in the YANG Module Names registry at approximately the same time. The goal is exact agreement and correct final references.

This is publication concurrency, not distributed execution. To substantiate it, an auditor would retain the extracted RFC bytes, the IANA object, their digests, retrieval times and final revision/version metadata. Even perfect equality would say nothing about a mirror observed earlier, a client's cached unsuffixed URL, package resolution, the server's advertised YANG Library set, process load, feature and deviation selection, instance-data migration or runtime behaviour.

The nearby BTW work on YANG filenames owns alias and loader-selection evidence; schema comparison owns ED/BC/NBC diff classification; module versioning owns branches and ancestry; packages own recursive composition. This draft's separate contribution is the controlled handoff that freezes one publication candidate and makes two publication surfaces agree.

Registry-derived modules follow another clock

Revision 03 then changes branches. An IANA-maintained module is not simply a second copy of an IETF module. It is a machine-readable projection of a companion registry, commonly built from enumerations or identities. New values enter the authoritative companion registry first; IANA then identifies the registry delta, applies the corresponding module change, sets a new revision and version, checks its classification, validates it, and publishes version- and date-addressable artifacts.

That workflow creates another bounded receipt. A revision can show that a documented registry change was represented in a particular module edition. It cannot prove that the projection was continuously fresh before or after the check, that every mapping was complete, or that a consumer retrieved and loaded it. RFC 9907's unique-registry and freshness problem remains distinct from this draft's handoff mechanics.

The evidence chain continues after publication

A defensible closeout keeps at least nine records separate: the approved draft candidate; every RFC Editor change and consultation; final revision and Semver judgment; exact validation inputs and tool versions; extracted RFC bytes; IANA-published bytes and retrieval time; client retrieval and cache provenance; device load and advertised effective schema; and observed datastore, protocol and service behaviour.

Heng Lu's Running-Code Primacy supplies the interpretive discipline, not a claim about IETF intent: a coordination artifact can describe a compatibility target without making adoption real. Minimum Initial Specification reinforces the useful part of the draft—the publication contract is narrow, deterministic where possible and locally checkable. Reality, Not Advocacy and Reality Layers require the account to stop at the last observed layer.

Two matching publication copies are therefore not trivial. They remove one ambiguity that should never reach operators. Their strength comes from refusing to certify the rest.

Sources

  1. Revision 03 text
  2. Live Datatracker record
  3. Datatracker history
  4. RFC 9907
  5. RFC 9890
  6. RFC 7950
  7. YANG Module Versioning revision 17
  8. YANG Semantic Versioning revision 26
  9. YANG Schema Comparison revision 09
  10. YANG module filename revision 14
  11. IANA YANG Parameters
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality, Not Advocacy
  15. Heng Lu — Reality Layers