idnits 2.17.1 draft-bjorklund-netmod-structural-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 220 has weird spacing: '...evision uni...' == Line 221 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 (February 26, 2016) is 2974 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) == Outdated reference: A later version (-14) exists of draft-ietf-netmod-rfc6020bis-11 == Outdated reference: A later version (-06) exists of draft-clemm-netmod-mount-03 == Outdated reference: A later version (-05) exists of draft-rtgyangdt-rtgwg-device-model-03 -- 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: 0 errors (**), 0 flaws (~~), 8 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 February 26, 2016 5 Expires: August 29, 2016 7 YANG Structural Mount 8 draft-bjorklund-netmod-structural-mount-02 10 Abstract 12 This document defines a mechanism to combine YANG modules into the 13 schema defined in other YANG modules. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 29, 2016. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 2 52 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Structural Mount . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Augment and Validation in Mounted Data . . . . . . . . . 4 55 3.2. Top-level RPCs . . . . . . . . . . . . . . . . . . . . . 4 56 3.3. Top-level Notifications . . . . . . . . . . . . . . . . . 5 57 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Structural Mount YANG Module . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 64 9.2. Informative References . . . . . . . . . . . . . . . . . 10 65 Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 11 66 Appendix B. Example: Network Manager . . . . . . . . . . . . . . 13 67 B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 16 68 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 16 69 Appendix D. Alternative solutions . . . . . . . . . . . . . . . 16 70 D.1. Static Mount Points with YANG Library Only . . . . . . . 16 71 D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 18 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 74 1. Introduction 76 1.1. Terminology 78 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 80 "OPTIONAL" in this document are to be interpreted as described in BCP 81 14, [RFC2119]. 83 1.1.1. Tree Diagrams 85 A simplified graphical representation of the data model is used in 86 this document. The meaning of the symbols in these diagrams is as 87 follows: 89 o Brackets "[" and "]" enclose list keys. 91 o Abbreviations before data node names: "rw" means configuration 92 data (read-write) and "ro" state data (read-only). 94 o Symbols after data node names: "?" means an optional node, "!" 95 means a presence container, and "*" denotes a list and leaf-list. 97 o Parentheses enclose choice and case nodes, and case nodes are also 98 marked with a colon (":"). 100 o Ellipsis ("...") stands for contents of subtrees that are not 101 shown. 103 2. Background 105 YANG has two mechanisms for extending a data model with additional 106 nodes; "uses" and "augment". The "uses" statement explicitly 107 incorporates the contents of a "grouping" defined in some other 108 module. The "augment" statement explicitly adds contents to a target 109 node defined in some other module. In both these cases, the source 110 and/or target model explicitly defines the relationship between the 111 models. 113 In some cases these mechanisms are not sufficient. For example, 114 suppose we have a model like ietf-interfaces [RFC7223] that is 115 defined to be implemented in a device. Now suppose we want to model 116 a device that supports multiple logical devices 117 [I-D.rtgyangdt-rtgwg-device-model], where each such logical device 118 has its own instantiation of ietf-interfaces (and other models), but 119 at the same time, we'd like to be able to manage all these logical 120 devices from the main device. We would like something like this: 122 +--rw interfaces 123 | +--rw interface* [name] 124 | ... 125 +--rw logical-device* [name] 126 +--rw name string 127 | ... 128 +--rw interfaces 129 +--rw interface* [name] 130 ... 132 With the "uses" approach, ietf-interfaces would have to define a 133 grouping with all its nodes, and the new model for logical devices 134 would have to use this grouping. This is a not a scalable solution, 135 since every time there is a new model defined, we would have to 136 update our model for logical devices to use a grouping from the new 137 model. Another problem is that this approach cannot handle vendor- 138 specific modules. 140 With the "augment" approach, ietf-interfaces would have to augment 141 the logical-device list with all its nodes, and at the same time 142 define all its nodes on the top-level. This approach is also not 143 scalable, since there may be other models to which we would like to 144 add the interface list. 146 3. Structural Mount 148 The structural mount mechanism defined in this document takes a 149 different approach to the extensibility problem described in the 150 previous section. It decouples the definition of the relation 151 between the source and target models from the definitions of the 152 models themselves. 154 This is accomplished with a YANG extension statement that is used to 155 specify a mount point in a data model. The purpose of a mount point 156 is to define a place in the node hierarchy where other YANG data 157 models may be attached, without any special notation in the other 158 YANG data models. 160 For each mount point supported by a server, the server populates an 161 operational state node hierarchy with information about which models 162 it has mounted. This node hierarchy can be read by a client in order 163 to learn what is implemented on a server. 165 Structural mount applies to the schema, and specifically does not 166 assume anything about how the mounted data is implemented. It may be 167 implemented using the same instrumentation as the rest of the system, 168 or it may be implemented by querying some other system. Future 169 specifications may define mechanisms to control or monitor the 170 implementation of specific mount points. 172 This document allows mounting of complete data models only. Other 173 specifications may extend this model by defining additional 174 mechanisms, for example mounting of sub-hierarchies of a module. 176 3.1. Augment and Validation in Mounted Data 178 All paths (in leafrefs, instance-identifiers, XPath expressions, and 179 target nodes of augments) in the data models mounted at a mount point 180 are interpreted with the mount point as the root node, and the 181 mounted data nodes as its children. This means that data within a 182 mounted subtree can never refer to data outside of this subtree. 184 3.2. Top-level RPCs 186 If any mounted data model defines RPCs, these RPCs can be invoked by 187 clients by treating them as actions defined where the mount point is 188 specified. 190 3.3. Top-level Notifications 192 If the server emits a notification defined at the top-level in any 193 mounted data model, it is treated as if the notification was attached 194 to the data node where the mount point is specified. 196 4. Data Model 198 This document defines the YANG 1.1 module 199 [I-D.ietf-netmod-rfc6020bis] "ietf-yang-structural-mount", which has 200 the following structure: 202 module: ietf-yang-structural-mount 203 +--ro mount-points 204 +--ro mount-point* [module name] 205 +--ro module yang:yang-identifier 206 +--ro name yang:yang-identifier 207 +--ro (data-model) 208 +--:(inline-yang-library) 209 | +--ro inline-yang-library? empty 210 +--:(modules) 211 +--ro modules 212 +--ro module* [name revision] 213 +--ro name yang:yang-identifier 214 +--ro revision union 215 +--ro schema? inet:uri 216 +--ro namespace inet:uri 217 +--ro feature* yang:yang-identifier 218 +--ro deviation* [name revision] 219 | +--ro name yang:yang-identifier 220 | +--ro revision union 221 +--ro conformance-type enumeration 222 +--ro submodules 223 +--ro submodule* [name revision] 224 +--ro name yang:yang-identifier 225 +--ro revision union 226 +--ro schema? inet:uri 228 5. Structural Mount YANG Module 230 file "ietf-yang-structural-mount@2016-02-26.yang" 232 module ietf-yang-structural-mount { 233 yang-version 1.1; 234 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-structural-mount"; 235 prefix yangmnt; 237 import ietf-yang-types { 238 prefix yang; 239 } 240 import ietf-yang-library { 241 prefix yanglib; 242 } 244 organization 245 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 247 contact 248 "WG Web: 249 WG List: 251 WG Chair: Thomas Nadeau 252 254 WG Chair: Juergen Schoenwaelder 255 257 WG Chair: Kent Watsen 258 260 Editor: Martin Bjorklund 261 "; 263 // RFC Ed.: replace XXXX with actual RFC number and remove this 264 // note. 265 description 266 "This module defines a YANG extension statement that can be used 267 to incorporate data models defined in other YANG modules in a 268 module. It also defines a operational state data so that 269 clients can learn which data models a server implements for the 270 mount points. 272 Copyright (c) 2016 IETF Trust and the persons identified as 273 authors of the code. All rights reserved. 275 Redistribution and use in source and binary forms, with or 276 without modification, is permitted pursuant to, and subject to 277 the license terms contained in, the Simplified BSD License set 278 forth in Section 4.c of the IETF Trust's Legal Provisions 279 Relating to IETF Documents 280 (http://trustee.ietf.org/license-info). 282 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 283 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 284 'OPTIONAL' in the module text are to be interpreted as described 285 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 287 This version of this YANG module is part of RFC XXXX 288 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 289 full legal notices."; 291 // RFC Ed.: update the date below with the date of RFC publication 292 // and remove this note. 293 revision 2016-02-26 { 294 description 295 "Initial revision."; 296 reference 297 "RFC XXXX: YANG Structural Mount"; 298 } 300 /* 301 * Extension statements 302 */ 304 extension mount-point { 305 argument name; 306 description 307 "The argument 'name' is a yang-identifier. The name of 308 the mount point MUST be unique within the module where it 309 is defined. 311 The 'mount-point' statement can be present in 'container' and 312 'list'. 314 If a mount point is defined in a grouping, its name is bound 315 to the module where the grouping is used. Note that this 316 implies that such a grouping can be used at most once in a 317 module. 319 A mount point defines a place in the node hierarchy where 320 other data models may be attached. A server that implements 321 a module with a mount point, populates the 322 /mount-points/mount-point list with detailed information on 323 which data models are mounted at each mount point. 325 The 'mount-yang-library' extension may be used as a 326 substatement to 'mount-point'."; 327 } 329 extension mount-yang-library { 330 description 331 "The presence of this statement as a substatement to 332 'mount-point' indicates that the data model defined in the 333 module 'ietf-yang-library' is mounted. When this statement is 334 present, a client can discover the mounted YANG modules by 335 reading from the mounted 'ietf-yang-library' data. 337 This statement is useful if the mount point is defined in a 338 list and different list entries may mount a different 339 set of modules."; 340 } 342 /* 343 * Operational state data nodes 344 */ 346 container mount-points { 347 config false; 348 description 349 "Contains information about which mount points are implemented 350 in the server, and their data models."; 352 list mount-point { 353 key "module name"; 354 description 355 "Contains information about which data models are implemented 356 for the mountpoint 'name' defined in 'module'."; 358 leaf module { 359 type yang:yang-identifier; 360 description 361 "The name of the module where the mount point is defined."; 362 } 363 leaf name { 364 type yang:yang-identifier; 365 description 366 "The name of the mount point."; 367 } 368 choice data-model { 369 mandatory true; 370 description 371 "Indicates which data models the server implements 372 for this mount point. 374 It is expected that this choice may be augmented with other 375 data model discovery mechansisms."; 377 leaf inline-yang-library { 378 type empty; 379 description 380 "This leaf indicates that the server has mounted 381 'ietf-yang-library' at the mount point, and that the 382 instantiation of 'ietf-yang-library' contains the 383 information about which modules are mounted. 385 This is useful if the mount point is defined in a 386 list and different list entries may mount a different 387 set of modules."; 388 } 390 container modules { 391 description 392 "The 'module' list contains the set of modules that are 393 mounted at the mount point."; 395 uses yanglib:module-list; 396 } 397 } 398 } 399 } 400 } 402 404 6. IANA Considerations 406 This document registers a URI in the IETF XML registry [RFC3688]. 407 Following the format in RFC 3688, the following registration is 408 requested to be made. 410 URI: urn:ietf:params:xml:ns:yang:ietf-yang-structural-mount 412 Registrant Contact: The IESG. 414 XML: N/A, the requested URI is an XML namespace. 416 This document registers a YANG module in the YANG Module Names 417 registry [RFC6020]. 419 name: ietf-yang-structural-mount 420 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-structural-mount 421 prefix: yangmnt 422 reference: RFC XXXX 424 7. Security Considerations 426 TBD 428 8. Contributors 430 The idea of having some way to combine schemas from different YANG 431 modules into one has been proposed independently by several groups of 432 people: Alexander Clemm, Jan Medved, and Eric Voit 433 ([I-D.clemm-netmod-mount]); Ladislav Lhotka 434 ([I-D.lhotka-netmod-ysdl]); and Lou Berger and Christian Hopps. 436 9. References 438 9.1. Normative References 440 [I-D.ietf-netmod-rfc6020bis] 441 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 442 draft-ietf-netmod-rfc6020bis-11 (work in progress), 443 February 2016. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 451 DOI 10.17487/RFC3688, January 2004, 452 . 454 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 455 the Network Configuration Protocol (NETCONF)", RFC 6020, 456 DOI 10.17487/RFC6020, October 2010, 457 . 459 9.2. Informative References 461 [I-D.clemm-netmod-mount] 462 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined 463 Information from Remote Datastores", draft-clemm-netmod- 464 mount-03 (work in progress), April 2015. 466 [I-D.lhotka-netmod-ysdl] 467 Lhotka, L., "YANG Schema Dispatching Language", draft- 468 lhotka-netmod-ysdl-00 (work in progress), November 2015. 470 [I-D.rtgyangdt-rtgwg-device-model] 471 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 472 "Network Device YANG Organizational Models", draft- 473 rtgyangdt-rtgwg-device-model-03 (work in progress), 474 February 2016. 476 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 477 and A. Bierman, Ed., "Network Configuration Protocol 478 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 479 . 481 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 482 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 483 . 485 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 486 RFC 7277, DOI 10.17487/RFC7277, June 2014, 487 . 489 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 490 System Management", RFC 7317, DOI 10.17487/RFC7317, August 491 2014, . 493 Appendix A. Example: Logical Devices 495 Logical devices within a device typically use the same set of data 496 models in each instance. This can be modelled with a mount point: 498 module example-logical-devices { 499 namespace "urn:example:logical-devices"; 500 prefix exld; 502 import ietf-yang-structural-mount { 503 prefix yangmnt; 504 } 506 container logical-devices { 507 list logical-device { 508 key name; 509 leaf name { 510 type string; 511 } 513 yangmnt:mount-point logical-device; 514 } 515 } 516 } 518 A server with two logical devices that both implement 519 "ietf-interfaces" [RFC7223], "ietf-ip" [RFC7277], and "ietf-system" 520 [RFC7317] YANG modules might populate the "mount-points" container 521 with: 523 525 526 example-logical-devices 527 logical-device 528 529 530 ietf-interface 531 2014-05-08 532 533 urn:ietf:params:xml:ns:yang:ietf-interfaces 534 535 implement 536 537 538 ietf-ip 539 2014-06-16 540 541 urn:ietf:params:xml:ns:yang:ietf-ip 542 543 implement 544 545 546 ietf-system 547 2014-08-06 548 549 urn:ietf:params:xml:ns:yang:ietf-system 550 551 implement 552 553 554 ietf-yang-types 555 2013-07-15 556 557 urn:ietf:params:xml:ns:yang:ietf-yang-types 558 559 import 560 561 562 563 565 and the "logical-devices" container might have: 567 568 569 vrtrA 570 572 573 eth0 574 575 true 576 ... 577 578 ... 579 580 581 582 ... 583 584 585 586 vrtrB 587 589 590 eth0 591 592 true 593 ... 594 595 ... 596 597 598 599 ... 600 601 602 604 Appendix B. Example: Network Manager 606 This example shows how a Network Manager application can use 607 structural mount to define a data model with all its managed devices. 608 Structural mount is used to mount the data models each device 609 supports, and these data models can be discovered by a client via the 610 "ietf-yang-library" module that is mounted for each device. 612 module example-network-manager { 613 namespace "urn:example:network-manager"; 614 prefix exnm; 616 import ietf-inet-types { 617 prefix inet; 618 } 619 import ietf-yang-structural-mount { 620 prefix yangmnt; 621 } 623 container managed-devices { 624 description 625 "The managed devices and device communication settings."; 627 list device { 628 key name; 629 leaf name { 630 type string; 631 } 632 choice transport { 633 mandatory true; 634 container netconf { 635 leaf address { 636 type inet:ip-address; 637 mandatory true; 638 } 639 container authentication { 640 // ... 641 } 642 } 643 container restconf { 644 leaf address { 645 type inet:ip-address; 646 mandatory true; 647 } 648 // ... 649 } 650 } 652 container root { 653 yangmnt:mount-point managed-device { 654 yangmnt:mount-yang-library; 655 } 656 } 657 } 658 } 659 } 660 The "devices" container might have: 662 663 664 rtrA 665 666 667
192.0.2.2
668 669 ... 670 671 ... 672 673 674 676 677 ietf-system 678 ... 679 680 681 682 ... 683 684 685 686 687 688 rtrB 689 690 691
192.0.2.3
692 693 ... 694 695 ... 696 697 698 700 701 ietf-interfaces 702 ... 703 704 705 707 ... 709 710 711 712 713 715 B.1. Invoking an RPC 717 A client that wants to invoke the "restart" operation [RFC7317] on 718 the managed device "rtrA" over NETCONF [RFC6241] can send: 720 722 723 724 725 rtrA 726 727 728 729 730 731 732 734 Appendix C. Open Issues 736 o Is there a use case for specifying modules that are required to be 737 mounted under a mount point? 739 o Do we really need the case where ietf-yang-library is not mounted? 740 The solution would be simpler if we always use ietf-yang-library 741 at every mount point. See Appendix D.1. 743 o Support non-named mount points? (ysdl case) See Appendix D.2. 745 Appendix D. Alternative solutions 747 This section discusses some alternative solution ideas. 749 D.1. Static Mount Points with YANG Library Only 751 This solution supports named mount points, and always use ietf-yang- 752 library. 754 There would be just one single extension statement, and no additional 755 operational state data: 757 extension mount-point { 758 argument name; 759 } 761 Data models need to be prepared with this extension: 763 container logical-devices { 764 list logical-device { 765 key name; 766 ... 767 yangmnt:mount-point logical-device; 768 } 769 } 771 The tree on the server from Appendix A would look like this: 773 "example-logical-devices:logical-devices": { 774 "logical-device": [ 775 { 776 "name": "vrtrA", 777 "ietf-yang-library:modules-state": { 778 "module-set-id": "ef50fe1", 779 "module": [ 780 { 781 "name": "ietf-interfaces", 782 ... 783 }, 784 { 785 "name": "ietf-system", 786 ... 787 } 788 ] 789 }, 790 "ietf-interfaces:interfaces": { 791 ... 792 }, 793 "ietf-system:system": { 794 ... 795 } 796 }, 797 { 798 "name": "vrtrB", 799 "ietf-yang-library:modules-state": { 800 ... 801 } 802 } 803 ] 804 } 806 D.2. Dynamic Mount Points with YANG Library Only 808 This solution supports only non-named mount points, and always use 809 ietf-yang-library. 811 There would be no extension statement. Instead, the server would 812 populate a list of dynamic mount points. Each such mount point MUST 813 mount ietf-yang-library. 815 container mount-points { 816 config false; 817 list mount-point { 818 key path; 819 leaf path { 820 type schema-node-path; 821 } 822 } 823 } 825 The tree on the server from Appendix A would look like this: 827 "ietf-yang-structural-mount:mount-points": { 828 "mount-point": [ 829 { "path": "/exld:logical-devices/exld:logical-device" } 830 ] 831 }, 832 "example-logical-devices:logical-devices": { 833 "logical-device": [ 834 { 835 "name": "vrtrA", 836 "ietf-yang-library:modules-state": { 837 "module-set-id": "ef50fe1", 838 "module": [ 839 { 840 "name": "ietf-interfaces", 841 ... 842 }, 843 { 844 "name": "ietf-system", 845 ... 846 } 847 ] 848 }, 849 "ietf-interfaces:interfaces": { 850 ... 851 }, 852 "ietf-system:system": { 853 ... 854 } 855 }, 856 { 857 "name": "vrtrB", 858 "ietf-yang-library:modules-state": { 859 ... 860 } 861 } 862 ] 863 } 865 A client needs to read the "/mount-points/mount-point" list in order 866 to learn where the server has mounted data models. Next, it needs to 867 read the "modules-state" subtree for each instantiated mount point in 868 order to learn which modules are mounted at that instance. 870 Author's Address 871 Martin Bjorklund 872 Tail-f Systems 874 Email: mbj@tail-f.com