Summary

  • RFC 10035 adds a read-only augmented-by list to YANG Library so a server can name modules that directly augment another module in the same module-set—relationships the base module cannot discover by parsing its own source.
  • The list is intentionally not a transitive closure. If B augments a node defined by A and C augments a child defined by B, A reports B and B reports C; C is not promoted into A's direct list merely because its target path begins under A.
  • Treat the result as versioned direct adjacency from one server. Effective-schema claims still require the YANG Library content-id, module revisions, access result, client traversal, retrieved sources and observed application outcome.

Most software dependencies point in a comfortable direction. Open a file and it tells you what it imports. Read a YANG module and its import and include statements disclose the modules or submodules it calls upon. The reader can start at the source and walk outward.

An augment reverses that view. A separate module can target a location in the first module's schema tree and insert new nodes there. The base module does not acquire a line saying who arrived from outside. Its effective shape can therefore depend on source it never names.

That is the narrow problem RFC 10035 addresses. Published on the IETF Standards Track in August 2026, YANG Library: Addition of the augmented-by List updates RFC 8525. Its authors are Zhuoyao Lin, Benoît Claise and Ignacio Dominguez Martinez-Casanueva. The document adds a read-only augmented-by leaf-list under a module entry in YANG Library. A server can now report which modules directly augment that module in the current module-set.

Claise is relevant here not as the owner of YANG or the sole inventor of this addition, but as one entity in a long-running operational conversation about how models meet running networks. His IETF Datatracker page, captured on 31 August 2026, lists 45 RFCs including RFC 10035 and current roles across network-management and operations work, performance-metrics review, an IAB workshop and YangCatalog support. An IETF 104 biography records his earlier service as Operations and Management Area co-director from 2012 to 2018 and work on YANG, telemetry and network automation. Those dated records provide context.

They do not transfer authority over any server, client or deployment to an RFC author.

The dependency points back toward the base

RFC 7950 makes the asymmetry concrete. import allows a module to use definitions from another module. include lets a module incorporate a submodule. Both are declared by the source that needs them. A parser looking at that source can see the dependency.

An external augment is different. Its author supplies a schema node identifier whose target may live in another module. The augmenting module knows the target. The target module does not necessarily know the augmenter. RFC 10035 groups this with deviation as a reverse dependency: another module changes the usable shape or behaviour associated with the base.

YANG Library already had a way to identify deviation modules. The missing piece was a comparable server-reported answer for augmentation. Without it, a client trying to assemble an effective schema could parse the base correctly and still omit nodes inserted from elsewhere. Searching an entire catalogue might find candidates, but a catalogue is not the same thing as the module-set a particular server says it implements.

augmented-by moves the answer to the server's library. For each module entry, the server can list the names of modules that directly augment it. The base and augmenting modules must both appear in the same module-set. This condition matters: the edge is not a timeless statement that two published modules are always joined. It is a relationship in one reported deployment context.

That makes the list useful for discovery while keeping its evidence claim modest. It answers, “Which modules in this module-set directly augment this module?” It does not answer, “What is every schema node reachable from here?”, “Does this implementation conform?”, or “Is it safe for my automation to act?”

Direct means the parent that owns the new attachment

The hardest boundary in RFC 10035 appears in its three-module example. Suppose module A defines foo-a. Module B augments A by adding foo-b beneath it. Module C then adds a leaf beneath foo-b.

The path used by C is rooted in territory that began with A. It would be tempting to say that C therefore augments A too. The RFC refuses that shortcut. The parent of C's added leaf is foo-b, and B defined that parent. YANG Library reports B in A's augmented-by list and C in B's list. It does not list C under A.

This is not a missing feature. It preserves the meaning of an edge. If every descendant were copied onto every ancestor, a direct relationship would become indistinguishable from a transitive consequence. A large schema would produce expanding, repetitive lists whose entries no longer said where the actual attachment occurred.

An application that needs the full closure can compute it: begin with A, follow A→B, then B→C, retaining the path and guarding against errors. An application concerned with a particular node can retrieve the modules and inspect the schema tree. Those are client functions. The server supplies direct adjacency, not the finished answer to every possible dependency question.

This division follows a minimum-initial-specification discipline. A shared mechanism names the smallest interoperable fact that was previously hard to discover. Recursive traversal policy, cycle handling, cache invalidation, node-specific analysis and risk decisions remain local because different applications need different answers.

The list belongs to a changing library instance

Direct edges are only useful if their version is known. RFC 8525 gives each YANG Library instance a content-id. The value represents the current library information on that server and must change when that information changes. A client can cache the library under one identifier, notice a later identifier, and retrieve the updated instance.

RFC 10035 adds an operational expectation: when new modules are onboarded, the YANG Library and its augmented-by data should be updated. That makes freshness part of the evidence. A screenshot of A→B without a server identity, capture time and content-id cannot show which library state produced the edge. An absent A→B is even more ambiguous. It might mean there is no direct augment, but it could also reflect an old library, an implementation without RFC 10035 support, filtered access or an incorrect report.

A defensible receipt therefore binds the list to server and management endpoint, authenticated principal, datastore and schema, module-set, module names, revisions and namespaces. It preserves content-id and the exact direct edges. If a client computes a closure, it records the traversal algorithm, limits, path, error treatment and output separately from the server response.

That separation prevents a computed graph from being misrepresented as something the server declared. It also makes a later result reproducible. If A→B→C changes after a module revision or onboarding event, an investigator can distinguish a changed library from changed client logic.

Read-only does not mean harmless

The new leaf-list changes no configuration. It is read-only. Yet its relationships can reveal which optional modules, features or implementation components are present. RFC 10035 warns that this structure could help an attacker target a particular implementation and recommends restricting reads to authorised users through the management access-control boundary.

That creates another reason not to treat a captured list as universal truth. Two principals may see different information because policy filters the library. A client that received no edge needs the access result as much as the JSON or XML value. “Not returned” and “does not exist” are not synonyms.

There is also a cost in size. Each reported reverse dependency enlarges the YANG Library instance. Operators need to update the data as modules change, and clients need to decide when a cache remains trustworthy. The useful optimisation is not to turn the library into an all-purpose analysis service, but to make a compact edge available and let applications fetch deeper evidence only when their decisions require it.

From adjacency to an operational claim

Consider a client that uses YANG Library to decide whether it understands a server's configuration schema. Seeing A→B proves that the current library instance reports B as a direct augmenter of A within the named module-set. It does not prove that the client retrieved B, selected the correct revision, parsed every statement, followed B→C, reconciled deviations, matched the right datastore or handled feature conditions.

Nor does it prove the running server behaves as the models predict. RFC 8342 distinguishes the intended and operational views that network-management systems have to reason about. A schema graph can organise expectations; only observations from the actual configuration, state and automation result show what occurred.

The evidence chain should therefore continue past discovery. Retain source retrieval and parser results. Record the application decision that consumed the graph. Compare expected nodes or constraints with the accessible datastore. Preserve the configuration, telemetry or automation outcome, along with the owner of any exception.

Running-Code Primacy is not a rejection of models. It is a refusal to let a model's existence settle a runtime claim. augmented-by improves the model-to-model join. It does not erase the last mile between declared schema, client interpretation and running behaviour.

Sources