Summary

  • YANG Schema Mount can let a mounted model evaluate constraints against selected parent data without making that data available through the mounted protocol surface.
  • Reusing identical modules does not prove that two network instances have identical reference context. Integration review needs to identify who controls the parent selection and the data it selects.
  • Schema scope, read-only status and user authorization answer different questions. Treating a mount boundary as proof of tenant isolation confuses them.

An interface can exist on a device and still be the wrong interface for a particular network instance. This is not merely an inventory problem. A configuration model may need to distinguish interfaces assigned to one instance from interfaces that belong elsewhere, while reusing a routing model that was not written specifically for that surrounding device structure.

YANG Schema Mount addresses this kind of composition. Its significance is not that another file can be loaded. It is that the place where a model is installed helps determine the context in which that model's references are understood. For a team automating configuration, the surrounding relationship becomes part of the work that must be understood before an apparently unchanged candidate can be trusted.

The clearest starting point is a non-normative network-instance example in RFC 8528, Appendix A.3. It selects interfaces from a parent tree according to their binding to the current network instance. A static route can consequently refer to an outgoing interface even though the interface module is not part of the mounted network-instance schema. The route has acquired a usable reference context without acquiring ownership of the interface model.

That example is an explanation of a standard, not a report of a deployed router or an outage. It nonetheless identifies a practical question that a module-only review cannot answer: which surrounding data is this particular instance configured to use for evaluating its constraints?

The relationship sits outside the reusable module

Ordinary reuse is attractive because it reduces the need to maintain several nearly identical models. Schema mount allows complete models to be placed beneath a mount point in a parent model. The parent designer provides an appropriate container or list location; the mounted modules need not be rewritten to describe that particular enclosing arrangement. Composition is supplied outside those modules.

The economy is real, but so is the additional responsibility. A maintainer can inspect a mounted module and correctly conclude that none of its definitions changed. That conclusion does not establish that the server still places it in the same surroundings. Nor does it establish that the data selected from those surroundings remains the same.

This is a narrower claim than saying configuration has become arbitrary. Constraints still have defined meanings. The missing item in a careless review is an input to their evaluation, not permission for an implementer to ignore them. A team investigating a changed result should therefore ask whether the relevant context changed before concluding that the model or validator is inconsistent.

A reference is not a read permission

Mounted paths normally use the mount point as their root. A reference written inside the mounted model is not automatically a reference to the physical device's entire data tree. This bounded interpretation is sometimes described as a mount jail. The phrase concerns model paths; it is not a certificate of process separation or a guarantee that tenants cannot affect one another.

Shared-schema mounting provides a deliberate way to bring selected parent nodes into the accessible tree used for mounted XPath evaluation. Its parent-reference expressions select node sets; the selected nodes and their ancestors become part of that evaluation context. This is what makes the network-instance interface example possible.

The standard draws a consequential boundary here. Those selected parent nodes do not thereby become available through NETCONF or RESTCONF operations on the mounted tree. A constraint can depend on data that the mounted protocol surface does not expose as its own readable or writable content. Calling both relationships “access” obscures the distinction that an operator needs to retain.

For an integration team, it is useful to keep three questions separate. What can a model refer to when checking data? What does the schema permit to be configured? What can a particular authenticated user do through a session? A single successful operation is not a substitute for answering all three.

What actually changes the answer

YANG's constraint rules explain why context matters. A must condition is evaluated conceptually as an XPath expression and must be true for the relevant data to be valid. A leaf reference whose require-instance property is true requires a matching instance, subject to the language's rules about defaults and configuration. When that property is false, absence is permitted. The distinction is specified in RFC 7950; it should not disappear into a generic assertion that every reference must resolve.

Consider the interface selection in the schema-mount example. If a surrounding assignment changes which interface nodes are selected for an instance, a mounted reference that depends on those nodes may encounter a different result even when the candidate's text is unchanged. This is an inference from the composition and constraint rules, not evidence that a particular product accepts an unsafe route. The exact outcome depends on the actual reference, the relevant data and the implemented schema.

It also does not follow that every parent change affects every mounted constraint. An unrelated node may be irrelevant. A selection can yield the same effective set after an edit. A constraint may not consult the selected data at all. Useful investigation traces the specific dependency; it does not turn the entire parent model into an undifferentiated risk label.

The standard's examples deserve the same precision. A verified editorial erratum, number 5797, corrects a separate logical-network-element example: an interface's binding must name the logical element, not repeat the interface's own name. It does not revoke the parent-reference mechanism. The lesson is modest but important: a familiar-looking identifier is not enough when a field identifies a different kind of thing.

Shared does not mean interchangeable

A shared-schema mount requires instances of that mount point to share a schema. Inline mounting permits different schemas at different instances. Operational discovery supplies YANG Library information at each mount. An implementation cannot safely treat two inline instances as equivalent merely because their library content identifiers happen to match; RFC 8528 explicitly warns against that inference.

There is a second, less obvious limit. Shared schema is not shared ordinary data. The same selection expression can select different interfaces because it is evaluated from different instance contexts. A library identifier describes library information, not a complete snapshot of every parent value a constraint might consult. Monitoring only module revisions and library changes can therefore leave a context-sensitive dependency unobserved.

This is not an argument against caching or shared models. It is an argument for knowing what the cache key proves. Reuse should eliminate redundant work without silently eliminating the evidence that distinguishes one instance from another.

An open path is not an isolation failure

Access control remains a separate part of the composition. Where NACM is implemented, mounted data is governed through its location in the composed tree. A mount does not simply create an unrelated private authorization universe. Likewise, making mounted data read-only through its schema or mount metadata does not specify which users may read it.

The NACM specification, RFC 8341, also warns that model dependencies and implicit effects deserve attention. Denying direct reads is not by itself a complete account of what a user might infer from permitted operations or related data. That caution does not establish a schema-mount exploit. It establishes why confidentiality review should examine dependencies as well as direct paths.

An operator should resist both easy conclusions: that an explicit parent reference necessarily defeats isolation, or that the absence of direct mounted reads necessarily proves isolation. The correct answer requires the model, the sessions, the permissions and the observable behavior. Schema Mount deliberately leaves aspects of instrumentation and instance lifecycle to implementations. Its presence cannot settle those questions on their behalf.

The operational conclusion is straightforward. Accepting a reusable model and accepting its placement are different responsibilities. A change review that records only the former can be accurate about the file and incomplete about the system.