draft-ietf-netmod-schema-mount-00.txt   draft-ietf-netmod-schema-mount-01.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 April 5, 2016 Intended status: Standards Track L. Lhotka
Expires: October 7, 2016 Expires: October 8, 2016 CZ.NIC
April 6, 2016
YANG Structural Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-00 draft-ietf-netmod-schema-mount-01
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 31 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 October 7, 2016. This Internet-Draft will expire on October 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 11 skipping to change at page 2, line 11
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 2 1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Structural Mount . . . . . . . . . . . . . . . . . . . . . . 4 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Augment and Validation in Mounted Data . . . . . . . . . 4 3.1. Augment and Validation in Mounted Data . . . . . . . . . 4
3.2. Top-level RPCs . . . . . . . . . . . . . . . . . . . . . 4 3.2. Top-level RPCs . . . . . . . . . . . . . . . . . . . . . 4
3.3. Top-level Notifications . . . . . . . . . . . . . . . . . 5 3.3. Top-level Notifications . . . . . . . . . . . . . . . . . 5
4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Structural Mount YANG Module . . . . . . . . . . . . . . . . 5 5. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 11 Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 11
Appendix B. Example: Network Manager . . . . . . . . . . . . . . 13 Appendix B. Example: Network Manager . . . . . . . . . . . . . . 13
B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 16 B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 16
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 16
Appendix D. Alternative solutions . . . . . . . . . . . . . . . 16 Appendix D. Alternative solutions . . . . . . . . . . . . . . . 16
D.1. Static Mount Points with YANG Library Only . . . . . . . 16 D.1. Static Mount Points with YANG Library Only . . . . . . . 16
D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 18 D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
1.1. Terminology 1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "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].
skipping to change at page 4, line 8 skipping to change at page 4, line 8
update our model for logical devices to use a grouping from the new update our model for logical devices to use a grouping from the new
model. Another problem is that this approach cannot handle vendor- model. Another problem is that this approach cannot handle vendor-
specific modules. specific modules.
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-device list with all its nodes, and at the same time
define all its nodes on the top-level. This approach is also not define all its nodes on the top-level. This approach is also not
scalable, since there may be other models to which we would like to scalable, since there may be other models to which we would like to
add the interface list. add the interface list.
3. Structural Mount 3. Schema Mount
The structural mount mechanism defined in this document takes a The schema mount mechanism defined in this document takes a different
different approach to the extensibility problem described in the approach to the extensibility problem described in the previous
previous section. It decouples the definition of the relation section. It decouples the definition of the relation between the
between the source and target models from the definitions of the source and target models from the definitions of the models
models themselves. themselves.
This is accomplished with a YANG extension statement that is used to This is accomplished with a YANG extension statement that is used to
specify a mount point in a data model. The purpose of a mount point specify a mount point in a data model. The purpose of a mount point
is to define a place in the node hierarchy where other YANG data is to define a place in the node hierarchy where other YANG data
models may be attached, without any special notation in the other models may be attached, without any special notation in the other
YANG data models. YANG data models.
For each mount point supported by a server, the server populates an For each mount point supported by a server, the server populates an
operational state node hierarchy with information about which models operational state node hierarchy with information about which models
it has mounted. This node hierarchy can be read by a client in order it has mounted. This node hierarchy can be read by a client in order
to learn what is implemented on a server. to learn what is implemented on a server.
Structural mount applies to the schema, and specifically does not Schema mount applies to the data model, and specifically does not
assume anything about how the mounted data is implemented. It may be assume anything about how the mounted data is implemented. It may be
implemented using the same instrumentation as the rest of the system, implemented using the same instrumentation as the rest of the system,
or it may be implemented by querying some other system. Future or it may be implemented by querying some other system. Future
specifications may define mechanisms to control or monitor the specifications may define mechanisms to control or monitor the
implementation of specific mount points. 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, for example mounting of sub-hierarchies of a module. mechanisms, for example mounting of sub-hierarchies of a module.
skipping to change at page 4, line 50 skipping to change at page 4, line 50
All paths (in leafrefs, instance-identifiers, XPath expressions, and All paths (in leafrefs, instance-identifiers, XPath expressions, and
target nodes of augments) in the data models mounted at a mount point target nodes of augments) in the data models mounted at a mount point
are interpreted with the mount point as the root node, and the are interpreted with the mount point as the root node, and the
mounted data nodes as its children. This means that data within a mounted data nodes as its children. This means that data within a
mounted subtree can never refer to data outside of this subtree. mounted subtree can never refer to data outside of this subtree.
3.2. Top-level RPCs 3.2. Top-level RPCs
If any mounted data model defines RPCs, these RPCs can be invoked by If any mounted data model defines RPCs, these RPCs can be invoked by
clients by treating them as actions defined where the mount point is clients by treating them as actions defined where the mount point is
specified. specified. An example of this is given in Appendix B.1.
3.3. Top-level Notifications 3.3. Top-level Notifications
If the server emits a notification defined at the top-level in any If the server emits a notification defined at the top-level in any
mounted data model, it is treated as if the notification was attached mounted data model, it is treated as if the notification was attached
to the data node where the mount point is specified. to the data node where the mount point is specified.
4. Data Model 4. Data Model
This document defines the YANG 1.1 module This document defines the YANG 1.1 module
[I-D.ietf-netmod-rfc6020bis] "ietf-yang-structural-mount", which has [I-D.ietf-netmod-rfc6020bis] "ietf-yang-schema-mount", which has the
the following structure: following structure:
module: ietf-yang-structural-mount module: ietf-yang-schema-mount
+--ro mount-points +--ro mount-points
+--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 (data-model) +--ro (data-model)
+--:(inline-yang-library) +--:(inline-yang-library)
| +--ro inline-yang-library? empty | +--ro inline-yang-library? empty
+--:(modules) +--:(modules)
+--ro modules +--ro modules
+--ro module* [name revision] +--ro module* [name revision]
skipping to change at page 5, line 43 skipping to change at page 5, line 43
+--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 submodules +--ro submodules
+--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
5. Structural Mount YANG Module 5. Schema Mount YANG Module
<CODE BEGINS> file "ietf-yang-structural-mount@2016-02-26.yang" <CODE BEGINS> file "ietf-yang-schema-mount@2016-04-05.yang"
module ietf-yang-structural-mount { module ietf-yang-schema-mount {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-structural-mount"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount";
prefix yangmnt; prefix yangmnt;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-yang-library { import ietf-yang-library {
prefix yanglib; prefix yanglib;
} }
organization organization
skipping to change at page 7, line 12 skipping to change at page 7, line 12
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 (http://tools.ietf.org/html/rfc2119). in RFC 2119 (http://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
(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for (http://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 2016-02-26 { revision 2016-04-05 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Structural Mount"; "RFC XXXX: YANG Schema Mount";
} }
/* /*
* Extension statements * Extension statements
*/ */
extension mount-point { extension mount-point {
argument name; argument name;
description description
"The argument 'name' is a yang-identifier. The name of "The argument 'name' is a yang-identifier. The name of
skipping to change at page 9, line 33 skipping to change at page 9, line 33
} }
<CODE ENDS> <CODE ENDS>
6. IANA Considerations 6. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registration is Following the format in RFC 3688, the following registration is
requested to be made. requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-structural-mount URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
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-structural-mount name: ietf-yang-schema-mount
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-structural-mount namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
prefix: yangmnt prefix: yangmnt
reference: RFC XXXX reference: RFC XXXX
7. Security Considerations 7. Security Considerations
TBD TBD
8. Contributors 8. 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
skipping to change at page 10, line 23 skipping to change at page 10, line 23
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-netmod-rfc6020bis] [I-D.ietf-netmod-rfc6020bis]
Bjorklund, M., "The YANG 1.1 Data Modeling Language", Bjorklund, M., "The YANG 1.1 Data Modeling Language",
draft-ietf-netmod-rfc6020bis-11 (work in progress), draft-ietf-netmod-rfc6020bis-11 (work in progress),
February 2016. February 2016.
[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>.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
[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>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
7277, DOI 10.17487/RFC7277, June 2014, RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>. <http://www.rfc-editor.org/info/rfc7277>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <http://www.rfc-editor.org/info/rfc7317>. 2014, <http://www.rfc-editor.org/info/rfc7317>.
Appendix A. Example: Logical Devices Appendix A. Example: Logical Devices
Logical devices within a device typically use the same set of data Logical devices within a device typically use the same set of data
models in each instance. This can be modelled with a mount point: models in each instance. This can be modelled with a mount point:
module example-logical-devices { module example-logical-devices {
namespace "urn:example:logical-devices"; namespace "urn:example:logical-devices";
prefix exld; prefix exld;
import ietf-yang-structural-mount { import ietf-yang-schema-mount {
prefix yangmnt; prefix yangmnt;
} }
container logical-devices { container logical-devices {
list logical-device { list logical-device {
key name; key name;
leaf name { leaf name {
type string; type string;
} }
skipping to change at page 12, line 6 skipping to change at page 12, line 6
} }
} }
} }
A server with two logical devices that both implement A server with two logical devices that both implement
"ietf-interfaces" [RFC7223], "ietf-ip" [RFC7277], and "ietf-system" "ietf-interfaces" [RFC7223], "ietf-ip" [RFC7277], and "ietf-system"
[RFC7317] YANG modules might populate the "mount-points" container [RFC7317] YANG modules might populate the "mount-points" container
with: with:
<mount-points <mount-points
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-structural-mount"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
<mount-point> <mount-point>
<module>example-logical-devices</module> <module>example-logical-devices</module>
<name>logical-device</name> <name>logical-device</name>
<modules> <modules>
<module> <module>
<name>ietf-interface</name> <name>ietf-interface</name>
<revision>2014-05-08</revision> <revision>2014-05-08</revision>
<namespace> <namespace>
urn:ietf:params:xml:ns:yang:ietf-interfaces urn:ietf:params:xml:ns:yang:ietf-interfaces
</namespace> </namespace>
skipping to change at page 13, line 44 skipping to change at page 13, line 44
</interface> </interface>
</interfaces> </interfaces>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"> <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
... ...
</system> </system>
</logical-device> </logical-device>
</logical-devices> </logical-devices>
Appendix B. Example: Network Manager Appendix B. Example: Network Manager
This example shows how a Network Manager application can use This example shows how a Network Manager application can use schema
structural mount to define a data model with all its managed devices. mount to define a data model with all its managed devices. Schema
Structural mount is used to mount the data models each device mount is used to mount the data models each device supports, and
supports, and these data models can be discovered by a client via the these data models can be discovered by a client via the
"ietf-yang-library" module that is mounted for each device. "ietf-yang-library" module that is mounted for each device.
module example-network-manager { module example-network-manager {
namespace "urn:example:network-manager"; namespace "urn:example:network-manager";
prefix exnm; prefix exnm;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-yang-structural-mount { import ietf-yang-schema-mount {
prefix yangmnt; prefix yangmnt;
} }
container managed-devices { container managed-devices {
description description
"The managed devices and device communication settings."; "The managed devices and device communication settings.";
list device { list device {
key name; key name;
leaf name { leaf name {
type string; type string;
} }
choice transport { container transport {
mandatory true; choice protocol {
container netconf { mandatory true;
leaf address { container netconf {
type inet:ip-address; leaf address {
mandatory true; type inet:ip-address;
mandatory true;
}
container authentication {
// ...
}
} }
container authentication { container restconf {
leaf address {
type inet:ip-address;
mandatory true;
}
// ... // ...
} }
} }
container restconf {
leaf address {
type inet:ip-address;
mandatory true;
}
// ...
}
} }
container root { container root {
yangmnt:mount-point managed-device { yangmnt:mount-point managed-device {
yangmnt:mount-yang-library; yangmnt:mount-yang-library;
} }
} }
} }
} }
} }
The "devices" container might have: The "devices" container might have:
<devices xmlns="urn:example:network-manager"> <devices xmlns="urn:example:network-manager">
<device> <device>
<name>rtrA</name> <name>rtrA</name>
<transport> <transport>
<netconf> <netconf>
<address>192.0.2.2</address> <address>192.0.2.2</address>
<authentication> <authentication>
... ...
skipping to change at page 15, line 17 skipping to change at page 15, line 16
<device> <device>
<name>rtrA</name> <name>rtrA</name>
<transport> <transport>
<netconf> <netconf>
<address>192.0.2.2</address> <address>192.0.2.2</address>
<authentication> <authentication>
... ...
</authentication> </authentication>
... ...
</netconf> </netconf>
<root>
<modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module>
<name>ietf-system</name>
...
</module>
</modules-state>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
...
</system>
</root>
</transport> </transport>
<root>
<modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module>
<name>ietf-system</name>
...
</module>
</modules-state>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
...
</system>
</root>
</device> </device>
<device> <device>
<name>rtrB</name> <name>rtrB</name>
<transport> <transport>
<restconf> <restconf>
<address>192.0.2.3</address> <address>192.0.2.3</address>
<authentication> <authentication>
... ...
</authentication> </authentication>
... ...
</restconf> </restconf>
<root> </transport>
<modules-state <root>
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> <modules-state
<module> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<name>ietf-interfaces</name> <module>
... <name>ietf-interfaces</name>
</module>
</modules-state>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
... ...
</module>
</modules-state>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
...
</interfaces>
</interfaces> </root>
</root>
</transport>
</device> </device>
</devices> </devices>
B.1. Invoking an RPC B.1. Invoking an RPC
A client that wants to invoke the "restart" operation [RFC7317] on A client that wants to invoke the "restart" operation [RFC7317] on
the managed device "rtrA" over NETCONF [RFC6241] can send: the managed device "rtrA" over NETCONF [RFC6241] can send:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
skipping to change at page 19, line 5 skipping to change at page 19, line 5
list mount-point { list mount-point {
key path; key path;
leaf path { leaf path {
type schema-node-path; type schema-node-path;
} }
} }
} }
The tree on the server from Appendix A would look like this: The tree on the server from Appendix A would look like this:
"ietf-yang-structural-mount:mount-points": { "ietf-yang-schema-mount:mount-points": {
"mount-point": [ "mount-point": [
{ "path": "/exld:logical-devices/exld:logical-device" } { "path": "/exld:logical-devices/exld:logical-device" }
] ]
}, },
"example-logical-devices:logical-devices": { "example-logical-devices:logical-devices": {
"logical-device": [ "logical-device": [
{ {
"name": "vrtrA", "name": "vrtrA",
"ietf-yang-library:modules-state": { "ietf-yang-library:modules-state": {
"module-set-id": "ef50fe1", "module-set-id": "ef50fe1",
skipping to change at page 19, line 48 skipping to change at page 19, line 48
} }
} }
] ]
} }
A client needs to read the "/mount-points/mount-point" list in order A client needs to read the "/mount-points/mount-point" list in order
to learn where the server has mounted data models. Next, it needs to to learn where the server has mounted data models. Next, it needs to
read the "modules-state" subtree for each instantiated mount point in read the "modules-state" subtree for each instantiated mount point in
order to learn which modules are mounted at that instance. order to learn which modules are mounted at that instance.
Author's Address Authors' Addresses
Martin Bjorklund Martin Bjorklund
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
Ladislav Lhotka
CZ.NIC
Email: mbj@lhotka@nic.cz
 End of changes. 40 change blocks. 
82 lines changed or deleted 84 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/