idnits 2.17.1 draft-ietf-netmod-schema-mount-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 575 has weird spacing: '... prefix yan...' == Line 600 has weird spacing: '...evision uni...' == Line 601 has weird spacing: '...ce-type enu...' == Line 604 has weird spacing: '...evision uni...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 6, 2017) is 2606 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) == Outdated reference: A later version (-06) exists of draft-clemm-netmod-mount-05 == Outdated reference: A later version (-42) exists of draft-ietf-isis-yang-isis-cfg-15 == Outdated reference: A later version (-02) exists of draft-ietf-rtgwg-device-model-01 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-lne-model-01 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ni-model-01 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund 3 Internet-Draft Tail-f Systems 4 Intended status: Standards Track L. Lhotka 5 Expires: September 7, 2017 CZ.NIC 6 March 6, 2017 8 YANG Schema Mount 9 draft-ietf-netmod-schema-mount-04 11 Abstract 13 This document defines a mechanism to combine YANG modules into the 14 schema defined in other YANG modules. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 7, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 52 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6 53 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 54 2.3. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6 55 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7 57 3.2. Specification of the Mounted Schema . . . . . . . . . . . 7 58 3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 11 59 4. Refering to Data Nodes in the Parent Schema . . . . . . . . . 11 60 5. RPC operations and Notifications . . . . . . . . . . . . . . 12 61 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 13 62 7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 15 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 66 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 69 12.2. Informative References . . . . . . . . . . . . . . . . . 22 70 Appendix A. Example: Device Model with LNEs and NIs . . . . . . 23 71 A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 23 72 A.2. Logical Network Elements . . . . . . . . . . . . . . . . 24 73 A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 27 74 A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 29 75 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 29 76 B.1. Referencing Mount Points Using Schema Node Identifiers . 29 77 B.2. Defining the "mount-point" Extension in a Separate Module 30 78 B.3. Parent References . . . . . . . . . . . . . . . . . . . . 31 79 B.4. RPC Operations and Notifications in Mounted Modules . . . 31 80 B.5. Tree Representation . . . . . . . . . . . . . . . . . . . 32 81 B.6. Design-Time Mounts . . . . . . . . . . . . . . . . . . . 32 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 84 1. Introduction 86 Modularity and extensibility were among the leading design principles 87 of the YANG data modeling language. As a result, the same YANG 88 module can be combined with various sets of other modules and thus 89 form a data model that is tailored to meet the requirements of a 90 specific use case. Server implementors are only required to specify 91 all YANG modules comprising the data model (together with their 92 revisions and other optional choices) in the YANG library data 93 ([RFC7895], and Section 5.6.4 of [RFC7950]) implemented by the 94 server. Such YANG modules appear in the data model "side by side", 95 i.e., top-level data nodes of each module - if there are any - are 96 also top-level nodes of the overall data model. 98 Furthermore, YANG has two mechanisms for contributing a schema 99 hierarchy defined elsewhere to the contents of an internal node of 100 the schema tree; these mechanisms are realized through the following 101 YANG statements: 103 o The "uses" statement explicitly incorporates the contents of a 104 grouping defined in the same or another module. See Section 4.2.6 105 of [RFC7950] for more details. 107 o The "augment" statement explicitly adds contents to a target node 108 defined in the same or another module. See Section 4.2.8 of 109 [RFC7950] for more details. 111 With both mechanisms, the source or target YANG module explicitly 112 defines the exact location in the schema tree where the new nodes are 113 placed. 115 In some cases these mechanisms are not sufficient; it is often 116 necessary that an existing module (or a set of modules) is added to 117 the data model starting at a non-root location. For example, YANG 118 modules such as "ietf-interfaces" [RFC7223] are often defined so as 119 to be used in a data model of a physical device. Now suppose we want 120 to model a device that supports multiple logical devices 121 [I-D.ietf-rtgwg-lne-model], each of which has its own instantiation 122 of "ietf-interfaces", and possibly other modules, but, at the same 123 time, we want to be able to manage all these logical devices from the 124 master device. Hence, we would like to have a schema like this: 126 +--rw interfaces 127 | +--rw interface* [name] 128 | ... 129 +--rw logical-device* [name] 130 +--rw name 131 | ... 132 +--rw interfaces 133 +--rw interface* [name] 134 ... 136 With the "uses" approach, the complete schema tree of 137 "ietf-interfaces" would have to be wrapped in a grouping, and then 138 this grouping would have to be used at the top level (for the master 139 device) and then also in the "logical-device" list (for the logical 140 devices). This approach has several disadvantages: 142 o It is not scalable because every time there is a new YANG module 143 that needs to be added to the logical device model, we have to 144 update the model for logical devices with another "uses" statement 145 pulling in contents of the new module. 147 o Absolute references to nodes defined inside a grouping may break 148 if the grouping is used in different locations. 150 o Nodes defined inside a grouping belong to the namespace of the 151 module where it is used, which makes references to such nodes from 152 other modules difficult or even impossible. 154 o It would be difficult for vendors to add proprietary modules when 155 the "uses" statements are defined in a standard module. 157 With the "augment" approach, "ietf-interfaces" would have to augment 158 the "logical-device" list with all its nodes, and at the same time 159 define all its nodes at the top level. The same hierarchy of nodes 160 would thus have to be defined twice, which is clearly not scalable 161 either. 163 This document introduces a new generic mechanism, denoted as schema 164 mount, that allows for mounting one data model consisting of any 165 number of YANG modules at a specified location of another (parent) 166 schema. Unlike the "uses" and "augment" approaches discussed above, 167 the mounted modules needn't be specially prepared for mounting and, 168 consequently, existing modules such as "ietf-interfaces" can be 169 mounted without any modifications. 171 The basic idea of schema mount is to label a data node in the parent 172 schema as the mount point, and then define a complete data model to 173 be attached to the mount point so that the labeled data node 174 effectively becomes the root node of the mounted data model. 176 In principle, the mounted schema can be specified at three different 177 phases of the data model life cycle: 179 1. Design-time: the mounted schema is defined along with the mount 180 point in the parent module. In this case, the mounted schema has 181 to be the same for every implementation of the parent module. 183 2. Implementation-time: the mounted schema is defined by a server 184 implementor and is as stable as YANG library information, i.e., 185 it may change after an upgrade of server software but not after 186 rebooting the server. Also, a client can learn the entire schema 187 together with YANG library data. 189 3. Run-time: the mounted schema is defined by instance data that is 190 part of the mounted data model. If there are multiple instances 191 of the same mount point (e.g., in multiple entries of a list), 192 the mounted data model may be different for each instance. 194 The schema mount mechanism defined in this document provides support 195 only for the latter two cases because design-time definition of the 196 mounted schema doesn't play well with the existing YANG modularity 197 mechanisms. For example, it would be impossible to augment the 198 mounted data model. 200 Schema mount applies to the data model, and specifically does not 201 assume anything about the source of instance data for the mounted 202 schemas. It may be implemented using the same instrumentation as the 203 rest of the system, or it may be implemented by querying some other 204 system. Future specifications may define mechanisms to control or 205 monitor the implementation of specific mount points. 207 This document allows mounting of complete data models only. Other 208 specifications may extend this model by defining additional 209 mechanisms such as mounting sub-hierarchies of a module. 211 2. Terminology and Notation 213 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 215 "OPTIONAL" in this document are to be interpreted as described in BCP 216 14, [RFC2119]. 218 The following terms are defined in [RFC6241] and are not redefined 219 here: 221 o client 223 o notification 225 o server 227 The following terms are defined in [RFC7950] and are not redefined 228 here: 230 o action 232 o configuration data 234 o container 236 o list 237 o operation 239 The following terms are defined in [RFC7223] and are not redefined 240 here: 242 o system-controlled interface 244 2.1. Glossary of New Terms 246 o inline schema: a mounted schema whose definition is provided as 247 part of the mounted data, using YANG library [RFC7895]. 249 o mount point: container or list node whose definition contains the 250 "mount-point" extension statement. The argument of the 251 "mount-point" statement defines the name of the mount point. 253 o parent schema (of a particular mounted schema): the schema that 254 contains the mount point for the mounted schema. 256 o top-level schema: a schema according to [RFC7950] in which schema 257 trees of each module (except augments) start at the root node. 259 2.2. Tree Diagrams 261 A simplified graphical representation of the data model is used in 262 this document. The meaning of the symbols in these diagrams is as 263 follows: 265 o Brackets "[" and "]" enclose list keys. 267 o Abbreviations before data node names: "rw" means configuration 268 data (read-write) and "ro" state data (read-only). 270 o Symbols after data node names: "?" means an optional node, "!" 271 means a presence container, and "*" denotes a list and leaf-list. 273 o Parentheses enclose choice and case nodes, and case nodes are also 274 marked with a colon (":"). 276 o Ellipsis ("...") stands for contents of subtrees that are not 277 shown. 279 2.3. Namespace Prefixes 281 In this document, names of data nodes, YANG extensions, actions and 282 other data model objects are often used without a prefix, as long as 283 it is clear from the context in which YANG module each name is 284 defined. Otherwise, names are prefixed using the standard prefix 285 associated with the corresponding YANG module, as shown in Table 1. 287 +---------+------------------------+-----------+ 288 | Prefix | YANG module | Reference | 289 +---------+------------------------+-----------+ 290 | yangmnt | ietf-yang-schema-mount | Section 8 | 291 | inet | ietf-inet-types | [RFC6991] | 292 | yang | ietf-yang-types | [RFC6991] | 293 | yanglib | ietf-yang-library | [RFC7895] | 294 +---------+------------------------+-----------+ 296 Table 1: Namespace Prefixes 298 3. Schema Mount 300 The schema mount mechanism defined in this document provides a new 301 extensibility mechanism for use with YANG 1.1. In contrast to the 302 existing mechanisms described in Section 1, schema mount defines the 303 relationship between the source and target YANG modules outside these 304 modules. The procedure consists of two separate steps that are 305 described in the following subsections. 307 3.1. Mount Point Definition 309 A "container" or "list" node becomes a mount point if the 310 "mount-point" extension (defined in the "ietf-yang-schema-mount" 311 module) is used in its definition. This extension can appear only as 312 a substatement of "container" and "list" statements. 314 The argument of the "mount-point" extension is a YANG identifier that 315 defines the name of the mount point. A module MAY contain multiple 316 "mount-point" statements having the same argument. 318 It is therefore up to the designer of the parent schema to decide 319 about the placement of mount points. A mount point can also be made 320 conditional by placing "if-feature" and/or "when" as substatements of 321 the "container" or "list" statement that represents the mount point. 323 The "mount-point" statement MUST NOT be used in a YANG version 1 324 module. Note, however, that modules written in any YANG version, 325 including version 1, can be mounted under a mount point. 327 3.2. Specification of the Mounted Schema 329 Mounted schemas for all mount points in the parent schema are defined 330 as state data in the "yangmnt:schema-mounts" container. Data in this 331 container is intended to be as stable as data in the top-level YANG 332 library [RFC7895]. In particular, it SHOULD NOT change during the 333 same management session. 335 The "schema-mount" container has the "mount-point" list as one of its 336 children. Every entry of this list refers through its key to a mount 337 point and specifies the mounted schema. 339 If a mount point is defined in the parent schema but does not have an 340 entry in the "mount-point" list, then the mounted schema is void, 341 i.e., instances of that mount point MUST NOT contain any data above 342 those that are defined in the parent schema. 344 If multiple mount points with the same name are defined in the same 345 module - either directly or because the mount point is defined in a 346 grouping and the grouping is used multiple times - then the 347 corresponding "mount-point" entry applies equally to all such mount 348 points. 350 The "config" property of mounted schema nodes is overriden and all 351 nodes in the mounted schema are read-only ("config false") if at 352 least one of the following conditions is satisfied for a mount point: 354 1. The mount point is itself defined as "config false". 356 2. The "config" leaf in the corresponding entry of the "mount-point" 357 list is set to "false". 359 An entry of the "mount-point" list can specify the mounted schema in 360 two different ways: 362 1. by stating that the schema is available inline, i.e., in run-time 363 instance data; or 365 2. by referring to one or more entries of the "schema" list in the 366 same instance of "schema-mounts". 368 In case 1, every instance of the mount point that exists in the 369 parent tree MUST contain a copy of YANG library data [RFC7895] that 370 defines the mounted schema exactly as for a top-level data model. A 371 client is expected to retrieve this data from the instance tree, 372 possibly after creating the mount point. Instances of the same mount 373 point MAY use different mounted schemas. 375 In case 2, the mounted schema is defined by the combination of all 376 "schema" entries referred to in the "use-schema" list. Optionally, a 377 reference to a "schema" entry can be made conditional by including 378 the "when" leaf. Its argument is an XPath expression that is 379 evaluated in the parent tree with the mount point instance as the 380 context node. The conditional "schema" entry is used only if the 381 XPath expression evaluates to true. XPath expressions in the 382 argument of "when" may use namespace prefixes that are declared in 383 the "namespace" list (child of "schema-mounts"). 385 Conditional schemas may be used, for example, in a situation where 386 virtual devices are of several different types and the schema for 387 each type is fixed and known in advance. The list of virtual devices 388 in a parent schema module (say "example-virtual-host") might be 389 defined as follows: 391 list virtual-device { 392 key name; 393 leaf name { 394 type string; 395 } 396 leaf type { 397 type identityref { 398 base virtual-device-type; 399 } 400 } 401 container root { 402 yangmnt:mount-point virtual-device; 403 } 405 The "schema-mounts" specification in state data might contain, for 406 example, 407 "yangmnt:schema-mounts": { 408 "namespace": [ 409 { 410 "prefix": "evh", 411 "ns-uri": "http://example.org/ns/example-virtual-host" 412 } 413 ], 414 "mount-point": [ 415 { 416 "module": "example-virtual-host", 417 "name": "root", 418 "use-schema": [ 419 { 420 "name": "virtual-router-schema", 421 "when": "derived-from(../evh:type, 'evh:virtual-router')" 422 }, 423 { 424 "name": "virtual-switch-schema", 425 "when": "derived-from(../evh:type, 'evh:virtual-switch')" 426 } 427 ], 428 "schema": [ 429 { 430 "name": "virtual-router-schema", 431 "module": [ 432 ... 433 ] 434 }, 435 { 436 "name": "virtual-switch-schema", 437 "module": [ 438 ... 439 ] 440 } 441 ] 442 } 444 The schema of virtual device instances can then be controlled by 445 setting the "type" leaf to an appropriate identity derived from the 446 "virtual-device-type" base. 448 In case 2, the mounted schema is specified as implementation-time 449 data that can be retrieved together with YANG library data for the 450 parent schema, i.e., even before any instances of the mount point 451 exist. However, the mounted schema has to be the same for all 452 instances of the mount point (except for parts that are conditional 453 due to "when" leaves). 455 Each entry of the "schema" list contains 457 o a list in the YANG library format specifying all YANG modules (and 458 revisions etc.) that are implemented or imported in the mounted 459 schema; 461 o (optionally) a new "schema-mounts" specification that applies to 462 mount points defined within the mounted schema. 464 3.3. Multiple Levels of Schema Mount 466 YANG modules in a mounted schema MAY again contain mount points under 467 which subschemas can be mounted. Consequently, it is possible to 468 construct data models with an arbitrary number of schema levels. A 469 subschema for a mount point contained in a mounted module can be 470 specified in one of the following ways: 472 o by implementing "ietf-yang-library" and "ietf-yang-schema-mount" 473 modules in the mounted schema, and specifying the subschemas 474 exactly as it is done in the top-level schema 476 o by using the "mount-point" list inside the coresponding "schema" 477 entry. 479 The former method is applicable to both "inline" and "use-schema" 480 cases whereas the latter requires the "use-schema" case. On the 481 other hand, the latter method allows for a compact representation of 482 a multi-level schema the does not rely on the presence of any 483 instance data. 485 4. Refering to Data Nodes in the Parent Schema 487 A fundamental design principle of schema mount is that the mounted 488 data model works exactly as a top-level data model, i.e., it is 489 confined to the "mount jail". This means that all paths in the 490 mounted data model (in leafrefs, instance-identifiers, XPath 491 expressions, and target nodes of augments) are interpreted with the 492 mount point as the root node. YANG modules of the mounted schema as 493 well as corresponding instance data thus cannot refer to schema nodes 494 or instance data outside the mount jail. 496 However, this restriction is sometimes too severe. A typical example 497 are network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI 498 has its own routing engine but the list of interfaces is global and 499 shared by all NIs. If we want to model this organization with the NI 500 schema mounted using schema mount, the overall schema tree would look 501 schematically as follows: 503 +--rw interfaces 504 | +--rw interface* [name] 505 | ... 506 +--rw network-instances 507 +--rw network-instance* [name] 508 +--rw name 509 +--rw root 510 +--rw routing 511 ... 513 Here, the "root" node is the mount point for the NI schema. Routing 514 configuration inside an NI often needs to refer to interfaces (at 515 least those that are assigned to the NI), which is impossible unless 516 such a reference can point to a node in the parent schema (interface 517 name). 519 Therefore, schema mount also allows for such references, albeit in a 520 limited and controlled way. The "schema-mounts" container has a 521 child leaf-list named "parent-reference" that contains zero or more 522 module names. All modules appearing in this leaf-list MUST be 523 implemented in the parent schema and MUST NOT be implemented in the 524 mounted schema. All absolute leafref paths and instance identifiers 525 within the mounted data model and corresponding instance data tree 526 are then evaluated as follows: 528 o If the leftmost node-identifier (right after the initial slash) 529 belongs to the namespace of a module that is listed in 530 "parent-reference", then the root of the accessible tree is not 531 the mount point but the root of the parent schema. 533 o Other rules for the "leafref" and "instance-identifier" types as 534 defined in Sections 9.9 and 9.13 of [RFC7950] remain in effect. 536 It is worth emphasizing that the mount jail can be escaped only via 537 absolute leafref paths and instance identifiers. Relative leafref 538 paths, "must"/"when" expressions and schema node identifiers are 539 still restricted to the mounted schema. 541 5. RPC operations and Notifications 543 If a mounted YANG module defines an RPC operation, clients can invoke 544 this operation by representing it as an action defined for the 545 corresponding mount point, see Section 7.15 of ^RFC7950. An example 546 of this is given in Appendix A.4. 548 Similarly, if the server emits a notification defined at the top 549 level of any mounted module, it MUST be represented as if the 550 notification was connected to the mount point, see Section 7.16 of 551 [RFC7950]. 553 6. Implementation Notes 555 Network management of devices that use a data model with schema mount 556 can be implemented in different ways. However, the following 557 implementations options are envisioned as typical: 559 o shared management: instance data of both parent and mounted 560 schemas are accessible within the same management session. 562 o split management: one (master) management session has access to 563 instance data of both parent and mounted schemas but, in addition, 564 an extra session exists for every instance of the mount point, 565 having access only to the mounted data tree. 567 7. Data Model 569 This document defines the YANG 1.1 module [RFC7950] 570 "ietf-yang-schema-mount", which has the following structure: 572 module: ietf-yang-schema-mount 573 +--ro schema-mounts 574 +--ro namespace* [prefix] 575 | +--ro prefix yang:yang-identifier 576 | +--ro ns-uri? inet:uri 577 +--ro mount-point* [module name] 578 | +--ro module yang:yang-identifier 579 | +--ro name yang:yang-identifier 580 | +--ro config? boolean 581 | +--ro (schema-ref)? 582 | +--:(inline) 583 | | +--ro inline? empty 584 | +--:(use-schema) 585 | +--ro use-schema* [name] 586 | +--ro name 587 | | -> /schema-mounts/schema/name 588 | +--ro when? yang:xpath1.0 589 | +--ro parent-reference* yang:yang-identifier 590 +--ro schema* [name] 591 +--ro name string 592 +--ro module* [name revision] 593 | +--ro name yang:yang-identifier 594 | +--ro revision union 595 | +--ro schema? inet:uri 596 | +--ro namespace inet:uri 597 | +--ro feature* yang:yang-identifier 598 | +--ro deviation* [name revision] 599 | | +--ro name yang:yang-identifier 600 | | +--ro revision union 601 | +--ro conformance-type enumeration 602 | +--ro submodule* [name revision] 603 | +--ro name yang:yang-identifier 604 | +--ro revision union 605 | +--ro schema? inet:uri 606 +--ro mount-point* [module name] 607 +--ro module yang:yang-identifier 608 +--ro name yang:yang-identifier 609 +--ro config? boolean 610 +--ro (schema-ref)? 611 +--:(inline) 612 | +--ro inline? empty 613 +--:(use-schema) 614 +--ro use-schema* [name] 615 +--ro name 616 | -> /schema-mounts/schema/name 617 +--ro when? yang:xpath1.0 618 +--ro parent-reference* yang:yang-identifier 620 8. Schema Mount YANG Module 622 This module references [RFC6991] and [RFC7895]. 624 file "ietf-yang-schema-mount@2017-03-06.yang" 626 module ietf-yang-schema-mount { 627 yang-version 1.1; 628 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"; 629 prefix yangmnt; 631 import ietf-inet-types { 632 prefix inet; 633 reference 634 "RFC 6991: Common YANG Data Types"; 635 } 637 import ietf-yang-types { 638 prefix yang; 639 reference 640 "RFC 6991: Common YANG Data Types"; 641 } 643 import ietf-yang-library { 644 prefix yanglib; 645 reference 646 "RFC 7895: YANG Module Library"; 647 } 649 organization 650 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 652 contact 653 "WG Web: 654 WG List: 656 Editor: Martin Bjorklund 657 659 Editor: Ladislav Lhotka 660 "; 662 description 663 "This module defines a YANG extension statement that can be used 664 to incorporate data models defined in other YANG modules in a 665 module. It also defines operational state data that specify the 666 overall structure of the data model. 668 Copyright (c) 2017 IETF Trust and the persons identified as 669 authors of the code. All rights reserved. 671 Redistribution and use in source and binary forms, with or 672 without modification, is permitted pursuant to, and subject to 673 the license terms contained in, the Simplified BSD License set 674 forth in Section 4.c of the IETF Trust's Legal Provisions 675 Relating to IETF Documents 676 (https://trustee.ietf.org/license-info). 678 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 679 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 680 'OPTIONAL' in the module text are to be interpreted as described 681 in RFC 2119 (https://tools.ietf.org/html/rfc2119). 683 This version of this YANG module is part of RFC XXXX 684 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 685 full legal notices."; 687 revision 2017-03-06 { 688 description 689 "Initial revision."; 690 reference 691 "RFC XXXX: YANG Schema Mount"; 692 } 694 /* 695 * Extensions 696 */ 698 extension mount-point { 699 argument name; 700 description 701 "The argument 'name' is a YANG identifier, i.e., it is of the 702 type 'yang:yang-identifier'. 704 The 'mount-point' statement MUST NOT be used in a YANG 705 version 1 module, neither explicitly nor via a 'uses' 706 statement. 708 The 'mount-point' statement MAY be present as a substatement 709 of 'container' and 'list', and MUST NOT be present elsewhere. 711 If a mount point is defined in a grouping, its name is bound 712 to the module where the grouping is used. 714 A mount point defines a place in the node hierarchy where 715 other data models may be attached. A server that implements a 716 module with a mount point populates the 717 /schema-mounts/mount-point list with detailed information on 718 which data models are mounted at each mount point."; 719 } 721 /* 722 * Groupings 723 */ 725 grouping mount-point-list { 726 description 727 "This grouping is used inside the 'schema-mounts' container and 728 inside the 'schema' list."; 729 list mount-point { 730 key "module name"; 731 description 732 "Each entry of this list specifies a schema for a particular 733 mount point. 735 Each mount point MUST be defined using the 'mount-point' 736 extension in one of the modules listed in the corresponding 737 YANG library instance with conformance type 'implement'. The 738 corresponding YANG library instance is: 740 - standard YANG library state data as defined in RFC 7895, 741 if the 'mount-point' list is a child of 'schema-mounts', 743 - the contents of the sibling 'yanglib:modules-state' 744 container, if the 'mount-point' list is a child of 745 'schema'."; 746 leaf module { 747 type yang:yang-identifier; 748 description 749 "Name of a module containing the mount point."; 750 } 751 leaf name { 752 type yang:yang-identifier; 753 description 754 "Name of the mount point defined using the 'mount-point' 755 extension."; 756 } 757 leaf config { 758 type boolean; 759 default "true"; 760 description 761 "If this leaf is set to 'false', then all data nodes in the 762 mounted schema are read-only (config false), regardless of 763 their 'config' property."; 765 } 766 choice schema-ref { 767 description 768 "Alternatives for specifying the schema."; 769 leaf inline { 770 type empty; 771 description 772 "This leaf indicates that the server has mounted 773 'ietf-yang-library' and 'ietf-schema-mount' at the mount 774 point, and their instantiation (i.e., state data 775 containers 'yanglib:modules-state' and 'schema-mounts') 776 provides the information about the mounted schema."; 777 } 778 list use-schema { 779 key "name"; 780 description 781 "Each entry of this list contains a reference to a schema 782 defined in the /schema-mounts/schema list. The entry can 783 be made conditional by specifying an XPath expression in 784 the 'when' leaf."; 785 leaf name { 786 type leafref { 787 path "/schema-mounts/schema/name"; 788 } 789 description 790 "Name of the referenced schema."; 791 } 792 leaf when { 793 type yang:xpath1.0; 794 description 795 "This leaf contains an XPath expression. If it is 796 present, then the current entry applies if and only if 797 the expression evaluates to true. 799 The XPath expression is evaluated once for each 800 instance of the data node containing the mount 801 point for which the 'when' leaf is defined. 803 The XPath expression is evaluated using the rules 804 specified in sec. 6.4 of RFC 7950, with these 805 modifications: 807 - The context node is the data node instance 808 containing the corresponding 'mount-point' 809 statement. 811 - The accessible tree contains only data belonging to 812 the parent schema, i.e., all instances of data 813 nodes containing the mount points are considered 814 empty. 816 - The set of namespace declarations is the set of all 817 prefix/namespace pairs defined in the 818 /schema-mounts/namespace list. Names without a 819 namespace prefix belong to the same namespace as the 820 context node."; 821 } 822 leaf-list parent-reference { 823 type yang:yang-identifier; 824 must "not(/schema-mounts/schema[name=current()/../name]/" 825 + "module[name=current() and conformance-type=" 826 + "'implement'])" { 827 error-message "Parent references cannot be used for a " 828 + "module implemented in the mounted schema."; 829 description 830 "Modules that are used for parent references MUST NOT 831 be implemented in the mounted schema."; 832 } 833 description 834 "Entries of this leaf-list are names of YANG modules. 835 All these modules MUST be implemented in the parent 836 schema. 838 Within the mounted schema and the corresponding data 839 tree, conceptual evaluation of absolute leafref paths 840 and instance identifiers is modified in the following 841 way: 843 If the leftmost node-identifier in an absolute leafref 844 path or instance identifier belongs to a module whose 845 name is listed in 'parent-reference', then the root 846 of the accessible data tree coincides with the root of 847 the parent data tree."; 848 } 849 } 850 } 851 } 852 } 854 /* 855 * State data nodes 856 */ 858 container schema-mounts { 859 config false; 860 description 861 "Contains information about the structure of the overall 862 mounted data model implemented in the server."; 863 list namespace { 864 key "prefix"; 865 description 866 "This list provides a mapping of namespace prefixes that are 867 used in XPath expressions of 'when' leafs to the 868 corresponding namespace URI references."; 869 leaf prefix { 870 type yang:yang-identifier; 871 description 872 "Namespace prefix."; 873 } 874 leaf ns-uri { 875 type inet:uri; 876 description 877 "Namespace URI reference."; 878 } 879 } 880 uses mount-point-list; 881 list schema { 882 key "name"; 883 description 884 "Each entry specifies a schema that can be mounted at a mount 885 point. The schema information consists of two parts: 887 - an instance of YANG library that defines YANG modules used 888 in the schema, 890 - mount-point list with content identical to the top-level 891 mount-point list (this makes the schema structure 892 recursive)."; 893 leaf name { 894 type string; 895 description 896 "Arbitrary name of the schema entry."; 897 } 898 uses yanglib:module-list; 899 uses mount-point-list; 900 } 901 } 902 } 904 906 9. IANA Considerations 908 This document registers a URI in the IETF XML registry [RFC3688]. 909 Following the format in RFC 3688, the following registration is 910 requested to be made. 912 URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount 914 Registrant Contact: The IESG. 916 XML: N/A, the requested URI is an XML namespace. 918 This document registers a YANG module in the YANG Module Names 919 registry [RFC6020]. 921 name: ietf-yang-schema-mount 922 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount 923 prefix: yangmnt 924 reference: RFC XXXX 926 10. Security Considerations 928 TBD 930 11. Contributors 932 The idea of having some way to combine schemas from different YANG 933 modules into one has been proposed independently by several groups of 934 people: Alexander Clemm, Jan Medved, and Eric Voit 935 ([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps: 937 o Lou Berger, LabN Consulting, L.L.C., 939 o Alexander Clemm, Huawei, 941 o Christian Hopps, Deutsche Telekom, 943 o Jan Medved, Cisco, 945 o Eric Voit, Cisco, 947 12. References 949 12.1. Normative References 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", BCP 14, RFC 2119, 953 DOI 10.17487/RFC2119, March 1997, 954 . 956 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 957 DOI 10.17487/RFC3688, January 2004, 958 . 960 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 961 the Network Configuration Protocol (NETCONF)", RFC 6020, 962 DOI 10.17487/RFC6020, October 2010, 963 . 965 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 966 RFC 6991, DOI 10.17487/RFC6991, July 2013, 967 . 969 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 970 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 971 . 973 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 974 RFC 7950, DOI 10.17487/RFC7950, August 2016, 975 . 977 12.2. Informative References 979 [I-D.clemm-netmod-mount] 980 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined 981 Information from Remote Datastores", draft-clemm-netmod- 982 mount-05 (work in progress), September 2016. 984 [I-D.ietf-isis-yang-isis-cfg] 985 Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L. 986 Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf- 987 isis-yang-isis-cfg-15 (work in progress), February 2017. 989 [I-D.ietf-rtgwg-device-model] 990 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 991 "Network Device YANG Organizational Models", draft-ietf- 992 rtgwg-device-model-01 (work in progress), October 2016. 994 [I-D.ietf-rtgwg-lne-model] 995 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 996 "YANG Logical Network Elements", draft-ietf-rtgwg-lne- 997 model-01 (work in progress), October 2016. 999 [I-D.ietf-rtgwg-ni-model] 1000 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 1001 "YANG Network Instances", draft-ietf-rtgwg-ni-model-01 1002 (work in progress), October 2016. 1004 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1005 and A. Bierman, Ed., "Network Configuration Protocol 1006 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1007 . 1009 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1010 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1011 . 1013 Appendix A. Example: Device Model with LNEs and NIs 1015 This non-normative example demonstrates an implementation of the 1016 device model as specified in Section 2 of 1017 [I-D.ietf-rtgwg-device-model], using both logical network elements 1018 (LNE) and network instances (NI). 1020 A.1. Physical Device 1022 The data model for the physical device may be described by this YANG 1023 library content: 1025 "ietf-yang-library:modules-state": { 1026 "module-set-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899", 1027 "module": [ 1028 { 1029 "name": "iana-if-type", 1030 "revision": "2014-05-08", 1031 "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", 1032 "conformance-type": "implement" 1033 }, 1034 { 1035 "name": "ietf-inet-types", 1036 "revision": "2013-07-15", 1037 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1038 "conformance-type": "import" 1039 }, 1040 { 1041 "name": "ietf-interfaces", 1042 "revision": "2014-05-08", 1043 "feature": [ 1044 "arbitrary-names", 1045 "pre-provisioning" 1046 ], 1047 "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1048 "conformance-type": "implement" 1049 }, 1050 { 1051 "name": "ietf-ip", 1052 "revision": "2014-06-16", 1053 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", 1054 "conformance-type": "implement" 1055 }, 1056 { 1057 "name": "ietf-logical-network-element", 1058 "revision": "2016-10-21", 1059 "feature": [ 1060 "bind-lne-name" 1061 ], 1062 "namespace": 1063 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element", 1064 "conformance-type": "implement" 1065 }, 1066 { 1067 "name": "ietf-yang-library", 1068 "revision": "2016-06-21", 1069 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1070 "conformance-type": "implement" 1071 }, 1072 { 1073 "name": "ietf-yang-schema-mount", 1074 "revision": "2017-03-06", 1075 "namespace": 1076 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1077 "conformance-type": "implement" 1078 }, 1079 { 1080 "name": "ietf-yang-types", 1081 "revision": "2013-07-15", 1082 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1083 "conformance-type": "import" 1084 } 1085 ] 1086 } 1088 A.2. Logical Network Elements 1090 Each LNE can have a specific data model that is determined at run 1091 time, so it is appropriate to mount it using the "inline" method, 1092 hence the following "schema-mounts" data: 1094 "ietf-yang-schema-mount:schema-mounts": { 1095 "mount-point": [ 1096 { 1097 "module": "ietf-logical-network-element", 1098 "name": "root", 1099 "inline": [null] 1100 } 1101 ] 1102 } 1104 An administrator of the host device has to configure an entry for 1105 each LNE instance, for example, 1107 { 1108 "ietf-interfaces:interfaces": { 1109 "interface": [ 1110 { 1111 "name": "eth0", 1112 "type": "iana-if-type:ethernetCsmacd", 1113 "enabled": true, 1114 "ietf-logical-network-element:bind-lne-name": "eth0" 1115 } 1116 ] 1117 }, 1118 "ietf-logical-network-element:logical-network-elements": { 1119 "logical-network-element": [ 1120 { 1121 "name": "lne-1", 1122 "managed": true, 1123 "description": "LNE with NIs", 1124 "root": { 1125 ... 1126 } 1127 }, 1128 ... 1129 ] 1130 } 1131 } 1133 and then also place necessary state data as the contents of the 1134 "root" instance, which should include at least 1136 o YANG library data specifying the LNE's data model, for example: 1138 "ietf-yang-library:modules-state": { 1139 "module-set-id": "9358e11874068c8be06562089e94a89e0a392019", 1140 "module": [ 1141 { 1142 "name": "iana-if-type", 1143 "revision": "2014-05-08", 1144 "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", 1145 "conformance-type": "implement" 1146 }, 1147 { 1148 "name": "ietf-inet-types", 1149 "revision": "2013-07-15", 1150 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1151 "conformance-type": "import" 1152 }, 1153 { 1154 "name": "ietf-interfaces", 1155 "revision": "2014-05-08", 1156 "feature": [ 1157 "arbitrary-names", 1158 "pre-provisioning" 1159 ], 1160 "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1161 "conformance-type": "implement" 1162 }, 1163 { 1164 "name": "ietf-ip", 1165 "revision": "2014-06-16", 1166 "feature": [ 1167 "ipv6-privacy-autoconf" 1168 ], 1169 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", 1170 "conformance-type": "implement" 1171 }, 1172 { 1173 "name": "ietf-network-instance", 1174 "revision": "2016-10-27", 1175 "feature": [ 1176 "bind-network-instance-name" 1177 ], 1178 "namespace": 1179 "urn:ietf:params:xml:ns:yang:ietf-network-instance", 1180 "conformance-type": "implement" 1181 }, 1182 { 1183 "name": "ietf-yang-library", 1184 "revision": "2016-06-21", 1185 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1186 "conformance-type": "implement" 1187 }, 1188 { 1189 "name": "ietf-yang-schema-mount", 1190 "revision": "2017-03-06", 1191 "namespace": 1192 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1193 "conformance-type": "implement" 1194 }, 1195 { 1196 "name": "ietf-yang-types", 1197 "revision": "2013-07-15", 1198 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1199 "conformance-type": "import" 1200 } 1201 ] 1202 } 1204 o state data for interfaces assigned to the LNE instance (that 1205 effectively become system-controlled interfaces for the LNE), for 1206 example: 1208 "ietf-interfaces:interfaces-state": { 1209 "interface": [ 1210 { 1211 "name": "eth0", 1212 "type": "iana-if-type:ethernetCsmacd", 1213 "oper-status": "up", 1214 "statistics": { 1215 "discontinuity-time": "2016-12-16T17:11:27+02:00" 1216 }, 1217 "ietf-ip:ipv6": { 1218 "address": [ 1219 { 1220 "ip": "fe80::42a8:f0ff:fea8:24fe", 1221 "origin": "link-layer", 1222 "prefix-length": 64 1223 } 1224 ] 1225 } 1226 }, 1227 ... 1228 ] 1229 } 1231 A.3. Network Instances 1233 Assuming that network instances share the same data model, it can be 1234 mounted using the "use-schema" method as follows: 1236 "ietf-yang-schema-mount:schema-mounts": { 1237 "mount-point": [ 1238 { 1239 "module": "ietf-network-instance", 1240 "name": "root", 1241 "parent-reference": ["ietf-interfaces"], 1242 "use-schema": [ 1243 { 1244 "name": "ni-schema" 1245 } 1246 ] 1247 } 1248 ], 1249 "schema": [ 1250 { 1251 "name": "ni-schema", 1252 "module": [ 1253 { 1254 "name": "ietf-ipv4-unicast-routing", 1255 "revision": "2016-11-04", 1256 "namespace": 1257 "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing", 1258 "conformance-type": "implement" 1259 }, 1260 { 1261 "name": "ietf-ipv6-unicast-routing", 1262 "revision": "2016-11-04", 1263 "namespace": 1264 "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing", 1265 "conformance-type": "implement" 1266 }, 1267 { 1268 "name": "ietf-routing", 1269 "revision": "2016-11-04", 1270 "feature": [ 1271 "multiple-ribs", 1272 "router-id" 1273 ], 1274 "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 1275 "conformance-type": "implement" 1276 } 1277 ] 1278 } 1279 ] 1280 } 1282 Note also that the "ietf-interfaces" module appears in the 1283 "parent-reference" leaf-list for the mounted NI schema. This means 1284 that references to LNE interfaces, such as "outgoing-interface" in 1285 static routes, are valid despite the fact that "ietf-interfaces" 1286 isn't part of the NI schema. 1288 A.4. Invoking an RPC Operation 1290 Assume that the mounted NI data model also implements the "ietf-isis" 1291 module [I-D.ietf-isis-yang-isis-cfg]. An RPC operation defined in 1292 this module, such as "clear-adjacency", can be invoked by a client 1293 session of a LNE's RESTCONF server as an action tied to a the mount 1294 point of a particular network instance using a request URI like this 1295 (all on one line): 1297 POST /restconf/data/ietf-network-instance:network-instances/ 1298 network-instance=rtrA/root/ietf-isis:clear-adjacency HTTP/1.1 1300 Appendix B. Open Issues 1302 B.1. Referencing Mount Points Using Schema Node Identifiers 1304 Each entry in the "mount-point" list is currently identified by two 1305 keys, namely YANG module name and mount point name. An alternative 1306 is to use a schema node identifier of the mount point as a single 1307 key. 1309 For example, the "schema-mounts" data for NI (Appendix A.3) would be 1310 changed as follows (the "schema" list doesn't change): 1312 "ietf-yang-schema-mount:schema-mounts": { 1313 "namespace": [ 1314 { 1315 "prefix": "ni", 1316 "ns-uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" 1317 } 1318 ] 1319 "mount-point": [ 1320 { 1321 "target": "/ni:network-instances/ni:network-instance/ni:root", 1322 "parent-reference": ["ietf-interfaces"], 1323 "use-schema": [ 1324 { 1325 "name": "ni-schema" 1326 } 1327 ] 1328 } 1329 ], 1330 "schema": [ 1331 ... 1332 ] 1333 } 1335 This change would have several advantages: 1337 o the schema mount mechanism becomes even closer to augments, which 1338 may simplify implementation 1340 o if a mount point appears inside a grouping, then a different 1341 mounted schema can be used for each use of the grouping. 1343 o it optionally allows for use of mount without use of the mount- 1344 point extension. 1346 B.2. Defining the "mount-point" Extension in a Separate Module 1348 The "inline" method of schema mounting can be further simplified by 1349 defining the "inline" case as the default. That is, if a mount point 1350 is defined through the "mount-point" extension but is not present in 1351 the "mount-point" list, the "inline" schema mount is assumed. 1353 Consequently, a data model that uses only the "inline" method could 1354 omit the "schema-mounts" data entirely, but it still needs to use the 1355 "mount-point" extension. In order to enable this, the definition of 1356 the "mount-point" extension has to be moved to a YANG module of its 1357 own. 1359 A variant of this approach is to completely separate the "inline" and 1360 "use-schema" cases by dedicating the "mount-point" extension for use 1361 with the "inline" method only (with no "schema-mounts" data), and 1362 using schema node identifiers as described in Appendix B.1 for the 1363 "use-schema" case. 1365 B.3. Parent References 1367 As explained in Section 4, references to the parent schema can only 1368 be used in absolute leafref paths and instance identifiers. However, 1369 it is conceivable that they may be useful in other XPath expressions, 1370 e.g. in "must" statements. The authors believe it is impossible to 1371 allow for parent references in general XPath expressions because, for 1372 example, in a location path "//foo:bar" it would be unclear whether 1373 the lookup has to be started in the mounted or parent schema. 1375 Should parent references in general XPath be needed, it would be 1376 necessary to indicate it explicitly. One way to achieve this is to 1377 defining a new XPath function, e.g., parent-root(), that returns the 1378 root of the parent data tree. 1380 B.4. RPC Operations and Notifications in Mounted Modules 1382 Turning RPC operations defined in mounted modules into actions tied 1383 to the corresponding mount point (see Section 5, and similarly for 1384 notifications) is not possible if the path to the mount point in the 1385 parent schema contains a keyless list (Section 7.15 of [RFC7950]). 1386 The solutions for this corner case are possible: 1388 1. any mount point MUST NOT have a keyless list among its ancestors 1390 2. any mounted module MUST NOT contain RPC operations and/or 1391 notifications 1393 3. specifically for each mount point, at least one of the above 1394 conditions MUST be satisfied. 1396 4. treat such actions and notifications as non-existing, i.e., 1397 ignore them. 1399 The first two requirements seem rather restrictive. On the other 1400 hand, the last one is difficult to guarantee - for example, things 1401 can break after an augment within the mounted schema. 1403 B.5. Tree Representation 1405 Need to decide how/if mount points are represented in trees. 1407 B.6. Design-Time Mounts 1409 The document currently doesn't provide explicit support for design- 1410 time mounts. Design-time mounts have been identified as possibly for 1411 multiple cases, and it may be worthwhile to identify a minimum or 1412 complete set of modules that must be supported under a mount point. 1413 This could be used in service modules that want to allow for 1414 configuration of device-specific information. One option could be to 1415 add an extension that specify that a certain module is required to be 1416 mounted. 1418 Also, if design-time mounts are supported, it could be possible to 1419 represent both mounts points and their required modules in tree 1420 representations and support for such would need to be defined. 1422 Authors' Addresses 1424 Martin Bjorklund 1425 Tail-f Systems 1427 Email: mbj@tail-f.com 1429 Ladislav Lhotka 1430 CZ.NIC 1432 Email: lhotka@nic.cz