draft-ietf-netmod-schema-mount-11.txt   draft-ietf-netmod-schema-mount-12.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: February 8, 2019 CZ.NIC Expires: April 20, 2019 CZ.NIC
August 7, 2018 October 17, 2018
YANG Schema Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-11 draft-ietf-netmod-schema-mount-12
Abstract Abstract
This document defines a mechanism to add the schema trees defined by This document defines a mechanism to add the schema trees defined by
a set of YANG modules onto a mount point defined in the schema tree a set of YANG modules onto a mount point defined in the schema tree
in some YANG module. 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 February 8, 2019. This Internet-Draft will expire on April 20, 2019.
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 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6 2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6
3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7
3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Specification of the Mounted Schema . . . . . . . . . . . 8 3.3. Specification of the Mounted Schema . . . . . . . . . . . 8
3.4. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9 3.4. 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 . . . . . . . . . . . . . . 11
6. Network Management Datastore Architecture (NMDA) 6. Network Management Datastore Architecture (NMDA)
Considerations . . . . . . . . . . . . . . . . . . . . . . . 11 Considerations . . . . . . . . . . . . . . . . . . . . . . . 11
7. Interaction with the Network Configuration Access Control 7. Interaction with the Network Configuration Access Control
Model (NACM) . . . . . . . . . . . . . . . . . . . . . . . . 11 Model (NACM) . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Implementation Notes . . . . . . . . . . . . . . . . . . . . 12 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . 12
9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 12 9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Example: Device Model with LNEs and NIs . . . . . . 21 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 . . . . . . . . . . . . . . . . 23 A.2. Logical Network Elements . . . . . . . . . . . . . . . . 23
A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 26 A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 26
A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27 A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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:
1. Design-time: the mounted schema is defined along with the mount 1. Design-time: the mounted schema is defined along with the mount
point in the parent YANG module. In this case, the mounted point in the parent YANG module. In this case, the mounted
schema has to be the same for every implementation of the parent schema has to be the same for every implementation of the parent
module. module.
2. Implementation-time: the mounted schema is defined by a server 2. Implementation-time: the mounted schema is defined by a server
implementor and is as stable as YANG library information of the implementor and is as stable as the YANG library information of
server. the server.
3. Run-time: the mounted schema is defined by instance data that is 3. Run-time: the mounted schema is defined by instance data that is
part of the mounted data model. If there are multiple instances part of the mounted data model. If there are multiple instances
of the same mount point (e.g., in multiple entries of a list), of the same mount point (e.g., in multiple entries of a list),
the mounted data model may be different for each instance. the mounted data model may be different for each instance.
The schema mount mechanism defined in this document provides support The schema mount mechanism defined in this document provides support
only for the latter two cases. Design-time mounts are outside the only for the latter two cases. Design-time mounts are outside the
scope of this document, and could be possibly dealt with in a future scope of this document, and could be possibly dealt with in a future
revision of the YANG data modeling language. revision of the YANG data modeling language.
skipping to change at page 6, line 20 skipping to change at page 6, line 20
o server o server
The following term is defined in [RFC8343] and is not redefined here: The following term is defined in [RFC8343] and is not redefined here:
o system-controlled interface o system-controlled interface
The following term is defined in [I-D.ietf-netconf-rfc7895bis] is not The following term is defined in [I-D.ietf-netconf-rfc7895bis] is not
redefined here: redefined here:
o YANG library checksum o YANG library content identifier
The following additional terms are used within this document: The following additional terms are used within this document:
o mount point: A container or a list node whose definition contains o mount point: A container or a list node whose definition contains
the "mount-point" extension statement. The argument of the 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 schema: A collection of schema trees with a common root. o schema: A collection of schema trees with a common root.
o top-level schema: A schema rooted at the root node. o top-level schema: A schema rooted at the root node.
skipping to change at page 9, line 27 skipping to change at page 9, line 27
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 schema. A client is expected to retrieve this data from top-level schema. A client is expected to retrieve this data from
the instance tree. In the "inline" case, instances of the same mount the instance tree. In the "inline" case, instances of the same mount
point MAY use different mounted schemas, whereas in the point MAY use different mounted schemas, whereas in the
"shared-schema" case, all instances MUST use the same mounted schema. "shared-schema" case, all instances MUST use the same mounted schema.
This means that in the "shared-schema" case, all instances of the This means that in the "shared-schema" case, all instances of the
same mount point MUST have the same YANG library checksum. In the same mount point MUST have the same YANG library content identifier.
"inline" case, if two instances have the same YANG library checksum In the "inline" case, if two instances have the same YANG library
it is not guaranteed that the YANG library contents are equal for content identifier it is not guaranteed that the YANG library
these instances. contents are equal for these instances.
Examples of "inline" and "shared-schema" can be found in Appendix A.2
and Appendix A.3, respectively.
3.4. 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 other schemas 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 mounted schemas. A construct data models with an arbitrary number of mounted schemas. A
schema 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 schemas exactly as it is done in the top-level schema. specifying the schemas exactly as it is done in the top-level 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
schema works exactly as a top-level schema, i.e., it is confined to schema works exactly as a top-level schema, i.e., it is confined to
the "mount jail". This means that all paths in the mounted schema the "mount jail". This means that all paths in the mounted schema
(in leafrefs, instance-identifiers, XPath expressions, and target (in leafrefs, instance-identifiers, XPath [XPATH] expressions, and
nodes of augments) are interpreted with the mount point as the root target nodes of augments) are interpreted with the mount point as the
node. YANG modules of the mounted schema as well as corresponding root node. YANG modules of the mounted schema as well as
instance data thus cannot refer to schema nodes or instance data corresponding instance data thus cannot refer to schema nodes or
outside the mount jail. instance data 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 11, line 13 skipping to change at page 11, line 20
of this is given in Appendix A.4. of this is given in Appendix A.4.
Similarly, if the server emits a notification defined at the top Similarly, if the server emits a notification defined at the top
level of any mounted module, it MUST be represented as if the level of any mounted module, it MUST be represented as if the
notification was connected to the mount point, see Section 7.16 of notification was connected to the mount point, see Section 7.16 of
[RFC7950]. [RFC7950].
Note, inline actions and notifications will not work when they are Note, inline actions and notifications will not work when they are
contained within a list node without a "key" statement (see section contained within a list node without a "key" statement (see section
7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points 7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points
which contain modules with RPCs, actions, and notifications SHOULD that contain modules with RPCs, actions, and notifications SHOULD NOT
NOT have any ancestor node that is a list node without a "key" have any ancestor node that is a list node without a "key" statement.
statement. This requirement applies to the definition of modules This requirement applies to the definition of modules using the
using the "mount-point" extension statement. "mount-point" extension statement.
6. Network Management Datastore Architecture (NMDA) Considerations 6. Network Management Datastore Architecture (NMDA) Considerations
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" [RFC7895] 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. Interaction with the Network Configuration Access Control Model 7. Interaction with the Network Configuration Access Control Model
(NACM) (NACM)
If NACM [RFC8341] is implemented on a server, it can be used to If NACM [RFC8341] is implemented on a server, it is used to control
control access to nodes defined by the mounted schema in the same way access to nodes defined by the mounted schema in the same way as for
as for nodes defined by the top-level schema. nodes defined by the top-level schema.
For example, suppose the module "ietf-interfaces" is mounted in the For example, suppose the module "ietf-interfaces" is mounted in the
"root" container in the "logical-network-element" list defined in "root" container in the "logical-network-element" list defined in
[I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used [I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used
to control access to the "interfaces" container (where the character to control access to the "interfaces" container (where the character
'\' is used where a line break has been inserted for formatting '\' is used where a line break has been inserted for formatting
reasons): reasons):
<path xmlns:lne= <path xmlns:lne=
"urn:ietf:params:xml:ns:yang:ietf-logical-network-element" "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"
skipping to change at page 12, line 30 skipping to change at page 12, line 32
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.
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@2018-08-07" <CODE BEGINS> file "ietf-yang-schema-mount@2018-10-16"
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 13, line 32 skipping to change at page 13, line 35
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
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
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', 'NOT RECOMMENDED',
'OPTIONAL' in the module text are to be interpreted as described 'MAY', and 'OPTIONAL' in the module text are to be interpreted
in RFC 2119 (https://tools.ietf.org/html/rfc2119). as described in BCP 14 [RFC 2119] [RFC8174] when, and only when,
they appear in all capitals, as shown here.
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.";
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
revision 2018-08-07 { revision 2018-10-16 {
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 label; argument label;
description description
"The argument 'label' 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'.
skipping to change at page 18, line 23 skipping to change at page 18, line 28
attacker identify the server capabilities and server attacker identify the server capabilities and server
implementations with known bugs. Server vulnerabilities may be implementations with known bugs. Server vulnerabilities may be
specific to particular modules included in the schema, module specific to particular modules included in the schema, module
revisions, module features, or even module deviations. For revisions, module features, or even module deviations. For
example, if a particular operation on a particular data node is example, if a particular operation on a particular data node is
known to cause a server to crash or significantly degrade device known to cause a server to crash or significantly degrade device
performance, then the schema information will help an attacker performance, then the schema information will help an attacker
identify server implementations with such a defect, in order to identify server implementations with such a defect, in order to
launch a denial-of-service attack on the device. launch a denial-of-service attack on the device.
It is important to take the security considerations for all nodes in
the mounted schemas into account, and control access to these nodes
by using the mechanism described in Section 7.
Care must be taken when the "parent-reference" XPath expressions are
constructed, since the result of the evaluation of these expressions
is added to the accessible tree for any XPath expression found in the
mounted schema.
12. Contributors 12. 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>
o Alexander Clemm, Huawei, <alexander.clemm@huawei.com> o Alexander Clemm, Huawei, <alexander.clemm@huawei.com>
skipping to change at page 20, line 5 skipping to change at page 20, line 15
[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>.
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Recommendation
REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
13.2. Informative References 13.2. Informative References
[I-D.clemm-netmod-mount] [I-D.clemm-netmod-mount]
Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined
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-19 (work in progress), November 2017. isis-yang-isis-cfg-24 (work in progress), August 2018.
[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-10 (work in progress), March 2018. ietf-rtgwg-lne-model-10 (work in progress), March 2018.
skipping to change at page 21, line 22 skipping to change at page 21, line 34
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", "content-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
"module-set": [ "module-set": [
{ {
"name": "physical-device-modules", "name": "physical-device-modules",
"module": [ "module": [
{ {
"name": "ietf-datastores", "name": "ietf-datastores",
"revision": "2018-02-14", "revision": "2018-02-14",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores" "urn:ietf:params:xml:ns:yang:ietf-datastores"
}, },
 End of changes. 19 change blocks. 
34 lines changed or deleted 51 lines changed or added

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