draft-ietf-netmod-schema-mount-06.txt   draft-ietf-netmod-schema-mount-07.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: January 6, 2018 CZ.NIC Expires: March 31, 2018 CZ.NIC
July 5, 2017 September 27, 2017
YANG Schema Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-06 draft-ietf-netmod-schema-mount-07
Abstract Abstract
This document defines a mechanism to combine YANG modules into the This document defines a mechanism to combine YANG modules into the
schema defined in other YANG modules. schema defined in other YANG modules.
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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 January 6, 2018. This Internet-Draft will expire on March 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 21 skipping to change at page 2, line 21
3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7
3.2. Specification of the Mounted Schema . . . . . . . . . . . 7 3.2. Specification of the Mounted Schema . . . . . . . . . . . 7
3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9 3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9
4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9 4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9
5. RPC operations and Notifications . . . . . . . . . . . . . . 10 5. RPC operations and Notifications . . . . . . . . . . . . . . 10
6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 11 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 11
7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 13 8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Example: Device Model with LNEs and NIs . . . . . . 20 Appendix A. Example: Device Model with LNEs and NIs . . . . . . 21
A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21 A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21
A.2. Logical Network Elements . . . . . . . . . . . . . . . . 22 A.2. Logical Network Elements . . . . . . . . . . . . . . . . 22
A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25 A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25
A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 26 A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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. Note, however, that modules written in any YANG version,
including version 1, can be mounted under a mount point. including version 1, can be mounted under a mount point.
Note that the "mount-point" statement does not define a new data
node.
3.2. Specification of the Mounted Schema 3.2. 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 "yangmnt:schema-mounts" container.
Data in this container is intended to be as stable as data in the Data in this container is intended to be as stable as data in the
top-level YANG library [RFC7895]. In particular, it SHOULD NOT top-level YANG library [RFC7895]. In particular, it SHOULD NOT
change during the same management session. change during the same management session.
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
skipping to change at page 10, line 25 skipping to change at page 10, line 25
Here, the "root" node is the mount point for the NI schema. Routing Here, the "root" node is the mount point for the NI schema. Routing
configuration inside an NI often needs to refer to interfaces (at configuration inside an NI often needs to refer to interfaces (at
least those that are assigned to the NI), which is impossible unless least those that are assigned to the NI), which is impossible unless
such a reference can point to a node in the parent schema (interface such a reference can point to a node in the parent schema (interface
name). name).
Therefore, schema mount also allows for such references. For every Therefore, schema mount also allows for such references. For every
schema mounted using the "use-schema" method, it is possible to schema mounted using the "use-schema" method, it is possible to
specify a leaf-list named "parent-reference" that contains zero or specify a leaf-list named "parent-reference" that contains zero or
more XPath 1.0 expressions. Each expression is evaluated with the more XPath 1.0 expressions. Each expression is evaluated with the
root of the parent data tree as the context node and the result MUST node in the parent data tree where the mount point is defined as the
be a nodeset (see the description of the "parent-reference" node for context node. The result of this evaluation MUST be a nodeset (see
a complete definition of the evaluation context). For the purposes the description of the "parent-reference" node for a complete
of evaluating XPath expressions within the mounted data tree, the definition of the evaluation context). For the purposes of
union of all such nodesets is added to the accessible data tree. evaluating XPath expressions within the mounted data tree, the union
of all such nodesets is added to the accessible data tree.
It is worth emphasizing that It is worth emphasizing that
o The nodes specified in "parent-reference" leaf-list are available o The nodes specified in "parent-reference" leaf-list are available
in the mounted schema only for XPath evaluations. In particular, in the mounted schema only for XPath evaluations. In particular,
they cannot be accessed there via network management protocols they cannot be accessed there via network management protocols
such as NETCONF [RFC6241] or RESTCONF [RFC8040]. such as NETCONF [RFC6241] or RESTCONF [RFC8040].
o The mechanism of referencing nodes in the parent schema is not o The mechanism of referencing nodes in the parent schema is not
available for schemas mounted using the "inline" method. available for schemas mounted using the "inline" method.
skipping to change at page 12, line 14 skipping to change at page 12, line 14
module: ietf-yang-schema-mount module: ietf-yang-schema-mount
+--ro schema-mounts +--ro schema-mounts
+--ro namespace* [prefix] +--ro namespace* [prefix]
| +--ro prefix yang:yang-identifier | +--ro prefix yang:yang-identifier
| +--ro uri? inet:uri | +--ro uri? inet:uri
+--ro mount-point* [module name] +--ro mount-point* [module name]
| +--ro module yang:yang-identifier | +--ro module yang:yang-identifier
| +--ro name yang:yang-identifier | +--ro name yang:yang-identifier
| +--ro config? boolean | +--ro config? boolean
| +--ro (schema-ref)? | +--ro (schema-ref)
| +--:(inline) | +--:(inline)
| | +--ro inline? empty | | +--ro inline? empty
| +--:(use-schema) | +--:(use-schema)
| +--ro use-schema* [name] | +--ro use-schema* [name]
| +--ro name | +--ro name
| | -> /schema-mounts/schema/name | | -> /schema-mounts/schema/name
| +--ro parent-reference* yang:xpath1.0 | +--ro parent-reference* yang:xpath1.0
+--ro schema* [name] +--ro schema* [name]
+--ro name string +--ro name string
+--ro module* [name revision] +--ro module* [name revision]
skipping to change at page 12, line 42 skipping to change at page 12, line 42
| | +--ro revision union | | +--ro revision union
| +--ro conformance-type enumeration | +--ro conformance-type enumeration
| +--ro submodule* [name revision] | +--ro submodule* [name revision]
| +--ro name yang:yang-identifier | +--ro name yang:yang-identifier
| +--ro revision union | +--ro revision union
| +--ro schema? inet:uri | +--ro schema? inet:uri
+--ro mount-point* [module name] +--ro mount-point* [module name]
+--ro module yang:yang-identifier +--ro module yang:yang-identifier
+--ro name yang:yang-identifier +--ro name yang:yang-identifier
+--ro config? boolean +--ro config? boolean
+--ro (schema-ref)? +--ro (schema-ref)
+--:(inline) +--:(inline)
| +--ro inline? empty | +--ro inline? empty
+--:(use-schema) +--:(use-schema)
+--ro use-schema* [name] +--ro use-schema* [name]
+--ro name +--ro name
| -> /schema-mounts/schema/name | -> /schema-mounts/schema/name
+--ro parent-reference* yang:xpath1.0 +--ro parent-reference* yang:xpath1.0
8. Schema Mount YANG Module 8. Schema Mount YANG Module
This module references [RFC6991] and [RFC7895]. This module references [RFC6991] and [RFC7895].
<CODE BEGINS> file "ietf-yang-schema-mount@2017-06-16.yang" <CODE BEGINS> file "ietf-yang-schema-mount@2017-09-27.yang"
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 14, line 24 skipping to change at page 14, line 24
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 2017-06-16 { revision 2017-09-27 {
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 14, line 47 skipping to change at page 14, line 47
description description
"The argument 'name' is a YANG identifier, i.e., it is of the "The argument 'name' is a YANG identifier, i.e., it is of the
type 'yang:yang-identifier'. type 'yang:yang-identifier'.
The 'mount-point' statement MUST NOT be used in a YANG The 'mount-point' statement MUST NOT be used in a YANG
version 1 module, neither explicitly nor via a 'uses' version 1 module, neither explicitly nor via a 'uses'
statement. statement.
The 'mount-point' statement MAY be present as a substatement The 'mount-point' statement MAY be present as a substatement
of 'container' and 'list', and MUST NOT be present elsewhere. 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 in a grouping, its name is bound If a mount point is defined within a grouping, its name is
to the module where the grouping is used. bound to the module where the grouping is used.
A mount point defines a place in the node hierarchy where A mount point defines a place in the node hierarchy where
other data models may be attached. A server that implements a other data models may be attached. A server that implements a
module with a mount point populates the module with a mount point populates the
/schema-mounts/mount-point list with detailed information on /schema-mounts/mount-point list with detailed information on
which data models are mounted at each mount point."; which data models are mounted at each mount point.
Note that the 'mount-point' statement does not define a new
data node.";
} }
/* /*
* Groupings * Groupings
*/ */
grouping mount-point-list { grouping mount-point-list {
description description
"This grouping is used inside the 'schema-mounts' container and "This grouping is used inside the 'schema-mounts' container and
inside the 'schema' list."; inside the 'schema' list.";
skipping to change at page 16, line 4 skipping to change at page 16, line 9
"Name of the mount point defined using the 'mount-point' "Name of the mount point defined using the 'mount-point'
extension."; extension.";
} }
leaf config { leaf config {
type boolean; type boolean;
default "true"; default "true";
description description
"If this leaf is set to 'false', then all data nodes in the "If this leaf is set to 'false', then all data nodes in the
mounted schema are read-only (config false), regardless of mounted schema are read-only (config false), regardless of
their 'config' property."; their 'config' property.";
} }
choice schema-ref { choice schema-ref {
mandatory true;
description description
"Alternatives for specifying the schema."; "Alternatives for specifying the schema.";
leaf inline { leaf inline {
type empty; type empty;
description description
"This leaf indicates that the server has mounted "This leaf indicates that the server has mounted
'ietf-yang-library' and 'ietf-schema-mount' at the mount 'ietf-yang-library' and 'ietf-schema-mount' at the mount
point, and their instantiation (i.e., state data point, and their instantiation (i.e., state data
containers 'yanglib:modules-state' and 'schema-mounts') containers 'yanglib:modules-state' and 'schema-mounts')
provides the information about the mounted schema."; provides the information about the mounted schema.";
} }
list use-schema { list use-schema {
key "name"; key "name";
min-elements 1;
description description
"Each entry of this list contains a reference to a schema "Each entry of this list contains a reference to a schema
defined in the /schema-mounts/schema list."; defined in the /schema-mounts/schema list.";
leaf name { leaf name {
type leafref { type leafref {
path "/schema-mounts/schema/name"; path "/schema-mounts/schema/name";
} }
description description
"Name of the referenced schema."; "Name of the referenced schema.";
} }
leaf-list parent-reference { leaf-list parent-reference {
type yang:xpath1.0; type yang:xpath1.0;
description description
"Entries of this leaf-list are XPath 1.0 expressions "Entries of this leaf-list are XPath 1.0 expressions
that are evaluated in the following context: that are evaluated in the following context:
- The context node is the root node of the parent data - The context node is the node in the parent data tree
tree. where the mount-point is defined.
- The accessible tree is the parent data tree - The accessible tree is the parent data tree
*without* any nodes defined in modules that are *without* any nodes defined in modules that are
mounted inside the parent schema. mounted inside the parent schema.
- The context position and context size are both equal - The context position and context size are both equal
to 1. to 1.
- The set of variable bindings is empty. - The set of variable bindings is empty.
skipping to change at page 18, line 44 skipping to change at page 19, line 7
This document registers a YANG module in the YANG Module Names This document registers a YANG module in the YANG Module Names
registry [RFC6020]. registry [RFC6020].
name: ietf-yang-schema-mount name: ietf-yang-schema-mount
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
reference: RFC XXXX reference: RFC XXXX
10. Security Considerations 10. Security Considerations
TBD This document defines a mechanism for combining schemas from
different YANG modules into a single schema, and as such doesn't
introduce new security issues.
11. Contributors 11. Contributors
The idea of having some way to combine schemas from different YANG The idea of having some way to combine schemas from different YANG
modules into one has been proposed independently by several groups of modules into one has been proposed independently by several groups of
people: Alexander Clemm, Jan Medved, and Eric Voit people: Alexander Clemm, Jan Medved, and Eric Voit
([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps: ([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps:
o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net> o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
skipping to change at page 19, line 20 skipping to change at page 19, line 33
o Jan Medved, Cisco, <jmedved@cisco.com> o Jan Medved, Cisco, <jmedved@cisco.com>
o Eric Voit, Cisco, <evoit@cisco.com> o Eric Voit, Cisco, <evoit@cisco.com>
12. References 12. References
12.1. Normative References 12.1. Normative References
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-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, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>. <http://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,
<http://www.rfc-editor.org/info/rfc7895>. <http://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,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
skipping to change at page 20, line 12 skipping to change at page 20, line 23
Information from Remote Datastores", draft-clemm-netmod- Information from Remote Datastores", draft-clemm-netmod-
mount-06 (work in progress), March 2017. mount-06 (work in progress), March 2017.
[I-D.ietf-isis-yang-isis-cfg] [I-D.ietf-isis-yang-isis-cfg]
Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L. Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.
Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf- Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-
isis-yang-isis-cfg-17 (work in progress), March 2017. isis-yang-isis-cfg-17 (work in progress), March 2017.
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-01 (work in progress), June ietf-netmod-yang-tree-diagrams-00 (work in progress), June
2017. 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., and D. Bogdanovic,
Liu, "YANG Logical Network Elements", draft-ietf-rtgwg- "YANG Logical Network Elements", draft-ietf-rtgwg-lne-
lne-model-03 (work in progress), July 2017. model-02 (work in progress), March 2017.
[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., and D. Bogdanovic,
Liu, "YANG Network Instances", draft-ietf-rtgwg-ni- "YANG Network Instances", draft-ietf-rtgwg-ni-model-02
model-03 (work in progress), July 2017. (work in progress), March 2017.
[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,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <http://www.rfc-editor.org/info/rfc7223>.
skipping to change at page 25, line 41 skipping to change at page 25, line 41
A.3. Network Instances A.3. Network Instances
Assuming that network instances share the same data model, it can be Assuming that network instances share the same data model, it can be
mounted using the "use-schema" method as follows: mounted using the "use-schema" method as follows:
"ietf-yang-schema-mount:schema-mounts": { "ietf-yang-schema-mount:schema-mounts": {
"namespace": [ "namespace": [
{ {
"prefix": "if", "prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
} }
], ],
"mount-point": [ "mount-point": [
{ {
"module": "ietf-network-instance", "module": "ietf-network-instance",
"name": "root", "name": "root",
"use-schema": [ "use-schema": [
{ {
"name": "ni-schema", "name": "ni-schema",
"parent-reference": ["/if:interfaces"] "parent-reference": [
"/if:interfaces/if:interface[
ni:bind-network-instance-name = current()/../ni:name]"
]
} }
] ]
} }
], ],
"schema": [ "schema": [
{ {
"name": "ni-schema", "name": "ni-schema",
"module": [ "module": [
{ {
"name": "ietf-ipv4-unicast-routing", "name": "ietf-ipv4-unicast-routing",
"revision": "2016-11-04", "revision": "2016-11-04",
 End of changes. 28 change blocks. 
38 lines changed or deleted 56 lines changed or added

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