Summary

  • draft-ietf-netmod-yang-versioning-reqs-14 defines five groups of obligations for a future versioning solution and explicitly neither considers nor endorses a solution.
  • Requirement coverage, WG Document status and I-D Exists are documentary receipts. They do not prove classification accuracy, old-client protection, node availability, lossless migration, interoperability or safe deployment.

An architecture review opens a spreadsheet with five green rows. Non-backwards-compatible updates: covered. Compatibility labels: covered. Existing clients: covered. Retired nodes: covered. Migration: covered. The evidence column contains citations to Section 5 of a twelve-page Internet-Draft.

The review has confused the test plan with the test result.

Revision 14 of YANG Module Versioning Requirements, dated 20 July 2026, is useful because it prevents that confusion when read on its own terms. Its masthead says Informational. Datatracker lists it as an active NETMOD WG Internet-Draft, a WG Document whose IESG state is I-D Exists. Its abstract is unusually explicit: the document describes problems, defines requirements on any solution, and does not consider or endorse a particular solution.

The first gate is change without synchronized renaming

The first group asks for a way to make an NBC update without forcing every importing module to change at the same time, while protecting clients that touch only unchanged or compatibly changed nodes. It also asks for an import constraint between “any revision” and one exact revision, and for incompatible steps to be expressible.

Those clauses define four separate acceptance questions. A proposal can avoid a module rename yet still resolve the wrong dependency. It can mark an NBC step yet misclassify the change. It can compile every importer while exposing an older client to a value, default or behavior it cannot handle. A serious receipt therefore records the before-and-after artifacts, complete import/include closure, resolved effective schema and the exact clients exercised. No single label closes all four.

Classification needs provenance, not just a category

The second group requires readers and tools to distinguish BC from NBC changes and recommends node-level comparison between arbitrary revisions. The background explains why syntax alone may be insufficient: semantic behavior can change while the YANG statements remain the same, leaving a human model designer to judge the consequence.

A candidate scheme should therefore be assessed twice. First, can it carry a classification in a stable, attributable form? Second, was that classification correct for the actual pair and context? Preserve the compared bytes, comparison policy, feature and deviation context, human overrides, warnings and reviewer. A parser accepting the marker proves legibility, not truth.

Old clients and retired nodes are target facts

The third group requires a mechanism for servers to support existing clients, including clients expecting an older module after NBC change. The fourth requires clients to discover whether deprecated nodes are implemented, document alternatives and reasons, and receive an early warning while a soon-obsolete definition is still implemented.

These are operating obligations. Test an old client against a new server and a new client against an old server. Exercise reads, writes, RPCs, notifications, errors and access roles with exact binaries, modules, features and deviations. For retired nodes, compare the advertised policy with the effective schema and probe representative behavior before and after reboot. A declaration can narrow uncertainty; it cannot manufacture node availability.

Migration is an accounting exercise

The fifth group requires guidance, a transition path from YANG 1.0/1.1 and an explanation of how NBC schema change affects instance data and references. Documentation can describe a mapping. It cannot show that one execution preserved meaning.

RFC 9195 makes the boundary concrete. Instance data can identify its content-schema, yet usability under another schema depends on revisions, features, deviations, scope and compatibility. A migration receipt must count renamed, dropped, synthesized, defaulted and rejected values, test semantic invariants and demonstrate rollback readability. Passing validation is only one line in that ledger.

The requirements draft has no new protocol or data model. Its five groups should be used as an acceptance matrix whose cells remain open until the relevant proposal, tool, server, client and migration supply evidence. Related work on revision histories, Semver, packages, schema comparison, filenames and YANG 2.0 may answer parts of the matrix. Their existence beside this draft does not answer it automatically.

That is not a weakness. A good requirements document resists premature victory. It names the promises so that a later implementation cannot substitute document status, a green validator or a familiar label for the behavior operators actually depend on.

Primary sources

The frozen official set includes revision 14, its Datatracker record and history, the NETMOD document list, RFC 2119, RFC 6020, RFC 7950, RFC 8049, RFC 8299, RFC 8525 and RFC 9195.