idnits 2.17.1 draft-ietf-netmod-schema-mount-01.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 226 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 (April 6, 2016) is 2941 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-04 == 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 L. Lhotka 5 Expires: October 8, 2016 CZ.NIC 6 April 6, 2016 8 YANG Schema Mount 9 draft-ietf-netmod-schema-mount-01 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 October 8, 2016. 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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . 13 68 B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 16 69 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 16 70 Appendix D. Alternative solutions . . . . . . . . . . . . . . . 16 71 D.1. Static Mount Points with YANG Library Only . . . . . . . 16 72 D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 submodules 224 +--ro submodule* [name revision] 225 +--ro name yang:yang-identifier 226 +--ro revision union 227 +--ro schema? inet:uri 229 5. Schema Mount YANG Module 231 file "ietf-yang-schema-mount@2016-04-05.yang" 233 module ietf-yang-schema-mount { 234 yang-version 1.1; 235 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"; 236 prefix yangmnt; 238 import ietf-yang-types { 239 prefix yang; 240 } 241 import ietf-yang-library { 242 prefix yanglib; 243 } 245 organization 246 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 248 contact 249 "WG Web: 250 WG List: 252 WG Chair: Thomas Nadeau 253 255 WG Chair: Juergen Schoenwaelder 256 258 WG Chair: Kent Watsen 259 261 Editor: Martin Bjorklund 262 "; 264 // RFC Ed.: replace XXXX with actual RFC number and remove this 265 // note. 266 description 267 "This module defines a YANG extension statement that can be used 268 to incorporate data models defined in other YANG modules in a 269 module. It also defines a operational state data so that 270 clients can learn which data models a server implements for the 271 mount points. 273 Copyright (c) 2016 IETF Trust and the persons identified as 274 authors of the code. All rights reserved. 276 Redistribution and use in source and binary forms, with or 277 without modification, is permitted pursuant to, and subject to 278 the license terms contained in, the Simplified BSD License set 279 forth in Section 4.c of the IETF Trust's Legal Provisions 280 Relating to IETF Documents 281 (http://trustee.ietf.org/license-info). 283 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 284 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 285 'OPTIONAL' in the module text are to be interpreted as described 286 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 288 This version of this YANG module is part of RFC XXXX 289 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 290 full legal notices."; 292 // RFC Ed.: update the date below with the date of RFC publication 293 // and remove this note. 294 revision 2016-04-05 { 295 description 296 "Initial revision."; 297 reference 298 "RFC XXXX: YANG Schema Mount"; 299 } 301 /* 302 * Extension statements 303 */ 305 extension mount-point { 306 argument name; 307 description 308 "The argument 'name' is a yang-identifier. The name of 309 the mount point MUST be unique within the module where it 310 is defined. 312 The 'mount-point' statement can be present in 'container' and 313 'list'. 315 If a mount point is defined in a grouping, its name is bound 316 to the module where the grouping is used. Note that this 317 implies that such a grouping can be used at most once in a 318 module. 320 A mount point defines a place in the node hierarchy where 321 other data models may be attached. A server that implements 322 a module with a mount point, populates the 323 /mount-points/mount-point list with detailed information on 324 which data models are mounted at each mount point. 326 The 'mount-yang-library' extension may be used as a 327 substatement to 'mount-point'."; 328 } 330 extension mount-yang-library { 331 description 332 "The presence of this statement as a substatement to 333 'mount-point' indicates that the data model defined in the 334 module 'ietf-yang-library' is mounted. When this statement is 335 present, a client can discover the mounted YANG modules by 336 reading from the mounted 'ietf-yang-library' data. 338 This statement is useful if the mount point is defined in a 339 list and different list entries may mount a different 340 set of modules."; 341 } 343 /* 344 * Operational state data nodes 345 */ 347 container mount-points { 348 config false; 349 description 350 "Contains information about which mount points are implemented 351 in the server, and their data models."; 353 list mount-point { 354 key "module name"; 355 description 356 "Contains information about which data models are implemented 357 for the mountpoint 'name' defined in 'module'."; 359 leaf module { 360 type yang:yang-identifier; 361 description 362 "The name of the module where the mount point is defined."; 363 } 364 leaf name { 365 type yang:yang-identifier; 366 description 367 "The name of the mount point."; 368 } 369 choice data-model { 370 mandatory true; 371 description 372 "Indicates which data models the server implements 373 for this mount point. 375 It is expected that this choice may be augmented with other 376 data model discovery mechansisms."; 378 leaf inline-yang-library { 379 type empty; 380 description 381 "This leaf indicates that the server has mounted 382 'ietf-yang-library' at the mount point, and that the 383 instantiation of 'ietf-yang-library' contains the 384 information about which modules are mounted. 386 This is useful if the mount point is defined in a 387 list and different list entries may mount a different 388 set of modules."; 389 } 391 container modules { 392 description 393 "The 'module' list contains the set of modules that are 394 mounted at the mount point."; 396 uses yanglib:module-list; 397 } 398 } 399 } 400 } 401 } 403 405 6. IANA Considerations 407 This document registers a URI in the IETF XML registry [RFC3688]. 408 Following the format in RFC 3688, the following registration is 409 requested to be made. 411 URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount 413 Registrant Contact: The IESG. 415 XML: N/A, the requested URI is an XML namespace. 417 This document registers a YANG module in the YANG Module Names 418 registry [RFC6020]. 420 name: ietf-yang-schema-mount 421 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount 422 prefix: yangmnt 423 reference: RFC XXXX 425 7. Security Considerations 427 TBD 429 8. Contributors 431 The idea of having some way to combine schemas from different YANG 432 modules into one has been proposed independently by several groups of 433 people: Alexander Clemm, Jan Medved, and Eric Voit 434 ([I-D.clemm-netmod-mount]); Ladislav Lhotka 435 ([I-D.lhotka-netmod-ysdl]); and Lou Berger and Christian Hopps. 437 9. References 439 9.1. Normative References 441 [I-D.ietf-netmod-rfc6020bis] 442 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 443 draft-ietf-netmod-rfc6020bis-11 (work in progress), 444 February 2016. 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 452 DOI 10.17487/RFC3688, January 2004, 453 . 455 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 456 the Network Configuration Protocol (NETCONF)", RFC 6020, 457 DOI 10.17487/RFC6020, October 2010, 458 . 460 9.2. Informative References 462 [I-D.clemm-netmod-mount] 463 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined 464 Information from Remote Datastores", draft-clemm-netmod- 465 mount-04 (work in progress), March 2016. 467 [I-D.lhotka-netmod-ysdl] 468 Lhotka, L., "YANG Schema Dispatching Language", draft- 469 lhotka-netmod-ysdl-00 (work in progress), November 2015. 471 [I-D.rtgyangdt-rtgwg-device-model] 472 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 473 "Network Device YANG Organizational Models", draft- 474 rtgyangdt-rtgwg-device-model-03 (work in progress), 475 February 2016. 477 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 478 and A. Bierman, Ed., "Network Configuration Protocol 479 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 480 . 482 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 483 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 484 . 486 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 487 RFC 7277, DOI 10.17487/RFC7277, June 2014, 488 . 490 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 491 System Management", RFC 7317, DOI 10.17487/RFC7317, August 492 2014, . 494 Appendix A. Example: Logical Devices 496 Logical devices within a device typically use the same set of data 497 models in each instance. This can be modelled with a mount point: 499 module example-logical-devices { 500 namespace "urn:example:logical-devices"; 501 prefix exld; 503 import ietf-yang-schema-mount { 504 prefix yangmnt; 505 } 507 container logical-devices { 508 list logical-device { 509 key name; 510 leaf name { 511 type string; 512 } 514 yangmnt:mount-point logical-device; 515 } 516 } 517 } 519 A server with two logical devices that both implement 520 "ietf-interfaces" [RFC7223], "ietf-ip" [RFC7277], and "ietf-system" 521 [RFC7317] YANG modules might populate the "mount-points" container 522 with: 524 526 527 example-logical-devices 528 logical-device 529 530 531 ietf-interface 532 2014-05-08 533 534 urn:ietf:params:xml:ns:yang:ietf-interfaces 535 536 implement 537 538 539 ietf-ip 540 2014-06-16 541 542 urn:ietf:params:xml:ns:yang:ietf-ip 543 544 implement 545 546 547 ietf-system 548 2014-08-06 549 550 urn:ietf:params:xml:ns:yang:ietf-system 551 552 implement 553 554 555 ietf-yang-types 556 2013-07-15 557 558 urn:ietf:params:xml:ns:yang:ietf-yang-types 559 560 import 561 562 563 564 566 and the "logical-devices" container might have: 568 569 570 vrtrA 571 573 574 eth0 575 576 true 577 ... 578 579 ... 580 581 582 583 ... 584 585 586 587 vrtrB 588 590 591 eth0 592 593 true 594 ... 595 596 ... 597 598 599 600 ... 601 602 603 605 Appendix B. Example: Network Manager 607 This example shows how a Network Manager application can use schema 608 mount to define a data model with all its managed devices. Schema 609 mount is used to mount the data models each device supports, and 610 these data models can be discovered by a client via the 611 "ietf-yang-library" module that is mounted for each device. 613 module example-network-manager { 614 namespace "urn:example:network-manager"; 615 prefix exnm; 616 import ietf-inet-types { 617 prefix inet; 618 } 619 import ietf-yang-schema-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 container transport { 633 choice protocol { 634 mandatory true; 635 container netconf { 636 leaf address { 637 type inet:ip-address; 638 mandatory true; 639 } 640 container authentication { 641 // ... 642 } 643 } 644 container restconf { 645 leaf address { 646 type inet:ip-address; 647 mandatory true; 648 } 649 // ... 650 } 651 } 652 } 653 container root { 654 yangmnt:mount-point managed-device { 655 yangmnt:mount-yang-library; 656 } 657 } 658 } 659 } 660 } 662 The "devices" container might have: 664 665 666 rtrA 667 668 669
192.0.2.2
670 671 ... 672 673 ... 674 675 676 677 679 680 ietf-system 681 ... 682 683 684 685 ... 686 687 688 689 690 rtrB 691 692 693
192.0.2.3
694 695 ... 696 697 ... 698 699 700 701 703 704 ietf-interfaces 705 ... 706 707 708 710 ... 711 713 714 715 717 B.1. Invoking an RPC 719 A client that wants to invoke the "restart" operation [RFC7317] on 720 the managed device "rtrA" over NETCONF [RFC6241] can send: 722 724 725 726 727 rtrA 728 729 730 731 732 733 734 736 Appendix C. Open Issues 738 o Is there a use case for specifying modules that are required to be 739 mounted under a mount point? 741 o Do we really need the case where ietf-yang-library is not mounted? 742 The solution would be simpler if we always use ietf-yang-library 743 at every mount point. See Appendix D.1. 745 o Support non-named mount points? (ysdl case) See Appendix D.2. 747 Appendix D. Alternative solutions 749 This section discusses some alternative solution ideas. 751 D.1. Static Mount Points with YANG Library Only 753 This solution supports named mount points, and always use ietf-yang- 754 library. 756 There would be just one single extension statement, and no additional 757 operational state data: 759 extension mount-point { 760 argument name; 761 } 763 Data models need to be prepared with this extension: 765 container logical-devices { 766 list logical-device { 767 key name; 768 ... 769 yangmnt:mount-point logical-device; 770 } 771 } 773 The tree on the server from Appendix A would look like this: 775 "example-logical-devices:logical-devices": { 776 "logical-device": [ 777 { 778 "name": "vrtrA", 779 "ietf-yang-library:modules-state": { 780 "module-set-id": "ef50fe1", 781 "module": [ 782 { 783 "name": "ietf-interfaces", 784 ... 785 }, 786 { 787 "name": "ietf-system", 788 ... 789 } 790 ] 791 }, 792 "ietf-interfaces:interfaces": { 793 ... 794 }, 795 "ietf-system:system": { 796 ... 797 } 798 }, 799 { 800 "name": "vrtrB", 801 "ietf-yang-library:modules-state": { 802 ... 803 } 804 } 805 ] 806 } 808 D.2. Dynamic Mount Points with YANG Library Only 810 This solution supports only non-named mount points, and always use 811 ietf-yang-library. 813 There would be no extension statement. Instead, the server would 814 populate a list of dynamic mount points. Each such mount point MUST 815 mount ietf-yang-library. 817 container mount-points { 818 config false; 819 list mount-point { 820 key path; 821 leaf path { 822 type schema-node-path; 823 } 824 } 825 } 827 The tree on the server from Appendix A would look like this: 829 "ietf-yang-schema-mount:mount-points": { 830 "mount-point": [ 831 { "path": "/exld:logical-devices/exld:logical-device" } 832 ] 833 }, 834 "example-logical-devices:logical-devices": { 835 "logical-device": [ 836 { 837 "name": "vrtrA", 838 "ietf-yang-library:modules-state": { 839 "module-set-id": "ef50fe1", 840 "module": [ 841 { 842 "name": "ietf-interfaces", 843 ... 844 }, 845 { 846 "name": "ietf-system", 847 ... 848 } 849 ] 850 }, 851 "ietf-interfaces:interfaces": { 852 ... 853 }, 854 "ietf-system:system": { 855 ... 856 } 857 }, 858 { 859 "name": "vrtrB", 860 "ietf-yang-library:modules-state": { 861 ... 862 } 863 } 864 ] 865 } 867 A client needs to read the "/mount-points/mount-point" list in order 868 to learn where the server has mounted data models. Next, it needs to 869 read the "modules-state" subtree for each instantiated mount point in 870 order to learn which modules are mounted at that instance. 872 Authors' Addresses 873 Martin Bjorklund 874 Tail-f Systems 876 Email: mbj@tail-f.com 878 Ladislav Lhotka 879 CZ.NIC 881 Email: mbj@lhotka@nic.cz