Summary

  • The IESG announced on 18 August 2026 that draft-ietf-netmod-yang-semver-28 had been approved for publication as a Proposed Standard. It adds a semantic-version identifier for YANG modules and optional version information in YANG Library, making compatibility claims and lineage easier for tools to consume.
  • The number classifies a relationship between module artifacts. It does not prove that a target server exposes a coherent module set, enables a required feature, applies no conflicting deviation, implements the expected behavior or authorizes a production change. Admission must join the version signal to the target’s exact schema context and running evidence.

The threshold passed before the target was examined

The opening is a hypothetical control failure, not a reported incident or vendor defect. It matters because recommended-min-version is designed to be useful without becoming a strict lock. A consumer can state the oldest preferred compatible version, and a compiler can compare the advertised numeric triplet. That is a valuable selection signal.

But the comparison deliberately ignores the compatibility modifier and prerelease or build metadata. A higher major version satisfies the numeric minimum. A version carrying _non_compatible can also satisfy it. If no viable version is found, the specification says a compiler should warn and continue with ordinary YANG import resolution rather than turn the hint into an absolute dependency gate.

The result is not a contradiction. The field says where a consumer would prefer resolution to begin. It does not certify the selected target. A controller that converts “minimum satisfied” into “change admitted” quietly invents authority the field was never given.

Approval makes lineage machine-readable

The IESG approval covers version 28 of “YANG Semantic Versioning.” The document is still an Internet-Draft while it waits in the RFC Editor queue. It is a NETMOD working-group product, and the announcement records overall consensus with some roughness as well as tooling under development.

The proposal defines ysv:version, using X.Y.Z_COMPAT with optional prerelease and build metadata. A major increment normally identifies a non-backwards-compatible change; a minor increment normally identifies a backwards-compatible addition; a patch increment identifies a backwards-compatible editorial change. The vocabulary makes an author’s compatibility classification visible without requiring every consumer to infer it from a date-like revision string.

The identifier also helps establish artifact identity. A module name and semantic version together identify one particular revision and content. Version history can express ancestry more precisely, and optional YANG Library leaves can expose the module version a server says it implements.

That is a real improvement in software supply-chain legibility. It reduces ambiguity about which artifact a dependency, package or device is referring to. The improvement is strongest when the number remains evidence about that artifact rather than being promoted into a warranty about every environment that consumes it.

Compatibility is an author’s classification of a change

Semantic versions are assigned by the module’s authors or maintainers. The specification gives them rules, but it also permits a more significant increment than the minimum and allows versions to be skipped. The number therefore communicates a maintained lineage policy; it is not a measurement produced by the target server.

The document is unusually explicit about the boundary. A version number does not guarantee that the described change occurred, nor that a particular consumer is affected by it. Determining the concrete differences between two schemas belongs to schema comparison. Determining whether a workflow, device or service behaves correctly belongs to implementation and instance testing.

That separation becomes important around augmentations, imports and deviations. A module may change compatibly in isolation while a consuming schema set changes because another module augments it. A target may disable an optional feature on which the workflow depends. A deviation may remove, replace or constrain a node. The source module’s version can remain perfectly truthful while the effective target schema does not meet the consumer’s assumption.

Compatibility is therefore scoped: compatible according to the documented rules for this artifact lineage. Operators should resist the much broader reading “safe for this device, configuration and production objective.”

A broken branch leaves a visible scar

The _compatible and _non_compatible modifiers address limited development branches between ordinary releases. They are not casual annotations. Once _non_compatible appears within the same major and minor branch, later versions in that branch cannot make it disappear or relabel the line as compatible. The modifier is sticky because later editorial motion cannot erase the fact that the branch crossed a compatibility boundary.

This is valuable history. It prevents a sequence from laundering a known incompatible step into a superficially clean progression. It also shows why consumers must retain the complete identifier rather than normalize everything to three integers.

Yet recommended-min-version compares only those integers. That choice preserves loose coupling and allows resolution to proceed, but it means the recommendation cannot double as an admission verdict. A system that wants to reject an incompatible modifier must say so in its own policy and test the selected artifact; it cannot pretend the minimum field already made that decision.

A server advertises a version inside a larger schema set

YANG Library describes much more than a single version leaf. A datastore schema is assembled from a module set: module names and revisions, imported-only modules, submodules, enabled features, deviations and locations. The semantic-version extension can add useful version information to that record, but it does not replace the record.

The versioning draft likewise says responsibility for constructing a coherent module set is outside the extension’s scope, pointing to adjacent work such as YANG packages. That caveat is operationally decisive. Two servers can advertise the same version of one module and still present different effective schemas because their surrounding modules, features or deviations differ.

RFC 8525 gives clients a way to discover the target’s schema inventory. RFC 7950 defines how modules, features, imports, augmentations and deviations produce the usable model. RFC 9907 improves revision-label handling, but labels still describe artifacts rather than exercising a deployment. Each layer narrows uncertainty; none abolishes the need to inspect the target actually receiving the change.

Impact belongs to the compiled target

Before admission, automation should resolve the exact target module set and build the effective schema, including imports, submodules, augmentations, enabled features and deviations. It should then compare the effective before-and-after schemas, validate intended instance data and run implementation tests against the device software and configuration class in scope.

The distinction is not academic. Removing a node is an obvious incompatibility, but a changed constraint can reject existing data; a feature switch can make an expected path absent; an augmentation can introduce a mandatory child from another module; a deviation can alter type, default or availability. Behavior outside the schema can also change even when the data tree remains compatible.

Running-code evidence should therefore be target-specific. A passing compiler test proves that a set of artifacts can be assembled under that compiler. A lab test proves behavior for a software build and configuration. A canary proves a bounded production slice. None alone proves the whole fleet, but together they create a defensible chain from lineage claim to operational consequence.

Automation needs an admission chain, not one comparison

A safe controller records the requested module and constraint, the resolved artifact and full semantic version, the target YANG Library snapshot, the compiled effective-schema hash, schema-comparison result, instance-validation result, implementation-test evidence, target software and configuration class, and the person or policy authorized to accept residual risk.

It should fail differently for different evidence gaps. An unsatisfied recommendation is a dependency warning. An incompatible modifier is a lineage-policy question. A missing feature or conflicting deviation is a target-schema failure. A behavioral regression is an implementation failure. Missing approval is a governance failure. Collapsing all five into “version mismatch” makes diagnosis weaker and encourages unsafe overrides.

The number deserves a place early in the chain. It can reject obviously unsuitable candidates, improve dependency selection and make change history auditable. It should not occupy the final gate. That gate belongs to evidence about the compiled target and to the owner who bears the consequence of changing it.

Sources