draft-ietf-netmod-schema-mount-02.txt   draft-ietf-netmod-schema-mount-03.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track L. Lhotka Intended status: Standards Track L. Lhotka
Expires: January 2, 2017 CZ.NIC Expires: May 4, 2017 CZ.NIC
July 1, 2016 October 31, 2016
YANG Schema Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-02 draft-ietf-netmod-schema-mount-03
Abstract Abstract
This document defines a mechanism to combine YANG modules into the This document defines a mechanism to combine YANG modules into the
schema defined in other YANG modules. schema defined in other YANG modules.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2017. This Internet-Draft will expire on May 4, 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 16 skipping to change at page 2, line 16
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. 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 . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 11 Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 14
Appendix B. Example: Network Manager . . . . . . . . . . . . . . 14 Appendix B. Example: Network Manager with Fixed Device Models . 16
B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 17 Appendix C. Example: Network Manager with Arbitrary Device
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 17 Models . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix D. Alternative solutions . . . . . . . . . . . . . . . 17 C.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 23
D.1. Static Mount Points with YANG Library Only . . . . . . . 18 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 23
D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 4, line 20 skipping to change at page 4, line 17
The schema mount mechanism defined in this document takes a different The schema mount mechanism defined in this document takes a different
approach to the extensibility problem described in the previous approach to the extensibility problem described in the previous
section. It decouples the definition of the relation between the section. It decouples the definition of the relation between the
source and target models from the definitions of the models source and target models from the definitions of the 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. Only "anydata" nodes can be used as mount points.
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.
Schema mount applies to the data model, 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
skipping to change at page 4, line 50 skipping to change at page 4, line 47
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. An example of this is given in Appendix B.1. specified. An example of this is given in Appendix C.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 [RFC7950]
[I-D.ietf-netmod-rfc6020bis] "ietf-yang-schema-mount", which has the "ietf-yang-schema-mount", which has the following structure:
following structure:
module: ietf-yang-schema-mount module: ietf-yang-schema-mount
+--ro mount-points +--ro schema-mounts
+--ro mount-point* [module name] +--ro namespace* [prefix]
+--ro module yang:yang-identifier | +--ro prefix yang:yang-identifier
+--ro name yang:yang-identifier | +--ro ns-uri? inet:uri
+--ro (data-model) +--ro mount-point* [module name]
+--:(inline-yang-library) | +--ro module yang:yang-identifier
| +--ro inline-yang-library? empty | +--ro name yang:yang-identifier
+--:(modules) | +--ro (subschema-ref)?
+--ro modules | +--:(inline)
+--ro module* [name revision] | | +--ro inline? empty
+--ro name yang:yang-identifier | +--:(use-schema)
+--ro revision union | +--ro use-schema* [name]
+--ro schema? inet:uri | +--ro name -> /schema-mounts/schema/name
+--ro namespace inet:uri | +--ro when? yang:xpath1.0
+--ro feature* yang:yang-identifier +--ro schema* [name]
+--ro deviation* [name revision] +--ro name string
| +--ro name yang:yang-identifier +--ro module* [name revision]
| +--ro revision union | +--ro name yang:yang-identifier
+--ro conformance-type enumeration | +--ro revision union
+--ro submodule* [name revision] | +--ro schema? inet:uri
+--ro name yang:yang-identifier | +--ro namespace inet:uri
+--ro revision union | +--ro feature* yang:yang-identifier
+--ro schema? inet:uri | +--ro deviation* [name revision]
| | +--ro name yang:yang-identifier
| | +--ro revision union
| +--ro conformance-type enumeration
| +--ro submodule* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro schema? inet:uri
+--ro mount-point* [module name]
+--ro module yang:yang-identifier
+--ro name yang:yang-identifier
+--ro (subschema-ref)?
+--:(inline)
| +--ro inline? empty
+--:(use-schema)
+--ro use-schema* [name]
+--ro name -> /schema-mounts/schema/name
+--ro when? yang:xpath1.0
5. Schema Mount YANG Module 5. Schema Mount YANG Module
This module references [RFC6991] and [RFC7895]. 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-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "RFC 6991: Common YANG Data Types"; 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"; 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: <https://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Thomas Nadeau WG Chair: Lou Berger
<mailto:tnadeau@lucidvision.com> <mailto:lberger@labn.net>
WG Chair: Juergen Schoenwaelder WG Chair: Kent Watsen
<mailto:j.schoenwaelder@jacobs-university.de> <mailto:kwatsen@juniper.net>
WG Chair: Kent Watsen Editor: Martin Bjorklund
<mailto:kwatsen@juniper.net> <mailto:mbj@tail-f.com>
Editor: Martin Bjorklund Editor: Ladislav Lhotka
<mailto:mbj@tail-f.com>"; <mailto:lhotka@nic.cz>";
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note.
description description
"This module defines a YANG extension statement that can be used "This module defines a YANG extension statement that can be used
to incorporate data models defined in other YANG modules in a to incorporate data models defined in other YANG modules in a
module. It also defines a operational state data so that module. It also defines operational state data that specify the
clients can learn which data models a server implements for the overall structure of the data model.
mount points.
Copyright (c) 2016 IETF Trust and the persons identified as Copyright (c) 2016 IETF Trust and the persons identified as
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
(http://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', '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 (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
(http://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 revision 2016-10-26 {
// and remove this note.
revision 2016-07-01 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Schema Mount"; "RFC XXXX: YANG Schema Mount";
} }
/* /*
* Extension statements * Extensions
*/ */
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
the mount point MUST be unique within the module where it mount point MUST be unique within the module where it is
is defined. defined.
The 'mount-point' statement can be present in 'anydata'. The 'mount-point' statement can only be present as a
substatement of 'anydata'.
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
a module with a mount point, populates the module with a mount point, populates the
/mount-points/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.";
The 'mount-yang-library' extension may be used as a
substatement to 'mount-point'.";
}
extension mount-yang-library {
description
"The presence of this statement as a substatement to
'mount-point' indicates that the data model defined in the
module 'ietf-yang-library' is mounted. When this statement is
present, a client can discover the mounted YANG modules by
reading from the mounted 'ietf-yang-library' data.
This statement is useful if the mount point is defined in a
list and different list entries may mount a different
set of modules.";
} }
/* /*
* Operational state data nodes * Groupings
*/ */
container mount-points { grouping mount-point-list {
config false;
description description
"Contains information about which mount points are implemented "This grouping is used inside the 'schema-mounts' container and
in the server, and their data models."; inside the 'schema' list.";
list mount-point { list mount-point {
key "module name"; key "module name";
description description
"Contains information about which data models are implemented "Each entry of this list specifies a subschema for a
for the mountpoint 'name' defined in 'module'."; particular mount point.
Each mount point MUST be defined using the 'mount-point'
extension in one of the modules listed in the corresponding
YANG library instance with conformance type 'implement'. The
corresponding YANG library instance is:
- standard YANG library state data as defined in RFC 7895, if
the 'mount-point' list is a child of 'schema-mounts',
- the contents of the sibling 'yanglib:modules-state'
container, if the 'mount-point' list is a child of
'schema'.";
leaf module { leaf module {
type yang:yang-identifier; type yang:yang-identifier;
description description
"The name of the module where the mount point is defined."; "Name of a module containing the mount point.";
} }
leaf name { leaf name {
type yang:yang-identifier; type yang:yang-identifier;
description description
"The name of the mount point."; "Name of the mount point defined using the 'mount-point'
extension.";
} }
choice data-model { choice subschema-ref {
mandatory true;
description description
"Indicates which data models the server implements "Alternative way for specifying the subschema.";
for this mount point. leaf inline {
It is expected that this choice may be augmented with other
data model discovery mechansisms.";
leaf inline-yang-library {
type empty; type empty;
description description
"This leaf indicates that the server has mounted "This leaf indicates that the server has mounted
'ietf-yang-library' at the mount point, and that the 'ietf-yang-library' and 'ietf-schema-mount' at the mount
instantiation of 'ietf-yang-library' contains the point, and their instantiation (i.e., state data
information about which modules are mounted. containers 'yanglib:modules-state' and 'schema-mounts')
provides the information about the mounted schema.";
This is useful if the mount point is defined in a
list and different list entries may mount a different
set of modules.";
} }
list use-schema {
container modules { key "name";
description description
"The 'module' list contains the set of modules that are "Each entry of this list contains a reference to a
mounted at the mount point."; subschema defined in the /schema-mounts/schema list. The
entry can be made conditional by specifying an XPath
expression in the 'when' leaf.";
leaf name {
type leafref {
path "/schema-mounts/schema/name";
}
description
"Name of the referenced schema.";
}
leaf when {
type yang:xpath1.0;
description
"This leaf contains an XPath expression. If it is
present, then the current entry applies if and only if
the expression evaluates to true.
uses yanglib:module-list; The XPath expression is evaluated once for each
instance of the anydata node containing the mount
point for which the 'when' leaf is defined.
The XPath expression is evaluated using the rules
specified in sec. 6.4 of RFC 7950, with these
modifications:
- The context node is the anydata instance containing
the corresponding 'mount-point' statement.
- The accessible tree contains only data belonging to
the parent schema, i.e., all instances of anydata
nodes containing the mount points are considered
empty.
- The set of namespace declarations is the set of all
prefix/namespace pairs defined in the
/schema-mounts/namespace list. Names without a
namespace prefix belong to the same namespace as the
context node.";
}
} }
} }
} }
} }
/*
* State data nodes
*/
container schema-mounts {
config "false";
description
"Contains information about the structure of the overall data
model implemented in the server.";
list namespace {
key "prefix";
description
"This list provides a mapping of namespace prefixes that are
used in XPath expressions of 'when' leafs to the
corresponding namespace URI references.";
leaf prefix {
type yang:yang-identifier;
description
"Namespace prefix.";
}
leaf ns-uri {
type inet:uri;
description
"Namespace URI reference.";
}
}
uses mount-point-list;
list schema {
key "name";
description
"Each entry specifies a schema that can be mounted at a mount
point. The schema information consists of two parts:
- an instance of YANG library that defines YANG modules used
in the schema,
- mount-point list with content identical to the top-level
mount-point list (this makes the schema structure
recursive).";
leaf name {
type string;
description
"Arbitrary name of the entry.";
}
uses yanglib:module-list;
uses mount-point-list;
}
}
} }
<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.
skipping to change at page 10, line 21 skipping to change at page 12, line 48
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]); 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]
Bjorklund, M., "The YANG 1.1 Data Modeling Language",
draft-ietf-netmod-rfc6020bis-14 (work in progress), June
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
skipping to change at page 10, line 48 skipping to change at page 13, line 22
<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 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>. <http://www.rfc-editor.org/info/rfc6991>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<http://www.rfc-editor.org/info/rfc7895>. <http://www.rfc-editor.org/info/rfc7895>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>.
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-05 (work in progress), September 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-04 (work in progress), May rtgyangdt-rtgwg-device-model-05 (work in progress), August
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 12, line 30 skipping to change at page 14, line 43
anydata root { anydata root {
yangmnt:mount-point logical-device; 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 "schema-mounts" container
with: with:
<mount-points <schema-mounts
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-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> <use-schema>
<module> <name>logical-device</name>
<name>ietf-interface</name> </use-schema>
<revision>2014-05-08</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-interfaces
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-ip</name>
<revision>2014-06-16</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-ip
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-system</name>
<revision>2014-08-06</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-system
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-yang-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-yang-types
</namespace>
<conformance-type>import</conformance-type>
</module>
</modules>
</mount-point> </mount-point>
</mount-points> <schema>
<name>logical-device</name>
<module>
<name>ietf-interface</name>
<revision>2014-05-08</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-interfaces
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-ip</name>
<revision>2014-06-16</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-ip
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-system</name>
<revision>2014-08-06</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-system
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-yang-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-yang-types
</namespace>
<conformance-type>import</conformance-type>
</module>
</schema>
</schema-mounts>
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>
<root> <root>
<interfaces <interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface> <interface>
skipping to change at page 14, line 46 skipping to change at page 16, line 46
... ...
</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>
</root> </root>
</logical-device> </logical-device>
</logical-devices> </logical-devices>
Appendix B. Example: Network Manager Appendix B. Example: Network Manager with Fixed Device Models
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 for a network consisting of devices
mount is used to mount the data models each device supports, and whose data models are known a priori and fixed.
these data models can be discovered by a client via the
"ietf-yang-library" module that is mounted for each device.
module example-network-manager { Assume for simplicity that only two device types are used (switch and
router), and they are identified by identities defined in the module
"example-device-types":
module example-device-types {
namespace "http://example.org/device-types";
prefix edt;
identity device-type;
identity switch-device {
base device-type;
}
identity router-device {
base device-type;
}
}
Schema mount is used to mount the device data models conditionally,
depending on the "type" leaf that is a sibling of the mount point.
This approach is similar to "ietf-interfaces" [RFC7223] where the
same effect is achieved via conditional augments.
The top-level module may look as follows:
module example-network-manager-fixed {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:network-manager"; namespace "urn:example:network-manager-fixed";
prefix exnm; prefix exf;
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;
} }
import example-device-types {
prefix edt;
}
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;
} }
leaf type {
type identityref {
base edt:device-type;
}
}
container transport { container transport {
choice protocol { choice protocol {
mandatory true; mandatory true;
container netconf { container netconf {
leaf address { leaf address {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
} }
container authentication { container authentication {
// ... // ...
skipping to change at page 15, line 48 skipping to change at page 18, line 30
container restconf { container restconf {
leaf address { leaf address {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
} }
// ... // ...
} }
} }
} }
anydata root { anydata root {
yangmnt:mount-point managed-device { yangmnt:mount-point managed-device;
yangmnt:mount-yang-library;
}
} }
} }
}
}
The "schema-mounts" container may have the following data:
<data-model
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
<namespace>
<prefix>edt</prefix>
<ns-uri>http://example.org/device-types</ns-uri>
</namespace>
<mount-point>
<module>example-network-manager</module>
<name>managed-device</name>
<use-schema>
<name>switch</name>
<when>derived-from-or-self(../type, 'edt:switch-device')</when>
</use-schema>
<use-schema>
<name>router</name>
<when>derived-from-or-self(../type, 'edt:router-device')</when>
</use-schema>
</mount-point>
<schema>
<name>switch</name>
<module>
...
</module>
...
</schema>
<schema>
<name>router</name>
<module>
...
</module>
...
</schema>
</data-model>
The "devices" list may contain any number of instances of either
type.
Appendix C. Example: Network Manager with Arbitrary Device Models
This example shows how a Network Manager application can use schema
mount to define a data model for a network consisting of devices
whose data models are not known in advance -- each device is expected
to provide its data model dynamically.
Schema mount is used to mount the data models that each device
supports, and these data models can be discovered by inspecting state
data under the corresponding mount point. Every such device must
therefore implement "ietf-yang-library" and optionally
"ietf-schema-mount".
module example-network-manager-arbitrary {
yang-version 1.1;
namespace "urn:example:network-manager-arbitrary";
prefix exa;
import ietf-inet-types {
prefix inet;
}
import ietf-yang-schema-mount {
prefix yangmnt;
}
container managed-devices {
description
"The managed devices and device communication settings.";
list device {
key name;
leaf name {
type string;
}
container transport {
choice protocol {
mandatory true;
container netconf {
leaf address {
type inet:ip-address;
mandatory true;
}
container authentication {
// ...
}
}
container restconf {
leaf address {
type inet:ip-address;
mandatory true;
}
// ...
}
}
}
anydata root {
yangmnt:mount-point managed-device;
}
}
} }
} }
The "schema-mounts" container may have the following data:
<data-model
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
<mount-point>
<module>example-network-manager</module>
<name>managed-device</name>
<inline/>
</mount-point>
</data-model>
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>2001:db8::2</address> <address>2001:db8::2</address>
<authentication> <authentication>
skipping to change at page 16, line 45 skipping to change at page 23, line 4
<device> <device>
<name>rtrB</name> <name>rtrB</name>
<transport> <transport>
<restconf> <restconf>
<address>2001:db8::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>
<name>ietf-interfaces</name> <name>ietf-interfaces</name>
... ...
</module> </module>
</modules-state> </modules-state>
<interfaces <interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
... ...
</interfaces> </interfaces>
</root> </root>
</device> </device>
</devices> </devices>
B.1. Invoking an RPC C.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">
<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>
<root> <root>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"> <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
<restart/> <restart/>
</system> </system>
</root> </root>
</device> </device>
</managed-devices> </managed-devices>
</action> </action>
</rpc> </rpc>
Appendix C. Open Issues Appendix D. Open Issues
o Is there a use case for specifying that certain modules are
required to be mounted under a mount point?
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
at every mount point. See Appendix D.1.
o Support non-named mount points? (ysdl case) See Appendix D.2.
Appendix D. Alternative solutions
This section discusses some alternative solution ideas.
D.1. Static Mount Points with YANG Library Only
This solution supports named mount points, and always use ietf-yang-
library.
There would be just one single extension statement, and no additional
operational state data:
extension mount-point {
argument name;
}
Data models need to be prepared with this extension:
container logical-devices {
list logical-device {
key name;
...
yangmnt:mount-point logical-device;
}
}
The tree on the server from Appendix A would look like this:
"example-logical-devices:logical-devices": {
"logical-device": [
{
"name": "vrtrA",
"ietf-yang-library:modules-state": {
"module-set-id": "ef50fe1",
"module": [
{
"name": "ietf-interfaces",
...
},
{
"name": "ietf-system",
...
}
]
},
"ietf-interfaces:interfaces": {
...
},
"ietf-system:system": {
...
}
},
{
"name": "vrtrB",
"ietf-yang-library:modules-state": {
...
}
}
]
}
D.2. Dynamic Mount Points with YANG Library Only
This solution supports only non-named mount points, and always use
ietf-yang-library.
There would be no extension statement. Instead, the server would
populate a list of dynamic mount points. Each such mount point MUST
mount ietf-yang-library.
container mount-points {
config false;
list mount-point {
key path;
leaf path {
type schema-node-path;
}
}
}
The tree on the server from Appendix A would look like this:
"ietf-yang-schema-mount:mount-points": {
"mount-point": [
{ "path": "/exld:logical-devices/exld:logical-device" }
]
},
"example-logical-devices:logical-devices": {
"logical-device": [
{
"name": "vrtrA",
"ietf-yang-library:modules-state": {
"module-set-id": "ef50fe1",
"module": [
{
"name": "ietf-interfaces",
...
},
{
"name": "ietf-system",
...
}
]
},
"ietf-interfaces:interfaces": {
...
},
"ietf-system:system": {
...
}
},
{
"name": "vrtrB",
"ietf-yang-library:modules-state": {
...
}
}
]
}
A client needs to read the "/mount-points/mount-point" list in order o Is the 'mount-point' extension really needed? Now that mount
to learn where the server has mounted data models. Next, it needs to points can only appear under anydata nodes, there seems to be
read the "modules-state" subtree for each instantiated mount point in little need to otherwise restrict mount point locations. In the
order to learn which modules are mounted at that instance. 'mount-point' list, schema node identifiers (as in 'augment'
statements) can be used instead of the (module, name) pair for
identifying mount points. As a useful side effect, a grouping
containing mount points could be used any number of times in the
same module. OTOH, by using this extension, the intention of the
data modeller is clear, and it provides a formal machine readable
instruction about where mounts are allowed to occur.
Authors' Addresses Authors' Addresses
Martin Bjorklund Martin Bjorklund
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
Ladislav Lhotka Ladislav Lhotka
CZ.NIC CZ.NIC
Email: mbj@lhotka@nic.cz Email: mbj@lhotka@nic.cz
 End of changes. 68 change blocks. 
320 lines changed or deleted 430 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/