--- 1/draft-ietf-netmod-schema-mount-11.txt 2018-10-17 01:13:29.417673357 -0700 +++ 2/draft-ietf-netmod-schema-mount-12.txt 2018-10-17 01:13:29.469674617 -0700 @@ -1,19 +1,19 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Intended status: Standards Track L. Lhotka -Expires: February 8, 2019 CZ.NIC - August 7, 2018 +Expires: April 20, 2019 CZ.NIC + October 17, 2018 YANG Schema Mount - draft-ietf-netmod-schema-mount-11 + draft-ietf-netmod-schema-mount-12 Abstract This document defines a mechanism to add the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in some YANG module. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,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 February 8, 2019. + This Internet-Draft will expire on April 20, 2019. Copyright Notice Copyright (c) 2018 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 @@ -51,32 +51,32 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7 3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Specification of the Mounted Schema . . . . . . . . . . . 8 3.4. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9 4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9 - 5. RPC operations and Notifications . . . . . . . . . . . . . . 10 + 5. RPC operations and Notifications . . . . . . . . . . . . . . 11 6. Network Management Datastore Architecture (NMDA) Considerations . . . . . . . . . . . . . . . . . . . . . . . 11 7. Interaction with the Network Configuration Access Control Model (NACM) . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . 12 9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Example: Device Model with LNEs and NIs . . . . . . 21 A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21 A.2. Logical Network Elements . . . . . . . . . . . . . . . . 23 A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 26 A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction @@ -172,22 +172,22 @@ In principle, the mounted schema can be specified at three different phases of the data model life cycle: 1. Design-time: the mounted schema is defined along with the mount point in the parent YANG module. In this case, the mounted schema has to be the same for every implementation of the parent module. 2. Implementation-time: the mounted schema is defined by a server - implementor and is as stable as YANG library information of the - server. + implementor and is as stable as the YANG library information of + the server. 3. Run-time: the mounted schema is defined by instance data that is part of the mounted data model. If there are multiple instances of the same mount point (e.g., in multiple entries of a list), the mounted data model may be different for each instance. The schema mount mechanism defined in this document provides support only for the latter two cases. Design-time mounts are outside the scope of this document, and could be possibly dealt with in a future revision of the YANG data modeling language. @@ -246,21 +246,21 @@ o server The following term is defined in [RFC8343] and is not redefined here: o system-controlled interface The following term is defined in [I-D.ietf-netconf-rfc7895bis] is not redefined here: - o YANG library checksum + o YANG library content identifier The following additional terms are used within this document: o mount point: A container or a list node whose definition contains the "mount-point" extension statement. The argument of the "mount-point" statement defines a label for the mount point. o schema: A collection of schema trees with a common root. o top-level schema: A schema rooted at the root node. @@ -396,45 +396,48 @@ two different ways, "inline" or "shared-schema". The mounted schema is determined at run time: every instance of the mount point that exists in the operational state MUST contain a copy of YANG library data that defines the mounted schema exactly as for a top-level schema. A client is expected to retrieve this data from the instance tree. In the "inline" case, instances of the same mount point MAY use different mounted schemas, whereas in the "shared-schema" case, all instances MUST use the same mounted schema. This means that in the "shared-schema" case, all instances of the - same mount point MUST have the same YANG library checksum. In the - "inline" case, if two instances have the same YANG library checksum - it is not guaranteed that the YANG library contents are equal for - these instances. + same mount point MUST have the same YANG library content identifier. + In the "inline" case, if two instances have the same YANG library + content identifier it is not guaranteed that the YANG library + contents are equal for these instances. + + Examples of "inline" and "shared-schema" can be found in Appendix A.2 + and Appendix A.3, respectively. 3.4. Multiple Levels of Schema Mount YANG modules in a mounted schema MAY again contain mount points under which other schemas can be mounted. Consequently, it is possible to construct data models with an arbitrary number of mounted schemas. A schema for a mount point contained in a mounted module can be specified by implementing "ietf-yang-library" and "ietf-yang-schema-mount" modules in the mounted schema, and specifying the schemas exactly as it is done in the top-level schema. 4. Referring to Data Nodes in the Parent Schema A fundamental design principle of schema mount is that the mounted schema works exactly as a top-level schema, i.e., it is confined to the "mount jail". This means that all paths in the mounted schema - (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. + (in leafrefs, instance-identifiers, XPath [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 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] @@ -477,47 +480,47 @@ 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 notification was connected to the mount point, see Section 7.16 of [RFC7950]. Note, inline actions and notifications will not work when they are contained within a list node without a "key" statement (see section 7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points - which contain modules with RPCs, actions, and notifications SHOULD - NOT have any ancestor node that is a list node without a "key" - statement. This requirement applies to the definition of modules - using the "mount-point" extension statement. + that contain modules with RPCs, actions, and notifications SHOULD NOT + have any ancestor node that is a list node without a "key" statement. + This requirement applies to the definition of modules using the + "mount-point" extension statement. 6. Network Management Datastore Architecture (NMDA) Considerations The schema mount solution presented in this document is designed to work both with servers that implement the NMDA [RFC8342], and old servers that don't implement the NMDA. Note to RFC Editor: please update the date YYYY-MM-DD below with the revision of the ietf-yang-library in the published version of draft- ietf-netconf-rfc7895bis, and remove this note. Specifically, a server that doesn't support the NMDA, MAY implement revision 2016-06-21 of "ietf-yang-library" [RFC7895] under a mount point. A server that supports the NMDA, MUST implement at least revision YYYY-MM-DD of "ietf-yang-library" [I-D.ietf-netconf-rfc7895bis] under the mount points. 7. Interaction with the Network Configuration Access Control Model (NACM) - If NACM [RFC8341] is implemented on a server, it can be used to - control access to nodes defined by the mounted schema in the same way - as for nodes defined by the top-level schema. + If NACM [RFC8341] is implemented on a server, it is used to control + access to nodes defined by the mounted schema in the same way as for + nodes defined by the top-level schema. For example, suppose the module "ietf-interfaces" is mounted in the "root" container in the "logical-network-element" list defined in [I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used to control access to the "interfaces" container (where the character '\' is used where a line break has been inserted for formatting reasons): file "ietf-yang-schema-mount@2018-08-07" + file "ietf-yang-schema-mount@2018-10-16" 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"; @@ -588,37 +591,37 @@ authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). 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). + NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', + 'MAY', and 'OPTIONAL' in the module text are to be interpreted + as described in BCP 14 [RFC 2119] [RFC8174] when, and only when, + they appear in all capitals, as shown here. 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."; // RFC Ed.: update the date below with the date of RFC publication // and remove this note. - revision 2018-08-07 { + revision 2018-10-16 { description "Initial revision."; reference "RFC XXXX: YANG Schema Mount"; } - /* * Extensions */ extension mount-point { argument label; description "The argument 'label' is a YANG identifier, i.e., it is of the type 'yang:yang-identifier'. @@ -821,20 +824,29 @@ attacker identify the server capabilities and server implementations with known bugs. Server vulnerabilities may be specific to particular modules included in the schema, module revisions, module features, or even module deviations. For example, if a particular operation on a particular data node is known to cause a server to crash or significantly degrade device performance, then the schema information will help an attacker identify server implementations with such a defect, in order to launch a denial-of-service attack on the device. + It is important to take the security considerations for all nodes in + the mounted schemas into account, and control access to these nodes + by using the mechanism described in Section 7. + + Care must be taken when the "parent-reference" XPath expressions are + constructed, since the result of the evaluation of these expressions + is added to the accessible tree for any XPath expression found in the + mounted schema. + 12. Contributors The idea of having some way to combine schemas from different YANG modules into one has been proposed independently by several groups of people: Alexander Clemm, Jan Medved, and Eric Voit ([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps: o Lou Berger, LabN Consulting, L.L.C., o Alexander Clemm, Huawei, @@ -896,31 +908,36 @@ [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . + [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) + Version 1.0", World Wide Web Consortium Recommendation + REC-xpath-19991116, November 1999, + . + 13.2. Informative References [I-D.clemm-netmod-mount] Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined 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-19 (work in progress), November 2017. + isis-yang-isis-cfg-24 (work in progress), August 2018. [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., Bogdanovic, D., and X. Liu, "YANG Model for Logical Network Elements", draft- ietf-rtgwg-lne-model-10 (work in progress), March 2018. @@ -957,21 +974,21 @@ In these examples, the character '\' is used where a line break has been inserted for formatting reasons. A.1. Physical Device The data model for the physical device may be described by this YANG library content, assuming the server supports the NMDA: { "ietf-yang-library:yang-library": { - "checksum": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899", + "content-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899", "module-set": [ { "name": "physical-device-modules", "module": [ { "name": "ietf-datastores", "revision": "2018-02-14", "namespace": "urn:ietf:params:xml:ns:yang:ietf-datastores" },