--- 1/draft-ietf-netmod-schema-mount-04.txt 2017-05-16 06:13:18.730004863 -0700 +++ 2/draft-ietf-netmod-schema-mount-05.txt 2017-05-16 06:13:18.782006096 -0700 @@ -1,19 +1,19 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Intended status: Standards Track L. Lhotka -Expires: September 7, 2017 CZ.NIC - March 6, 2017 +Expires: November 17, 2017 CZ.NIC + May 16, 2017 YANG Schema Mount - draft-ietf-netmod-schema-mount-04 + draft-ietf-netmod-schema-mount-05 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. @@ -21,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 September 7, 2017. + This Internet-Draft will expire on November 17, 2017. Copyright Notice Copyright (c) 2017 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 @@ -48,45 +48,42 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7 3.2. Specification of the Mounted Schema . . . . . . . . . . . 7 - 3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 11 - 4. Refering to Data Nodes in the Parent Schema . . . . . . . . . 11 - 5. RPC operations and Notifications . . . . . . . . . . . . . . 12 - 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 13 - 7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 12.2. Informative References . . . . . . . . . . . . . . . . . 22 - Appendix A. Example: Device Model with LNEs and NIs . . . . . . 23 - A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 23 - A.2. Logical Network Elements . . . . . . . . . . . . . . . . 24 - A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 27 - A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 29 - Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 29 - B.1. Referencing Mount Points Using Schema Node Identifiers . 29 - B.2. Defining the "mount-point" Extension in a Separate Module 30 - B.3. Parent References . . . . . . . . . . . . . . . . . . . . 31 - B.4. RPC Operations and Notifications in Mounted Modules . . . 31 - B.5. Tree Representation . . . . . . . . . . . . . . . . . . . 32 - B.6. Design-Time Mounts . . . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + 3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9 + 4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9 + 5. RPC operations and Notifications . . . . . . . . . . . . . . 10 + 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 11 + 7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 13 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 12.2. Informative References . . . . . . . . . . . . . . . . . 19 + Appendix A. Example: Device Model with LNEs and NIs . . . . . . 20 + A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 20 + A.2. Logical Network Elements . . . . . . . . . . . . . . . . 22 + A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25 + A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27 + Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 27 + B.1. RPC Operations and Notifications in Mounted Modules . . . 27 + B.2. Tree Representation . . . . . . . . . . . . . . . . . . . 27 + B.3. Design-Time Mounts . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Modularity and extensibility were among the leading design principles of the YANG data modeling language. As a result, the same YANG module can be combined with various sets of other modules and thus form a data model that is tailored to meet the requirements of a specific use case. Server implementors are only required to specify all YANG modules comprising the data model (together with their revisions and other optional choices) in the YANG library data @@ -319,189 +317,118 @@ about the placement of mount points. A mount point can also be made conditional by placing "if-feature" and/or "when" as substatements of the "container" or "list" statement that represents the mount point. The "mount-point" statement MUST NOT be used in a YANG version 1 module. Note, however, that modules written in any YANG version, including version 1, can be mounted under a mount point. 3.2. Specification of the Mounted Schema - Mounted schemas for all mount points in the parent schema are defined - as state data in the "yangmnt:schema-mounts" container. Data in this - container is intended to be as stable as data in the top-level YANG - library [RFC7895]. In particular, it SHOULD NOT change during the - same management session. + Mounted schemas for all mount points in the parent schema are + determined from state data in the "yangmnt:schema-mounts" container. + Data in this container is intended to be as stable as data in the + top-level YANG library [RFC7895]. In particular, it SHOULD NOT + change during the same management session. - The "schema-mount" container has the "mount-point" list as one of its - children. Every entry of this list refers through its key to a mount - point and specifies the mounted schema. + The "schema-mounts" container has the "mount-point" list as one of + its children. Every entry of this list refers through its key to a + mount point and specifies the mounted schema. If a mount point is defined in the parent schema but does not have an entry in the "mount-point" list, then the mounted schema is void, i.e., instances of that mount point MUST NOT contain any data above those that are defined in the parent schema. If multiple mount points with the same name are defined in the same module - either directly or because the mount point is defined in a grouping and the grouping is used multiple times - then the corresponding "mount-point" entry applies equally to all such mount points. - The "config" property of mounted schema nodes is overriden and all + The "config" property of mounted schema nodes is overridden and all nodes in the mounted schema are read-only ("config false") if at least one of the following conditions is satisfied for a mount point: - 1. The mount point is itself defined as "config false". + o the mount point is itself defined as "config false" - 2. The "config" leaf in the corresponding entry of the "mount-point" + o the "config" leaf in the corresponding entry of the "mount-point" list is set to "false". An entry of the "mount-point" list can specify the mounted schema in two different ways: 1. by stating that the schema is available inline, i.e., in run-time instance data; or 2. by referring to one or more entries of the "schema" list in the same instance of "schema-mounts". - In case 1, every instance of the mount point that exists in the - parent tree MUST contain a copy of YANG library data [RFC7895] that - defines the mounted schema exactly as for a top-level data model. A - client is expected to retrieve this data from the instance tree, - possibly after creating the mount point. Instances of the same mount - point MAY use different mounted schemas. + In case 1, the mounted schema is determined at run time: every + instance of the mount point that exists in the parent tree MUST + contain a copy of YANG library data [RFC7895] that defines the + mounted schema exactly as for a top-level data model. A client is + expected to retrieve this data from the instance tree, possibly after + creating the mount point. Instances of the same mount point MAY use + different mounted schemas. In case 2, the mounted schema is defined by the combination of all - "schema" entries referred to in the "use-schema" list. Optionally, a - reference to a "schema" entry can be made conditional by including - the "when" leaf. Its argument is an XPath expression that is - evaluated in the parent tree with the mount point instance as the - context node. The conditional "schema" entry is used only if the - XPath expression evaluates to true. XPath expressions in the - argument of "when" may use namespace prefixes that are declared in - the "namespace" list (child of "schema-mounts"). - - Conditional schemas may be used, for example, in a situation where - virtual devices are of several different types and the schema for - each type is fixed and known in advance. The list of virtual devices - in a parent schema module (say "example-virtual-host") might be - defined as follows: - - list virtual-device { - key name; - leaf name { - type string; - } - leaf type { - type identityref { - base virtual-device-type; - } - } - container root { - yangmnt:mount-point virtual-device; - } - - The "schema-mounts" specification in state data might contain, for - example, - "yangmnt:schema-mounts": { - "namespace": [ - { - "prefix": "evh", - "ns-uri": "http://example.org/ns/example-virtual-host" - } - ], - "mount-point": [ - { - "module": "example-virtual-host", - "name": "root", - "use-schema": [ - { - "name": "virtual-router-schema", - "when": "derived-from(../evh:type, 'evh:virtual-router')" - }, - { - "name": "virtual-switch-schema", - "when": "derived-from(../evh:type, 'evh:virtual-switch')" - } - ], - "schema": [ - { - "name": "virtual-router-schema", - "module": [ - ... - ] - }, - { - "name": "virtual-switch-schema", - "module": [ - ... - ] - } - ] - } - - The schema of virtual device instances can then be controlled by - setting the "type" leaf to an appropriate identity derived from the - "virtual-device-type" base. - - In case 2, the mounted schema is specified as implementation-time - data that can be retrieved together with YANG library data for the - parent schema, i.e., even before any instances of the mount point - exist. However, the mounted schema has to be the same for all - instances of the mount point (except for parts that are conditional - due to "when" leaves). + "schema" entries referred to in the "use-schema" list. In this case, + the mounted schema is specified as implementation-time data that can + be retrieved together with YANG library data for the parent schema, + i.e., even before any instances of the mount point exist. However, + the mounted schema has to be the same for all instances of the mount + point. Each entry of the "schema" list contains o a list in the YANG library format specifying all YANG modules (and revisions etc.) that are implemented or imported in the mounted schema; - o (optionally) a new "schema-mounts" specification that applies to - mount points defined within the mounted schema. + o (optionally) a new "mount-point" list that applies to mount points + defined within the mounted schema. 3.3. Multiple Levels of Schema Mount YANG modules in a mounted schema MAY again contain mount points under which subschemas can be mounted. Consequently, it is possible to construct data models with an arbitrary number of schema levels. A subschema for a mount point contained in a mounted module can be specified in one of the following ways: o by implementing "ietf-yang-library" and "ietf-yang-schema-mount" modules in the mounted schema, and specifying the subschemas exactly as it is done in the top-level schema - o by using the "mount-point" list inside the coresponding "schema" + o by using the "mount-point" list inside the corresponding "schema" entry. The former method is applicable to both "inline" and "use-schema" cases whereas the latter requires the "use-schema" case. On the other hand, the latter method allows for a compact representation of a multi-level schema the does not rely on the presence of any instance data. -4. Refering to Data Nodes in the Parent Schema +4. Referring to Data Nodes in the Parent Schema A fundamental design principle of schema mount is that the mounted data model works exactly as a top-level data model, i.e., it is confined to the "mount jail". This means that all paths in the mounted data model (in leafrefs, instance-identifiers, XPath expressions, and target nodes of augments) are interpreted with the mount point as the root node. YANG modules of the mounted schema as well as corresponding instance data thus cannot refer to schema nodes or instance data outside the mount jail. However, this restriction is sometimes too severe. A typical example - are network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI + is network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI has its own routing engine but the list of interfaces is global and shared by all NIs. If we want to model this organization with the NI schema mounted using schema mount, the overall schema tree would look schematically as follows: +--rw interfaces | +--rw interface* [name] | ... +--rw network-instances +--rw network-instance* [name] @@ -509,41 +436,39 @@ +--rw root +--rw routing ... Here, the "root" node is the mount point for the NI schema. Routing configuration inside an NI often needs to refer to interfaces (at least those that are assigned to the NI), which is impossible unless such a reference can point to a node in the parent schema (interface name). - Therefore, schema mount also allows for such references, albeit in a - limited and controlled way. The "schema-mounts" container has a - child leaf-list named "parent-reference" that contains zero or more - module names. All modules appearing in this leaf-list MUST be - implemented in the parent schema and MUST NOT be implemented in the - mounted schema. All absolute leafref paths and instance identifiers - within the mounted data model and corresponding instance data tree - are then evaluated as follows: + Therefore, schema mount also allows for such references. For every + schema mounted using the "use-schema" method, it is possible to + specify a leaf-list named "parent-reference" that contains zero or + more XPath 1.0 expressions. Each expression is evaluated with the + root of the parent data tree as the context node and the result MUST + be a nodeset (see the description of the "parent-reference" node for + a complete definition of the evaluation context). For the purposes + of evaluating XPath expressions within the mounted data tree, the + union of all such nodesets is added to the accessible data tree. - o If the leftmost node-identifier (right after the initial slash) - belongs to the namespace of a module that is listed in - "parent-reference", then the root of the accessible tree is not - the mount point but the root of the parent schema. + It is worth emphasizing that - o Other rules for the "leafref" and "instance-identifier" types as - defined in Sections 9.9 and 9.13 of [RFC7950] remain in effect. + o The nodes specified in "parent-reference" leaf-list are available + in the mounted schema only for XPath evaluations. In particular, + they cannot be accessed there via network management protocols + such as NETCONF [RFC6241] or RESTCONF [RFC8040]. - It is worth emphasizing that the mount jail can be escaped only via - absolute leafref paths and instance identifiers. Relative leafref - paths, "must"/"when" expressions and schema node identifiers are - still restricted to the mounted schema. + o The mechanism of referencing nodes in the parent schema is not + available for schemas mounted using the "inline" method. 5. RPC operations and Notifications If a mounted YANG module defines an RPC operation, clients can invoke this operation by representing it as an action defined for the corresponding mount point, see Section 7.15 of ^RFC7950. An example of this is given in Appendix A.4. Similarly, if the server emits a notification defined at the top level of any mounted module, it MUST be represented as if the @@ -578,22 +503,21 @@ | +--ro module yang:yang-identifier | +--ro name yang:yang-identifier | +--ro config? boolean | +--ro (schema-ref)? | +--:(inline) | | +--ro inline? empty | +--:(use-schema) | +--ro use-schema* [name] | +--ro name | | -> /schema-mounts/schema/name - | +--ro when? yang:xpath1.0 - | +--ro parent-reference* yang:yang-identifier + | +--ro parent-reference* yang:xpath1.0 +--ro schema* [name] +--ro name string +--ro module* [name revision] | +--ro name yang:yang-identifier | +--ro revision union | +--ro schema? inet:uri | +--ro namespace inet:uri | +--ro feature* yang:yang-identifier | +--ro deviation* [name revision] | | +--ro name yang:yang-identifier @@ -607,28 +531,27 @@ +--ro module yang:yang-identifier +--ro name yang:yang-identifier +--ro config? boolean +--ro (schema-ref)? +--:(inline) | +--ro inline? empty +--:(use-schema) +--ro use-schema* [name] +--ro name | -> /schema-mounts/schema/name - +--ro when? yang:xpath1.0 - +--ro parent-reference* yang:yang-identifier + +--ro parent-reference* yang:xpath1.0 8. Schema Mount YANG Module This module references [RFC6991] and [RFC7895]. - file "ietf-yang-schema-mount@2017-03-06.yang" + file "ietf-yang-schema-mount@2017-05-16.yang" module ietf-yang-schema-mount { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"; prefix yangmnt; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; @@ -677,21 +600,21 @@ The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119 (https://tools.ietf.org/html/rfc2119). This version of this YANG module is part of RFC XXXX (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for full legal notices."; - revision 2017-03-06 { + revision 2017-05-16 { description "Initial revision."; reference "RFC XXXX: YANG Schema Mount"; } /* * Extensions */ @@ -772,106 +695,79 @@ "This leaf indicates that the server has mounted 'ietf-yang-library' and 'ietf-schema-mount' at the mount point, and their instantiation (i.e., state data containers 'yanglib:modules-state' and 'schema-mounts') provides the information about the mounted schema."; } list use-schema { key "name"; description "Each entry of this list contains a reference to a schema - defined in the /schema-mounts/schema list. The entry can - be made conditional by specifying an XPath expression in - the 'when' leaf."; + defined in the /schema-mounts/schema list."; leaf name { type leafref { path "/schema-mounts/schema/name"; } description "Name of the referenced schema."; } - leaf when { + leaf-list parent-reference { 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. + "Entries of this leaf-list are XPath 1.0 expressions + that are evaluated in the following context: - The XPath expression is evaluated once for each - instance of the data node containing the mount - point for which the 'when' leaf is defined. + - The context node is the root node of the parent data + tree. - The XPath expression is evaluated using the rules - specified in sec. 6.4 of RFC 7950, with these - modifications: + - The accessible tree is the parent data tree + *without* any nodes defined in modules that are + mounted inside the parent schema. - - The context node is the data node instance - containing the corresponding 'mount-point' - statement. + - The context position and context size are both equal + to 1. - - The accessible tree contains only data belonging to - the parent schema, i.e., all instances of data - nodes containing the mount points are considered - empty. + - The set of variable bindings is 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."; - } - leaf-list parent-reference { - type yang:yang-identifier; - must "not(/schema-mounts/schema[name=current()/../name]/" - + "module[name=current() and conformance-type=" - + "'implement'])" { - error-message "Parent references cannot be used for a " - + "module implemented in the mounted schema."; - description - "Modules that are used for parent references MUST NOT - be implemented in the mounted schema."; - } - description - "Entries of this leaf-list are names of YANG modules. - All these modules MUST be implemented in the parent - schema. + - The function library is the core function library + defined in [XPath] and the functions defined in + Section 10 of [RFC7950]. - Within the mounted schema and the corresponding data - tree, conceptual evaluation of absolute leafref paths - and instance identifiers is modified in the following - way: + - The set of namespace declarations is defined by the + 'namespace' list under 'schema-mounts'. - If the leftmost node-identifier in an absolute leafref - path or instance identifier belongs to a module whose - name is listed in 'parent-reference', then the root - of the accessible data tree coincides with the root of - the parent data tree."; + Each XPath expression MUST evaluate to a nodeset + (possibly empty). For the purposes of evaluating XPath + expressions whose context nodes are defined in the + mounted schema, the union of all these nodesets + together with ancestor nodes are added to the + accessible data tree."; } } } } } /* * State data nodes */ container schema-mounts { config false; description "Contains information about the structure of the overall mounted 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 + used in XPath expressions of 'parent-reference' 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."; @@ -970,53 +866,57 @@ Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . 12.2. Informative References [I-D.clemm-netmod-mount] - Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined + Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined Information from Remote Datastores", draft-clemm-netmod- - mount-05 (work in progress), September 2016. + mount-06 (work in progress), March 2017. [I-D.ietf-isis-yang-isis-cfg] Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L. Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf- - isis-yang-isis-cfg-15 (work in progress), February 2017. + isis-yang-isis-cfg-17 (work in progress), March 2017. [I-D.ietf-rtgwg-device-model] Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, - "Network Device YANG Organizational Models", draft-ietf- - rtgwg-device-model-01 (work in progress), October 2016. + "Network Device YANG Logical Organization", draft-ietf- + rtgwg-device-model-02 (work in progress), March 2017. [I-D.ietf-rtgwg-lne-model] Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, "YANG Logical Network Elements", draft-ietf-rtgwg-lne- - model-01 (work in progress), October 2016. + model-02 (work in progress), March 2017. [I-D.ietf-rtgwg-ni-model] Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, - "YANG Network Instances", draft-ietf-rtgwg-ni-model-01 - (work in progress), October 2016. + "YANG Network Instances", draft-ietf-rtgwg-ni-model-02 + (work in progress), March 2017. [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, . + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + Appendix A. Example: Device Model with LNEs and NIs This non-normative example demonstrates an implementation of the device model as specified in Section 2 of [I-D.ietf-rtgwg-device-model], using both logical network elements (LNE) and network instances (NI). A.1. Physical Device The data model for the physical device may be described by this YANG @@ -1064,22 +964,23 @@ "conformance-type": "implement" }, { "name": "ietf-yang-library", "revision": "2016-06-21", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type": "implement" }, { "name": "ietf-yang-schema-mount", - "revision": "2017-03-06", + "revision": "2017-05-16", "namespace": + "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", "conformance-type": "implement" }, { "name": "ietf-yang-types", "revision": "2013-07-15", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", "conformance-type": "import" } ] @@ -1180,21 +1080,21 @@ "conformance-type": "implement" }, { "name": "ietf-yang-library", "revision": "2016-06-21", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type": "implement" }, { "name": "ietf-yang-schema-mount", - "revision": "2017-03-06", + "revision": "2017-05-16", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", "conformance-type": "implement" }, { "name": "ietf-yang-types", "revision": "2013-07-15", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", "conformance-type": "import" } @@ -1292,99 +1192,21 @@ this module, such as "clear-adjacency", can be invoked by a client session of a LNE's RESTCONF server as an action tied to a the mount point of a particular network instance using a request URI like this (all on one line): POST /restconf/data/ietf-network-instance:network-instances/ network-instance=rtrA/root/ietf-isis:clear-adjacency HTTP/1.1 Appendix B. Open Issues -B.1. Referencing Mount Points Using Schema Node Identifiers - - Each entry in the "mount-point" list is currently identified by two - keys, namely YANG module name and mount point name. An alternative - is to use a schema node identifier of the mount point as a single - key. - - For example, the "schema-mounts" data for NI (Appendix A.3) would be - changed as follows (the "schema" list doesn't change): - - "ietf-yang-schema-mount:schema-mounts": { - "namespace": [ - { - "prefix": "ni", - "ns-uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" - } - ] - "mount-point": [ - { - "target": "/ni:network-instances/ni:network-instance/ni:root", - "parent-reference": ["ietf-interfaces"], - "use-schema": [ - { - "name": "ni-schema" - } - ] - } - ], - "schema": [ - ... - ] - } - - This change would have several advantages: - - o the schema mount mechanism becomes even closer to augments, which - may simplify implementation - - o if a mount point appears inside a grouping, then a different - mounted schema can be used for each use of the grouping. - - o it optionally allows for use of mount without use of the mount- - point extension. - -B.2. Defining the "mount-point" Extension in a Separate Module - - The "inline" method of schema mounting can be further simplified by - defining the "inline" case as the default. That is, if a mount point - is defined through the "mount-point" extension but is not present in - the "mount-point" list, the "inline" schema mount is assumed. - - Consequently, a data model that uses only the "inline" method could - omit the "schema-mounts" data entirely, but it still needs to use the - "mount-point" extension. In order to enable this, the definition of - the "mount-point" extension has to be moved to a YANG module of its - own. - - A variant of this approach is to completely separate the "inline" and - "use-schema" cases by dedicating the "mount-point" extension for use - with the "inline" method only (with no "schema-mounts" data), and - using schema node identifiers as described in Appendix B.1 for the - "use-schema" case. - -B.3. Parent References - - As explained in Section 4, references to the parent schema can only - be used in absolute leafref paths and instance identifiers. However, - it is conceivable that they may be useful in other XPath expressions, - e.g. in "must" statements. The authors believe it is impossible to - allow for parent references in general XPath expressions because, for - example, in a location path "//foo:bar" it would be unclear whether - the lookup has to be started in the mounted or parent schema. - - Should parent references in general XPath be needed, it would be - necessary to indicate it explicitly. One way to achieve this is to - defining a new XPath function, e.g., parent-root(), that returns the - root of the parent data tree. - -B.4. RPC Operations and Notifications in Mounted Modules +B.1. RPC Operations and Notifications in Mounted Modules Turning RPC operations defined in mounted modules into actions tied to the corresponding mount point (see Section 5, and similarly for notifications) is not possible if the path to the mount point in the parent schema contains a keyless list (Section 7.15 of [RFC7950]). The solutions for this corner case are possible: 1. any mount point MUST NOT have a keyless list among its ancestors 2. any mounted module MUST NOT contain RPC operations and/or @@ -1393,25 +1215,25 @@ 3. specifically for each mount point, at least one of the above conditions MUST be satisfied. 4. treat such actions and notifications as non-existing, i.e., ignore them. The first two requirements seem rather restrictive. On the other hand, the last one is difficult to guarantee - for example, things can break after an augment within the mounted schema. -B.5. Tree Representation +B.2. Tree Representation Need to decide how/if mount points are represented in trees. -B.6. Design-Time Mounts +B.3. Design-Time Mounts The document currently doesn't provide explicit support for design- time mounts. Design-time mounts have been identified as possibly for multiple cases, and it may be worthwhile to identify a minimum or complete set of modules that must be supported under a mount point. This could be used in service modules that want to allow for configuration of device-specific information. One option could be to add an extension that specify that a certain module is required to be mounted.