Summary

  • YANG 2.0 is designed to coexist with YANG 1 and 1.1. Its import rules are deliberately asymmetric: a 2.0 module may import an older module by revision, while an older module may not import a 2.0 module by revision.
  • A special unversioned-import rule can keep an old module A beside an upgraded module B and avoid a cascading rewrite. Advertisement of that combination still does not prove client revision binding, a common effective schema, compatibility, interoperability, or production adoption.

Imagine the maintenance window. Module B has been revised in YANG 2.0. Module A, still written in YANG 1.1, imports B without naming a revision. The server starts, both names appear in its advertised inventory, and the change dashboard turns green. Nothing in that sequence is necessarily wrong. The error begins when “the modules coexist” is promoted into “every client sees the same schema” or “the upgrade is compatible.”

The distinction matters because the current YANG 2.0 work explicitly tries to prevent one language upgrade from forcing a whole dependency graph to move at once. The revision 00 draft, dated 6 July 2026, says YANG 2.0 does not obsolete RFC 6020 or RFC 7950 and that a complete model may mix language versions. The IETF Datatracker records it as an active NETMOD working-group Internet-Draft. Its header proposes Standards Track status, but it remains a draft, not an RFC and not evidence of implementation or deployment.

The asymmetry is the migration design

Section 12 draws a directional boundary. A YANG 2.0 module must include only 2.0 submodules. A YANG 1 or 1.1 module must not include a 2.0 submodule. Likewise, an old-language module or submodule must not import a 2.0 module by revision. The reverse is permitted: a 2.0 module or submodule may import a YANG 1 or 1.1 module by revision.

That is not a symmetrical compatibility promise. It is a controlled migration topology. New code can reach backward to a named older dependency; old code cannot declare a revision-pinned forward dependency on the new language.

The draft then handles the awkward but common case in which old module A imported B without a revision and B is later updated to 2.0. A server may implement A and B at the same time. It must advertise the modules under the implementation rules and should advertise A together with the latest B revision expressed in YANG 1 or 1.1. The stated purpose is anti-cascade: without the exception, moving B to 2.0 could force A, every importer of A, and then their importers to be rewritten in turn.

This is valuable restraint. It keeps a language transition from becoming an all-at-once institutional command. It resembles the discipline in Lu Heng's note on Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption: establish the minimum shared rule, then leave later adoption to participants that can validate and operate it. But restraint changes the burden of proof. Once multiple language generations can legitimately coexist, the operator must show which combination each participant actually used.

Advertisement is a claim with a defined scope

The draft's implementation section says a server must not implement more than one revision of a module. It also distinguishes an implemented module from an import-only module used for typedefs or other schema material. RFC 8525 gives that distinction a richer inventory: module sets, implemented and import-only modules, features, deviations and an identifier that changes when the library content changes.

Those records are essential. They can establish what a server declared at a moment in time. They can show that A was present, which B revisions were listed, whether a revision was implemented or import-only, and which features and deviations the server reported. They cannot, on their own, establish what bytes a client fetched, how its resolver satisfied A's unversioned import, whether two parsers built the same schema tree, or whether a running client used the advertised state it had just read.

This is the article's narrow boundary with adjacent YANG work. Module-version labels improve revision identity. Semantic-version expressions can constrain acceptable updates. Packages can describe a coherent set. Schema comparison can classify changes. A filename can help a human locate a candidate source. None of those artifacts, separately or together, substitutes for evidence of the exact resolution, compilation and runtime path. They answer useful questions; they do not answer this one by vocabulary alone.

The evidence ladder after coexistence

An upgrade claim should therefore climb a sequence that cannot be collapsed into one green status:

  1. Source identity. Preserve the exact module and submodule bytes, provenance, namespace, language version, revision and content hash. A revision label is not the file.
  2. Dependency resolution. Record the complete import/include closure and, especially, the resolver decision for every import that omitted a revision. This is where A can bind differently across toolchains.
  3. Server declaration. Capture the complete YANG Library snapshot, conformance roles, features, deviations, module-set identity and time of observation—not a screenshot of two names.
  4. Effective-schema construction. Record parser/compiler identity, diagnostics and a normalized fingerprint of the effective schema after imports, includes, augments, features and deviations have been applied.
  5. Validation. Test representative instances and deliberately invalid cases against the frozen schema. A clean parse is not instance conformance.
  6. Client behavior. Trace independent clients' resolver choices and compare what they compile. Agreement cannot be inferred from a shared server inventory.
  7. Interoperability. Exercise reads, edits, RPCs, actions and notifications across the mixed-version boundary, including failures and rollback.
  8. Operation. Observe the intended and operational datastores, production behavior and recovery. RFC 8342 makes the separation between intended configuration and operational state explicit.

The ladder is cumulative. A higher rung does not erase the need to preserve the lower evidence, and a lower rung cannot borrow the authority of a higher one. That is the practical value of Lu Heng's argument about reality layers: a declaration, a resolved artifact, a successful validation and a running outcome are related, but they are not interchangeable.

The immediate conclusion is modest. The draft gives operators a way to avoid unnecessary cascading conversion. It does not give them a shortcut around evidence. Two language generations may be allowed to share a server. Whether they produce the same effective contract for a particular client remains a question to be measured.

Sources