idnits 2.17.1 draft-claise-netconf-metadata-for-collection-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 : ---------------------------------------------------------------------------- ** There are 126 instances of too long lines in the document, the longest one being 68 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2021) is 1018 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: 'I-D.ietf-netmod-rfc6991-bis' is defined on line 957, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-netconf-notification-capabilities-16 == Outdated reference: A later version (-15) exists of draft-ietf-netmod-rfc6991-bis-06 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF B. Claise 3 Internet-Draft Huawei 4 Intended status: Standards Track M. Nayyar 5 Expires: January 12, 2022 A. Reddy Sesani 6 Cisco Systems, Inc. 7 July 11, 2021 9 Per-Node Capabilities for Optimum Operational Data Collection 10 draft-claise-netconf-metadata-for-collection-02 12 Abstract 14 This document proposes a YANG module that provides per-node 15 capabilities for optimum operational data collection. This YANG 16 module augments the YANG Modules for describing System Capabilities 17 and YANG-Push Notification capabilities. 19 This module defines augmented nodes to publish the metadata 20 information specific to YANG node-identifier as per ietf-system- 21 capabilities datatree. 23 Complementary RPCs, based on the same node capabilities, simplify the 24 data collection operations. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 12, 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Base ietf-system-node-metadata YANG module . . . . . . . . . 7 64 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. Full Tree View . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 70 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 20 71 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 74 9.2. Informative References . . . . . . . . . . . . . . . . . 22 75 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 78 1. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document are to be interpreted as described in BCP 83 14 [RFC2119] [RFC8174] when, and only when, they appear in all 84 capitals, as shown here. 86 The term Client and Server are specified in [RFC8342]. 88 The term Implementation-time and Run-time are specified in 89 [I-D.ietf-netconf-notification-capabilities]. 91 2. Introduction 93 This document specifies a way to learn from the devices how granular 94 its telemetry and data can be to provide the best post-processing 95 analytics. In the end, the service assurance architecture 97 [I-D.claise-opsawg-service-assurance-architecture], it's not 98 sufficient to simply stream (or poll) telemetry data, it is equally 99 important to be able to act on the data. As such, a series of extra 100 information about the node capabilities is essential. 102 The module ietf-system-capabilities 103 [I-D.ietf-netconf-notification-capabilities] provides a structure 104 that can be used to specify YANG related system capabilities for 105 servers. The module can be used in conjunction with YANG Instance 106 Data to make this information available at implementation-time. The 107 module can also be used to report capability information from the 108 server at run-time. 110 The module ietf-notification-capabilities 111 [I-D.ietf-netconf-notification-capabilities] augments ietf-system- 112 capabilities to specify capabilities related to "Subscription to YANG 113 Datastores" (YANG-Push) [RFC8639]. It provides a starting point by 114 specifying some per-node telemetry-related capabilities. Of 115 particular interest are the following node capabilities: 117 o minimum-dampening-period 119 o on-change-supported 121 o periodic-notifications-supported 123 o supported-excluded-change-type 125 Taking the example of on-change-supported and periodic-notifications- 126 supported, it's key to understand whether a publisher is capable of 127 sending on-change notifications versus sending periodic notifications 128 for the selected data store or data nodes. Indeed, not only would 129 the telemetry configuration change depending on the capabilities (on- 130 change versus periodic), but more importantly the client's handling 131 of the telemetry information would change. Upon receipt of an on- 132 change telemetry message, an immediate action could be taken to 133 correct or mitigate the issue, while in case of periodic 134 notification, a comparison with the previous value must first be 135 performed in order to understand if and how the network state has 136 changed. 138 Exactly like a client that connects to a server is able to discover 139 the capabilities in terms of supported YANG modules, features, 140 deviations, and protocol capabilities; the same client must also be 141 able to discover the required per-node capabilities (also known as 142 metadata) to correctly act on the telemetry information. It forms 143 part of the API contract for managing and monitoring the device. 144 Extending the per-node capabilities specified in 146 [I-D.ietf-netconf-notification-capabilities], additional per-node 147 capabilities are required. 149 The YANG module in this document augments the ietf-system- 150 capabilities YANG module in "YANG Modules for describing System 151 Capabilities and Yang-Push Notification Capabilities" 152 [I-D.ietf-netconf-notification-capabilities]. 154 The YANG data model in this document conform to the Network 155 Management Datastore Architecture (NMDA) defined in [RFC8342]. 157 3. Concepts 159 Doing networking data collection for the sake of doing collection is 160 not useful. At the time of network automation, displaying nice 161 graphs from collected data is not useful: the collected data must be 162 acted upon immediately. Some use cases are: network availability, 163 closed loop automation (reconfiguring network based on observed 164 network state changes), service assurance 165 [I-D.claise-opsawg-service-assurance-architecture], etc. 167 Along with the capabilities specified in ietf-netconf-notification- 168 capabilities [I-D.ietf-netconf-notification-capabilities] YANG model, 169 there is some additional information that can be made available per 170 node-selector to help with this optimum collection of operational 171 data. For example, these additional metadata can help reduce the 172 load on the devices being managed along with the performance 173 improvements because of the way data is subscribed to. Some other 174 metadata can help with the collection automation itself (mapping of 175 config and oper data node, mapping of MIB oid to YANG leaf). 177 Some metadata are static and can augment the node-capabilities in 178 [I-D.ietf-netconf-notification-capabilities], for both implementation 179 time and run time environments. Other metadata are dynamic and have 180 to be derived during the run-time. They can change based on the role 181 of the device and the scale of the data being observed. 183 Per-node static metadata includes: 185 o minimum-observable-period: This is the minimum observable period 186 in nanoseconds for the node-selector. Streaming or polling more 187 frequently then this interval may not fetch useful information as 188 the node could be updated only at this frequency internally. If a 189 close loop automation system would stream or poll more frequently, 190 it could actually draw the wrong conclusions. Let's take the 191 example of interface counters than are updated more frequently 192 than 30 seconds in a distributed system. Streaming interface 193 counters every 30 seconds would see an natural increase in the 194 interface counters. However, streaming those interface counters 195 every 10 seconds could lead to the wrong conclusion that no 196 packets are received/sent on that specific interface ... 197 triggering an automatic interface troubleshooting action. Hence 198 determining the minimum-observable-period for every monitored leaf 199 is essential for closed loop automation and assurance systems. 201 o suggested-observable-period: The suggested observable period for 202 this node-selector. This value represents factory default 203 suggested information, only available at implementation time. Let 204 us assume that an assurance system would like to monitor all FIB 205 entries in the router. The router would advertise that the 206 suggested observable period is, let's say, 30 seconds. Those 5 207 seconds are the factory defaults, provided at the implementation 208 time. Once the router is in production, the observable period 209 would obviously change depending on the environment (as an 210 example, a FIB containing all BGP entries is huge): this dynamic 211 suggest observable period is called the computed-observable-period 212 and is available part of the get-measurement-metadata RPC. 214 o optimized-measurement-point: In some server design, operational 215 data are usually modeled/structured in a way that the relevant 216 data are grouped together and reside together. In most cases, it 217 is more performant to fetch this data together than as individual 218 leaves: data are structured together internally, grouped together, 219 and therefore fetched together. This feature specifies optimum 220 observable points in the model at which data can be collected and 221 streamed in an efficient way. Depending on the implementation, 222 optimum points can be leaves or a container nodes in the YANG 223 tree. This is a selection node, that means its presence for a 224 node-selector indicates it is the optimized measurement point. 226 o corresponding-mib-oid: The object identifier (OID) assigned to a 227 SMIv2 definition, corresponding to the node-selector. The object 228 identifier value is written in decimal dotted notation. Existing 229 SNMP MIBs based automations can use this information to migrate to 230 more analytics-ready YANG Modeled data. Working from a single 231 data model system (YANG-based in this case) for data collection 232 simplifies the management, as opposed to use different data 233 models. Therefore, knowing the mapping MIB OID/YANG leaf is 234 important, as transition mechanism towards YANG (for example: 235 moving away from SNMP polling to model-driven telemetry) but also 236 as a way to understand whether the same operational data is 237 metered in both the MIB and YANG worlds, adding to the load on 238 devices. Some IETF RFCs, such as the YANG Interface Management 239 [RFC8343], specify the mapping in the document. However, 240 providing this mapping directly from the server helps automation 241 from a client point of view. 243 o related-node: Data nodes that are related for closed-loop scenario 244 for data node specified in node-capabilities. In case node- 245 capabilities is an operational node then the associated node- 246 instance-identifier represents config paths directly related to 247 this operational node capabilities. In case node-capabilities is 248 an config node then the associated node-instance-identifier 249 represents operational leaf directly related to this configuration 250 node capabilities. This node is specifically interesting for non 251 NMDA [RFC8342], non openconfig YANG modules. For example, in the 252 initial YANG data model for interface management [RFC7223], which 253 is not NMDA-compliant, advertising the mapping between the admin- 254 status and the oper-status leaves would clearly simplify the 255 closed loop automation. Note that NMDA and the openconfig -state 256 container solved that issue but not all servers are NMDA compliant 257 and openconfig models don't cover all server functions. 259 A generic RPC, get-system-node-capabilities, provides the 260 capabilities for the nodes in the subtree of the input. If the input 261 node passed is a leaf/leaf-list, then all the metadata for that input 262 node are returned. If the input node is not leaf/leaf-list then the 263 RPC returns the metadata of all of its subtree nodes. 265 There is some run-time information that is very helpful for the 266 applications to know, to be able to start listening to the device 267 without adding too much additional resource strain on the device. 268 The get-measurement-metadata RPC can be used to fetch this data. 270 Per-node dynamic metadata includes, part of the get-measurement- 271 metadata RPC: 273 o optimized-measurement-point: The node-selector is searched up the 274 data tree chain to find the parent node that is the optimized 275 measurement point (if the optimized-measurement-point-feature is 276 supported). If the node-selector itself is the optimized point 277 then same data node is returned in the output. If the node- 278 selector has no optimized measurement point then this optimized- 279 measurement-point leaf is not returned. 281 o computed-observable-period: the computed observable period for 282 this node-selector (and optimized-measurement-point). The system 283 internally dynamically computes the suggested observable period 284 (relevant for polling or streaming cadence) which can be greater- 285 or-equal to the minimal-observable-period. Since this value is 286 dynamic, this metadata is only available in a run time 287 environment. 289 o active-measurements - subscribed-measurement-period: List of 290 existing subscriptions for this node-selector. If there are no 291 active subscriptions then system calculate the measurement-period 292 and this list is not-returned, else, each instance in this list 293 will be pair of active measurement with intended and actual period 294 used by the system. 296 4. Base ietf-system-node-metadata YANG module 298 4.1. Tree View 300 The following tree diagram [RFC8340] provides an overview of the 301 ietf-system-node-metadata data model. 303 module: ietf-system-node-metadata 304 augment /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per-node-capabilities/sysc:node-selection/sysc:node-selector: 305 +--ro minimum-observable-period? uint64 306 +--ro suggested-observable-period? uint64 307 +--ro optimized-measurement-point? empty {optimized-measurement-point-feature}? 308 +--ro corresponding-mib-oid? yang:object-identifier-128 309 +--ro related-node? yang:node-instance-identifier 311 rpcs: 312 +---x get-measurement-metadata 313 | +---w input 314 | | +---w node-selector? yang:node-instance-identifier 315 | +--ro output 316 | +--ro optimized-measurement-point? yang:node-instance-identifier {optimized-measurement-point-feature}? 317 | +--ro computed-observable-period? uint64 318 | +--ro active-measurements* [] 319 | +--ro subscribed-measurement-period? uint64 320 +---x get-system-node-capabilities 321 +---w input 322 | +---w node-selector? yang:node-instance-identifier 323 +--ro output 324 +--ro node-selector-capability* [] 325 +--ro node? yang:node-instance-identifier 326 +--ro minimum-observable-period? uint64 327 +--ro suggested-observable-period? uint64 328 +--ro optimized-measurement-point? empty {optimized-measurement-point-feature}? 329 +--ro corresponding-mib-oid? yang:object-identifier-128 330 +--ro related-node? yang:node-instance-identifier 332 4.2. Full Tree View 334 The following tree diagram [RFC8340] provides an overview of the 335 ietf-system-capabilities and ietf-system-node-metadata data models. 337 module: ietf-system-node-metadata 339 rpcs: 340 +---x get-measurement-metadata 341 | +---w input 342 | | +---w node-selector? yang:node-instance-identifier 343 | +--ro output 344 | +--ro optimized-measurement-point? yang:node-instance-identifier {optimized-measurement-point-feature}? 345 | +--ro computed-observable-period? uint64 346 | +--ro active-measurements* [] 347 | +--ro subscribed-measurement-period? uint64 348 +---x get-system-node-capabilities 349 +---w input 350 | +---w node-selector? yang:node-instance-identifier 351 +--ro output 352 +--ro node-selector-capability* [] 353 +--ro node? yang:node-instance-identifier 354 +--ro minimum-observable-period? uint64 355 +--ro suggested-observable-period? uint64 356 +--ro optimized-measurement-point? empty {optimized-measurement-point-feature}? 357 +--ro corresponding-mib-oid? yang:object-identifier-128 358 +--ro related-node? yang:node-instance-identifier 359 module: ietf-system-capabilities 360 +--ro system-capabilities 361 +--ro datastore-capabilities* [datastore] 362 +--ro datastore -> /yanglib:yang-library/datastore/name 363 +--ro per-node-capabilities* [] 364 +--ro (node-selection)? 365 +--:(node-selector) 366 +--ro node-selector? nacm:node-instance-identifier 367 +--ro sys-metadata:minimum-observable-period? uint64 368 +--ro sys-metadata:suggested-observable-period? uint64 369 +--ro sys-metadata:optimized-measurement-point? empty {optimized-measurement-point-feature}? 370 +--ro sys-metadata:corresponding-mib-oid? yang:object-identifier-128 371 +--ro sys-metadata:related-node? yang:node-instance-identifier 373 4.3. YANG Module 375 file "ietf-system-node-metadata@2020-03-20.yang" 377 module ietf-system-node-metadata { 378 yang-version 1.1; 379 namespace "urn:ietf:params:xml:ns:yang:ietf-system-node-metadata"; 380 prefix sys-metadata; 382 import ietf-system-capabilities { 383 prefix sysc; 384 reference 385 "RFC XXXX: YANG Modules for describing System Capabilities and 386 Yang-Push Notification Capabilities"; 387 } 388 import ietf-yang-types { 389 prefix yang; 390 reference 391 "RFC XXXX: Currently draft-ietf-netmod-rfc6991-bis-04, Common 392 YANG Data types"; 393 } 395 organization 396 "IETF NETCONF (Network Configuration) Working Group"; 397 contact 398 "WG Web: 399 WG List: 401 Editor: Benoit Claise 402 404 Editor: Munish Nayyar 405 407 Editor: Adithya Reddy Sesani 408 409 "; 410 description 411 "This document proposes a YANG module that provides per-node 412 capabilities for optimum operational data collection. 414 This YANG module augments the YANG Modules for describing 415 System Capabilities and Yang-Push Notification capabilities 416 [RFC XXXX]. 418 This module defines augmented nodes to publish the 419 metadata information specific to YANG node-identifier as per 420 ietf-system-capabilities datatree. 422 Complementary RPCs, based on the same node capabilities, 423 simplify the data collection operations. 425 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 426 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 427 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 428 are to be interpreted as described in BCP 14 (RFC 2119) 429 (RFC 8174) when, and only when, they appear in all 430 capitals, as shown here. 432 Copyright (c) 2020 IETF Trust and the persons identified as 433 authors of the code. All rights reserved. 435 Redistribution and use in source and binary forms, with or 436 without modification, is permitted pursuant to, and subject 437 to the license terms contained in, the Simplified BSD License 438 set forth in Section 4.c of the IETF Trust's Legal Provisions 439 Relating to IETF Documents 440 (http://trustee.ietf.org/license-info). 442 This version of this YANG module is part of RFC XXXX 443 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 444 for full legal notices."; 446 revision 2020-03-23 { 447 description 448 "Initial version"; 449 reference 450 "RFC XXX: Per-Node Capabilities For Closed Loop Automation."; 451 } 453 feature optimized-measurement-point-feature { 454 description 455 "Support for optimized measurement point within data tree."; 456 } 458 grouping system-node-metadata-info { 459 description 460 "group of metadata properties associated to the 461 node-instance."; 462 leaf minimum-observable-period { 463 type uint64; 464 units "nanoseconds"; 465 description 466 "The minimum observable period for this node-selector. Don't 467 poll or stream more frequently that minimum observable 468 period in nanoseconds as the corresponding counter is not 469 updated more frequently."; 470 } 471 leaf suggested-observable-period { 472 type uint64; 473 units "nanoseconds"; 474 description 475 "The suggested observable period for this node-selector. 476 This value represents factory default suggested 477 information, only available at implementation time."; 478 } 479 leaf optimized-measurement-point { 480 if-feature "optimized-measurement-point-feature"; 481 type empty; 482 description 483 "This node-selector is an optimized measurement point."; 484 } 485 leaf corresponding-mib-oid { 486 type yang:object-identifier-128; 487 description 488 "The object identifier (OID) assigned to a SMIv2 definition, 489 corresponding to this node-selector."; 490 } 491 leaf related-node { 492 type yang:node-instance-identifier; 493 description 494 "In case the node instance is an operational node then the 495 associated node-instance-identifier represents the config 496 leaf directly related to this operational node. In case the 497 node instance is an config node then the associated 498 node-instance-identifier represents the operational leaf 499 directly related to this configuration node. A typical 500 example is the relationship between the admin-status and 501 oper-status, which is impossible to detect automatically in 502 a non-NMDA environment or for non-openconfig YANG moduels. 503 The related-node SHOULD NOT reported for NMDA architectures 504 and openconfig YANG modules."; 505 } 506 } 508 augment 509 "/sysc:system-capabilities/sysc:datastore-capabilities/" 510 + "sysc:per-node-capabilities/" 511 + "sysc:node-selection/sysc:node-selector" { 512 description 513 "Metadata information tied to the per-node-capabilities"; 514 uses system-node-metadata-info; 515 } 517 rpc get-measurement-metadata { 518 description 519 "RPC that returns the optimized measurement per-node 520 capabilities and some measurement parameters. This RPC 521 is added to allow clients to learn dynamically changing 522 metadata for a specific leaf on a server. 524 If the server supports the optimized-measurement-point 525 feature, then the output data refers to 526 optimized-measurement-point. The server will internally 527 find the optimized-measurement-point. If it can not find it, 528 then no output is returned (for the 529 optimized-measurement-point, computed-observable-period, 530 and active-measurements). 532 If the server doesn't support the optimized-measurement-point 533 feature, then the output data refers to input node selector."; 534 input { 535 leaf node-selector { 536 type yang:node-instance-identifier; 537 description 538 "node instance for which metadata is requested"; 539 } 540 } 541 output { 542 leaf optimized-measurement-point { 543 if-feature "optimized-measurement-point-feature"; 544 type yang:node-instance-identifier; 545 description 546 "The node-selector is searched up the data tree chain to 547 find the parent node that is the optimized measurement 548 point (if the optimized-measurement-point-feature is 549 supported). 551 If the node-selector itself is the optimized point then 552 same data node is returned in the output. 554 If the node-selector has no optimized measurement point 555 then this optimized-measurement-point leaf is not 556 returned."; 557 } 558 leaf computed-observable-period { 559 type uint64; 560 units "nanoseconds"; 561 description 562 "the computed observable period for this node-selector (and 563 optimized-measurement-point). The system internally 564 dynamically computes the suggested observable period 565 (relevant for polling or streaming cadence) which can be 566 greater-or-equal to the minimal-observable-period. 567 Since this value is dynamic, this metadata is only 568 available in a run time environment."; 569 } 570 list active-measurements { 571 description 572 "list of existing subscriptions for this node-selector. If 573 there are no active subscriptions then system calculate 574 the measurement-period and this list is not-returned, 575 else, each instance in this list will be pair of active 576 measurement with intended and actual period used by the 577 system"; 578 leaf subscribed-measurement-period { 579 type uint64; 580 units "nanoseconds"; 581 description 582 "Currently subscribed measurement period for this 583 node-selector (and optimized-measurement-point)"; 584 } 585 } 586 } 587 } 589 rpc get-system-node-capabilities { 590 description 591 "RPC to get the capabilities for the nodes in the subtree of 592 the input. 593 If the input node passed is a leaf/leaf-list, then 594 the same node metadata is returned in the output. 595 If the input node is not leaf/leaf-list then metadata of its 596 subtree nodes is returned."; 597 input { 598 leaf node-selector { 599 type yang:node-instance-identifier; 600 description 601 "node instance whose subtree which metadata is requested."; 602 } 603 } 604 output { 605 list node-selector-capability { 606 description 607 "metadata of nodes in the subtree of node-selector."; 608 leaf node { 609 type yang:node-instance-identifier; 610 description 611 "instance path of the node inside subtree of 612 node-selector."; 613 } 614 uses system-node-metadata-info; 615 } 616 } 617 } 618 } 620 622 5. Examples 624 The YANG module specified in this document defines a schema for data 625 that is designed to be accessed via network management protocols such 626 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 627 is the secure transport layer, and the mandatory-to-implement secure 628 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 629 is HTTPS, and the mandatory-to-implement secure transport is TLS 630 [RFC8446]. 632 XML data tree for the ietf-interface YANG module [RFC8343]: 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 671 Example1: Demonstrating the querying metadata for all system schema 672 nodes for the ietf-interfaces [RFC8343]. 674 675 676 677 678 679 680 681 682 684 685 686 687 688 689 ds:operational 690 691 /if:interfaces/if:interface 692 693 694 1000 695 1000 696 697 698 /if:interfaces/if:interface/if:admin-status 699 1.3.6.1.2.1.2.2.1.7 700 1000 701 1000 702 703 704 /if:interfaces/if:interface/if:oper-status 705 1.3.6.1.2.1.2.2.1.8 706 1000 707 1000 708 709 710 /if:interfaces/if:interface/if:if-index 711 1.3.6.1.2.1.2.1 712 1000 713 1000 714 715 716 /if:interfaces/if:interface/if:phys-address 717 1.3.6.1.2.1.2.2.1.6 718 1000 719 1000 720 721 722 /if:interfaces/if:interface/if:lower-layer-if 723 1.3.6.1.2.1.31.1.2.1.2 724 1000 725 1000 726 727 728 /if:interfaces/if:interface/if:higher-layer-if 729 1.3.6.1.2.1.31.1.2.1.1 730 1000 731 1000 732 733 734 /if:interfaces/if:interface/if:speed 735 1.3.6.1.2.1.2.2.1.5 736 1000 737 1000 738 739 740 /if:interfaces/if:interface/if:statistics 741 742 1.3.6.1.2.1.31.1.1 743 1000 744 1000 745 746 747 /if:interfaces/if:interface/if:statistics/if:discontinuity-time 748 749 1.3.6.1.2.1.31.1.1.1.19 750 1000 751 1000 752 753 754 /if:interfaces/if:interface/if:statistics/if:in-octets 755 1.3.6.1.2.1.2.2.1.10 756 1000 757 1000 758 759 760 /if:interfaces/if:interface/if:statistics/if:in-unicast-pkts 761 1.3.6.1.2.1.2.2.1.11 762 1000 763 1000 764 765 766 /if:interfaces/if:interface/if:statistics/if:in-multicast-pkts 767 1.3.6.1.2.1.31.1.1.1.2 768 1000 769 1000 770 771 772 /if:interfaces/if:interface/if:statistics/if:in-broadcast-pkts 773 1.3.6.1.2.1.31.1.1.1.3 774 1000 775 1000 776 777 778 /if:interfaces/if:interface/if:statistics/if:in-discards 779 1.3.6.1.2.1.2.2.1.13 780 1000 781 1000 782 783 784 /if:interfaces/if:interface/if:statistics/if:in-errors 785 1.3.6.1.2.1.2.2.1.14 786 1000 787 1000 788 789 790 /if:interfaces/if:interface/if:statistics/if:in-unknown-protos 791 1.3.6.1.2.1.2.2.1.15 792 1000 793 1000 794 795 796 /if:interfaces/if:interface/if:statistics/if:out-octets 797 1.3.6.1.2.1.2.2.1.16 798 1000 799 1000 800 801 802 /if:interfaces/if:interface/if:statistics/if:out-unicast-pkts 803 1.3.6.1.2.1.2.2.1.17 804 1000 805 1000 806 807 808 /if:interfaces/if:interface/if:statistics/if:out-multicast-pkts 809 1.3.6.1.2.1.31.1.1.1.4 810 1000 811 1000 812 813 814 /if:interfaces/if:interface/if:statistics/if:out-broadcast-pkts 815 1.3.6.1.2.1.31.1.1.1.5 816 1000 817 1000 818 819 820 /if:interfaces/if:interface/if:statistics/if:out-discards 821 1.3.6.1.2.1.2.2.1.19 822 1000 823 1000 824 825 826 /if:interfaces/if:interface/if:statistics/if:out-errors 827 1.3.6.1.2.1.2.2.1.20 828 1000 829 1000 830 831 832 833 834 836 Example2: Demonstrating the querying metadata of all optimized- 837 measurement-point(s). Use containment and selection nodes filtering 838 criteria to express which all metadata you want. In this example: 839 get query filter only to "select" the node-instance-identifier, 840 optimized-measurement-point nodes, for the ietf-interfaces [RFC8343]. 841 There are two optimized-measurement-points: interface and statistics. 843 844 845 846 847 848 849 ds:operational 850 851 852 853 854 855 856 858 860 861 862 863 864 ds:operational 865 866 /if:interfaces/if:interface 867 868 869 870 /if:interfaces/if:interface/if:statistics 871 872 873 874 875 876 878 Example3: Demonstrating the usage of RPC to query the device for 879 computed-measurement-period and the subscribed-measurement-period(s) 880 for the in-errors YANG leaf. 882 884 885 886 /if:interfaces/if:interface/if:statistics/if:in-errors 887 888 890 891 892 /if:interfaces/if:interface/if:statistics 893 3000 894 895 1000 896 897 898 1000 899 900 901 1000 902 903 905 6. Security Considerations 907 The YANG module specified in this document defines a schema for data 908 that is designed to be accessed via network management protocols such 909 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 910 is the secure transport layer, and the mandatory-to-implement secure 911 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 912 is HTTPS, and the mandatory-to-implement secure transport is TLS 913 [RFC8446]. 915 The Network Configuration Access Control Model (NACM) [RFC8341] 916 provides the means to restrict access for particular NETCONF or 917 RESTCONF users to a preconfigured subset of all available NETCONF or 918 RESTCONF protocol operations and content. 920 7. IANA Considerations 922 7.1. The IETF XML Registry 924 This document registers two URIs in the IETF XML registry [RFC3688]. 925 Following the format in [RFC3688], the following registrations are 926 requested: 928 URI: urn:ietf:params:xml:ns:yang:ietf-system-node-metadata 929 Registrant Contact: The NETCONF WG of the IETF. 930 XML: N/A, the requested URI is an XML namespace. 932 8. Open Issues 934 "related-node" should be split into two: "related-config-node" and 935 "related-state-node"? 937 Explain how to use the RPC from the client side, along with the 938 different options. 940 Expand on the active measurement use case 942 nanosecond: an overkill? 944 security considerations: see https://trac.ietf.org/trac/ops/wiki/ 945 yang-security-guidelines 947 9. References 949 9.1. Normative References 951 [I-D.ietf-netconf-notification-capabilities] 952 Lengyel, B., Clemm, A., and B. Claise, "YANG Modules 953 describing Capabilities for Systems and Datastore Update 954 Notifications", draft-ietf-netconf-notification- 955 capabilities-16 (work in progress), April 2021. 957 [I-D.ietf-netmod-rfc6991-bis] 958 Schoenwaelder, J., "Common YANG Data Types", draft-ietf- 959 netmod-rfc6991-bis-06 (work in progress), April 2021. 961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 962 Requirement Levels", BCP 14, RFC 2119, 963 DOI 10.17487/RFC2119, March 1997, 964 . 966 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 967 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 968 May 2017, . 970 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 971 Access Control Model", STD 91, RFC 8341, 972 DOI 10.17487/RFC8341, March 2018, 973 . 975 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 976 E., and A. Tripathy, "Subscription to YANG Notifications", 977 RFC 8639, DOI 10.17487/RFC8639, September 2019, 978 . 980 9.2. Informative References 982 [I-D.claise-opsawg-service-assurance-architecture] 983 Claise, B., Quilbeuf, J., Lopez, D. R., Voyer, D., and T. 984 Arumugam, "Service Assurance for Intent-based Networking 985 Architecture", draft-claise-opsawg-service-assurance- 986 architecture-05 (work in progress), April 2021. 988 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 989 DOI 10.17487/RFC3688, January 2004, 990 . 992 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 993 and A. Bierman, Ed., "Network Configuration Protocol 994 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 995 . 997 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 998 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 999 . 1001 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1002 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1003 . 1005 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1006 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1007 . 1009 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1010 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1011 . 1013 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1014 and R. Wilton, "Network Management Datastore Architecture 1015 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1016 . 1018 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1019 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1020 . 1022 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1023 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1024 . 1026 Acknowledgements 1028 The authors would like to thank ... for their reviews and feedback. 1030 Authors' Addresses 1032 Benoit Claise 1033 Huawei 1035 Email: benoit.claise@huawei.com 1037 Munish Nayyar 1038 Cisco Systems, Inc. 1039 Milpitas 1040 California 1041 United States 1043 Email: mnayyar@cisco.com 1045 Adithya Reddy Sesani 1046 Cisco Systems, Inc. 1047 Milpitas 1048 California 1049 United States 1051 Email: adithyas@cisco.com