YANG Schema Mount
Extracted elements (22)
Multiple levels of schema mount are explicitly allowed: YANG modules in a mounted schema MAY themselves contain mount points. This is supported by implementing 'ietf-yang-library' and 'ietf-yang-schema-mount' within the mounted schema and specifying nested schemas identically to the top-level schema.
Schema mount supports only implementation-time and run-time schema specification, not design-time mounts. Design-time mounts (where the mounted schema is fixed in the parent YANG module itself) are explicitly out of scope, left for a possible future YANG language revision.
Schema mount was introduced because the existing 'uses' and 'augment' YANG mechanisms are insufficient for attaching existing modules (e.g., 'ietf-interfaces') at non-root locations. The 'uses' approach requires wrapping every module in a grouping and updating the parent model for each new module, while 'augment' would require defining the same hierarchy twice. Schema mount allows mounting without modifying the mounted modules.
NACM (RFC 8341) applies to nodes defined by the mounted schema in the same way as for top-level schema nodes. NACM path expressions can traverse into mounted schema subtrees using standard XPath notation that includes the mount point container.
A fundamental principle is that the mounted schema operates within a 'mount jail': all paths (leafrefs, instance-identifiers, XPath expressions, augment targets) within the mounted schema are interpreted with the mount point as the root node, and cannot refer to nodes outside the mount jail.
A server that does not support NMDA MAY implement revision 2016-06-21 of 'ietf-yang-library' (RFC 7895) under a mount point. A server that supports NMDA MUST implement at least revision 2019-01-04 of 'ietf-yang-library' (RFC 8525) under a mount point.
If a mount point is defined in the parent schema but has no entry in the '/schema-mounts/mount-point' list, then the mounted schema is void and instances of that mount point MUST NOT contain any data except those defined in the parent schema.
If the server emits a notification defined at the top level of any mounted module, it MUST be represented as if the notification were connected to the mount point (per RFC 7950 Section 7.16).
In the 'shared-schema' case, all instances of the same mount point MUST use the same mounted schema and therefore MUST have the same YANG library content identifier. In the 'inline' case, different instances MAY use different mounted schemas.
Mount points that contain modules with RPCs, actions, and notifications SHOULD NOT have any ancestor node that is a list node without a 'key' statement, because inline actions and notifications will not work in such lists.
Nodes in the mounted schema are all made read-only ('config false') if the mount point is itself 'config false' OR if the 'config' leaf in the corresponding 'mount-point' list entry is set to 'false'.
Parent-reference nodes are available in the mounted schema only for XPath evaluations; they CANNOT be accessed via network management protocols such as NETCONF or RESTCONF from within the mounted schema.
The 'mount-point' extension statement MUST NOT be used in a YANG version 1 module. This restriction exists because YANG version 1 cannot support invocation of mounted RPC operations or receipt of mounted notifications.
A mount point is defined by placing the 'mount-point' extension statement (from 'ietf-yang-schema-mount') inside a 'container' or 'list' statement. The extension's argument is a YANG identifier that labels the mount point. A module MAY contain multiple mount points with the same label.
The 'ietf-yang-schema-mount' module defines a read-only '/schema-mounts' container that holds: a 'namespace' list (mapping XPath prefixes to URIs) and a 'mount-point' list (keyed by module and label) that specifies the mounted schema for each mount point via either 'inline' or 'shared-schema' alternatives.
The 'ietf-yang-schema-mount' YANG module (revision 2019-01-14) defines: one extension ('mount-point' with a label argument), and one read-only container ('schema-mounts') with a 'namespace' list and a 'mount-point' list. The 'mount-point' list entries include 'module', 'label', 'config' (boolean, default true), and a mandatory 'schema-ref' choice between 'inline' and 'shared-schema'.
The mounted schema is determined at run time: every instance of a mount point that exists in the operational state MUST contain a copy of YANG library data (either RFC 7895 or RFC 8525 format) that defines the mounted schema. Clients retrieve this data from the instance tree.
The 'shared-schema' case supports a 'parent-reference' leaf-list containing XPath 1.0 expressions evaluated with the mount-point node as context. The union of all resulting node-sets (plus ancestor nodes) is added to the accessible data tree for XPath evaluation within the mounted schema, allowing references to parent schema nodes like interface lists.
This document registers a URI in the IETF XML Registry: 'urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount'. It also registers the YANG module 'ietf-yang-schema-mount' with prefix 'yangmnt' in the YANG Module Names registry.
Care must be taken when constructing 'parent-reference' XPath expressions, because the evaluation result is added to the accessible tree for all XPath expressions in the mounted schema, potentially exposing unintended data nodes from the parent schema to mounted schema logic.
The '/schema-mounts' state data reveals detailed server implementation information — including mounted module names, revisions, features, and deviations — that could help an attacker identify server capabilities or known bugs in specific module versions, facilitating targeted denial-of-service attacks. Read access to this container should be controlled via NACM.
The YANG module data is accessed via NETCONF (mandatory secure transport: SSH per RFC 6242) or RESTCONF (mandatory secure transport: TLS per RFC 8446). Security considerations for all nodes in mounted schemas must be accounted for and access controlled using NACM.