idnits 2.17.1 draft-ietf-netconf-rfc7895bis-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 : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 273 has weird spacing: '...ce-type enu...' == 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 (October 30, 2017) is 2367 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) == Unused Reference: 'RFC8040' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: 'RFC5277' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'RFC6470' is defined on line 1044, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-05 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bierman 3 Internet-Draft YumaWorks 4 Obsoletes: rfc7895 (if approved) M. Bjorklund 5 Intended status: Standards Track Tail-f Systems 6 Expires: May 3, 2018 K. Watsen 7 Juniper Networks 8 October 30, 2017 10 YANG Library 11 draft-ietf-netconf-rfc7895bis-02 13 Abstract 15 This document describes a YANG library that provides information 16 about all the YANG modules and datastores used by a network 17 management server (e.g., a Network Configuration Protocol (NETCONF) 18 server). Simple caching mechanisms are provided to allow clients to 19 minimize retrieval of this information. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 3, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Motivation for rfc7895bis . . . . . . . . . . . . . . . . 4 59 1.4. Summary of Changes from RFC 7895 . . . . . . . . . . . . 5 60 2. YANG Library . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1. yang-library . . . . . . . . . . . . . . . . . . . . . . 7 62 2.1.1. yang-library/modules/module . . . . . . . . . . . . . 7 63 2.1.2. yang-library/module-sets/module-set . . . . . . . . . 8 64 2.1.3. yang-library/datastores/datastore . . . . . . . . . . 8 65 2.2. YANG Library Module . . . . . . . . . . . . . . . . . . . 9 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 67 3.1. YANG Module Registry . . . . . . . . . . . . . . . . . . 20 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 22 72 6.2. Informative References . . . . . . . . . . . . . . . . . 23 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 75 1. Introduction 77 There is a need for standard mechanisms to provide the operational 78 state of a network management server. This includes, for instance, 79 identifying the YANG modules and datastores that are in use by a 80 server and how they relate to each other. 82 This document defines a YANG module that can be used to provide this 83 informaton, in a way that is compatible with the NMDA 84 [I-D.ietf-netmod-revised-datastores], but that is also backwards 85 compatible with the "YANG Module Library" YANG module defined in 86 [RFC7895]. 88 If a large number of YANG modules are utilized by the server, then 89 the YANG library contents needed can be relatively large. This 90 information changes very infrequently, so it is important that 91 clients be able to cache the YANG library contents and easily 92 identify whether their cache is out of date. 94 YANG library information can be different on every server and can 95 change at runtime or across a server reboot. 97 If the server implements multiple protocols to access the YANG- 98 defined data, each such protocol has its own conceptual instantiation 99 of the YANG library. 101 The following information is needed by a client application (for each 102 YANG module in the library) to fully utilize the YANG data modeling 103 language: 105 o identifier: a unique identifier for the module that includes the 106 module's name, revision, submodules, features, and deviations. 108 o name: The name of the YANG module. 110 o revision: Each YANG module and submodule within the library SHOULD 111 have a revision. This is derived from the most recent revision 112 statement within the module or submodule. 114 o submodule list: The name, and if defined, revision of each 115 submodule used by the module MUST be identified. 117 o feature list: The name of each YANG feature supported by the 118 server, in a given datastore schema, MUST be identified. 120 o deviation list: The name of each YANG module used for deviation 121 statements, in a given datastore schema, MUST be identified. 123 The following information is needed by a client application (for each 124 datastore supported by the server) to fully access all the YANG- 125 modelled data available on the server: 127 o identity: the YANG identity for the datastore. 129 o modules: modules supported by the datastore, including any 130 features and deviations. 132 1.1. Terminology 134 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14, [RFC2119]. 139 The following terms are defined in [RFC6241]: 141 o client 143 o server 144 The following terms are defined in [RFC7950]: 146 o module 148 o submodule 150 The following terms are defined in ^NMDA": 152 o conventional configuration datastore 154 o operational datastore 156 o datastore schema 158 The following terms are used within this document: 160 o YANG library: A collection of metadata describing the server's 161 operational state. 163 1.2. Tree Diagrams 165 A simplified graphical representation of the data model is used in 166 this document. The meaning of the symbols in these diagrams is as 167 follows: 169 o Brackets "[" and "]" enclose list keys. 171 o Abbreviations before data node names: "rw" means configuration 172 data (read-write) and "ro" state data (read-only). 174 o Symbols after data node names: "?" means an optional node, "!" 175 means a presence container, and "*" denotes a list and leaf-list. 177 o Parentheses enclose choice and case nodes, and case nodes are also 178 marked with a colon (":"). 180 o Ellipsis ("...") stands for contents of subtrees that are not 181 shown. 183 1.3. Motivation for rfc7895bis 185 RFC Ed.: delete this section, including this note, at time of 186 publication. 188 All NETCONF servers supporting YANG 1.1 [RFC7950] MUST support YANG 189 Library (see Section 5.6.4 of RFC 7950). Similarly, all RESTCONF 190 servers MUST support YANG Library (see Section 10 of RFC 8040). 192 These requirements are independent of if the server supports NMDA or 193 not. 195 RFC 7895 has a mandatory to implement 'modules-state' tree that a 196 server uses to advertise all the modules it supports. However, this 197 module was designed assuming the all modules would be in all 198 datastores, and with the same number of features and deviations. 199 However, this is not the case with NMDA-compatible servers that may 200 have some modules that only appear in (e.g., ietf- 201 network-topo) or only also appear in a dynamic datastore (e.g., i2rs- 202 ephemeral-rib). It is also possible that a server only implements a 203 module in , as it hasn't yet coded support for returning the 204 module's opstate yet. Presumably, an NMDA-supporting server would 205 return all modules implemented in every datastore, but this would be 206 misleading to existing clients and unhelpful to NMDA-aware clients. 208 In the end, it appears that the 'modules-state' node should be for 209 non-NMDA aware clients. For backwards compatability, an NMDA- 210 supporting server SHOULD populate 'modules-state' in a backwards- 211 compatible manner. The new 'yang-library' node would be ignored by 212 legacy clients, while providing all the data needed for NMDA-aware 213 clients, which would themselves ignore the 'modules-state' tree. 215 The solution presented in this document is further motivated by the 216 following desires: 218 o leverage Section 5.6.4 of RFC 7950 and Section 10 of RFC 8040. 220 o indicate which modules are supported by each datastore 222 o enable the features and deviations to vary by datastore 224 o structure extensible to support schema-mount 226 o provide a top-level container for all server metadata 228 1.4. Summary of Changes from RFC 7895 230 This document updates [RFC7895] in the following ways: 232 o Renames document title from "YANG Module Library" to "YANG 233 Library". 235 o Adds a new top-level "yang-library" container to hold many types 236 of server metadata: modules supported, datastores supported, 237 relationships between datastores and modules, etc. 239 o Adds a set of new groupings as replacements for the deprecated 240 "module-list" grouping. 242 o Adds a "yang-library-update" notification as a replacement for the 243 deprecated "yang-library-change" notification. 245 o Deprecates the "modules-state" tree. 247 o Deprecates the "module-list" grouping. 249 o Deprecates the "yang-library-change" notification. 251 2. YANG Library 253 The "ietf-yang-library" module provides information about the modules 254 and datastores supported by a server. This module is defined using 255 YANG version 1.1, but it supports the description of YANG modules 256 written in any revision of YANG. 258 Following is the YANG Tree Diagram for the "ietf-yang-library" 259 module, excluding the deprecated 'modules-state' tree: 261 module: ietf-yang-library 262 +--ro yang-library 263 +--ro modules 264 | +--ro module* [id] 265 | +--ro id string 266 | +--ro name yang:yang-identifier 267 | +--ro revision? revision-identifier 268 | +--ro schema? inet:uri 269 | +--ro namespace inet:uri 270 | +--ro feature* yang:yang-identifier 271 | +--ro deviation* [module] 272 | | +--ro module -> ../../id 273 | +--ro conformance-type enumeration 274 | +--ro submodule* [name] 275 | +--ro name yang:yang-identifier 276 | +--ro revision? revision-identifier 277 | +--ro schema? inet:uri 278 +--ro module-sets 279 | +--ro module-set* [id] 280 | +--ro id string 281 | +--ro module* -> ../../../modules/module/id 282 +--ro datastores 283 | +--ro datastore* [name] 284 | +--ro name identityref 285 | +--ro module-set 286 | -> ../../../module-sets/module-set/id 287 +--ro checksum string 289 notifications: 290 +---n yang-library-update 292 2.1. yang-library 294 This container holds all of the server's metadata. 296 2.1.1. yang-library/modules/module 298 This list contains one entry for each unique instance of a module in 299 use by the server. Each entry is distinguished by the module's name, 300 revisions, features, and deviations. 302 A server cannot implement different revisions of the same module in 303 different datastores, so there MUST only be a single revision of a 304 given module in the "module" list that has a "conformance-type" leaf 305 of "implement". 307 Although the server is at liberty to choose the unique "id" for each 308 entry in the "module" list, it is suggested to use an "id" that would 309 be meaningful to clients. For example, "ietf-interfaces@2017-08-17" 310 could be used as the "id" for a particular revision of the IETF 311 interfaces YANG module. For a module that holds deviations or 312 features specific to a datastore perhaps an "id" that also contains 313 the datastore name, like "ietf-interfaces-deviations@2017-08-17/ 314 operational" could be used. 316 2.1.2. yang-library/module-sets/module-set 318 A "module-set" represents the datastore schema that is used by one or 319 more datastores. 321 This list contains one entry for each module set in use by the server 322 (e.g., presented by a datastore). 324 All conventional configuration datastores use the same datastore 325 schema, which can normally be modelled using a single module set. 327 A dynamic configuration datastore may use a different datastore 328 schema from the conventional configuration datastores, and hence may 329 require a separate module set definition. 331 The datastore schema for the operational datastore is the superset of 332 the datastore schema of all the configuration datastores, but can 333 have unsupported nodes removed via datastore specific deviations or 334 by omitting one or more modules from the module set associated with 335 the operational datastore. 337 However, where possible, the same module set used for conventional 338 configuration datatstores should also be used for the operational 339 datastore. For example, deviations that are specific to "config 340 false" nodes could still be applied to a common module instance that 341 is also included in the module set used for the conventional 342 datastores. 344 Although the server is at liberty to choose the unique "id" for the 345 "module-set" list entry, it is suggested to choose an "id" that would 346 be meaningful to clients, perhaps including the datastore name if the 347 module set is only relevant to a single datastore. 349 2.1.3. yang-library/datastores/datastore 351 This list contains one entry for each datastore supported by the 352 server, and identifes the datastore schema associated with a 353 datastore via a reference to a module-set. Each supported 354 conventional configuration datastore has a separate entry. 356 2.2. YANG Library Module 358 The "ietf-yang-library" module defines monitoring information for the 359 YANG modules used by a server. 361 The modules "ietf-yang-types" and "ietf-inet-types" from [RFC6991] 362 and the module "ietf-datastores" from 363 [I-D.ietf-netmod-revised-datastores] are used by this module for some 364 type definitions. 366 RFC Ed.: update the date below with the date of RFC publication and 367 remove this note. 369 file "ietf-yang-library@2017-10-30.yang" 371 module ietf-yang-library { 372 yang-version 1.1; 373 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library"; 374 prefix "yanglib"; 376 import ietf-yang-types { 377 prefix yang; 378 reference "RFC 6991: Common YANG Data Types."; 379 } 380 import ietf-inet-types { 381 prefix inet; 382 reference "RFC 6991: Common YANG Data Types."; 383 } 384 import ietf-datastores { 385 prefix ds; 386 reference "I-D.ietf-revised-datastores: 387 Network Management Datastore Architecture."; 388 } 390 organization 391 "IETF NETCONF (Network Configuration) Working Group"; 393 contact 394 "WG Web: 395 WG List: 397 Author: Andy Bierman 398 400 Author: Martin Bjorklund 401 403 Author: Kent Watsen 404 "; 406 description 407 "This module contains information about the YANG server 408 instance, including the modules and datastores the 409 server supports, and which modules are present in 410 which datastores. 412 Copyright (c) 2017 IETF Trust and the persons identified as 413 authors of the code. All rights reserved. 415 Redistribution and use in source and binary forms, with or 416 without modification, is permitted pursuant to, and subject 417 to the license terms contained in, the Simplified BSD License 418 set forth in Section 4.c of the IETF Trust's Legal Provisions 419 Relating to IETF Documents 420 (http://trustee.ietf.org/license-info). 422 This version of this YANG module is part of RFC XXXX; see 423 the RFC itself for full legal notices."; 425 // RFC Ed.: update the date below with the date of RFC publication 426 // and remove this note. 427 // RFC Ed.: replace XXXX with actual RFC number and remove this 428 // note. 429 revision 2017-10-30 { 430 description 431 "Updated revision."; 432 reference 433 "RFC XXXX: YANG Library."; 434 } 435 revision 2016-04-09 { 436 description 437 "Initial revision."; 438 reference 439 "RFC 7895: YANG Module Library."; 440 } 442 /* 443 * Typedefs 444 */ 446 typedef revision-identifier { 447 type string { 448 pattern '\d{4}-\d{2}-\d{2}'; 449 } 450 description 451 "Represents a specific date in YYYY-MM-DD format."; 453 } 455 /* 456 * Groupings 457 */ 459 grouping module-identification-leafs { 460 description 461 "Parameters for identifying YANG modules and submodules."; 463 leaf name { 464 type yang:yang-identifier; 465 mandatory true; 466 description 467 "The YANG module or submodule name."; 468 } 469 leaf revision { 470 type revision-identifier; 471 description 472 "The YANG module or submodule revision date. If no revision 473 statement is present in the YANG module or submodule, this 474 leaf is not instantiated."; 475 } 476 } 478 grouping schema-leaf { 479 description 480 "Common schema leaf parameter for modules and submodules."; 482 leaf schema { 483 type inet:uri; 484 description 485 "Contains a URL that represents the YANG schema 486 resource for this module or submodule. 488 This leaf will only be present if there is a URL 489 available for retrieval of the schema for this entry."; 490 } 491 } 493 grouping implementation-parameters { 494 description 495 "Parameters for describing the implementation of a module."; 497 leaf-list feature { 498 type yang:yang-identifier; 499 description 500 "List of YANG feature names from this module that are 501 supported by the server, regardless whether they are defined 502 in the module or any included submodule."; 503 } 504 list deviation { 505 key "module"; 506 description 507 "List of YANG deviation modules used by 508 this server to modify the conformance of the module 509 associated with this entry. Note that the same module can 510 be used for deviations for multiple modules, so the same 511 entry MAY appear within multiple 'module' entries."; 513 leaf module { 514 type leafref { 515 path "../../id"; 516 } 517 description 518 "The module that deviates the module associated with this 519 entry. The deviation modules MUST be part of the same 520 module-sets as the module it deviates."; 521 } 522 } 523 leaf conformance-type { 524 type enumeration { 525 enum implement { 526 description 527 "Indicates that the server implements one or more 528 protocol-accessible objects defined in the YANG module 529 identified in this entry. This includes deviation 530 statements defined in the module. 532 For YANG version 1.1 modules, there is at most one 533 module entry with conformance type 'implement' for a 534 particular module name, since YANG 1.1 requires that at 535 most one revision of a module is implemented. 537 For YANG version 1 modules, there SHOULD NOT be more 538 than one module entry for a particular module name."; 539 } 540 enum import { 541 description 542 "Indicates that the server imports reusable definitions 543 from the specified revision of the module, but does not 544 implement any protocol accessible objects from this 545 revision. 547 Multiple module entries for the same module name MAY 548 exist. This can occur if multiple modules import the 549 same module, but specify different revision-dates in the 550 import statements."; 551 } 552 } 553 mandatory true; 554 description 555 "Indicates the type of conformance the server is claiming 556 for the YANG module identified by this entry."; 557 } 558 } 560 grouping yang-library-parameters { 561 description 562 "The YANG library data structure is represented as a grouping 563 so it can be reused in configuration or another monitoring 564 data structure."; 566 container modules { 567 description 568 "A container holding a list of modules. Modules being 569 listed here does not necessarily mean that they are 570 supported by any particular datastore. 572 If a module has the value 'implemented' for it's 573 'conformance-type' leaf in the 'module' list, it means that 574 the server supports the rpcs and notifications defined in 575 the module (adjusted for features and deviations), even if 576 the module is not supported in any particular datastore."; 578 list module { 579 key "id"; 580 description 581 "Each entry represents a revision of a module currently 582 supported by the server with a particular set of supported 583 features and deviations"; 585 leaf id { 586 type string; 587 description 588 "A unique identifier, independent of any other part 589 of this module instance."; 590 } 592 uses module-identification-leafs; 593 uses schema-leaf; 595 leaf namespace { 596 type inet:uri; 597 mandatory true; 598 description 599 "The XML namespace identifier for this module."; 600 } 602 uses implementation-parameters; 604 list submodule { 605 key "name"; 606 description 607 "Each entry represents one submodule within the 608 parent module."; 609 uses module-identification-leafs; 610 uses schema-leaf; 611 } 612 } 613 } 615 container module-sets { 616 description 617 "A container for the list of module-sets supported by the 618 server"; 620 list module-set { 621 key "id"; 622 description 623 "An arbitrary module-set definition provided by the 624 server. 626 A module-set represents a datastore schema associated with 627 one or more datastores. 629 Module-sets being listed here does not necessarily mean 630 that they are used by any particular datastore. 632 In the case of a configuration datastore, only the config 633 true subset of a datastore schema is applicable to the 634 datastore, any config false schema nodes and any action 635 statements are ignored."; 637 leaf id { 638 type string; 639 description 640 "A system-generated value that uniquely represents the 641 referenced set of modules. Any change to the number 642 of modules referenced, or to the modules themselves, 643 generates a different value."; 644 } 645 leaf-list module { 646 type leafref { 647 path "../../../modules/module/id"; 648 } 649 description 650 "A module-instance supported by the server, including its 651 features and deviations."; 652 } 653 } 654 } 656 container datastores { 657 description 658 "A container for the list of datastores supported by the 659 server."; 661 list datastore { 662 key "name"; 663 description 664 "A datastore supported by this server. 666 Each datastore indicates which module-set it supports. 668 The server MUST instantiate one entry in this list per 669 specific datastore it supports. 671 Each datstore entry with the same datastore schema SHOULD 672 reference the same module-set."; 674 leaf name { 675 type identityref { 676 base ds:datastore; 677 } 678 description 679 "The identity of the datastore."; 680 } 681 leaf module-set { 682 type leafref { 683 path "../../../module-sets/module-set/id"; 684 } 685 mandatory true; 686 description 687 "A reference to the module-set supported by this 688 datastore"; 689 } 690 } 691 } 692 } 693 /* 694 * Top-level container 695 */ 697 container yang-library { 698 config false; 699 description 700 "Container providing all the YANG meta information the 701 server possesses."; 703 uses yang-library-parameters; 705 leaf checksum { 706 type string; 707 config false; 708 mandatory true; 709 description 710 "A server-generated checksum of the contents of the 711 'yang-library' tree. The server MUST change the value of 712 this leaf if the information represented by the 713 'yang-library' tree, except yang-library/checksum, has 714 changed."; 715 } 716 } 718 /* 719 * Notifications 720 */ 722 notification yang-library-update { 723 description 724 "Generated when any YANG library information on the 725 server has changed."; 726 } 728 /* 729 * Legacy groupings 730 */ 732 grouping module-list { 733 status deprecated; 734 description 735 "The module data structure is represented as a grouping 736 so it can be reused in configuration or another monitoring 737 data structure."; 739 grouping common-leafs { 740 status deprecated; 741 description 742 "Common parameters for YANG modules and submodules."; 744 leaf name { 745 type yang:yang-identifier; 746 status deprecated; 747 description 748 "The YANG module or submodule name."; 749 } 750 leaf revision { 751 type union { 752 type revision-identifier; 753 type string { 754 length 0; 755 } 756 } 757 status deprecated; 758 description 759 "The YANG module or submodule revision date. 760 A zero-length string is used if no revision statement 761 is present in the YANG module or submodule."; 762 } 763 } 765 list module { 766 key "name revision"; 767 status deprecated; 768 description 769 "Each entry represents one revision of one module 770 currently supported by the server."; 772 uses common-leafs { 773 status deprecated; 774 } 775 uses schema-leaf { 776 status deprecated; 777 } 779 leaf namespace { 780 type inet:uri; 781 mandatory true; 782 status deprecated; 783 description 784 "The XML namespace identifier for this module."; 785 } 786 leaf-list feature { 787 type yang:yang-identifier; 788 status deprecated; 789 description 790 "List of YANG feature names from this module that are 791 supported by the server, regardless whether they are 792 defined in the module or any included submodule."; 793 } 794 list deviation { 795 key "name revision"; 796 status deprecated; 797 description 798 "List of YANG deviation module names and revisions 799 used by this server to modify the conformance of 800 the module associated with this entry. Note that 801 the same module can be used for deviations for 802 multiple modules, so the same entry MAY appear 803 within multiple 'module' entries. 805 The deviation module MUST be present in the 'module' 806 list, with the same name and revision values. 807 The 'conformance-type' value will be 'implement' for 808 the deviation module."; 809 uses common-leafs { 810 status deprecated; 811 } 812 } 813 leaf conformance-type { 814 type enumeration { 815 enum implement { 816 description 817 "Indicates that the server implements one or more 818 protocol-accessible objects defined in the YANG module 819 identified in this entry. This includes deviation 820 statements defined in the module. 822 For YANG version 1.1 modules, there is at most one 823 module entry with conformance type 'implement' for a 824 particular module name, since YANG 1.1 requires that 825 at most one revision of a module is implemented. 827 For YANG version 1 modules, there SHOULD NOT be more 828 than one module entry for a particular module name."; 829 } 830 enum import { 831 description 832 "Indicates that the server imports reusable definitions 833 from the specified revision of the module, but does 834 not implement any protocol accessible objects from 835 this revision. 837 Multiple module entries for the same module name MAY 838 exist. This can occur if multiple modules import the 839 same module, but specify different revision-dates in 840 the import statements."; 841 } 842 } 843 mandatory true; 844 status deprecated; 845 description 846 "Indicates the type of conformance the server is claiming 847 for the YANG module identified by this entry."; 848 } 849 list submodule { 850 key "name revision"; 851 status deprecated; 852 description 853 "Each entry represents one submodule within the 854 parent module."; 855 uses common-leafs { 856 status deprecated; 857 } 858 uses schema-leaf { 859 status deprecated; 860 } 861 } 862 } 863 } 865 /* 866 * Legacy operational state data nodes 867 */ 869 container modules-state { 870 config false; 871 status deprecated; 872 description 873 "Contains YANG module monitoring information."; 875 leaf module-set-id { 876 type string; 877 mandatory true; 878 status deprecated; 879 description 880 "Contains a server-specific identifier representing 881 the current set of modules and submodules. The 882 server MUST change the value of this leaf if the 883 information represented by the 'module' list instances 884 has changed."; 886 } 888 uses module-list { 889 status deprecated; 890 } 891 } 893 /* 894 * Legacy notifications 895 */ 897 notification yang-library-change { 898 status deprecated; 899 description 900 "Generated when the set of modules and submodules supported 901 by the server has changed."; 902 leaf module-set-id { 903 type leafref { 904 path "/yanglib:modules-state/yanglib:module-set-id"; 905 } 906 mandatory true; 907 status deprecated; 908 description 909 "Contains the module-set-id value representing the 910 set of modules and submodules supported at the server 911 at the time the notification is generated."; 912 } 913 } 915 } 917 919 3. IANA Considerations 921 3.1. YANG Module Registry 923 RFC 7895 previously registered one URI in the IETF XML registry 924 [RFC3688]. Following the format in RFC 3688, the following 925 registration was made: 927 URI: urn:ietf:params:xml:ns:yang:ietf-yang-library 928 Registrant Contact: The NETCONF WG of the IETF. 929 XML: N/A, the requested URI is an XML namespace. 931 This document takes over this registration entry made by RFC 7895. 933 RFC 7895 previously registered one YANG module in the "YANG Module 934 Names" registry [RFC6020] as follows: 936 name: ietf-yang-library 937 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library 938 prefix: yanglib 939 reference: RFC 7895 941 This document takes over this registration entry made by RFC 7895. 943 4. Security Considerations 945 The YANG module defined in this memo is designed to be accessed via 946 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 947 secure transport layer and the mandatory-to-implement secure 948 transport is SSH [RFC6242]. The NETCONF access control model 949 [RFC6536] provides the means to restrict access for particular 950 NETCONF users to a pre-configured subset of all available NETCONF 951 protocol operations and content. 953 Some of the readable data nodes in this YANG module may be considered 954 sensitive or vulnerable in some network environments. It is thus 955 important to control read access (e.g., via get, get-config, or 956 notification) to these data nodes. These are the subtrees and data 957 nodes and their sensitivity/vulnerability: 959 o /modules-state/module: The module list used in a server 960 implementation may help an attacker identify the server 961 capabilities and server implementations with known bugs. Although 962 some of this information may be available to all users via the 963 NETCONF message (or similar messages in other management 964 protocols), this YANG module potentially exposes additional 965 details that could be of some assistance to an attacker. Server 966 vulnerabilities may be specific to particular modules, module 967 revisions, module features, or even module deviations. This 968 information is included in each module entry. For example, if a 969 particular operation on a particular data node is known to cause a 970 server to crash or significantly degrade device performance, then 971 the module list information will help an attacker identify server 972 implementations with such a defect, in order to launch a denial- 973 of-service attack on the device. 975 5. Acknowledgements 977 Contributions to this material by Andy Bierman are based upon work 978 supported by the The Space & Terrestrial Communications Directorate 979 (S&TCD) under Contract No. W15P7T-13-C-A616. Any opinions, findings 980 and conclusions or recommendations expressed in this material are 981 those of the author(s) and do not necessarily reflect the views of 982 The Space & Terrestrial Communications Directorate (S&TCD). 984 6. References 986 6.1. Normative References 988 [I-D.ietf-netmod-revised-datastores] 989 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 990 and R. Wilton, "Network Management Datastore 991 Architecture", draft-ietf-netmod-revised-datastores-05 992 (work in progress), October 2017. 994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 995 Requirement Levels", BCP 14, RFC 2119, 996 DOI 10.17487/RFC2119, March 1997, . 999 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1000 DOI 10.17487/RFC3688, January 2004, . 1003 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1004 the Network Configuration Protocol (NETCONF)", RFC 6020, 1005 DOI 10.17487/RFC6020, October 2010, . 1008 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1009 and A. Bierman, Ed., "Network Configuration Protocol 1010 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1011 . 1013 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1014 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1015 . 1017 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1018 Protocol (NETCONF) Access Control Model", RFC 6536, 1019 DOI 10.17487/RFC6536, March 2012, . 1022 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1023 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1024 . 1026 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 1027 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 1028 . 1030 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1031 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1032 . 1034 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1035 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1036 . 1038 6.2. Informative References 1040 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 1041 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 1042 . 1044 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 1045 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 1046 February 2012, . 1048 Authors' Addresses 1050 Andy Bierman 1051 YumaWorks 1053 Email: andy@yumaworks.com 1055 Martin Bjorklund 1056 Tail-f Systems 1058 Email: mbj@tail-f.com 1060 Kent Watsen 1061 Juniper Networks 1063 Email: kwatsen@juniper.net