--- 1/draft-ietf-netmod-schema-mount-07.txt 2017-10-21 07:13:07.248272925 -0700 +++ 2/draft-ietf-netmod-schema-mount-08.txt 2017-10-21 07:13:07.296274060 -0700 @@ -1,19 +1,19 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Intended status: Standards Track L. Lhotka -Expires: March 31, 2018 CZ.NIC - September 27, 2017 +Expires: April 24, 2018 CZ.NIC + October 21, 2017 YANG Schema Mount - draft-ietf-netmod-schema-mount-07 + draft-ietf-netmod-schema-mount-08 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 March 31, 2018. + This Internet-Draft will expire on April 24, 2018. 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 @@ -45,21 +45,21 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6 2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7 + 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 6 3.2. Specification of the Mounted Schema . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 19 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 @@ -214,22 +214,20 @@ o notification o server The following terms are defined in [RFC7950] and are not redefined here: o action - o configuration data - o container o list o operation The following terms are defined in [RFC7223] and are not redefined here: o system-controlled interface @@ -236,21 +235,21 @@ Tree diagrams used in this document follow the notation defined in [I-D.ietf-netmod-yang-tree-diagrams]. 2.1. Glossary of New Terms o inline schema: a mounted schema whose definition is provided as part of the mounted data, using YANG library [RFC7895]. o mount point: container or list node whose definition contains the "mount-point" extension statement. The argument of the - "mount-point" statement defines the name of the mount point. + "mount-point" statement defines a label for the mount point. o parent schema (of a particular mounted schema): the schema that contains the mount point for the mounted schema. o top-level schema: a schema according to [RFC7950] in which schema trees of each module (except augments) start at the root node. 2.2. Namespace Prefixes In this document, names of data nodes, YANG extensions, actions and @@ -280,21 +279,21 @@ described in the following subsections. 3.1. Mount Point Definition A "container" or "list" node becomes a mount point if the "mount-point" extension (defined in the "ietf-yang-schema-mount" module) is used in its definition. This extension can appear only as a substatement of "container" and "list" statements. The argument of the "mount-point" extension is a YANG identifier that - defines the name of the mount point. A module MAY contain multiple + defines a label for the mount point. A module MAY contain multiple "mount-point" statements having the same argument. It is therefore up to the designer of the parent schema to decide 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. @@ -493,23 +492,23 @@ 7. Data Model This document defines the YANG 1.1 module [RFC7950] "ietf-yang-schema-mount", which has the following structure: module: ietf-yang-schema-mount +--ro schema-mounts +--ro namespace* [prefix] | +--ro prefix yang:yang-identifier | +--ro uri? inet:uri - +--ro mount-point* [module name] + +--ro mount-point* [module label] | +--ro module yang:yang-identifier - | +--ro name yang:yang-identifier + | +--ro label 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 parent-reference* yang:xpath1.0 +--ro schema* [name] @@ -521,38 +520,38 @@ | +--ro namespace inet:uri | +--ro feature* yang:yang-identifier | +--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 mount-point* [module label] +--ro module yang:yang-identifier - +--ro name yang:yang-identifier + +--ro label 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 parent-reference* yang:xpath1.0 8. Schema Mount YANG Module This module references [RFC6991] and [RFC7895]. - file "ietf-yang-schema-mount@2017-09-27.yang" + file "ietf-yang-schema-mount@2017-10-09.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"; @@ -601,47 +600,47 @@ 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-09-27 { + revision 2017-10-09 { description "Initial revision."; reference "RFC XXXX: YANG Schema Mount"; } /* * Extensions */ extension mount-point { - argument name; + argument label; description - "The argument 'name' is a YANG identifier, i.e., it is of the + "The argument 'label' is a YANG identifier, i.e., it is of the type 'yang:yang-identifier'. The 'mount-point' statement MUST NOT be used in a YANG version 1 module, neither explicitly nor via a 'uses' statement. The 'mount-point' statement MAY be present as a substatement of 'container' and 'list', and MUST NOT be present elsewhere. There MUST NOT be more than one 'mount-point' statement in a given 'container' or 'list' statement. - If a mount point is defined within a grouping, its name is + If a mount point is defined within a grouping, its label is bound to the module where the grouping is used. A mount point defines a place in the node hierarchy where other data models may be attached. A server that implements a module with a mount point populates the /schema-mounts/mount-point list with detailed information on which data models are mounted at each mount point. Note that the 'mount-point' statement does not define a new data node."; @@ -649,45 +648,45 @@ /* * Groupings */ grouping mount-point-list { description "This grouping is used inside the 'schema-mounts' container and inside the 'schema' list."; list mount-point { - key "module name"; + key "module label"; description "Each entry of this list specifies a schema for a 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 { type yang:yang-identifier; description "Name of a module containing the mount point."; } - leaf name { + leaf label { type yang:yang-identifier; description - "Name of the mount point defined using the 'mount-point' + "Label of the mount point defined using the 'mount-point' extension."; } leaf config { type boolean; default "true"; description "If this leaf is set to 'false', then all data nodes in the mounted schema are read-only (config false), regardless of their 'config' property."; } @@ -847,35 +846,35 @@ o Jan Medved, Cisco, o Eric Voit, Cisco, 12. References 12.1. Normative References [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, . - [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", - RFC 6991, DOI 10.17487/RFC6991, July 2013, + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC + 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 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, . @@ -886,37 +885,37 @@ Information from Remote Datastores", draft-clemm-netmod- 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-17 (work in progress), March 2017. [I-D.ietf-netmod-yang-tree-diagrams] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- - ietf-netmod-yang-tree-diagrams-00 (work in progress), June + ietf-netmod-yang-tree-diagrams-01 (work in progress), June 2017. [I-D.ietf-rtgwg-device-model] Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, "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-02 (work in progress), March 2017. + Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. + Liu, "YANG Logical Network Elements", draft-ietf-rtgwg- + lne-model-03 (work in progress), July 2017. [I-D.ietf-rtgwg-ni-model] - Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, - "YANG Network Instances", draft-ietf-rtgwg-ni-model-02 - (work in progress), March 2017. + Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. + Liu, "YANG Network Instances", draft-ietf-rtgwg-ni- + model-03 (work in progress), July 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, . @@ -1003,21 +1002,21 @@ A.2. Logical Network Elements Each LNE can have a specific data model that is determined at run time, so it is appropriate to mount it using the "inline" method, hence the following "schema-mounts" data: "ietf-yang-schema-mount:schema-mounts": { "mount-point": [ { "module": "ietf-logical-network-element", - "name": "root", + "label": "root", "inline": [null] } ] } An administrator of the host device has to configure an entry for each LNE instance, for example, { "ietf-interfaces:interfaces": { "interface": [ @@ -1153,21 +1152,21 @@ "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" }, { "prefix": "ni", "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" } ], "mount-point": [ { "module": "ietf-network-instance", - "name": "root", + "label": "root", "use-schema": [ { "name": "ni-schema", "parent-reference": [ "/if:interfaces/if:interface[ ni:bind-network-instance-name = current()/../ni:name]" ] } ] }