file "ietf-yang-schema-mount@2019-01-14.yang"
module ietf-yang-schema-mount {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount";
prefix yangmnt;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web:
WG List:
Editor: Martin Bjorklund
Bjorklund & Lhotka Standards Track [Page 13]
RFC 8528 YANG Schema Mount March 2019
Editor: Ladislav Lhotka
";
description
"This module defines a YANG extension statement that can be used
to incorporate data models defined in other YANG modules in a
module. It also defines operational state data that specify the
overall structure of the data model.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8528;
see the RFC itself for full legal notices.";
revision 2019-01-14 {
description
"Initial revision.";
reference
"RFC 8528: YANG Schema Mount";
}
/*
* Extensions
*/
extension mount-point {
argument label;
description
"The argument 'label' is a YANG identifier, i.e., it is of the
type 'yang:yang-identifier'.
The 'mount-point' statement MUST NOT be used in a YANG
version 1 module, neither explicitly nor via a 'uses'
statement.
Bjorklund & Lhotka Standards Track [Page 14]
RFC 8528 YANG Schema Mount March 2019
The 'mount-point' statement MAY be present as a substatement
of 'container' and 'list' and MUST NOT be present elsewhere.
There MUST NOT be more than one 'mount-point' statement in a
given 'container' or 'list' statement.
If a mount point is defined within a grouping, its label is
bound to the module where the grouping is used.
A mount point defines a place in the node hierarchy where
other data models may be attached. A server that implements a
module with a mount point populates the
'/schema-mounts/mount-point' list with detailed information on
which data models are mounted at each mount point.
Note that the 'mount-point' statement does not define a new
data node.";
}
/*
* State data nodes
*/
container schema-mounts {
config false;
description
"Contains information about the structure of the overall
mounted data model implemented in the server.";
list namespace {
key "prefix";
description
"This list provides a mapping of namespace prefixes that are
used in XPath expressions of 'parent-reference' leafs to the
corresponding namespace URI references.";
leaf prefix {
type yang:yang-identifier;
description
"Namespace prefix.";
}
leaf uri {
type inet:uri;
description
"Namespace URI reference.";
}
}
list mount-point {
key "module label";
Bjorklund & Lhotka Standards Track [Page 15]
RFC 8528 YANG Schema Mount March 2019
description
"Each entry of this list specifies a schema for a particular
mount point.
Each mount point MUST be defined using the 'mount-point'
extension in one of the modules listed in the server's
YANG library instance with conformance type 'implement'.";
leaf module {
type yang:yang-identifier;
description
"Name of a module containing the mount point.";
}
leaf label {
type yang:yang-identifier;
description
"Label of the mount point defined using the 'mount-point'
extension.";
}
leaf config {
type boolean;
default "true";
description
"If this leaf is set to 'false', then all data nodes in the
mounted schema are read-only ('config false'), regardless
of their 'config' property.";
}
choice schema-ref {
mandatory true;
description
"Alternatives for specifying the schema.";
container inline {
presence
"A complete self-contained schema is mounted at the
mount point.";
description
"This node indicates that the server has mounted at least
the module 'ietf-yang-library' at the mount point, and
its instantiation provides the information about the
mounted schema.
Different instances of the mount point may have
different schemas mounted.";
}
container shared-schema {
presence
"The mounted schema together with the 'parent-reference'
make up the schema for this mount point.";
Bjorklund & Lhotka Standards Track [Page 16]
RFC 8528 YANG Schema Mount March 2019
description
"This node indicates that the server has mounted at least
the module 'ietf-yang-library' at the mount point, and
its instantiation provides the information about the
mounted schema. When XPath expressions in the mounted
schema are evaluated, the 'parent-reference' leaf-list
is taken into account.
Different instances of the mount point MUST have the
same schema mounted.";
leaf-list parent-reference {
type yang:xpath1.0;
description
"Entries of this leaf-list are XPath 1.0 expressions
that are evaluated in the following context:
- The context node is the node in the parent data tree
where the mount-point is defined.
- The accessible tree is the parent data tree
*without* any nodes defined in modules that are
mounted inside the parent schema.
- The context position and context size are both equal
to 1.
- The set of variable bindings is empty.
- The function library is the core function library
defined in the W3C XPath 1.0 document
(http://www.w3.org/TR/1999/REC-xpath-19991116) and
the functions defined in Section 10 of RFC 7950.
- The set of namespace declarations is defined by the
'namespace' list under 'schema-mounts'.
Each XPath expression MUST evaluate to a node-set
(possibly empty). For the purposes of evaluating
XPath expressions whose context nodes are defined in
the mounted schema, the union of all these node-sets
together with ancestor nodes are added to the
accessible data tree.
Note that in the case 'ietf-yang-schema-mount' is
itself mounted, a 'parent-reference' in the mounted
module may refer to nodes that were brought into the
accessible tree through a 'parent-reference' in the
parent schema.";
Bjorklund & Lhotka Standards Track [Page 17]
RFC 8528 YANG Schema Mount March 2019
}
}
}
}
}
}
10. IANA Considerations
This document registers a URI in the "IETF XML Registry" [RFC3688].
URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the "YANG Module Names"
registry [RFC6020].
name: ietf-yang-schema-mount
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
prefix: yangmnt
reference: RFC 8528
11. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
Bjorklund & Lhotka Standards Track [Page 18]
RFC 8528 YANG Schema Mount March 2019
o /schema-mounts: The schema defined by this state data provides
detailed information about a server implementation that may help
an attacker identify the server capabilities and server
implementations with known bugs. Server vulnerabilities may be
specific to particular modules included in the schema, module
revisions, module features, or even module deviations. For
example, if a particular operation on a particular data node is
known to cause a server to crash or significantly degrade device
performance, then the schema information will help an attacker
identify server implementations with such a defect, in order to
launch a denial-of-service attack on the device.
It is important to take into account the security considerations for
all nodes in the mounted schemas and to control access to these nodes
by using the mechanism described in Section 7.
Care must be taken when the "parent-reference" XPath expressions are
constructed, since the result of the evaluation of these expressions
is added to the accessible tree for any XPath expression found in the
mounted schema.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
.
Bjorklund & Lhotka Standards Track [Page 19]
RFC 8528 YANG Schema Mount March 2019
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019,
.
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Recommendation
REC-xpath-19991116, November 1999,
.
Bjorklund & Lhotka Standards Track [Page 20]
RFC 8528 YANG Schema Mount March 2019
12.2. Informative References
[DEVICE-YANG]
Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C.
Hopps, "Network Device YANG Logical Organization", Work in
Progress, draft-ietf-rtgwg-device-model-02, March 2017.
[IS-IS-YANG]
Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L.
Lhotka, "YANG Data Model for IS-IS protocol", Work in
Progress, draft-ietf-isis-yang-isis-cfg-34, January 2019.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
.
[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and
X. Liu, "YANG Data Model for Network Instances", RFC 8529,
DOI 10.17487/RFC8529, March 2019,
.
[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and
X. Liu, "YANG Model for Logical Network Elements",
RFC 8530, DOI 10.17487/RFC8530, March 2019,
.
[YANG-MOUNT]
Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined
Information from Remote Datastores", Work in Progress,
draft-clemm-netmod-mount-06, March 2017.
Bjorklund & Lhotka Standards Track [Page 21]
RFC 8528 YANG Schema Mount March 2019
Appendix A. Example: Device Model with LNEs and NIs
This non-normative example demonstrates an implementation of the
device model as specified in Section 2 of [DEVICE-YANG], using both
logical network elements (LNEs) and network instances (NIs).
In these examples, the character '\' is used where a line break has
been inserted for formatting reasons.
A.1. Physical Device
The data model for the physical device may be described by this YANG
library content, assuming the server supports the NMDA:
{
"ietf-yang-library:yang-library": {
"content-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
"module-set": [
{
"name": "physical-device-modules",
"module": [
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
},
{
"name": "iana-if-type",
"revision": "2015-06-12",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type"
},
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"feature": ["arbitrary-names", "pre-provisioning" ],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"name": "ietf-ip",
"revision": "2018-02-22",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"
},
{
"name": "ietf-logical-network-element",
"revision": "2018-03-20",
"feature": [ "bind-lne-name" ],
Bjorklund & Lhotka Standards Track [Page 22]
RFC 8528 YANG Schema Mount March 2019
"namespace":
"urn:ietf:params:xml:ns:yang:\
ietf-logical-network-element"
},
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
}
]
}
],
"schema": [
{
"name": "physical-device-schema",
"module-set": [ "physical-device-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "physical-device-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "physical-device-schema"
}
Bjorklund & Lhotka Standards Track [Page 23]
RFC 8528 YANG Schema Mount March 2019
]
}
}
A.2. Logical Network Elements
Each LNE can have a specific data model that is determined at run
time, so it is appropriate to mount it using the "inline" method.
Hence, the following "schema-mounts" data is used:
{
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-logical-network-element",
"label": "root",
"inline": {}
}
]
}
}
An administrator of the host device has to configure an entry for
each LNE instance, for example:
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"enabled": true,
"ietf-logical-network-element:bind-lne-name": "eth0"
}
]
},
"ietf-logical-network-element:logical-network-elements": {
"logical-network-element": [
{
"name": "lne-1",
"managed": true,
"description": "LNE with NIs",
"root": {
...
}
}
...
]
Bjorklund & Lhotka Standards Track [Page 24]
RFC 8528 YANG Schema Mount March 2019
}
}
and then also place necessary state data as the contents of the
"root" instance, which should include at least:
o YANG library data specifying the LNE's data model, for example,
assuming the server does not implement the NMDA:
{
"ietf-yang-library:modules-state": {
"module-set-id": "9358e11874068c8be06562089e94a89e0a392019",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "implement"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"feature": [
"ipv6-privacy-autoconf"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-network-instance",
"revision": "2018-03-20",
"feature": [
Bjorklund & Lhotka Standards Track [Page 25]
RFC 8528 YANG Schema Mount March 2019
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
}
}
o state data for interfaces assigned to the LNE instance (that
effectively become system-controlled interfaces for the LNE), for
example:
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"statistics": {
"discontinuity-time": "2016-12-16T17:11:27+02:00"
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "fe80::42a8:f0ff:fea8:24fe",
"origin": "link-layer",
Bjorklund & Lhotka Standards Track [Page 26]
RFC 8528 YANG Schema Mount March 2019
"prefix-length": 64
}
]
}
}
]
}
}
A.3. Network Instances
Assuming that network instances share the same data model, it can be
mounted using the "shared-schema" method as follows:
{
"ietf-yang-schema-mount:schema-mounts": {
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"module": "ietf-network-instance",
"label": "root",
"shared-schema": {
"parent-reference": [
"/if:interfaces/if:interface[\
ni:bind-network-instance-name = current()/../ni:name]"
]
}
}
]
}
}
Note also that the "ietf-interfaces" module appears in the
"parent-reference" leaf-list for the mounted NI schema. This means
that references to LNE interfaces, such as "outgoing-interface" in
static routes, are valid despite the fact that "ietf-interfaces"
isn't part of the NI schema.
Bjorklund & Lhotka Standards Track [Page 27]
RFC 8528 YANG Schema Mount March 2019
A.4. Invoking an RPC Operation
Assume that the mounted NI data model also implements the "ietf-isis"
module [IS-IS-YANG]. An RPC operation defined in this module, such
as "clear-adjacency", can be invoked by a client session of an LNE's
RESTCONF server as an action tied to the mount point of a particular
network instance using a request URI like this (all on one line):
POST /restconf/data/ietf-network-instance:network-instances/
network-instance=rtrA/root/ietf-isis:clear-adjacency HTTP/1.1
Contributors
The idea of having some way to combine schemas from different YANG
modules into one has been proposed independently by others:
o Authors of [YANG-MOUNT]:
* Lou Berger, LabN Consulting, L.L.C.,
* Alexander Clemm, Huawei,
* Christian Hopps, Deutsche Telekom,
o Jan Medved, Cisco,
o Eric Voit, Cisco,
Authors' Addresses
Martin Bjorklund
Tail-f Systems
Email: mbj@tail-f.com
Ladislav Lhotka
CZ.NIC
Email: lhotka@nic.cz
Bjorklund & Lhotka Standards Track [Page 28]
gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8528.txt -- Leo's gemini proxy
-- Connecting to gemini.bortzmeyer.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/plain
-- Response ended
-- Page fetched on Mon May 6 15:28:10 2024