Summary

  • draft-ietf-netmod-yang-module-versioning-17 explicitly permits non-linear module and submodule histories. A revision date identifies an immutable revision; it does not establish ancestry, ordering or compatibility.
  • rev:non-backwards-compatible, rev:recommended-min-date and the YANG Library status booleans are bounded declarations. Safe use still requires the revision graph, effective schema, server behavior, client execution, instance migration, rollout and rollback to be observed separately.

A controller sees two revisions of the same YANG module. The first is dated April; the second is dated May. An import recommends April as the minimum. The May revision therefore looks newer, eligible and safe. Yet the May file was cut from another branch and never inherited the grouping introduced in April. The date test passes while the dependency fails.

That is the quiet but consequential change in revision 17 of Updated YANG Module Revision Handling. The draft, posted on 29 June 2026 and still an Internet-Draft rather than an RFC, stops pretending that a date is a lineage. It allows two independent revisions of a module or submodule to derive from the same parent. Revision dates remain unique identifiers, but the document explicitly removes any implied ordering or backwards compatibility from them.

A history becomes a path through a graph

Under a linear mental model, later dates appear to inherit everything before them. A branch breaks that inference. Each revision carries the path from which it was derived, not a catalogue of every revision on every branch. The draft is blunt: ancestry cannot be determined from revision dates or version identifiers alone; the revision history must be consulted.

Even that history is not necessarily complete. Authors may remove older entries under rules that preserve the remaining compatibility relationships. They may trim the oldest contiguous sequence, and in some cases remove intermediate entries, but they must not create a false picture of where an incompatible step occurred. The newest entry cannot be removed. These rules protect the meaning of the surviving record, not the existence of a full repository graph.

For an operator, the evidence object is therefore larger than the module header. It includes the exact bytes of every revision, the source repository or archive, commit ancestry, removed-history record and included submodule identities. A module that includes submodules should pin their revision dates; without that, the including module alone cannot reveal which submodule content was used. A tidy revision list is a useful authored view. It is not a complete chain of custody.

The NBC marker is an assertion with a defined direction

The draft relaxes the old rule that published updates must always be backwards-compatible. New revisions still should not introduce non-backwards-compatible changes, because those changes can break clients and importers, but the procedure allows them for reasons such as correcting a defect, retiring an old node or restructuring an unstable model.

When a revision contains a change that violates the updated backwards-compatible rules relative to its preceding revision in that history, it must carry rev:non-backwards-compatible. When the marker is absent, the changes must be backwards-compatible. This gives reviewers and tooling an important alarm boundary.

It is not an automatic classification report. The author decides whether the rule applies and can even add the marker conservatively where a formally compatible expansion may still have serious client impact—for example, a larger value space on operational data. Conversely, a missing marker is only as reliable as the change review and the accuracy of the retained history. The record should bind the old and new bytes, enumerate changes, cite the classification rule and name the reviewer. The schema-comparison algorithm belongs to a separate specification and is not reproduced here.

A minimum date is not a branch constraint

RFC 7950 lets an import name one exact revision-date. Without that substatement, the language does not define which revision supplies imported definitions. Exact pins can be too rigid for loosely coupled modules, so revision 17 introduces rev:recommended-min-date: a machine-readable suggestion for the earliest revision expected to satisfy a dependency.

The word “recommended” does real work. A tool may warn when the chosen revision is older, but the extension neither changes import behavior nor changes YANG conformance. More importantly, the draft’s own example shows that a later-dated revision on another branch may not contain what the minimum revision introduced. The mechanism is most useful for linear chronological histories and is explicitly ill-suited to branches.

A defensible resolver receipt must therefore show more than chosen_date >= minimum_date. It should identify the chosen revision, prove that it descends from the required revision or otherwise contains the required definitions, resolve every imported symbol under the actual feature and deviation context, and hash the resulting schema. Passing the date predicate is admission to inspection, not proof of dependency satisfaction.

Two booleans narrow ambiguity, not reality

The draft also defines ietf-yang-library-status, augmenting the RFC 8525 YANG Library schema with two read-only booleans. deprecated-nodes-implemented=true means deprecated nodes are implemented as though current unless a deviation explicitly removes them. obsolete-nodes-absent=true means no obsolete nodes are implemented. When either value remains at its default false, behavior is unspecified.

Setting both true gives a client a clearer advertised schema. If the deprecated-node value is not true, the draft tells clients not to rely on NBC markers alone, because a node may have become deprecated and the server may no longer implement it. That is a valuable disclosure rule.

But an advertisement is still produced by the server being assessed. It does not execute a read, write, RPC or notification against every retired node. It does not prove that deviations were loaded, that a reboot preserved the same schema, or that all management protocols expose the same behavior. Verification must sample the actual node surface, record errors and defaults, and compare the reported YANG Library set with the schema the process actually loaded.

The client and the data get separate votes

Revision 17 anticipates client failure. A server using an NBC revision may return a value valid under its schema but outside the constraints compiled into an older client. The guidance calls for defensive handling, monitoring revision histories and understanding the specific NBC change before migration. Clients should move away from deprecated nodes and must stop using obsolete ones.

None of those actions is evidenced by a label. Test the old client against the new server and the new client against the old server. Exercise parsing, canonical encodings, defaults, RPC inputs, notifications, error handling and access-control roles. Record the exact client and server binaries, schema sets, enabled features and deviations.

Persistent instance data is another boundary. RFC 9195 can bind instance data to a content-schema, but successful validation under a target schema does not show that a conversion preserved meaning. A migration receipt should count renamed, dropped, synthesized, defaulted and rejected nodes, test semantic invariants, and prove that rollback can still read the state written by the new version.

Finally, RFC 8342 separates running, intended and operational datastores because configured state, applied intent and observed behavior can diverge. A successful import and a green schema validator cannot show that the device applied the desired state, that mixed-version peers interoperated, or that service-level results held.

Revision 17 improves the accountability of module evolution by making forks, incompatible steps, loose dependency advice and old-node policy visible. Its precision is best preserved when each declaration closes only its own question. Dates identify. Histories describe one ancestry path. NBC markers warn. Minimum dates guide. YANG Library reports. The running client, migrated data and observed network must supply the rest.

Primary sources

The frozen official source set comprises Updated YANG Module Revision Handling, revision 17, its Datatracker record and history, YANG 1.1, RFC 7950, YANG Library, RFC 8525, Guidance for IETF YANG Modules, RFC 9907, NMDA, RFC 8342, NACM, RFC 8341, YANG Instance Data, RFC 9195 and YANG Module Versioning Requirements, revision 13.