--- 1/draft-ietf-netmod-schema-mount-00.txt 2016-04-06 00:16:23.343689481 -0700 +++ 2/draft-ietf-netmod-schema-mount-01.txt 2016-04-06 00:16:23.379690377 -0700 @@ -1,18 +1,19 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems -Intended status: Standards Track April 5, 2016 -Expires: October 7, 2016 +Intended status: Standards Track L. Lhotka +Expires: October 8, 2016 CZ.NIC + April 6, 2016 - YANG Structural Mount - draft-ietf-netmod-schema-mount-00 + YANG Schema Mount + draft-ietf-netmod-schema-mount-01 Abstract This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -20,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -43,40 +44,40 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Structural Mount . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Augment and Validation in Mounted Data . . . . . . . . . 4 3.2. Top-level RPCs . . . . . . . . . . . . . . . . . . . . . 4 3.3. Top-level Notifications . . . . . . . . . . . . . . . . . 5 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 5. Structural Mount YANG Module . . . . . . . . . . . . . . . . 5 + 5. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 11 Appendix B. Example: Network Manager . . . . . . . . . . . . . . 13 B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 16 Appendix D. Alternative solutions . . . . . . . . . . . . . . . 16 D.1. Static Mount Points with YANG Library Only . . . . . . . 16 D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 18 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 1.1. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. @@ -136,40 +137,40 @@ update our model for logical devices to use a grouping from the new model. Another problem is that this approach cannot handle vendor- specific modules. With the "augment" approach, ietf-interfaces would have to augment 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 scalable, since there may be other models to which we would like to add the interface list. -3. Structural Mount +3. Schema Mount - The structural mount mechanism defined in this document takes a - different approach to the extensibility problem described in the - previous section. It decouples the definition of the relation - between the source and target models from the definitions of the - models themselves. + The schema mount mechanism defined in this document takes a different + approach to the extensibility problem described in the previous + section. It decouples the definition of the relation between the + source and target models from the definitions of the models + themselves. 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 is to define a place in the node hierarchy where other YANG data models may be attached, without any special notation in the other YANG data models. For each mount point supported by a server, the server populates an operational state node hierarchy with information about which models it has mounted. This node hierarchy can be read by a client in order 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 implemented using the same instrumentation as the rest of the system, or it may be implemented by querying some other system. Future specifications may define mechanisms to control or monitor the implementation of specific mount points. This document allows mounting of complete data models only. Other specifications may extend this model by defining additional mechanisms, for example mounting of sub-hierarchies of a module. @@ -178,35 +179,35 @@ All paths (in leafrefs, instance-identifiers, XPath expressions, and 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 mounted data nodes as its children. This means that data within a mounted subtree can never refer to data outside of this subtree. 3.2. Top-level RPCs 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 - specified. + specified. An example of this is given in Appendix B.1. 3.3. Top-level Notifications 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 to the data node where the mount point is specified. 4. Data Model This document defines the YANG 1.1 module - [I-D.ietf-netmod-rfc6020bis] "ietf-yang-structural-mount", which has - the following structure: + [I-D.ietf-netmod-rfc6020bis] "ietf-yang-schema-mount", which has the + following structure: - module: ietf-yang-structural-mount + module: ietf-yang-schema-mount +--ro mount-points +--ro mount-point* [module name] +--ro module yang:yang-identifier +--ro name yang:yang-identifier +--ro (data-model) +--:(inline-yang-library) | +--ro inline-yang-library? empty +--:(modules) +--ro modules +--ro module* [name revision] @@ -218,27 +219,27 @@ +--ro deviation* [name revision] | +--ro name yang:yang-identifier | +--ro revision union +--ro conformance-type enumeration +--ro submodules +--ro submodule* [name revision] +--ro name yang:yang-identifier +--ro revision union +--ro schema? inet:uri -5. Structural Mount YANG Module +5. Schema Mount YANG Module - file "ietf-yang-structural-mount@2016-02-26.yang" + file "ietf-yang-schema-mount@2016-04-05.yang" - module ietf-yang-structural-mount { + module ietf-yang-schema-mount { 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; import ietf-yang-types { prefix yang; } import ietf-yang-library { prefix yanglib; } organization @@ -283,25 +284,25 @@ NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119 (http://tools.ietf.org/html/rfc2119). This version of this YANG module is part of RFC XXXX (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: update the date below with the date of RFC publication // and remove this note. - revision 2016-02-26 { + revision 2016-04-05 { description "Initial revision."; reference - "RFC XXXX: YANG Structural Mount"; + "RFC XXXX: YANG Schema Mount"; } /* * Extension statements */ extension mount-point { argument name; description "The argument 'name' is a yang-identifier. The name of @@ -400,31 +401,31 @@ } 6. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is 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. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC6020]. - name: ietf-yang-structural-mount - namespace: urn:ietf:params:xml:ns:yang:ietf-yang-structural-mount + name: ietf-yang-schema-mount + namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount prefix: yangmnt reference: RFC XXXX 7. Security Considerations TBD 8. Contributors The idea of having some way to combine schemas from different YANG @@ -436,22 +437,22 @@ 9. References 9.1. Normative References [I-D.ietf-netmod-rfc6020bis] Bjorklund, M., "The YANG 1.1 Data Modeling Language", draft-ietf-netmod-rfc6020bis-11 (work in progress), February 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . @@ -475,38 +476,38 @@ [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, . - [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC - 7277, DOI 10.17487/RFC7277, June 2014, + [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", + RFC 7277, DOI 10.17487/RFC7277, June 2014, . [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, . Appendix A. Example: Logical Devices Logical devices within a device typically use the same set of data models in each instance. This can be modelled with a mount point: module example-logical-devices { namespace "urn:example:logical-devices"; prefix exld; - import ietf-yang-structural-mount { + import ietf-yang-schema-mount { prefix yangmnt; } container logical-devices { list logical-device { key name; leaf name { type string; } @@ -514,21 +515,21 @@ } } } A server with two logical devices that both implement "ietf-interfaces" [RFC7223], "ietf-ip" [RFC7277], and "ietf-system" [RFC7317] YANG modules might populate the "mount-points" container with: + xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"> example-logical-devices logical-device ietf-interface 2014-05-08 urn:ietf:params:xml:ns:yang:ietf-interfaces @@ -596,74 +597,75 @@ ... Appendix B. Example: Network Manager - This example shows how a Network Manager application can use - structural mount to define a data model with all its managed devices. - Structural mount is used to mount the data models each device - supports, and these data models can be discovered by a client via the + This example shows how a Network Manager application can use 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 + 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 { namespace "urn:example:network-manager"; prefix exnm; - import ietf-inet-types { prefix inet; } - import ietf-yang-structural-mount { + 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; } - choice transport { + 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; } // ... } } - + } container root { yangmnt:mount-point managed-device { yangmnt:mount-yang-library; } } } } } + The "devices" container might have: rtrA
192.0.2.2
... @@ -663,44 +665,45 @@ rtrA
192.0.2.2
... ... + ietf-system ... ... - rtrB
192.0.2.3
... ... + ietf-interfaces ... @@ -698,24 +701,23 @@ ietf-interfaces ... ... - + - B.1. Invoking an RPC A client that wants to invoke the "restart" operation [RFC7317] on the managed device "rtrA" over NETCONF [RFC6241] can send: @@ -817,21 +819,21 @@ 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-structural-mount:mount-points": { + "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", @@ -860,15 +862,20 @@ } } ] } 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 read the "modules-state" subtree for each instantiated mount point in order to learn which modules are mounted at that instance. -Author's Address +Authors' Addresses Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com + + Ladislav Lhotka + CZ.NIC + + Email: mbj@lhotka@nic.cz