draft-ietf-netmod-schema-mount-09.txt   draft-ietf-netmod-schema-mount-10.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track L. Lhotka Intended status: Standards Track L. Lhotka
Expires: September 21, 2018 CZ.NIC Expires: October 14, 2018 CZ.NIC
March 20, 2018 April 12, 2018
YANG Schema Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-09 draft-ietf-netmod-schema-mount-10
Abstract Abstract
This document defines a mechanism to combine YANG modules into the This document defines a mechanism to add the schema trees defined by
schema defined in other YANG modules. a set of YANG modules onto a mount point defined in the schema tree
in some YANG module.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 21, 2018. This Internet-Draft will expire on October 14, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6
2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6
3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7
3.2. Specification of the Mounted Schema . . . . . . . . . . . 7 3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 8 3.3. Specification of the Mounted Schema . . . . . . . . . . . 8
4. Referring to Data Nodes in the Parent Schema . . . . . . . . 8 3.4. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9
5. RPC operations and Notifications . . . . . . . . . . . . . . 9 4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9
5. RPC operations and Notifications . . . . . . . . . . . . . . 10
6. Network Management Datastore Architecture (NMDA) 6. Network Management Datastore Architecture (NMDA)
Considerations . . . . . . . . . . . . . . . . . . . . . . . 10 Considerations . . . . . . . . . . . . . . . . . . . . . . . 11
7. Implementation Notes . . . . . . . . . . . . . . . . . . . . 10 7. Interaction with the Network Configuration Access Control
8. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 10 Model (NACM) . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 11 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Example: Device Model with LNEs and NIs . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 20
A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Example: Device Model with LNEs and NIs . . . . . . 21
A.2. Logical Network Elements . . . . . . . . . . . . . . . . 21 A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21
A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25 A.2. Logical Network Elements . . . . . . . . . . . . . . . . 23
A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 25 A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Modularity and extensibility were among the leading design principles Modularity and extensibility were among the leading design principles
of the YANG data modeling language. As a result, the same YANG of the YANG data modeling language. As a result, the same YANG
module can be combined with various sets of other modules and thus module can be combined with various sets of other modules and thus
form a data model that is tailored to meet the requirements of a form a data model that is tailored to meet the requirements of a
specific use case. Server implementors are only required to specify specific use case. Server implementors are only required to specify
all YANG modules comprising the data model (together with their all YANG modules comprising the data model (together with their
revisions and other optional choices) in the YANG library data revisions and other optional choices) in the YANG library data
([RFC7895], [I-D.ietf-netconf-rfc7895bis] and Section 5.6.4 of ([RFC7895], [I-D.ietf-netconf-rfc7895bis] and Section 5.6.4 of
[RFC7950]) implemented by the server. Such YANG modules appear in [RFC7950]) implemented by the server. Such YANG modules appear in
the data model "side by side", i.e., top-level data nodes of each the data model "side by side", i.e., top-level data nodes of each
module - if there are any - are also top-level nodes of the overall module - if there are any - are also top-level nodes of the overall
data model. data model.
Furthermore, YANG has two mechanisms for contributing a schema YANG has two mechanisms for contributing a schema hierarchy defined
hierarchy defined elsewhere to the contents of an internal node of elsewhere to the contents of an internal node of the schema tree;
the schema tree; these mechanisms are realized through the following these mechanisms are realized through the following YANG statements:
YANG statements:
o The "uses" statement explicitly incorporates the contents of a o The "uses" statement explicitly incorporates the contents of a
grouping defined in the same or another module. See Section 4.2.6 grouping defined in the same or another module. See Section 4.2.6
of [RFC7950] for more details. of [RFC7950] for more details.
o The "augment" statement explicitly adds contents to a target node o The "augment" statement explicitly adds contents to a target node
defined in the same or another module. See Section 4.2.8 of defined in the same or another module. See Section 4.2.8 of
[RFC7950] for more details. [RFC7950] for more details.
With both mechanisms, the source or target YANG module explicitly With both mechanisms, the source or target YANG module explicitly
defines the exact location in the schema tree where the new nodes are defines the exact location in the schema tree where the new nodes are
placed. placed.
In some cases these mechanisms are not sufficient; it is often In some cases these mechanisms are not sufficient; it is sometimes
necessary that an existing module (or a set of modules) is added to necessary that an existing module (or a set of modules) is added to
the data model starting at a non-root location. For example, YANG the data model starting at locations other than the root. For
modules such as "ietf-interfaces" [RFC8343] are often defined so as example, YANG modules such as "ietf-interfaces" [RFC8343] are defined
to be used in a data model of a physical device. Now suppose we want so as to be used in a data model of a physical device. Now suppose
to model a device that supports multiple logical devices we want to model a device that supports multiple logical devices
[I-D.ietf-rtgwg-lne-model], each of which has its own instantiation [I-D.ietf-rtgwg-lne-model], each of which has its own instantiation
of "ietf-interfaces", and possibly other modules, but, at the same of "ietf-interfaces", and possibly other modules, but, at the same
time, we want to be able to manage all these logical devices from the time, we want to be able to manage all these logical devices from the
master device. Hence, we would like to have a schema like this: master device. Hence, we would like to have a schema tree like this:
+--rw interfaces +--rw interfaces
| +--rw interface* [name] | +--rw interface* [name]
| ... | ...
+--rw logical-device* [name] +--rw logical-network-element* [name]
+--rw name +--rw name
| ... | ...
+--rw interfaces +--rw interfaces
+--rw interface* [name] +--rw interface* [name]
... ...
With the "uses" approach, the complete schema tree of With the "uses" approach, the complete schema tree of
"ietf-interfaces" would have to be wrapped in a grouping, and then "ietf-interfaces" would have to be wrapped in a grouping, and then
this grouping would have to be used at the top level (for the master this grouping would have to be used at the top level (for the master
device) and then also in the "logical-device" list (for the logical device) and then also in the "logical-network-element" list (for the
devices). This approach has several disadvantages: logical devices). This approach has several disadvantages:
o It is not scalable because every time there is a new YANG module o It is not scalable because every time there is a new YANG module
that needs to be added to the logical device model, we have to that needs to be added to the logical device model, we have to
update the model for logical devices with another "uses" statement update the model for logical devices with another "uses" statement
pulling in contents of the new module. pulling in contents of the new module.
o Absolute references to nodes defined inside a grouping may break o Absolute references to nodes defined inside a grouping may break
if the grouping is used in different locations. if the grouping is used in different locations.
o Nodes defined inside a grouping belong to the namespace of the o Nodes defined inside a grouping belong to the namespace of the
module where it is used, which makes references to such nodes from module where it is used, which makes references to such nodes from
other modules difficult or even impossible. other modules difficult or even impossible.
o It would be difficult for vendors to add proprietary modules when o It would be difficult for vendors to add proprietary modules when
the "uses" statements are defined in a standard module. the "uses" statements are defined in a standard module.
With the "augment" approach, "ietf-interfaces" would have to augment With the "augment" approach, "ietf-interfaces" would have to augment
the "logical-device" list with all its nodes, and at the same time the "logical-network-element" list with all its nodes, and at the
define all its nodes at the top level. The same hierarchy of nodes same time define all its nodes at the top level. The same hierarchy
would thus have to be defined twice, which is clearly not scalable of nodes would thus have to be defined twice, which is clearly not
either. scalable either.
This document introduces a new generic mechanism, denoted as schema This document introduces a new mechanism, denoted as schema mount,
mount, that allows for mounting one data model consisting of any that allows for mounting one data model consisting of any number of
number of YANG modules at a specified location of another (parent) YANG modules at a specified location of another (parent) schema.
schema. Unlike the "uses" and "augment" approaches discussed above, Unlike the "uses" and "augment" approaches discussed above, the
the mounted modules needn't be specially prepared for mounting and, mounted modules needn't be specially prepared for mounting and,
consequently, existing modules such as "ietf-interfaces" can be consequently, existing modules such as "ietf-interfaces" can be
mounted without any modifications. mounted without any modifications.
The basic idea of schema mount is to label a data node in the parent The basic idea of schema mount is to label a data node in the parent
schema as the mount point, and then define a complete data model to schema as the mount point, and then define a complete data model to
be attached to the mount point so that the labeled data node be attached to the mount point so that the labeled data node
effectively becomes the root node of the mounted data model. effectively becomes the root node of the mounted data model.
In principle, the mounted schema can be specified at three different In principle, the mounted schema can be specified at three different
phases of the data model life cycle: phases of the data model life cycle:
skipping to change at page 5, line 18 skipping to change at page 5, line 18
assume anything about the source of instance data for the mounted assume anything about the source of instance data for the mounted
schemas. It may be implemented using the same instrumentation as the schemas. It may be implemented using the same instrumentation as the
rest of the system, or it may be implemented by querying some other rest of the system, or it may be implemented by querying some other
system. Future specifications may define mechanisms to control or system. Future specifications may define mechanisms to control or
monitor the implementation of specific mount points. monitor the implementation of specific mount points.
This document allows mounting of complete data models only. Other This document allows mounting of complete data models only. Other
specifications may extend this model by defining additional specifications may extend this model by defining additional
mechanisms such as mounting sub-hierarchies of a module. mechanisms such as mounting sub-hierarchies of a module.
The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA) [RFC8342].
2. Terminology and Notation 2. Terminology and Notation
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are defined in [RFC7950] and are not redefined The following terms are defined in [RFC7950] and are not redefined
here: here:
o action o action
o container o container
o data node
o list o list
o RPC operation o RPC operation
o schema node
o schema tree
The following terms are defined in [RFC8342] and are not redefined The following terms are defined in [RFC8342] and are not redefined
here: here:
o client o client
o notification o notification
o operational state o operational state
o server o server
The following terms are defined in [RFC8343] and are not redefined The following term is defined in [RFC8343] and are not redefined
here: here:
o system-controlled interface o system-controlled interface
Tree diagrams used in this document follow the notation defined in
[RFC8340] The following term is defined in [I-D.ietf-netconf-rfc7895bis] and
are not redefined here:
o YANG library checksum
2.1. Glossary of New Terms 2.1. Glossary of New Terms
o mount point: container or list node whose definition contains the o mount point: container or list node whose definition contains the
"mount-point" extension statement. The argument of the "mount-point" extension statement. The argument of the
"mount-point" statement defines a label for the mount point. "mount-point" statement defines a label for the mount point.
o parent schema (of a particular mounted schema): the schema that o schema: collection of schema trees with a common root
contains the mount point for the mounted schema.
o top-level schema: a schema according to [RFC7950] in which schema o top-level schema: schema rooted at the root node
trees of each module (except augments) start at the root node.
2.2. Namespace Prefixes o mounted schema: schema rooted at a mount point
o parent schema (of a mounted schema): schema containing the mount
point
2.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in
[RFC8340]
2.3. Namespace Prefixes
In this document, names of data nodes, YANG extensions, actions and In this document, names of data nodes, YANG extensions, actions and
other data model objects are often used without a prefix, as long as other data model objects are often used without a prefix, as long as
it is clear from the context in which YANG module each name is it is clear from the context in which YANG module each name is
defined. Otherwise, names are prefixed using the standard prefix defined. Otherwise, names are prefixed using the standard prefix
associated with the corresponding YANG module, as shown in Table 1. associated with the corresponding YANG module, as shown in Table 1.
+---------+------------------------+--------------------------------+ +---------+------------------------+--------------------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+---------+------------------------+--------------------------------+ +---------+------------------------+--------------------------------+
skipping to change at page 7, line 22 skipping to change at page 7, line 43
The argument of the "mount-point" extension is a YANG identifier that The argument of the "mount-point" extension is a YANG identifier that
defines a label for the mount point. A module MAY contain multiple defines a label for the mount point. A module MAY contain multiple
"mount-point" statements having the same argument. "mount-point" statements having the same argument.
It is therefore up to the designer of the parent schema to decide It is therefore up to the designer of the parent schema to decide
about the placement of mount points. A mount point can also be made about the placement of mount points. A mount point can also be made
conditional by placing "if-feature" and/or "when" as substatements of conditional by placing "if-feature" and/or "when" as substatements of
the "container" or "list" statement that represents the mount point. the "container" or "list" statement that represents the mount point.
The "mount-point" statement MUST NOT be used in a YANG version 1 The "mount-point" statement MUST NOT be used in a YANG version 1
module. Note, however, that modules written in any YANG version, module [RFC6020]. The reason for this is that otherwise it is not
including version 1, can be mounted under a mount point. possible to invoke mounted RPC operations, and receive mounted
notifications. See Section 5 for details. Note, however, that
modules written in any YANG version, including version 1, can be
mounted under a mount point.
Note that the "mount-point" statement does not define a new data Note that the "mount-point" statement does not define a new data
node. node.
3.2. Specification of the Mounted Schema 3.2. Data Model
This document defines the YANG 1.1 module [RFC7950]
"ietf-yang-schema-mount", which has the following structure:
module: ietf-yang-schema-mount
+--ro schema-mounts
+--ro namespace* [prefix]
| +--ro prefix yang:yang-identifier
| +--ro uri? inet:uri
+--ro mount-point* [module label]
+--ro module yang:yang-identifier
+--ro label yang:yang-identifier
+--ro config? boolean
+--ro (schema-ref)
+--:(inline)
| +--ro inline!
+--:(shared-schema)
+--ro shared-schema!
+--ro parent-reference* yang:xpath1.0
3.3. Specification of the Mounted Schema
Mounted schemas for all mount points in the parent schema are Mounted schemas for all mount points in the parent schema are
determined from state data in the "yangmnt:schema-mounts" container. determined from state data in the "/schema-mounts" container.
Data in this container is intended to be as stable as data in the
top-level YANG library.
Generally, the modules that are mounted under a mount point have no Generally, the modules that are mounted under a mount point have no
relation to the modules in the parent schema; specifically, if a relation to the modules in the parent schema; specifically, if a
module is mounted it may or may not be present in the parent schema module is mounted it may or may not be present in the parent schema
and, if present, its data will generally have no relationship to the and, if present, its data will generally have no relationship to the
data of the parent. Exceptions are possible and such needs to be data of the parent. Exceptions are possible and such needs to be
defined in the model defining the exception, e.g., the interface defined in the model defining the exception. For example,
module in [I-D.ietf-rtgwg-lne-model]. [I-D.ietf-rtgwg-lne-model] defines a mechanism to bind interfaces to
mounted logical network elements.
The "schema-mounts" container has the "mount-point" list as one of The "/schema-mounts" container has the "mount-point" list as one of
its children. Every entry of this list refers through its key to a its children. Every entry of this list refers through its key to a
mount point and specifies the mounted schema. mount point and specifies the mounted schema.
If a mount point is defined in the parent schema but does not have an If a mount point is defined in the parent schema but does not have an
entry in the "mount-point" list, then the mounted schema is void, entry in the "mount-point" list, then the mounted schema is void,
i.e., instances of that mount point MUST NOT contain any data above i.e., instances of that mount point MUST NOT contain any data except
those that are defined in the parent schema. those that are defined in the parent schema.
If multiple mount points with the same name are defined in the same If multiple mount points with the same name are defined in the same
module - either directly or because the mount point is defined in a module - either directly or because the mount point is defined in a
grouping and the grouping is used multiple times - then the grouping and the grouping is used multiple times - then the
corresponding "mount-point" entry applies equally to all such mount corresponding "mount-point" entry applies equally to all such mount
points. points.
The "config" property of mounted schema nodes is overridden and all The "config" property of mounted schema nodes is overridden and all
nodes in the mounted schema are read-only ("config false") if at nodes in the mounted schema are read-only ("config false") if at
skipping to change at page 8, line 26 skipping to change at page 9, line 22
o the "config" leaf in the corresponding entry of the "mount-point" o the "config" leaf in the corresponding entry of the "mount-point"
list is set to "false". list is set to "false".
An entry of the "mount-point" list can specify the mounted schema in An entry of the "mount-point" list can specify the mounted schema in
two different ways, "inline" or "shared-schema". two different ways, "inline" or "shared-schema".
The mounted schema is determined at run time: every instance of the The mounted schema is determined at run time: every instance of the
mount point that exists in the operational state MUST contain a copy mount point that exists in the operational state MUST contain a copy
of YANG library data that defines the mounted schema exactly as for a of YANG library data that defines the mounted schema exactly as for a
top-level data model. A client is expected to retrieve this data top-level schema. A client is expected to retrieve this data from
from the instance tree, possibly after creating the mount point. In the instance tree. In the "inline" case, instances of the same mount
the "inline" case, instances of the same mount point MAY use point MAY use different mounted schemas, whereas in the
different mounted schemas, whereas in the "shared-schema" case, all "shared-schema" case, all instances MUST use the same mounted schema.
instances MUST use the same mounted schema. This means that in the "shared-schema" case, all instances of the
same mount point MUST have the same YANG library checksum. In the
"inline" case, if two instances have the same YANG library checksum
it is not guaranteed that the YANG library contents are equal for
these instances.
3.3. Multiple Levels of Schema Mount 3.4. Multiple Levels of Schema Mount
YANG modules in a mounted schema MAY again contain mount points under YANG modules in a mounted schema MAY again contain mount points under
which subschemas can be mounted. Consequently, it is possible to which other schemas can be mounted. Consequently, it is possible to
construct data models with an arbitrary number of schema levels. A construct data models with an arbitrary number of mounted schemas. A
subschema for a mount point contained in a mounted module can be schema for a mount point contained in a mounted module can be
specified by implementing "ietf-yang-library" and specified by implementing "ietf-yang-library" and
"ietf-yang-schema-mount" modules in the mounted schema, and "ietf-yang-schema-mount" modules in the mounted schema, and
specifying the subschemas exactly as it is done in the top-level specifying the schemas exactly as it is done in the top-level schema.
schema.
4. Referring to Data Nodes in the Parent Schema 4. Referring to Data Nodes in the Parent Schema
A fundamental design principle of schema mount is that the mounted A fundamental design principle of schema mount is that the mounted
data model works exactly as a top-level data model, i.e., it is schema works exactly as a top-level schema, i.e., it is confined to
confined to the "mount jail". This means that all paths in the the "mount jail". This means that all paths in the mounted schema
mounted data model (in leafrefs, instance-identifiers, XPath (in leafrefs, instance-identifiers, XPath expressions, and target
expressions, and target nodes of augments) are interpreted with the nodes of augments) are interpreted with the mount point as the root
mount point as the root node. YANG modules of the mounted schema as node. YANG modules of the mounted schema as well as corresponding
well as corresponding instance data thus cannot refer to schema nodes instance data thus cannot refer to schema nodes or instance data
or instance data outside the mount jail. outside the mount jail.
However, this restriction is sometimes too severe. A typical example However, this restriction is sometimes too severe. A typical example
is network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI is network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI
has its own routing engine but the list of interfaces is global and has its own routing engine but the list of interfaces is global and
shared by all NIs. If we want to model this organization with the NI shared by all NIs. If we want to model this organization with the NI
schema mounted using schema mount, the overall schema tree would look schema mounted using schema mount, the overall schema tree would look
schematically as follows: schematically as follows:
+--rw interfaces +--rw interfaces
| +--rw interface* [name] | +--rw interface* [name]
skipping to change at page 10, line 29 skipping to change at page 11, line 29
The schema mount solution presented in this document is designed to The schema mount solution presented in this document is designed to
work both with servers that implement the NMDA [RFC8342], and old work both with servers that implement the NMDA [RFC8342], and old
servers that don't implement the NMDA. servers that don't implement the NMDA.
Note to RFC Editor: please update the date YYYY-MM-DD below with the Note to RFC Editor: please update the date YYYY-MM-DD below with the
revision of the ietf-yang-library in the published version of draft- revision of the ietf-yang-library in the published version of draft-
ietf-netconf-rfc7895bis, and remove this note. ietf-netconf-rfc7895bis, and remove this note.
Specifically, a server that doesn't support the NMDA, MAY implement Specifically, a server that doesn't support the NMDA, MAY implement
revision 2016-06-21 of "ietf-yang-library" [RFC7950] under a mount revision 2016-06-21 of "ietf-yang-library" [RFC7895] under a mount
point. A server that supports the NMDA, MUST implement at least point. A server that supports the NMDA, MUST implement at least
revision YYYY-MM-DD of "ietf-yang-library" revision YYYY-MM-DD of "ietf-yang-library"
[I-D.ietf-netconf-rfc7895bis] under the mount points. [I-D.ietf-netconf-rfc7895bis] under the mount points.
7. Implementation Notes 7. Interaction with the Network Configuration Access Control Model
(NACM)
If NACM [RFC8341] is implemented on a server, it can be used to
control access to nodes defined by the mounted schema in the same way
as for nodes defined by the top-level schema.
For example, suppose the module "ietf-interfaces" is mounted in the
"root" container in the "logical-network-element" list defined in
[I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used
to control access to the "interfaces" container (where the character
'\' is used where a line break has been inserted for formatting
reasons):
<path xmlns:lne=
"urn:ietf:params:xml:ns:yang:ietf-logical-network-element"
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
/lne:logical-network-elements\
/lne:logical-network-element/lne:root/if:interfaces
</path>
8. Implementation Notes
Network management of devices that use a data model with schema mount Network management of devices that use a data model with schema mount
can be implemented in different ways. However, the following can be implemented in different ways. However, the following
implementations options are envisioned as typical: implementations options are envisioned as typical:
o shared management: instance data of both parent and mounted o shared management: instance data of both parent and mounted
schemas are accessible within the same management session. schemas are accessible within the same management session.
o split management: one (master) management session has access to o split management: one (master) management session has access to
instance data of both parent and mounted schemas but, in addition, instance data of both parent and mounted schemas but, in addition,
an extra session exists for every instance of the mount point, an extra session exists for every instance of the mount point,
having access only to the mounted data tree. having access only to the mounted data tree.
8. Data Model
This document defines the YANG 1.1 module [RFC7950]
"ietf-yang-schema-mount", which has the following structure:
module: ietf-yang-schema-mount
+--ro schema-mounts
+--ro namespace* [prefix]
| +--ro prefix yang:yang-identifier
| +--ro uri? inet:uri
+--ro mount-point* [module label]
+--ro module yang:yang-identifier
+--ro label yang:yang-identifier
+--ro config? boolean
+--ro (schema-ref)
+--:(inline)
| +--ro inline!
+--:(shared-schema)
+--ro shared-schema!
+--ro parent-reference* yang:xpath1.0
9. Schema Mount YANG Module 9. Schema Mount YANG Module
This module references [RFC6991]. This module references [RFC6991].
<CODE BEGINS> file "ietf-yang-schema-mount@2017-10-09.yang" <CODE BEGINS> file "ietf-yang-schema-mount@2018-04-05"
module ietf-yang-schema-mount { module ietf-yang-schema-mount {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount";
prefix yangmnt; prefix yangmnt;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
skipping to change at page 12, line 8 skipping to change at page 13, line 13
contact contact
"WG Web: <https://tools.ietf.org/wg/netmod/> "WG Web: <https://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Editor: Martin Bjorklund Editor: Martin Bjorklund
<mailto:mbj@tail-f.com> <mailto:mbj@tail-f.com>
Editor: Ladislav Lhotka Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>"; <mailto:lhotka@nic.cz>";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note.
description description
"This module defines a YANG extension statement that can be used "This module defines a YANG extension statement that can be used
to incorporate data models defined in other YANG modules in a to incorporate data models defined in other YANG modules in a
module. It also defines operational state data that specify the module. It also defines operational state data that specify the
overall structure of the data model. overall structure of the data model.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
skipping to change at page 12, line 33 skipping to change at page 13, line 40
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
'OPTIONAL' in the module text are to be interpreted as described 'OPTIONAL' in the module text are to be interpreted as described
in RFC 2119 (https://tools.ietf.org/html/rfc2119). in RFC 2119 (https://tools.ietf.org/html/rfc2119).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
full legal notices."; full legal notices.";
revision 2018-03-20 { // RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
revision 2018-04-05 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Schema Mount"; "RFC XXXX: YANG Schema Mount";
} }
/* /*
* Extensions * Extensions
*/ */
skipping to change at page 15, line 41 skipping to change at page 16, line 52
Section 10 of [RFC7950]. Section 10 of [RFC7950].
- The set of namespace declarations is defined by the - The set of namespace declarations is defined by the
'namespace' list under 'schema-mounts'. 'namespace' list under 'schema-mounts'.
Each XPath expression MUST evaluate to a nodeset Each XPath expression MUST evaluate to a nodeset
(possibly empty). For the purposes of evaluating XPath (possibly empty). For the purposes of evaluating XPath
expressions whose context nodes are defined in the expressions whose context nodes are defined in the
mounted schema, the union of all these nodesets mounted schema, the union of all these nodesets
together with ancestor nodes are added to the together with ancestor nodes are added to the
accessible data tree."; 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.";
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
10. IANA Considerations 10. IANA Considerations
skipping to change at page 17, line 33 skipping to change at page 18, line 47
o Eric Voit, Cisco, <evoit@cisco.com> o Eric Voit, Cisco, <evoit@cisco.com>
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-netconf-rfc7895bis] [I-D.ietf-netconf-rfc7895bis]
Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", draft-ietf-netconf- and R. Wilton, "YANG Library", draft-ietf-netconf-
rfc7895bis-05 (work in progress), February 2018. rfc7895bis-06 (work in progress), April 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
editor.org/info/rfc3688>. editor.org/info/rfc3688>.
skipping to change at page 18, line 26 skipping to change at page 19, line 35
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<https://www.rfc-editor.org/info/rfc7895>. <https://www.rfc-editor.org/info/rfc7895>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, <https://www.rfc- DOI 10.17487/RFC8341, March 2018, <https://www.rfc-
editor.org/info/rfc8341>. editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
skipping to change at page 19, line 8 skipping to change at page 20, line 25
isis-yang-isis-cfg-19 (work in progress), November 2017. isis-yang-isis-cfg-19 (work in progress), November 2017.
[I-D.ietf-rtgwg-device-model] [I-D.ietf-rtgwg-device-model]
Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
"Network Device YANG Logical Organization", draft-ietf- "Network Device YANG Logical Organization", draft-ietf-
rtgwg-device-model-02 (work in progress), March 2017. rtgwg-device-model-02 (work in progress), March 2017.
[I-D.ietf-rtgwg-lne-model] [I-D.ietf-rtgwg-lne-model]
Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Model for Logical Network Elements", draft- Liu, "YANG Model for Logical Network Elements", draft-
ietf-rtgwg-lne-model-09 (work in progress), March 2018. ietf-rtgwg-lne-model-10 (work in progress), March 2018.
[I-D.ietf-rtgwg-ni-model] [I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Model for Network Instances", draft-ietf-rtgwg- Liu, "YANG Model for Network Instances", draft-ietf-rtgwg-
ni-model-11 (work in progress), March 2018. ni-model-12 (work in progress), March 2018.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
skipping to change at page 19, line 39 skipping to change at page 21, line 12
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>. <https://www.rfc-editor.org/info/rfc8343>.
Appendix A. Example: Device Model with LNEs and NIs Appendix A. Example: Device Model with LNEs and NIs
This non-normative example demonstrates an implementation of the This non-normative example demonstrates an implementation of the
device model as specified in Section 2 of device model as specified in Section 2 of
[I-D.ietf-rtgwg-device-model], using both logical network elements [I-D.ietf-rtgwg-device-model], using both logical network elements
(LNE) and network instances (NI). (LNE) and network instances (NI).
In these examples, the character "\" is used where a line break has In these examples, the character '\' is used where a line break has
been inserted for formatting reasons. been inserted for formatting reasons.
A.1. Physical Device A.1. Physical Device
The data model for the physical device may be described by this YANG The data model for the physical device may be described by this YANG
library content, assuming the server supports the NMDA: library content, assuming the server supports the NMDA:
{ {
"ietf-yang-library:yang-library": { "ietf-yang-library:yang-library": {
"checksum": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899", "checksum": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
"module-set": [ "module-set": [
{ {
"name": "physical-device-modules", "name": "physical-device-modules",
"module": [ "module": [
{ {
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
},
{
"name": "iana-if-type", "name": "iana-if-type",
"revision": "2015-06-12", "revision": "2015-06-12",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type" "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type"
}, },
{ {
"name": "ietf-interfaces", "name": "ietf-interfaces",
"revision": "2018-02-20", "revision": "2018-02-20",
"feature": ["arbitrary-names", "pre-provisioning" ], "feature": ["arbitrary-names", "pre-provisioning" ],
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces" "urn:ietf:params:xml:ns:yang:ietf-interfaces"
skipping to change at page 21, line 7 skipping to change at page 22, line 34
"name": "ietf-inet-types", "name": "ietf-inet-types",
"revision": "2013-07-15", "revision": "2013-07-15",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types" "urn:ietf:params:xml:ns:yang:ietf-inet-types"
}, },
{ {
"name": "ietf-yang-types", "name": "ietf-yang-types",
"revision": "2013-07-15", "revision": "2013-07-15",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types" "urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
} }
] ]
} }
], ],
"schema": [ "schema": [
{ {
"name": "physical-device-schema", "name": "physical-device-schema",
"module-set": [ "physical-device-modules" ] "module-set": [ "physical-device-modules" ]
} }
], ],
 End of changes. 51 change blocks. 
125 lines changed or deleted 188 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/