idnits 2.17.1 draft-ietf-netmod-schema-mount-02.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 221 has weird spacing: '...evision uni...' == Line 222 has weird spacing: '...ce-type enu...' == Line 225 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 (July 1, 2016) is 2853 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-04 == Outdated reference: A later version (-05) exists of draft-rtgyangdt-rtgwg-device-model-04 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 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: January 2, 2017 CZ.NIC 6 July 1, 2016 8 YANG Schema Mount 9 draft-ietf-netmod-schema-mount-02 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 January 2, 2017. 33 Copyright Notice 35 Copyright (c) 2016 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 2 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Augment and Validation in Mounted Data . . . . . . . . . 4 56 3.2. Top-level RPCs . . . . . . . . . . . . . . . . . . . . . 4 57 3.3. Top-level Notifications . . . . . . . . . . . . . . . . . 5 58 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 65 9.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 11 67 Appendix B. Example: Network Manager . . . . . . . . . . . . . . 14 68 B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 17 69 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 17 70 Appendix D. Alternative solutions . . . . . . . . . . . . . . . 17 71 D.1. Static Mount Points with YANG Library Only . . . . . . . 18 72 D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 19 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 1.1. Terminology 79 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14, [RFC2119]. 84 1.1.1. Tree Diagrams 86 A simplified graphical representation of the data model is used in 87 this document. The meaning of the symbols in these diagrams is as 88 follows: 90 o Brackets "[" and "]" enclose list keys. 92 o Abbreviations before data node names: "rw" means configuration 93 data (read-write) and "ro" state data (read-only). 95 o Symbols after data node names: "?" means an optional node, "!" 96 means a presence container, and "*" denotes a list and leaf-list. 98 o Parentheses enclose choice and case nodes, and case nodes are also 99 marked with a colon (":"). 101 o Ellipsis ("...") stands for contents of subtrees that are not 102 shown. 104 2. Background 106 YANG has two mechanisms for extending a data model with additional 107 nodes; "uses" and "augment". The "uses" statement explicitly 108 incorporates the contents of a "grouping" defined in some other 109 module. The "augment" statement explicitly adds contents to a target 110 node defined in some other module. In both these cases, the source 111 and/or target model explicitly defines the relationship between the 112 models. 114 In some cases these mechanisms are not sufficient. For example, 115 suppose we have a model like ietf-interfaces [RFC7223] that is 116 defined to be implemented in a device. Now suppose we want to model 117 a device that supports multiple logical devices 118 [I-D.rtgyangdt-rtgwg-device-model], where each such logical device 119 has its own instantiation of ietf-interfaces (and other models), but 120 at the same time, we'd like to be able to manage all these logical 121 devices from the main device. We would like something like this: 123 +--rw interfaces 124 | +--rw interface* [name] 125 | ... 126 +--rw logical-device* [name] 127 +--rw name string 128 | ... 129 +--rw interfaces 130 +--rw interface* [name] 131 ... 133 With the "uses" approach, ietf-interfaces would have to define a 134 grouping with all its nodes, and the new model for logical devices 135 would have to use this grouping. This is a not a scalable solution, 136 since every time there is a new model defined, we would have to 137 update our model for logical devices to use a grouping from the new 138 model. Another problem is that this approach cannot handle vendor- 139 specific modules. 141 With the "augment" approach, ietf-interfaces would have to augment 142 the logical-device list with all its nodes, and at the same time 143 define all its nodes on the top-level. This approach is also not 144 scalable, since there may be other models to which we would like to 145 add the interface list. 147 3. Schema Mount 149 The schema mount mechanism defined in this document takes a different 150 approach to the extensibility problem described in the previous 151 section. It decouples the definition of the relation between the 152 source and target models from the definitions of the models 153 themselves. 155 This is accomplished with a YANG extension statement that is used to 156 specify a mount point in a data model. The purpose of a mount point 157 is to define a place in the node hierarchy where other YANG data 158 models may be attached, without any special notation in the other 159 YANG data models. 161 For each mount point supported by a server, the server populates an 162 operational state node hierarchy with information about which models 163 it has mounted. This node hierarchy can be read by a client in order 164 to learn what is implemented on a server. 166 Schema mount applies to the data model, and specifically does not 167 assume anything about how the mounted data is implemented. It may be 168 implemented using the same instrumentation as the rest of the system, 169 or it may be implemented by querying some other system. Future 170 specifications may define mechanisms to control or monitor the 171 implementation of specific mount points. 173 This document allows mounting of complete data models only. Other 174 specifications may extend this model by defining additional 175 mechanisms, for example mounting of sub-hierarchies of a module. 177 3.1. Augment and Validation in Mounted Data 179 All paths (in leafrefs, instance-identifiers, XPath expressions, and 180 target nodes of augments) in the data models mounted at a mount point 181 are interpreted with the mount point as the root node, and the 182 mounted data nodes as its children. This means that data within a 183 mounted subtree can never refer to data outside of this subtree. 185 3.2. Top-level RPCs 187 If any mounted data model defines RPCs, these RPCs can be invoked by 188 clients by treating them as actions defined where the mount point is 189 specified. An example of this is given in Appendix B.1. 191 3.3. Top-level Notifications 193 If the server emits a notification defined at the top-level in any 194 mounted data model, it is treated as if the notification was attached 195 to the data node where the mount point is specified. 197 4. Data Model 199 This document defines the YANG 1.1 module 200 [I-D.ietf-netmod-rfc6020bis] "ietf-yang-schema-mount", which has the 201 following structure: 203 module: ietf-yang-schema-mount 204 +--ro mount-points 205 +--ro mount-point* [module name] 206 +--ro module yang:yang-identifier 207 +--ro name yang:yang-identifier 208 +--ro (data-model) 209 +--:(inline-yang-library) 210 | +--ro inline-yang-library? empty 211 +--:(modules) 212 +--ro modules 213 +--ro module* [name revision] 214 +--ro name yang:yang-identifier 215 +--ro revision union 216 +--ro schema? inet:uri 217 +--ro namespace inet:uri 218 +--ro feature* yang:yang-identifier 219 +--ro deviation* [name revision] 220 | +--ro name yang:yang-identifier 221 | +--ro revision union 222 +--ro conformance-type enumeration 223 +--ro submodule* [name revision] 224 +--ro name yang:yang-identifier 225 +--ro revision union 226 +--ro schema? inet:uri 228 5. Schema Mount YANG Module 230 This module references [RFC6991] and [RFC7895]. 232 file "ietf-yang-schema-mount@2016-04-05.yang" 234 module ietf-yang-schema-mount { 235 yang-version 1.1; 236 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"; 237 prefix yangmnt; 238 import ietf-yang-types { 239 prefix yang; 240 reference "RFC 6991: Common YANG Data Types"; 242 } 243 import ietf-yang-library { 244 prefix yanglib; 245 reference "RFC 7895: YANG Module Library"; 246 } 248 organization 249 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 251 contact 252 "WG Web: 253 WG List: 255 WG Chair: Thomas Nadeau 256 258 WG Chair: Juergen Schoenwaelder 259 261 WG Chair: Kent Watsen 262 264 Editor: Martin Bjorklund 265 "; 267 // RFC Ed.: replace XXXX with actual RFC number and remove this 268 // note. 269 description 270 "This module defines a YANG extension statement that can be used 271 to incorporate data models defined in other YANG modules in a 272 module. It also defines a operational state data so that 273 clients can learn which data models a server implements for the 274 mount points. 276 Copyright (c) 2016 IETF Trust and the persons identified as 277 authors of the code. All rights reserved. 279 Redistribution and use in source and binary forms, with or 280 without modification, is permitted pursuant to, and subject to 281 the license terms contained in, the Simplified BSD License set 282 forth in Section 4.c of the IETF Trust's Legal Provisions 283 Relating to IETF Documents 284 (http://trustee.ietf.org/license-info). 285 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 286 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 287 'OPTIONAL' in the module text are to be interpreted as described 288 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 290 This version of this YANG module is part of RFC XXXX 291 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 292 full legal notices."; 294 // RFC Ed.: update the date below with the date of RFC publication 295 // and remove this note. 296 revision 2016-07-01 { 297 description 298 "Initial revision."; 299 reference 300 "RFC XXXX: YANG Schema Mount"; 301 } 303 /* 304 * Extension statements 305 */ 307 extension mount-point { 308 argument name; 309 description 310 "The argument 'name' is a yang-identifier. The name of 311 the mount point MUST be unique within the module where it 312 is defined. 314 The 'mount-point' statement can be present in 'anydata'. 316 If a mount point is defined in a grouping, its name is bound 317 to the module where the grouping is used. Note that this 318 implies that such a grouping can be used at most once in a 319 module. 321 A mount point defines a place in the node hierarchy where 322 other data models may be attached. A server that implements 323 a module with a mount point, populates the 324 /mount-points/mount-point list with detailed information on 325 which data models are mounted at each mount point. 327 The 'mount-yang-library' extension may be used as a 328 substatement to 'mount-point'."; 329 } 331 extension mount-yang-library { 332 description 333 "The presence of this statement as a substatement to 334 'mount-point' indicates that the data model defined in the 335 module 'ietf-yang-library' is mounted. When this statement is 336 present, a client can discover the mounted YANG modules by 337 reading from the mounted 'ietf-yang-library' data. 339 This statement is useful if the mount point is defined in a 340 list and different list entries may mount a different 341 set of modules."; 342 } 344 /* 345 * Operational state data nodes 346 */ 348 container mount-points { 349 config false; 350 description 351 "Contains information about which mount points are implemented 352 in the server, and their data models."; 354 list mount-point { 355 key "module name"; 356 description 357 "Contains information about which data models are implemented 358 for the mountpoint 'name' defined in 'module'."; 360 leaf module { 361 type yang:yang-identifier; 362 description 363 "The name of the module where the mount point is defined."; 364 } 365 leaf name { 366 type yang:yang-identifier; 367 description 368 "The name of the mount point."; 369 } 370 choice data-model { 371 mandatory true; 372 description 373 "Indicates which data models the server implements 374 for this mount point. 376 It is expected that this choice may be augmented with other 377 data model discovery mechansisms."; 379 leaf inline-yang-library { 380 type empty; 381 description 382 "This leaf indicates that the server has mounted 383 'ietf-yang-library' at the mount point, and that the 384 instantiation of 'ietf-yang-library' contains the 385 information about which modules are mounted. 387 This is useful if the mount point is defined in a 388 list and different list entries may mount a different 389 set of modules."; 390 } 392 container modules { 393 description 394 "The 'module' list contains the set of modules that are 395 mounted at the mount point."; 397 uses yanglib:module-list; 398 } 399 } 400 } 401 } 402 } 404 406 6. IANA Considerations 408 This document registers a URI in the IETF XML registry [RFC3688]. 409 Following the format in RFC 3688, the following registration is 410 requested to be made. 412 URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount 414 Registrant Contact: The IESG. 416 XML: N/A, the requested URI is an XML namespace. 418 This document registers a YANG module in the YANG Module Names 419 registry [RFC6020]. 421 name: ietf-yang-schema-mount 422 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount 423 prefix: yangmnt 424 reference: RFC XXXX 426 7. Security Considerations 428 TBD 430 8. Contributors 432 The idea of having some way to combine schemas from different YANG 433 modules into one has been proposed independently by several groups of 434 people: Alexander Clemm, Jan Medved, and Eric Voit 435 ([I-D.clemm-netmod-mount]); Ladislav Lhotka 436 ([I-D.lhotka-netmod-ysdl]); and Lou Berger and Christian Hopps. 438 9. References 440 9.1. Normative References 442 [I-D.ietf-netmod-rfc6020bis] 443 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 444 draft-ietf-netmod-rfc6020bis-14 (work in progress), June 445 2016. 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, 449 DOI 10.17487/RFC2119, March 1997, 450 . 452 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 453 DOI 10.17487/RFC3688, January 2004, 454 . 456 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 457 the Network Configuration Protocol (NETCONF)", RFC 6020, 458 DOI 10.17487/RFC6020, October 2010, 459 . 461 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 462 RFC 6991, DOI 10.17487/RFC6991, July 2013, 463 . 465 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 466 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 467 . 469 9.2. Informative References 471 [I-D.clemm-netmod-mount] 472 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined 473 Information from Remote Datastores", draft-clemm-netmod- 474 mount-04 (work in progress), March 2016. 476 [I-D.lhotka-netmod-ysdl] 477 Lhotka, L., "YANG Schema Dispatching Language", draft- 478 lhotka-netmod-ysdl-00 (work in progress), November 2015. 480 [I-D.rtgyangdt-rtgwg-device-model] 481 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 482 "Network Device YANG Organizational Models", draft- 483 rtgyangdt-rtgwg-device-model-04 (work in progress), May 484 2016. 486 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 487 and A. Bierman, Ed., "Network Configuration Protocol 488 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 489 . 491 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 492 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 493 . 495 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 496 RFC 7277, DOI 10.17487/RFC7277, June 2014, 497 . 499 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 500 System Management", RFC 7317, DOI 10.17487/RFC7317, August 501 2014, . 503 Appendix A. Example: Logical Devices 505 Logical devices within a device typically use the same set of data 506 models in each instance. This can be modelled with a mount point: 508 module example-logical-devices { 509 yang-version 1.1; 510 namespace "urn:example:logical-devices"; 511 prefix exld; 513 import ietf-yang-schema-mount { 514 prefix yangmnt; 515 } 517 container logical-devices { 518 list logical-device { 519 key name; 520 leaf name { 521 type string; 522 } 524 anydata root { 525 yangmnt:mount-point logical-device; 526 } 527 } 528 } 529 } 531 A server with two logical devices that both implement 532 "ietf-interfaces" [RFC7223], "ietf-ip" [RFC7277], and "ietf-system" 533 [RFC7317] YANG modules might populate the "mount-points" container 534 with: 536 538 539 example-logical-devices 540 logical-device 541 542 543 ietf-interface 544 2014-05-08 545 546 urn:ietf:params:xml:ns:yang:ietf-interfaces 547 548 implement 549 550 551 ietf-ip 552 2014-06-16 553 554 urn:ietf:params:xml:ns:yang:ietf-ip 555 556 implement 557 558 559 ietf-system 560 2014-08-06 561 562 urn:ietf:params:xml:ns:yang:ietf-system 563 564 implement 565 566 567 ietf-yang-types 568 2013-07-15 569 570 urn:ietf:params:xml:ns:yang:ietf-yang-types 571 572 import 573 574 575 576 578 and the "logical-devices" container might have: 580 581 582 vrtrA 583 584 586 587 eth0 588 589 true 590 ... 591 592 ... 593 594 595 596 ... 597 598 599 600 601 vrtrB 602 603 605 606 eth0 607 608 true 609 ... 610 611 ... 612 613 614 615 ... 616 617 618 619 621 Appendix B. Example: Network Manager 623 This example shows how a Network Manager application can use schema 624 mount to define a data model with all its managed devices. Schema 625 mount is used to mount the data models each device supports, and 626 these data models can be discovered by a client via the 627 "ietf-yang-library" module that is mounted for each device. 629 module example-network-manager { 630 yang-version 1.1; 631 namespace "urn:example:network-manager"; 632 prefix exnm; 634 import ietf-inet-types { 635 prefix inet; 636 } 637 import ietf-yang-schema-mount { 638 prefix yangmnt; 639 } 641 container managed-devices { 642 description 643 "The managed devices and device communication settings."; 645 list device { 646 key name; 647 leaf name { 648 type string; 649 } 650 container transport { 651 choice protocol { 652 mandatory true; 653 container netconf { 654 leaf address { 655 type inet:ip-address; 656 mandatory true; 657 } 658 container authentication { 659 // ... 660 } 661 } 662 container restconf { 663 leaf address { 664 type inet:ip-address; 665 mandatory true; 666 } 667 // ... 668 } 669 } 670 } 671 anydata root { 672 yangmnt:mount-point managed-device { 673 yangmnt:mount-yang-library; 674 } 675 } 676 } 678 } 679 } 681 The "devices" container might have: 683 684 685 rtrA 686 687 688
2001:db8::2
689 690 ... 691 692 ... 693 694 695 696 698 699 ietf-system 700 ... 701 702 703 704 ... 705 706 707 708 709 rtrB 710 711 712
2001:db8::3
713 714 ... 715 716 ... 717 718 719 720 722 723 ietf-interfaces 724 ... 725 727 728 730 ... 731 732 733 734 736 B.1. Invoking an RPC 738 A client that wants to invoke the "restart" operation [RFC7317] on 739 the managed device "rtrA" over NETCONF [RFC6241] can send: 741 743 744 745 746 rtrA 747 748 749 750 751 752 753 754 755 757 Appendix C. Open Issues 759 o Is there a use case for specifying that certain modules are 760 required to be mounted under a mount point? 762 o Do we really need the case where ietf-yang-library is not mounted? 763 The solution would be simpler if we always use ietf-yang-library 764 at every mount point. See Appendix D.1. 766 o Support non-named mount points? (ysdl case) See Appendix D.2. 768 Appendix D. Alternative solutions 770 This section discusses some alternative solution ideas. 772 D.1. Static Mount Points with YANG Library Only 774 This solution supports named mount points, and always use ietf-yang- 775 library. 777 There would be just one single extension statement, and no additional 778 operational state data: 780 extension mount-point { 781 argument name; 782 } 784 Data models need to be prepared with this extension: 786 container logical-devices { 787 list logical-device { 788 key name; 789 ... 790 yangmnt:mount-point logical-device; 791 } 792 } 794 The tree on the server from Appendix A would look like this: 796 "example-logical-devices:logical-devices": { 797 "logical-device": [ 798 { 799 "name": "vrtrA", 800 "ietf-yang-library:modules-state": { 801 "module-set-id": "ef50fe1", 802 "module": [ 803 { 804 "name": "ietf-interfaces", 805 ... 806 }, 807 { 808 "name": "ietf-system", 809 ... 810 } 811 ] 812 }, 813 "ietf-interfaces:interfaces": { 814 ... 815 }, 816 "ietf-system:system": { 817 ... 818 } 819 }, 820 { 821 "name": "vrtrB", 822 "ietf-yang-library:modules-state": { 823 ... 824 } 825 } 826 ] 827 } 829 D.2. Dynamic Mount Points with YANG Library Only 831 This solution supports only non-named mount points, and always use 832 ietf-yang-library. 834 There would be no extension statement. Instead, the server would 835 populate a list of dynamic mount points. Each such mount point MUST 836 mount ietf-yang-library. 838 container mount-points { 839 config false; 840 list mount-point { 841 key path; 842 leaf path { 843 type schema-node-path; 844 } 845 } 846 } 848 The tree on the server from Appendix A would look like this: 850 "ietf-yang-schema-mount:mount-points": { 851 "mount-point": [ 852 { "path": "/exld:logical-devices/exld:logical-device" } 853 ] 854 }, 855 "example-logical-devices:logical-devices": { 856 "logical-device": [ 857 { 858 "name": "vrtrA", 859 "ietf-yang-library:modules-state": { 860 "module-set-id": "ef50fe1", 861 "module": [ 862 { 863 "name": "ietf-interfaces", 864 ... 865 }, 866 { 867 "name": "ietf-system", 868 ... 869 } 870 ] 871 }, 872 "ietf-interfaces:interfaces": { 873 ... 874 }, 875 "ietf-system:system": { 876 ... 877 } 878 }, 879 { 880 "name": "vrtrB", 881 "ietf-yang-library:modules-state": { 882 ... 883 } 884 } 885 ] 886 } 888 A client needs to read the "/mount-points/mount-point" list in order 889 to learn where the server has mounted data models. Next, it needs to 890 read the "modules-state" subtree for each instantiated mount point in 891 order to learn which modules are mounted at that instance. 893 Authors' Addresses 894 Martin Bjorklund 895 Tail-f Systems 897 Email: mbj@tail-f.com 899 Ladislav Lhotka 900 CZ.NIC 902 Email: mbj@lhotka@nic.cz