Summary

  • The IESG announced on 18 August 2026 that draft-ietf-netmod-yang-module-versioning-17 had been approved for publication as a Proposed Standard. It permits documented non-backwards-compatible module evolution, adds recommended-min-date for imports and exposes how servers handle deprecated and obsolete nodes.
  • The draft’s own branched-history example shows the limit of chronological admission: a 2019-05-01 revision satisfies a 2019-04-01 minimum even though it may not contain what the 2019-04-01 branch introduced. A date threshold orders artifacts; it does not prove descent, effective target schema or authority to deploy.

The date gate admitted the sibling

The opening is an analytical construction based on the document’s example, not a reported device or network incident. The resolver is doing exactly what recommended-min-date defines. It selects a revision whose date is equal to or later than the recommendation.

The difficulty is structural. After a common 2019-02-01 revision, the example divides. One branch advances through 2019-03-01 to 2019-05-01. The other advances through 2019-04-01 to 2019-06-01. A consumer that needs something introduced at 2019-04-01 can set that date as its recommended minimum. Numerically, 2019-05-01 passes. Genealogically, it is on the other branch.

The draft states the consequence directly: the 2019-05-01 revision may not contain what is desired from 2019-04-01. The field is not well suited to a branched revision history and is most useful for a linear chronology.

This is not a defect in date comparison. It is a category error in the admission policy. “Later than” describes position on a calendar. “Derived from” describes a path through a graph.

Approval makes incompatible evolution visible

The IESG approved version 17 of “Updated YANG Module Revision Handling” four minutes after the companion semantic-versioning action on 18 August. The document is a NETMOD product and remains an Internet-Draft in the RFC Editor queue. The approval notice says implementation status is unknown.

RFC 7950 required strict backwards-compatible module updates. The new work recognizes that incompatible changes sometimes occur: a bug fix may need to match real server behavior, obsolete nodes may be removed after transition, unstable material may need refinement, or a compatible restructuring may cost more than its benefit.

Such changes remain discouraged. When a revision contains a non-backwards-compatible change relative to its parent, the new rev:non-backwards-compatible statement must appear under that revision. The marker turns a previously silent edge into reviewable evidence.

That is a significant improvement. It allows tooling to distinguish “a new revision exists” from “the edge into this revision crossed a compatibility boundary.” It still does not tell a resolver which branch contains the capability it needs unless the resolver also follows the history.

An immutable revision can live in a branching history

Within its history, a module name and revision date identify a specific immutable module definition. That gives the date a strong identity function. It does not give the date a lineage function.

The document says ancestry between two module or submodule revisions cannot be determined by comparing their dates or version identifiers alone; the revision history must be consulted. Two revisions can even have identical content except for the history when the same change is applied on multiple branches.

Submodules expose a related boundary. If an include statement does not constrain the exact submodule revision, the including module alone cannot prove which submodule content was used. Exact revision-date, YANG Library or a package inventory must close that gap.

An admission record therefore needs more than the selected date. It needs the exact artifact hash, its parent or branch path, included submodule revisions and the target’s resolved module set. Otherwise an immutable identifier can still be interpreted inside the wrong family tree.

The minimum date deliberately avoids a hard pin

recommended-min-date is a substatement of import, with zero or one allowed per import. Adding, changing or removing it is itself classified as backwards-compatible. If a parser ignores it, ordinary RFC 7950 import resolution continues.

The draft recommends this looser suggestion over an exact import revision-date when a dependency floor is useful, because an exact date creates an overly strict dependency. That is a practical trade: consumers can benefit from later compatible work without being frozen to one artifact.

Loose coupling requires a separate suitability check. The field asks for a revision on or after a date. It does not ask whether the selected artifact descends from the particular revision, retains a named node, includes a sibling-branch change, exposes the same default or remains acceptable to the client.

Exact pinning and a date floor are not the only choices. Automation can use a date to find candidates, then test ancestry and effective schema. Treating the preference as the final gate discards the flexibility benefit while keeping the uncertainty.

The incompatibility marker belongs to an edge

rev:non-backwards-compatible qualifies a revision relative to its parent. It can warn that a node was made obsolete, a constraint changed or another permitted incompatibility occurred. It cannot certify every relationship between that revision and every other point in a branched history.

This matters when evidence is compressed. A dashboard may show the newest date and whether that row carries a warning. But the capability a client depends on may have been introduced on another branch. The absence of a warning on the selected row does not create an ancestry edge.

The document also permits maintainers to add the marker even for a change that is formally compatible when they judge the client impact significant, such as widening the value space of an operational leaf. The signal is intentionally conservative. It is an invitation to examine the actual difference, not an automatic reject or accept instruction.

Schema-comparison tooling belongs beside the marker. The marker identifies an edge that deserves attention; comparison describes what the edge changed; target tests show whether the client and server can operate together.

History can be shortened only without falsifying the remaining edges

Maintainers may remove some published revision statements, for example to shorten a long history or discourage an old import. They must not remove the newest entry, and any remaining non-backwards-compatible markers must still describe their relationships to preceding retained entries accurately.

The draft warns that pruning can remove visibility into when incompatible changes were introduced and recommends retaining old statements. Its example prohibits removing one entry when doing so would make a later revision appear compatible with older revisions across a hidden incompatible step.

This makes history retention part of operational evidence. A resolver cannot prove ancestry from a record that no longer preserves the relevant edge. Where history is curtailed, artifact repositories, package manifests, signed hashes and change records become more important—not as substitutes for the standard, but as the retained chain needed for a decision.

The governance risk is subtle. Storage pressure or cosmetic simplification can erase the very evidence used to justify automated admission. History policy therefore affects production risk even when no module body changes.

Node status remains a target-specific fact

The new ietf-yang-library-status module adds two booleans. deprecated-nodes-implemented set to true means deprecated nodes behave as current unless a deviation explicitly removes them. obsolete-nodes-absent set to true means the server implements no obsolete nodes.

Both default to false, and false means the behavior is unspecified. The draft recommends that servers set both true so clients can know the exact schema. If the deprecated-node statement is not true, clients must not rely only on incompatibility markers when deciding whether two revisions are compatible.

This is another reason a revision date cannot finish admission. A client may select the intended branch and still face a target that has already dropped a deprecated node or retains an obsolete one. A deviation can further change the result.

Lifecycle guidance reduces surprises: move from current to deprecated before obsolete; state replacements and support horizons where known; clients should plan to stop using deprecated nodes and must stop using obsolete ones. The transition is an operating process, not a property inferred from the calendar.

Admission needs a graph and a running target

A defensible controller records the requested capability and the revision where it appeared. It resolves the exact artifact, proves a parent path from that revision, preserves incompatible edges and history gaps, pins included submodules, captures YANG Library and the two node-status declarations, applies deviations, compiles the effective schema and validates representative data.

It then tests the client against the actual server software and configuration class. Incompatible revisions can expose values beyond an older client’s assumed range, alter defaults or require changes to NACM rules. A clean date comparison cannot observe those effects.

Failures should remain distinct. A later artifact on the wrong branch is a lineage failure. A missing deprecated-node declaration is a target-discovery gap. A changed tree is a schema failure. An out-of-range value or different default is an implementation consequence. Missing approval is a governance failure.

The date remains useful. It narrows a repository search and documents a preference without over-pinning imports. Its proper authority is candidate selection. Descent, target evidence and an accountable owner decide whether the candidate enters production.

Sources