Summary

  • draft-ietf-netmod-yang-module-filename-15 recommends a YANG Semver filename when a revision carries ysv:version, permits revision-date and unversioned aliases, and requires aliases for the same revision to be byte-for-byte identical.
  • The module body remains authoritative. Repository names, matching hashes, symlinks and registry entries prove discovery or identity only; selection, loading, effective schema, instance compatibility and deployment outcome require separate records.

Imagine a repository containing an unsuffixed edge-policy.yang file alongside revision-date-suffixed and semantic-version-suffixed aliases. Their SHA-256 values match. The semantic-version name agrees with the newest revision statement. A registry lists both dated and versioned forms. Every visible check is green.

One question remains unanswered: which path did the controller open?

That gap is the operational centre of the YANG Module File Name Convention. Revision 15 was posted on 20 August 2026. The IETF Datatracker lists it as an active NETMOD Internet-Draft, intended for the Standards Track and currently in the RFC Editor queue. It is still work in progress. Its proposed convention is precise, but its precision belongs to publishing and discovery. It does not silently extend to runtime selection.

The body outranks the label

For a revision with ysv:version, the draft says a file using that semantic version in its name should be created. Files with the revision date or no suffix may also exist. The form permits a module or submodule name followed by an at-sign delimiter and either a YANG Semver identifier or revision date, ending in .yang or .yin.

The strongest requirement is also the easiest to misread. The semantic version in the filename must match the version in the latest revision statement, yet the draft immediately says the module contents are authoritative. The filename is a quick index. It is not a second source of truth.

This matters because valid YANG Semver identifiers carry more than three digits. A name may include _non_compatible, pre-release material, build metadata or a competing-draft label. Two branches can share 2.0.1 while their full identifiers differ. Stripping the suffix to fit a package browser destroys evidence that the convention was designed to preserve.

The byte-identity rule has a similarly narrow force. If the three names represent the same revision, their contents must be identical byte for byte. Hash comparison can demonstrate that. It cannot demonstrate that the version classification was correct, that every dependency was resolved, or that a process used any of those bytes.

Discovery is not selection

A directory listing proves that a path was visible to the observer at a time. A symlink proves a namespace relation and, after resolving it, perhaps a target. An IANA or package-registry row proves what the registry published. A matching digest proves identity of the captured byte streams. None records the search path, precedence rule, cache, embedded resource, container layer or command-line override used by a particular tool.

The draft acknowledges this boundary. Legacy systems and deployed tools may not handle the convention, and declining to use it can be acceptable. Tooling may need updates; symlinks are offered as one migration technique. A symlink can help old and new names coexist, but it does not make an old parser understand semantic-version syntax or prove that a sandbox, archive exporter or remote loader followed the link.

A defensible selection record therefore names the tool and version, exact configuration, ordered search paths, every candidate considered, the precedence decision, the final canonical path and the digest read. A successful exit code without that trace shows only that the tool completed.

One module is not the effective schema

The loaded object is larger than one file. RFC 8525 describes a datastore schema as the union of module sets. Those sets identify implemented and import-only modules, submodules, locations, enabled features and deviations. A module set need not be referentially complete, while a datastore schema must satisfy all imports.

Consequently, two controllers may hash the focal file to the same value and still compile different schemas. One may locate a newer imported typedef module. Another may enable a feature, apply a vendor deviation or attach the module under a different schema-mount context. A third may use the same repository but an earlier cached dependency.

YANG Library helps describe the server side. Its content-id must change when represented library information changes, but it is implementation-specific; equal information need not yield the same value on different servers. It is a change detector, not a universal cross-party digest. Bilateral proof needs the expanded module, submodule, feature and deviation sets from both sides, tied to the session and datastore that matter.

This article does not repeat the schema-comparison algorithm covered elsewhere. A compatibility classification can be one input to the record. It cannot substitute for identifying the inputs or observing consumer behaviour.

Validation is not deployment

Parsing the selected module proves syntax under one tool. Compiling a referentially complete schema proves more. Validating representative instance data proves that those examples conform. Client/server integration tests add protocol behaviour. Mixed-version rehearsal adds rollout evidence. Runtime telemetry and service indicators finally address operational and business results.

Each step has a different object. A valid file is not a valid dependency closure. A valid closure is not the same closure on both endpoints. Schema-valid data may still lose intended meaning, trigger different defaults or meet changed access control. A successful canary does not establish that every cohort received the same artifact, or that rollback can reconstruct the previous schema and data together.

The evidence chain should remain explicit: discovery; byte identity; body declaration; classification basis; dependency resolution; tool selection; load event; effective schema on both endpoints; instance and behaviour tests; rollout order; runtime state; external outcome. Collapsing those stages makes an attractive filename bear responsibility it never accepted.

What the draft’s validator does—and does not—say

The Datatracker currently shows two errors and two warnings for the extracted example module. The visible tool output says the ysv prefix is not defined in that extraction. That is evidence about revision 15’s current document example and validation context. It is not evidence that a vendor implementation has failed, nor that the naming convention is deployed.

The same restraint applies in the other direction. Entry into the RFC Editor queue does not turn a draft into a runtime fact. A registry update does not prove repository synchronisation. Matching filenames do not prove interoperability. Standards status and deployment evidence must keep separate columns.

Primary sources

The closed primary-source set comprises revision 15, its Datatracker record and history, Updated YANG Module Revision Handling revision 17, YANG Semantic Versioning revision 28, RFC 7950, RFC 8525, RFC 9907 and IANA YANG guidance revision 03: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-filename-15; https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/; https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/history/; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-17; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-28; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc9907.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-iana-yang-guidance-03.