draft-ietf-netmod-schema-mount-01.txt   draft-ietf-netmod-schema-mount-02.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: October 8, 2016 CZ.NIC Expires: January 2, 2017 CZ.NIC
April 6, 2016 July 1, 2016
YANG Schema Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-01 draft-ietf-netmod-schema-mount-02
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 October 8, 2016. This Internet-Draft will expire on January 2, 2017.
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 18 skipping to change at page 2, line 18
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. Schema 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. Schema 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 . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . 14
B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 16 B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 17
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 17
Appendix D. Alternative solutions . . . . . . . . . . . . . . . 16 Appendix D. Alternative solutions . . . . . . . . . . . . . . . 17
D.1. Static Mount Points with YANG Library Only . . . . . . . 16 D.1. Static Mount Points with YANG Library Only . . . . . . . 18
D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 18 D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 5, line 37 skipping to change at page 5, line 37
+--ro module* [name revision] +--ro module* [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 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 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. Schema Mount YANG Module 5. Schema Mount YANG Module
This module references [RFC6991] and [RFC7895].
<CODE BEGINS> file "ietf-yang-schema-mount@2016-04-05.yang" <CODE BEGINS> file "ietf-yang-schema-mount@2016-04-05.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-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "RFC 6991: Common YANG Data Types";
} }
import ietf-yang-library { import ietf-yang-library {
prefix yanglib; prefix yanglib;
reference "RFC 7895: YANG Module Library";
} }
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Thomas Nadeau WG Chair: Thomas Nadeau
skipping to change at page 7, line 12 skipping to change at page 7, line 15
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-04-05 { revision 2016-07-01 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Schema 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
the mount point MUST be unique within the module where it the mount point MUST be unique within the module where it
is defined. is defined.
The 'mount-point' statement can be present in 'container' and The 'mount-point' statement can be present in 'anydata'.
'list'.
If a mount point is defined in a grouping, its name is bound If a mount point is defined in a grouping, its name is bound
to the module where the grouping is used. Note that this to the module where the grouping is used. Note that this
implies that such a grouping can be used at most once in a implies that such a grouping can be used at most once in a
module. module.
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 other data models may be attached. A server that implements
a module with a mount point, populates the a module with a mount point, populates the
/mount-points/mount-point list with detailed information on /mount-points/mount-point list with detailed information on
skipping to change at page 10, line 19 skipping to change at page 10, line 23
people: Alexander Clemm, Jan Medved, and Eric Voit people: Alexander Clemm, Jan Medved, and Eric Voit
([I-D.clemm-netmod-mount]); Ladislav Lhotka ([I-D.clemm-netmod-mount]); Ladislav Lhotka
([I-D.lhotka-netmod-ysdl]); and Lou Berger and Christian Hopps. ([I-D.lhotka-netmod-ysdl]); and Lou Berger and Christian Hopps.
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-14 (work in progress), June
February 2016. 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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/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 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<http://www.rfc-editor.org/info/rfc7895>.
9.2. Informative References 9.2. Informative References
[I-D.clemm-netmod-mount] [I-D.clemm-netmod-mount]
Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined
Information from Remote Datastores", draft-clemm-netmod- Information from Remote Datastores", draft-clemm-netmod-
mount-04 (work in progress), March 2016. mount-04 (work in progress), March 2016.
[I-D.lhotka-netmod-ysdl] [I-D.lhotka-netmod-ysdl]
Lhotka, L., "YANG Schema Dispatching Language", draft- Lhotka, L., "YANG Schema Dispatching Language", draft-
lhotka-netmod-ysdl-00 (work in progress), November 2015. lhotka-netmod-ysdl-00 (work in progress), November 2015.
[I-D.rtgyangdt-rtgwg-device-model] [I-D.rtgyangdt-rtgwg-device-model]
Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
"Network Device YANG Organizational Models", draft- "Network Device YANG Organizational Models", draft-
rtgyangdt-rtgwg-device-model-03 (work in progress), rtgyangdt-rtgwg-device-model-04 (work in progress), May
February 2016. 2016.
[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 11, line 28 skipping to change at page 12, line 6
[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 {
yang-version 1.1;
namespace "urn:example:logical-devices"; namespace "urn:example:logical-devices";
prefix exld; prefix exld;
import ietf-yang-schema-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;
} }
yangmnt:mount-point logical-device; anydata root {
yangmnt:mount-point logical-device;
}
} }
} }
} }
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
skipping to change at page 13, line 8 skipping to change at page 14, line 8
</module> </module>
</modules> </modules>
</mount-point> </mount-point>
</mount-points> </mount-points>
and the "logical-devices" container might have: and the "logical-devices" container might have:
<logical-devices xmlns="urn:example:logical-devices"> <logical-devices xmlns="urn:example:logical-devices">
<logical-device> <logical-device>
<name>vrtrA</name> <name>vrtrA</name>
<interfaces <root>
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interfaces
<interface> xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<name>eth0</name> <interface>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"> <name>eth0</name>
<enabled>true</enabled> <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
... <enabled>true</enabled>
</ipv6> ...
</ipv6>
...
</interface>
</interfaces>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
... ...
</interface> </system>
</interfaces> </root>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
...
</system>
</logical-device> </logical-device>
<logical-device> <logical-device>
<name>vrtrB</name> <name>vrtrB</name>
<interfaces <root>
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interfaces
<interface> xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<name>eth0</name> <interface>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"> <name>eth0</name>
<enabled>true</enabled> <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
... <enabled>true</enabled>
</ipv6> ...
</ipv6>
...
</interface>
</interfaces>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
... ...
</interface> </system>
</interfaces> </root>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-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 schema This example shows how a Network Manager application can use schema
mount to define a data model with all its managed devices. Schema mount to define a data model with all its managed devices. Schema
mount is used to mount the data models each device supports, and mount is used to mount the data models each device 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 {
yang-version 1.1;
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-schema-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.";
skipping to change at page 14, line 41 skipping to change at page 15, line 47
} }
container restconf { container restconf {
leaf address { leaf address {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
} }
// ... // ...
} }
} }
} }
container root { anydata 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>
skipping to change at page 15, line 10 skipping to change at page 16, line 15
} }
} }
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>2001:db8::2</address>
<authentication> <authentication>
... ...
</authentication> </authentication>
... ...
</netconf> </netconf>
</transport> </transport>
<root> <root>
<modules-state <modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module> <module>
skipping to change at page 15, line 34 skipping to change at page 16, line 39
</modules-state> </modules-state>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"> <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
... ...
</system> </system>
</root> </root>
</device> </device>
<device> <device>
<name>rtrB</name> <name>rtrB</name>
<transport> <transport>
<restconf> <restconf>
<address>192.0.2.3</address> <address>2001:db8::3</address>
<authentication> <authentication>
... ...
</authentication> </authentication>
... ...
</restconf> </restconf>
</transport> </transport>
<root> <root>
<modules-state <modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module> <module>
skipping to change at page 16, line 20 skipping to change at page 17, line 25
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">
<action xmlns="urn:ietf:params:xml:ns:yang:1"> <action xmlns="urn:ietf:params:xml:ns:yang:1">
<managed-devices xmlns="urn:example:network-manager"> <managed-devices xmlns="urn:example:network-manager">
<device> <device>
<name>rtrA</name> <name>rtrA</name>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"> <root>
<restart/> <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
</system> <restart/>
</system>
</root>
</device> </device>
</managed-devices> </managed-devices>
</action> </action>
</rpc> </rpc>
Appendix C. Open Issues Appendix C. Open Issues
o Is there a use case for specifying modules that are required to be o Is there a use case for specifying that certain modules are
mounted under a mount point? required to be mounted under a mount point?
o Do we really need the case where ietf-yang-library is not mounted? o Do we really need the case where ietf-yang-library is not mounted?
The solution would be simpler if we always use ietf-yang-library The solution would be simpler if we always use ietf-yang-library
at every mount point. See Appendix D.1. at every mount point. See Appendix D.1.
o Support non-named mount points? (ysdl case) See Appendix D.2. o Support non-named mount points? (ysdl case) See Appendix D.2.
Appendix D. Alternative solutions Appendix D. Alternative solutions
This section discusses some alternative solution ideas. This section discusses some alternative solution ideas.
 End of changes. 29 change blocks. 
60 lines changed or deleted 82 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/