draft-ietf-netmod-schema-mount-07.txt   draft-ietf-netmod-schema-mount-08.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: March 31, 2018 CZ.NIC Expires: April 24, 2018 CZ.NIC
September 27, 2017 October 21, 2017
YANG Schema Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-07 draft-ietf-netmod-schema-mount-08
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 March 31, 2018. This Internet-Draft will expire on April 24, 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 12 skipping to change at page 2, line 12
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. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6
3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 5, line 39 skipping to change at page 5, line 39
o notification o notification
o server o server
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 configuration data
o container o container
o list o list
o operation o operation
The following terms are defined in [RFC7223] and are not redefined The following terms are defined in [RFC7223] and are not redefined
here: here:
o system-controlled interface o system-controlled interface
skipping to change at page 6, line 14 skipping to change at page 6, line 12
Tree diagrams used in this document follow the notation defined in Tree diagrams used in this document follow the notation defined in
[I-D.ietf-netmod-yang-tree-diagrams]. [I-D.ietf-netmod-yang-tree-diagrams].
2.1. Glossary of New Terms 2.1. Glossary of New Terms
o inline schema: a mounted schema whose definition is provided as o inline schema: a mounted schema whose definition is provided as
part of the mounted data, using YANG library [RFC7895]. part of the mounted data, using YANG library [RFC7895].
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 the name of 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 parent schema (of a particular mounted schema): the schema that
contains the mount point for the mounted schema. contains the mount point for the mounted schema.
o top-level schema: a schema according to [RFC7950] in which schema o top-level schema: a schema according to [RFC7950] in which schema
trees of each module (except augments) start at the root node. trees of each module (except augments) start at the root node.
2.2. Namespace Prefixes 2.2. Namespace Prefixes
In this document, names of data nodes, YANG extensions, actions and In this document, names of data nodes, YANG extensions, actions and
skipping to change at page 7, line 13 skipping to change at page 7, line 8
described in the following subsections. described in the following subsections.
3.1. Mount Point Definition 3.1. Mount Point Definition
A "container" or "list" node becomes a mount point if the A "container" or "list" node becomes a mount point if the
"mount-point" extension (defined in the "ietf-yang-schema-mount" "mount-point" extension (defined in the "ietf-yang-schema-mount"
module) is used in its definition. This extension can appear only as module) is used in its definition. This extension can appear only as
a substatement of "container" and "list" statements. a substatement of "container" and "list" statements.
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 the name of 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. 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.
skipping to change at page 12, line 10 skipping to change at page 12, line 10
7. Data Model 7. Data Model
This document defines the YANG 1.1 module [RFC7950] This document defines the YANG 1.1 module [RFC7950]
"ietf-yang-schema-mount", which has the following structure: "ietf-yang-schema-mount", which has the following structure:
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 label]
| +--ro module yang:yang-identifier | +--ro module yang:yang-identifier
| +--ro name yang:yang-identifier | +--ro label 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]
skipping to change at page 12, line 38 skipping to change at page 12, line 38
| +--ro namespace inet:uri | +--ro namespace inet:uri
| +--ro feature* yang:yang-identifier | +--ro feature* yang:yang-identifier
| +--ro deviation* [name revision] | +--ro deviation* [name revision]
| | +--ro name yang:yang-identifier | | +--ro name yang:yang-identifier
| | +--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 label]
+--ro module yang:yang-identifier +--ro module yang:yang-identifier
+--ro name yang:yang-identifier +--ro label 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-09-27.yang" <CODE BEGINS> file "ietf-yang-schema-mount@2017-10-09.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-09-27 { revision 2017-10-09 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Schema Mount"; "RFC XXXX: YANG Schema Mount";
} }
/* /*
* Extensions * Extensions
*/ */
extension mount-point { extension mount-point {
argument name; argument label;
description description
"The argument 'name' is a YANG identifier, i.e., it is of the "The argument 'label' 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 There MUST NOT be more than one 'mount-point' statement in a
given 'container' or 'list' statement. given 'container' or 'list' statement.
If a mount point is defined within a grouping, its name is If a mount point is defined within a grouping, its label is
bound 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 Note that the 'mount-point' statement does not define a new
data node."; data node.";
skipping to change at page 15, line 24 skipping to change at page 15, line 24
/* /*
* 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.";
list mount-point { list mount-point {
key "module name"; key "module label";
description description
"Each entry of this list specifies a schema for a particular "Each entry of this list specifies a schema for a particular
mount point. mount point.
Each mount point MUST be defined using the 'mount-point' Each mount point MUST be defined using the 'mount-point'
extension in one of the modules listed in the corresponding extension in one of the modules listed in the corresponding
YANG library instance with conformance type 'implement'. The YANG library instance with conformance type 'implement'. The
corresponding YANG library instance is: corresponding YANG library instance is:
- standard YANG library state data as defined in RFC 7895, - standard YANG library state data as defined in RFC 7895,
if the 'mount-point' list is a child of 'schema-mounts', if the 'mount-point' list is a child of 'schema-mounts',
- the contents of the sibling 'yanglib:modules-state' - the contents of the sibling 'yanglib:modules-state'
container, if the 'mount-point' list is a child of container, if the 'mount-point' list is a child of
'schema'."; 'schema'.";
leaf module { leaf module {
type yang:yang-identifier; type yang:yang-identifier;
description description
"Name of a module containing the mount point."; "Name of a module containing the mount point.";
} }
leaf name { leaf label {
type yang:yang-identifier; type yang:yang-identifier;
description description
"Name of the mount point defined using the 'mount-point' "Label 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.";
} }
skipping to change at page 19, line 33 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, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, 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", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC
RFC 6991, DOI 10.17487/RFC6991, July 2013, 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 23 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-00 (work in progress), June ietf-netmod-yang-tree-diagrams-01 (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., and D. Bogdanovic, Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
"YANG Logical Network Elements", draft-ietf-rtgwg-lne- Liu, "YANG Logical Network Elements", draft-ietf-rtgwg-
model-02 (work in progress), March 2017. lne-model-03 (work in progress), July 2017.
[I-D.ietf-rtgwg-ni-model] [I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
"YANG Network Instances", draft-ietf-rtgwg-ni-model-02 Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-
(work in progress), March 2017. model-03 (work in progress), July 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 22, line 42 skipping to change at page 22, line 42
A.2. Logical Network Elements A.2. Logical Network Elements
Each LNE can have a specific data model that is determined at run 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, time, so it is appropriate to mount it using the "inline" method,
hence the following "schema-mounts" data: hence the following "schema-mounts" data:
"ietf-yang-schema-mount:schema-mounts": { "ietf-yang-schema-mount:schema-mounts": {
"mount-point": [ "mount-point": [
{ {
"module": "ietf-logical-network-element", "module": "ietf-logical-network-element",
"name": "root", "label": "root",
"inline": [null] "inline": [null]
} }
] ]
} }
An administrator of the host device has to configure an entry for An administrator of the host device has to configure an entry for
each LNE instance, for example, each LNE instance, for example,
{ {
"ietf-interfaces:interfaces": { "ietf-interfaces:interfaces": {
"interface": [ "interface": [
skipping to change at page 25, line 50 skipping to change at page 25, line 50
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
}, },
{ {
"prefix": "ni", "prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
} }
], ],
"mount-point": [ "mount-point": [
{ {
"module": "ietf-network-instance", "module": "ietf-network-instance",
"name": "root", "label": "root",
"use-schema": [ "use-schema": [
{ {
"name": "ni-schema", "name": "ni-schema",
"parent-reference": [ "parent-reference": [
"/if:interfaces/if:interface[ "/if:interfaces/if:interface[
ni:bind-network-instance-name = current()/../ni:name]" ni:bind-network-instance-name = current()/../ni:name]"
] ]
} }
] ]
} }
 End of changes. 26 change blocks. 
34 lines changed or deleted 32 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/