idnits 2.17.1 draft-ietf-netmod-node-tags-07.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 7 instances of too long lines in the document, the longest one being 13 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 (29 April 2022) is 728 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: 'RFC9196' is defined on line 980, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group Q. Wu 3 Internet-Draft B. Claise 4 Updates: 8407 (if approved) Huawei 5 Intended status: Standards Track P. Liu 6 Expires: 31 October 2022 Z. Du 7 China Mobile 8 M. Boucadair 9 Orange 10 29 April 2022 12 Data Node Tags in YANG Modules 13 draft-ietf-netmod-node-tags-07 15 Abstract 17 This document defines a method to tag data nodes that are associated 18 with operation and management data in YANG modules. This method for 19 tagging YANG data nodes is meant to be used for classifying data 20 nodes or instance of data nodes from different YANG modules and 21 identifying their characteristic data. Tags may be registered as 22 well as assigned during the definition of the module, assigned by 23 implementations, or dynamically defined and set by users. 25 This document also provides guidance to future YANG data model 26 writers; as such, this document updates RFC 8407. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 31 October 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Data Classification and Fetching using Data Node Tags . . . . 4 64 4. Data Node Tag Values . . . . . . . . . . . . . . . . . . . . 7 65 4.1. IETF Tags . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Vendor Tags . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. User Tags . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.4. Reserved Tags . . . . . . . . . . . . . . . . . . . . . . 8 69 5. Data Node Tag Management . . . . . . . . . . . . . . . . . . 8 70 5.1. Module Design Tagging . . . . . . . . . . . . . . . . . . 8 71 5.2. Implementation Tagging . . . . . . . . . . . . . . . . . 10 72 5.3. User Tagging . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Data Node Tags Module Structure . . . . . . . . . . . . . . . 10 74 6.1. Data Node Tags Module Tree . . . . . . . . . . . . . . . 10 75 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 14 77 8.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 14 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. YANG Data Object Tag Prefixes Registry . . . . . . . . . 15 80 9.2. IETF YANG Data Object Tags Registry . . . . . . . . . . . 16 81 9.3. Updates to the IETF XML Registry . . . . . . . . . . . . 18 82 9.4. Updates to the YANG Module Names Registry . . . . . . . . 18 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 85 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 88 13.2. Informative References . . . . . . . . . . . . . . . . . 20 89 Appendix A. Example: Additional Auxiliary Data Property 90 Information . . . . . . . . . . . . . . . . . . . . . . . 22 91 Appendix B. Instance Level Tunnel Tagging Example . . . . . . . 22 92 Appendix C. NETCONF Example . . . . . . . . . . . . . . . . . . 24 93 Appendix D. Non-NMDA State Module . . . . . . . . . . . . . . . 25 94 Appendix E. Targeted Data Fetching Example . . . . . . . . . . . 28 95 Appendix F. Changes between Revisions . . . . . . . . . . . . . 30 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 98 1. Introduction 100 The use of tags for classification and organization purposes is 101 fairly ubiquitous, not only within IETF protocols, but globally in 102 the Internet (e.g., "#hashtags"). For the specific case of YANG data 103 models, a module tag is defined as a string that is associated with a 104 module name at the module level [RFC8819]. 106 Many data models have been specified by various Standards Developing 107 Organizations (SDOs) and the Open Source community, and it is likely 108 that many more will be specified. These models cover many of the 109 networking protocols and techniques. However, data nodes defined by 110 these technology-specific data models might represent only a portion 111 of fault, configuration, accounting, performance, and security 112 (FCAPS) management information ([FCAPS]) at different levels and 113 network locations, but also categorised in various different ways. 114 Furthermore, there is no consistent classification criteria or 115 representations for a specific service, feature, or data source. 117 This document defines data node tags and shows how they may be 118 associated with data nodes within a YANG module, which: 120 * Provide dictionary meaning for specific targeted data nodes. 122 * Indicate a relationship between data nodes within the same YANG 123 module or from different YANG modules. 125 * Identify key performance metric related data nodes and the 126 absolute XPath expression identifying the element path to the 127 nodes. 129 The data node tags can be used by a NETCONF [RFC6241] or RESTCONF 130 [RFC8040]client to classify data nodes of instance of these data 131 nodes from different YANG modules and identify characteristic data. 132 In addition, these tags can provide input, instructions, or 133 indications to selection filters and filter queries of configuration 134 or operational state on a server based on these data node tags (e.g., 135 return specific data containing operational state related to 136 performance management). NETCONF clients can discover data nodes or 137 instances of data nodes with data node tags supported by a NETCONF 138 server by means of the operation (Section 3.1 of 139 [RFC6022]). The data node tag information can also be queried using 140 the model defined in Section 6.1. Similar to YANG module tags 141 defined in [RFC8819], these data node tags may be registered or 142 assigned during the module definition, assigned by implementations, 143 or dynamically defined and set by users. 145 This document defines a YANG module [RFC7950] that augments the 146 module tag model [RFC8819] and provides a list of data node instance 147 entries to add or remove data node tags as well as to view the set of 148 data node tags associated with specific data nodes or instance of 149 data nodes within YANG modules. 151 This document defines three extension statements to indicate data 152 node tags that should be added by the module implementation 153 automatically (i.e., outside of configuration). 155 This document also defines an IANA registry for tag prefixes and a 156 set of globally assigned tags (Section 9). 158 Section 8 provides guidelines for authors of YANG data models. This 159 document updates [RFC8407]. 161 The YANG data model in this document conforms to the Network 162 Management Datastore Architecture defined in [RFC8342]. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119][RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 The meanings of the symbols in tree diagrams are defined in 173 [RFC8340]. 175 3. Data Classification and Fetching using Data Node Tags 177 Among data node tags, the 'opm' (object, property, metric) tags can 178 be used to classify collected data, indicate relationships between 179 data nodes, and capture YANG-modelled performance metrics data 180 associated with data nodes of instances of data nodes. An example is 181 depicted in Figure 1. 183 .------. 184 |Object| 185 | Tag | 186 '--+--' 187 | 188 +---------V--------+ contain 189 | YANG Data Node <----------------+ 190 | 1 | | 191 +--^-------------^-+ | 192 |contain |contain | 193 | | | 194 +-----------+---+ +- -----+-------+ +-----+---------+ 195 | YANG Data Node| | YANG Data Node| | YANG Data Node| 196 | 2 | | 3 | | 4 | 197 +--^------------+ +^-----^--------+ +^-----^------^-+ 198 | | | | | | 199 .---+---. | .--+--. | .--+--. | 200 |Property | | |Metric | | |Metric | | 201 | Tag | | | Tag | | | Tag | | 202 '---------' | '-------' | '-------' | 203 | | | 204 .--+--. .--+--. .---+---. 205 |Metric | |Metric | || Multi || 206 | Type | | Type | ||Metric || 207 | Tag | | Tag | ||Source || 208 '-------' '-------' \\ Tag // 209 '-----' 211 Figure 1: The Relation between Object, Property, and Metric 213 In Figure 1. 215 Data nodes that contain other data nodes can be one of type 216 'container', 'leaf-list', or 'list' and are tagged with the 'object' 217 tag. 219 A Data node tagged with the 'property' tag is a 'leaf' node. 221 Data nodes tagged with the 'metric' tag can be one of 'container', 222 'leaf-list', 'list', or 'leaf' data node. 224 A data node may be associated with one single 'object' tag, or one 225 single 'property' tag, or one single 'metric' tag. The data node 226 tagged with the 'metric' tag also can have one or multiple MetricType 227 tags and/or one single multi-source tag. 229 The use of 'opm' tags is meant to help filter discrete categories of 230 YANG data objects scattered across the same or different YANG modules 231 that are supported by a device and capture all network performance 232 data or all property data in a single view of the data. In the 233 example shown in Figure 2, the 'tunnel-svc' data node is a list node 234 defined in a 'example-tunnel-pm' module and can be seen as the root 235 object for property tagged data node (e.g., 'tunnel-svc'/'create- 236 time') and metric tagged data node (e.g., 'tunnel-svc'/'avg- 237 latency'). The 'name', 'create-time', and 'modified-time' are 238 property tagged data node under 'tunnel-svc' list. The 'avg-latency' 239 and 'packet-loss' metrics are metric tagged data nodes under 'tunnel- 240 svc' list node. Consider the 'tunnel-svc' data node and the 'tunnel- 241 svc/name' data node as an example: the 'tunnel-svc' data node has one 242 single 'object' tag (i.e., 'ietf:object'), while the 'tunnel-svc/ 243 name' data node has one single 'property' data node tag (i.e., 244 'ietf:property'). In addition, not all metric data node need to be 245 tagged (e.g., define specific categories, such as loss-related metric 246 data nodes need to be tagged with a metric-type tag which can further 247 reduce amount data to be fetched). 249 +------------------------+--------------------------------+-----------+ 250 | Data | Object Property Metric | Multi- | 251 | Node | Tag Tag Tag |Source Tag | 252 +------------------------+--------------------------------+-----------+ 253 | | ietf: | | 254 |tunnel-svc | object | | 255 | | ietf: | | 256 |tunnel-svc/name | property | | 257 | | ietf: | | 258 |tunnel-svc/create-time | property | | 259 | | ietf: | | 260 |tunnel-svc/modified-time| property | | 261 | | | | 262 |tunnel-svc/avg-latency | ietf: | non-agg | 263 | | metric | | 264 |tunnel-svc/packet-loss | ietf: | non-agg | 265 | | metric | | 266 |tunnel-svc/min-latency | ietf: | non-agg | 267 | | metric | | 268 |tunnel-svc/max-latency | ietf: | non-agg | 269 | | metric | | 270 +------------------------+--------------------------------+-----------+ 272 Figure 2: Example of OPM Tags Used in the YANG Module 274 If data objects in YANG modules are adequately tagged and learnt by 275 the client from a server, the client can retrieve paths to all 276 targeted data nodes and then use an XPath query defined in 277 [RFC8639][RFC8641] to list all tagged data nodes which reflect the 278 network characteristics. 280 4. Data Node Tag Values 282 All data node tags (except in some cases of user tags as described in 283 Section 4.3) begin with a prefix indicating who owns their 284 definition. An IANA registry (Section 9.1) is used to register data 285 node tag prefixes. Initially, three prefixes are defined. 287 No further structure is imposed by this document on the value 288 following the registered prefix, and the value can contain any YANG 289 type 'string' characters except carriage returns, newlines, tabs, and 290 spaces. 292 Except for the conflict-avoiding prefix, this document is 293 purposefully not specifying any structure on (i.e., restricting) the 294 tag values. The intent is to avoid arbitrarily restricting the 295 values that designers, implementers, and users can use. As a result 296 of this choice, designers, implementers, and users are free to add or 297 not add any structure they may require to their own tag values. 299 4.1. IETF Tags 301 An IETF tag is a data node tag that has the prefix "ietf:". 303 All IETF data node tags are registered with IANA in the registry 304 defined in Section 9.2. 306 4.2. Vendor Tags 308 A vendor tag is a tag that has the prefix "vendor:". 310 These tags are defined by the vendor that implements the module, and 311 are not registered with IANA. However, it is RECOMMENDED that the 312 vendor includes extra identification in the tag to avoid collisions, 313 such as using the enterprise or organization name following the 314 "vendor:" prefix (e.g., vendor:entno:vendor-defined-classifier). 316 4.3. User Tags 318 User tags are defined by a user/administrator and are not registered 319 by IANA. 321 Any tag with the prefix "user:" is a user tag. Furthermore, any tag 322 that does not contain a colon (":", i.e., has no prefix) is also a 323 user tag. Users are not required to use the "user:" prefix; however, 324 doing so is RECOMMENDED. 326 4.4. Reserved Tags 328 Section 9.1 describes the IANA registry of tag prefixes. Any prefix 329 not included in that registry is reserved for future use, but tags 330 starting with such a prefix are still valid tags. 332 5. Data Node Tag Management 334 Tags may be associated with a data node within a YANG module in a 335 number of ways. Typically, tags may be defined and associated at the 336 module design time, at implementation time without the need of a live 337 server, or via user administrative control. As the main consumers of 338 data node tags are users, users may also remove any tag from a live 339 server, no matter how the tag became associated with a data node 340 within a YANG module. 342 5.1. Module Design Tagging 344 A data node definition MAY indicate a set of data node tags to be 345 added by a module's implementer. These design time tags are 346 indicated using a set of extension statements which include: 348 opm-tag extension statement: Classifies management and operation 349 data into object, property, and metric three categories. Three 350 values (object, property and metric) are assigned to the 'opm-tag' 351 tag. 353 Data nodes that contain other data nodes can be one of type 354 'container', 'leaf-list', and 'list' and are tagged with the 355 'object' tag value. A data node tagged with the 'property' tag 356 value is a 'leaf' node. Data node tagged with the 'metric' tag 357 value can be one of 'container', 'leaf-list', 'list', or 'leaf' 358 data node. A data node contains one single 'object' tag, one 359 single 'property' tag, or one single 'metric' tag. Both 'object' 360 tag value and 'property' tag value are not inherited down the 361 containment hierarchy, e.g., if a container is marked with a 362 'object ' tag value, all its contained leaves don't inherit the 363 tag value. The 'metric' tag value is inherited down the 364 containment hierarchy if Data nodes tagged with the 'metric' tag 365 is one of 'container', 'leaf-list', 'list'. 367 A data node tagged with the 'metric' tag also can have one or 368 multiple Metric type tag and/or one single multi-source tag. See 369 the examples depicted in Figure 2 and Figure 4. 371 metric-type extension statement: Provides metric related data nodes 372 classifications (e.g., loss, jitter, delay, counter, gauge, 373 summary, unknown) for data nodes tagged with the 'metric' tag. 374 Data nodes tagged with the 'metric-type' tag can be one of 375 'container', 'leaf-list', 'list', or 'leaf' data node. The 376 'metric-type' tag is inherited down the containment hierarchy if 377 Data nodes tagged with the 'metric-type' tag is one of 378 'container', 'leaf-list', 'list'. Figure 6 provides a list of 379 possbile values for the 'metric-type' tag. 381 multi-source-tag extension statement: Identifies multi-source 382 aggregation type for data nodes tagged with the 'metric' tag. Two 383 values (i.e., aggregated, non-aggregated) are assigned to 'multi- 384 source-tag' tag. 386 The 'aggregated' multi-source aggregation type allows a large 387 number of measurements on metric subobjects from different sources 388 of the same type (e.g., line card, each subinterface of aggregated 389 Ethernet interface) to be combined into aggregated statistics and 390 report as one metric subobject. 392 The 'non-aggregated' multi-source aggregation type allows 393 measurement from each source of the same type (e.g., line card, 394 each subinterface of aggregated Ethernet interface) to be reported 395 separately. 397 Data nodes tagged with the 'multi-source-tag' tag can be one of 398 'container', 'leaf-list', 'list', or 'leaf' data node. The 399 'multi-source-tag' tag is inherited down the containment hierarchy 400 if Data nodes tagged with the 'multi-source-tag' tag is one of 401 'container', 'leaf-list', 'list'. 403 Among these extension statements, the 'metric-type' and 'multi- 404 source-tag' extension statements are context information that can be 405 used to correlate data nodes from the different modules. 407 If the data node is defined in an IETF Standards Track document, the 408 data node tags MUST be IETF Tags (Section 4.1). Thus, new data nodes 409 can drive the addition of new IETF tags to the IANA registry defined 410 in Section 9.2, and the IANA registry can serve as a check against 411 duplication. 413 5.2. Implementation Tagging 415 An implementation MAY include additional tags associated with data 416 nodes within a YANG module. These tags SHOULD be IETF ((i.e., 417 registered) ) or vendor tags. 419 5.3. User Tagging 421 data node tags of any kind, with or without a prefix, can be assigned 422 and removed by the user from a server using normal configuration 423 mechanisms. In order to remove a data node tag from the operational 424 datastore, the user adds a matching "masked-tag" entry for a given 425 data node within the 'ietf-data-node-tags' module. 427 6. Data Node Tags Module Structure 429 6.1. Data Node Tags Module Tree 431 The tree associated with the "ietf-data-node-tags" module is as 432 follows: 434 module: ietf-data-node-tags 435 augment /tags:module-tags/tags:module: 436 +--rw data-node-tags 437 +--rw data-node* [ni-id] 438 +--rw ni-id nacm:node-instance-identifier 439 +--rw tag* tags:tag 440 +--rw masked-tag* tags:tag 441 +--rw extended-tag-type? identityref 443 Figure 3: YANG Module Data Node Tags Tree Diagram 445 7. YANG Module 447 This module imports types from [RFC8819],[RFC8341]. 449 file "ietf-data-node-tags@2022-02-04.yang" 450 module ietf-data-node-tags { 451 yang-version 1.1; 452 namespace "urn:ietf:params:xml:ns:yang:ietf-data-node-tags"; 453 prefix ntags; 455 import ietf-netconf-acm { 456 prefix nacm; 457 reference 458 "RFC 8341: Network Configuration Access Control 459 Model"; 460 } 461 import ietf-module-tags { 462 prefix tags; 463 reference 464 "RFC 8819: YANG Module Tags "; 465 } 467 organization 468 "IETF NetMod Working Group (NetMod)"; 469 contact 470 "WG Web: 471 WG List: 473 Editor: Qin Wu 474 476 Editor: Benoit Claise 477 479 Editor: Peng Liu 480 482 Editor: Zongpeng Du 483 485 Editor: Mohamed Boucadair 486 "; 487 // RFC Ed.: replace XXXX with actual RFC number and 488 // remove this note. 489 description 490 "This module describes a mechanism associating data node 491 tags with YANG data node within YANG modules. Tags may be IANA 492 assigned or privately defined. 494 Copyright (c) 2022 IETF Trust and the persons identified as 495 authors of the code. All rights reserved. 497 Redistribution and use in source and binary forms, with or 498 without modification, is permitted pursuant to, and subject to 499 the license terms contained in, the Revised BSD License set 500 forth in Section 4.c of the IETF Trust's Legal Provisions 501 Relating to IETF Documents 502 (https://trustee.ietf.org/license-info). 504 This version of this YANG module is part of RFC XXXX 505 (https://datatracker.ietf.org/html/rfcXXXX); see the RFC itself 506 for full legal notices."; 508 // RFC Ed.: update the date below with the date of RFC publication 509 // and RFC number and remove this note. 510 revision 2022-02-04 { 511 description 512 "Initial revision."; 513 reference 514 "RFC XXXX: data node Tags in YANG Modules"; 515 } 516 identity other-data-property { 517 description 518 "Base identity for data property type."; 519 } 520 extension opm-tag { 521 argument tag; 522 description 523 "The argument 'tag' is of type 'tag'. This extension statement 524 is used by module authors to indicate the opm tags that should 525 be added automatically by the system. 'opm-tag' is used to 526 classify operation and management data nodes into the three 527 categories, object, property, and metric. A data node 528 tagged with 'object' tag can be one of container, leaf-list, or 529 list. A data node tagged is with the 'property' tag is a leaf 530 node. The data node tagged with the 'metric' tag can be one of 531 container, leaf-list, list, or leaf. A data nodes tagged 532 with either property tag or metric tag are child nodes 533 belonging to a specific root data node. Each data node may 534 contain one single 'object' tag, or one single 'property' tag, 535 or one single 'metric' tag (these tags are mutually 536 exclusive). As such, the origin of the value for the 537 pre-defined tags should be set to 'system'."; 538 } 540 extension metric-type { 541 argument tag; 542 description 543 "The argument 'tag' is of type 'tag'. The metric type can be 544 used to provide metric data node classification 545 (e.g., loss, jitter, packet loss, counter, gauge, 546 summary, unknown) within a YANG module.The initial values of 547 the 'metric-type' tag is defined in section 9.2, additional 548 metric-type tag value can be added in the future."; 549 } 551 extension multi-source-tag { 552 argument tag; 553 description 554 "The argument 'tag' is of type 'tag'. The multi-source-tag can 555 be used to identify multi-source aggregation type 556 (e.g., aggregated, non-aggregated) related to a metric 557 subobject. 559 The 'aggregated' multi-source aggregation type allows a large 560 number of measurements on metric subobjects from different 561 sources of the same type (e.g., line card, each subinterface of 562 an aggregated Ethernet interface) to be combined into 563 aggregated statistics and reported as one metric subobject 564 value. 566 The 'non-aggregated'multi-source aggregation type allows 567 measurement from each source of the same type (e.g., line 568 card, each subinterface of an aggregated Ethernet interface) to 569 be reported separately."; 570 } 572 augment "/tags:module-tags/tags:module" { 573 description 574 "Augment the Module Tags module with data node tag 575 attributes."; 576 container data-node-tags { 577 description 578 "Contains the list of data nodes and their associated data 579 object tags."; 580 list data-node { 581 key "ni-id"; 582 description 583 "Includes a list of data nodes and their associated data 584 object tags."; 585 leaf ni-id { 586 type nacm:node-instance-identifier; 587 mandatory true; 588 description 589 "The YANG data node name."; 590 } 591 leaf-list tag { 592 type tags:tag; 593 description 594 "Lists the tags associated with the data node within 595 the YANG module. 597 See the IANA 'YANG data node Tag Prefixes' registry 598 for reserved prefixes and the IANA 'IETF YANG Data 599 Object Tags' registry for IETF tags. 601 The 'operational' state view of this list is 602 constructed using the following steps: 604 1) System tags (i.e., tags of 'system' origin) are 605 added. 606 2) User configured tags (i.e., tags of 'intended' 607 origin) are added. 608 3) Any tag that is equal to a masked-tag is removed."; 609 reference 610 "RFC XXXX: data node Tags in YANG Data 611 Modules, Section 9"; 612 } 613 leaf-list masked-tag { 614 type tags:tag; 615 description 616 "The list of tags that should not be associated with the 617 data node within the YANG module. The user can remove 618 (mask) tags from the operational state datastore by 619 adding them to this list. It is not an error to add tags 620 to this list that are not associated with the data 621 object within YANG module, but they have no operational 622 effect."; 623 } 624 leaf extended-tag-type { 625 type identityref { 626 base other-data-property; 627 } 628 description 629 "Type of the extended tag. The extended tag type doesn't include opm tag, 630 metric-type tag and multi-source tag three types defined in 631 this document. The specific extended tag type and associated auxiliary data 632 are defined in the data node tags extension module."; 633 } 634 } 635 } 636 } 637 } 638 640 8. Guidelines to Model Writers 642 This section updates [RFC8407] by providing text that may be regarded 643 as a new subsection to Section 4 of that document. It does not 644 change anything already present in [RFC8407]. 646 8.1. Define Standard Tags 648 A module MAY indicate, using data node tag extension statements, a 649 set of data node tags that are to be automatically associated with 650 data node within the module (i.e., not added through configuration). 652 module example-module-A { 653 //... 654 import ietf-data-node-tags { prefix ntags; } 656 container top { 657 ntags:opm-tag "ietf:object"; 658 list X { 659 leaf foo { 660 ntags:opm-tag "ietf:property"; 661 } 662 leaf bar { 663 ntags:opm-tag "ietf:metric"; 664 } 665 } 666 } 667 // ... 668 } 670 Figure 4: An Example of Data Object Tag 672 The module writer can use existing standard data node tags, or use 673 new data node tags defined in the data node definition, as 674 appropriate. For IETF standardized modules, new data node tags MUST 675 be assigned in the IANA registry defined in Section 9.2. 677 9. IANA Considerations 679 9.1. YANG Data Object Tag Prefixes Registry 681 This document requests IANA to create "YANG data node Tag Prefixes" 682 subregistry in "YANG data node Tag" registry. 684 Prefix entries in this registry should be short strings consisting of 685 lowercase ASCII alpha-numeric characters and a final ":" character. 687 The allocation policy for this registry is Specification Required 688 [RFC8126]. The Reference and Assignee values should be sufficient to 689 identify and contact the organization that has been allocated the 690 prefix. There is no specific guidance for the Designated Expert and 691 there is a presumption that a code point should be granted unless 692 there is a compelling reason to the contrary. 694 The initial values for this registry are as follows: 696 +----------+----------------------------------+-----------+----------+ 697 | Prefix | Description | Reference | Assignee | 698 +----------+----------------------------------+-----------+----------+ 699 | ietf: | IETF Tags allocated in the IANA | [This | IETF | 700 | | IETF YANG data node Tags | document] | | 701 | | registry | | | 702 | | | | | 703 | vendor: | Non-registered tags allocated by | [This | IETF | 704 | | the module's implementer. | document] | | 705 | | | | | 706 | user: | Non-registered tags allocated by | [This | IETF | 707 | | and for the user. | document] | | 708 +----------+----------------------------------+-----------+----------+ 710 Figure 5: Table 1 712 Other standards organizations (SDOs) wishing to allocate their own 713 set of tags should request the allocation of a prefix from this 714 registry. 716 9.2. IETF YANG Data Object Tags Registry 718 This document requests IANA to create "IETF OPM Tags","IETF Metric 719 Type Tags","IETF Multiple Source Tags" three subregistries in "YANG 720 data node Tag" registry. These 3 subregistries appear below "YANG 721 data node Tag Prefixes" registry. 723 Three subregistries allocate tags that have the registered prefix 724 "ietf:". New values should be well considered and not achievable 725 through a combination of already existing IETF tags. 727 The allocation policy for these three subregistries is IETF Review 728 [RFC8126]. The Designated Expert is expected to verify that IANA 729 assigned tags conform to Net-Unicode as defined in [RFC5198], and 730 shall not need normalization. 732 The initial values for these three subregistries are as follows: 734 +----------------------------+--------------------------+-----------+ 735 | OPM Tag | Description | Reference | 736 +----------------------------+--------------------------+-----------+ 737 | ietf:object |Represents Root object | [This | 738 | |containing other data | document] | 739 | |objects (e.g., interfaces)| | 740 | | | | 741 | ietf:property |Represents a property | [This | 742 | |data node(e.g., ifindex) | document] | 743 | |associated with a specific| | 744 | |root object (e.g., | | 745 | |interfaces) | | 746 | | | | 747 | ietf:metric |Represent metric data | [This | 748 | |object(e.g., ifstatistics)| document] | 749 | |associated with specific | | 750 | |root object(e.g., | | 751 | |interfaces) | | 752 +----------------------------+--------------------------+-----------+ 753 +----------------------------+--------------------------+-----------+ 754 | Metric Type Tag | Description | Reference | 755 +----------------------------+--------------------------+-----------+ 756 | ietf:delay |Represents the delay metric | 757 | |group to which the metric | [This | 758 | |data nodes belong to. | document] | 759 | | | | 760 | ietf:jitter |Represents the jitter metric [This | 761 | |group to which the metric |document] | 762 | |data nodes belong to. | | 763 | | | | 764 | ietf:loss |Represents the loss metric| [This | 765 | |group to which the metric | document] | 766 | |data nodes belong to. | | 767 | | | | 768 | ietf:counter |Represents any metric value | 769 | |associated with a metric | | 770 | |data node that monotonically[This | 771 | |increases over time, | document] | 772 | |starting from zero. | | 773 | | | | 774 | ietf:gauge |Represents current | | 775 | |measurements associated | [This | 776 | |with a metric data node |document] | 777 | |that may increase, | | 778 | |decrease or stay constant.| | 779 | | | | 780 | ietf:summary |Represents the metric value [This | 781 | |associated with a metric | document] | 782 | |data node that measures | | 783 | |distributions of discrete | | 784 | |events without knowing | | 785 | |predefined range. | | 786 | | | | 787 | ietf:unknown |Represents the metric value [This | 788 | |associated with metric | document] | 789 | |data node that can not | | 790 | |determine the type of metric. | 791 +----------------------------+--------------------------+-----------+ 792 +----------------------------+--------------------------+-----------+ 793 | Multiple Source Tag | Description | Reference | 794 +----------------------------+--------------------------+-----------+ 795 |ietf:agg |Relates to multiple sources [This | 796 | |aggregation type (i.e., | document] | 797 | |aggregated statistics) | | 798 | | | | 799 |ietf:non-agg |Relates to multiple sources [This | 800 | |aggregation type (i.e., | document] | 801 | |non-aggregated statistics)| | 802 +----------------------------+--------------------------+-----------+ 804 Figure 6: Table 2 806 9.3. Updates to the IETF XML Registry 808 This document registers the following namespace URI in the "ns" 809 subregistry within the "IETF XML Registry" [RFC3688]: 811 URI: urn:ietf:params:xml:ns:yang:ietf-data-node-tags 812 Registrant Contact: The IESG. 813 XML: N/A; the requested URI is an XML namespace. 815 9.4. Updates to the YANG Module Names Registry 817 This document registers the following YANG module in the YANG Module 818 Names registry [RFC6020] within the "YANG Parameters" registry: 820 name: ietf-data-node-tags 821 namespace: urn:ietf:params:xml:ns:yang:ietf-data-node-tags 822 prefix: ntags 823 reference: RFC XXXX 824 maintained by IANA: N 826 10. Security Considerations 828 The YANG module specified in this document defines schema for data 829 that is designed to be accessed via network management protocols such 830 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 831 is the secure transport layer, and the mandatory-to-implement secure 832 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 833 is HTTPS, and the mandatory-to-implement secure transport is TLS 834 [RFC8446]. 836 The Network Configuration Access Control Model (NACM) [RFC8341] 837 provides the means to restrict access for particular NETCONF or 838 RESTCONF users to a preconfigured subset of all available NETCONF or 839 RESTCONF protocol operations and content, e.g., the presence of tags 840 may reveal information about the way in which data nodes are used and 841 therefore providing access to private information or revealing an 842 attack vector should be restricted. Note that appropriate privilege 843 and security levels need to be applied to the addition and removal of 844 user tags to ensure that a user receives the correct data. 846 This document adds the ability to associate data node tag with data 847 nodes or instances of data nodes within the YANG modules. This 848 document does not define any actions based on these associations, and 849 none are yet defined, and therefore it does not by itself introduce 850 any new security considerations. 852 Users of the data node tag meta-data may define various actions to be 853 taken based on the data node tag meta-data. These actions and their 854 definitions are outside the scope of this document. Users will need 855 to consider the security implications of any actions they choose to 856 define, including the potential for a tag to get 'masked' by another 857 user. 859 11. Acknowledgements 861 The authors would like to thank Ran Tao for his major contributions 862 to the initial modeling and use cases. 864 The authors would also like to acknowledge the comments and 865 suggestions received from Juergen Schoenwaelder, Andy Bierman, Lou 866 Berger,Jaehoon Paul Jeong, Wei Wang, Yuan Zhang, Ander Liu, YingZhen 867 Qu, Boyuan Yan, Adrian Farrel, and Mahesh Jethanandani. 869 12. Contributors 871 Liang Geng 872 Individual 873 32 Xuanwumen West St, Xicheng District 874 Beijing 10053 876 13. References 878 13.1. Normative References 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, 882 DOI 10.17487/RFC2119, March 1997, 883 . 885 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 886 DOI 10.17487/RFC3688, January 2004, 887 . 889 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 890 the Network Configuration Protocol (NETCONF)", RFC 6020, 891 DOI 10.17487/RFC6020, October 2010, 892 . 894 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 895 RFC 7950, DOI 10.17487/RFC7950, August 2016, 896 . 898 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 899 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 900 . 902 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 903 Writing an IANA Considerations Section in RFCs", BCP 26, 904 RFC 8126, DOI 10.17487/RFC8126, June 2017, 905 . 907 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 908 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 909 May 2017, . 911 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 912 Access Control Model", STD 91, RFC 8341, 913 DOI 10.17487/RFC8341, March 2018, 914 . 916 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 917 Documents Containing YANG Data Models", BCP 216, RFC 8407, 918 DOI 10.17487/RFC8407, October 2018, 919 . 921 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 922 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 923 . 925 [RFC8819] Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module 926 Tags", RFC 8819, DOI 10.17487/RFC8819, January 2021, 927 . 929 13.2. Informative References 931 [FCAPS] International Telecommunication Union, "X.700 : Management 932 framework for Open Systems Interconnection (OSI) for CCITT 933 applications", , September 1992, 934 . 936 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 937 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 938 . 940 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 941 Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010, 942 . 944 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 945 and A. Bierman, Ed., "Network Configuration Protocol 946 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 947 . 949 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 950 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 951 . 953 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 954 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 955 . 957 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 958 and R. Wilton, "Network Management Datastore Architecture 959 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 960 . 962 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 963 E., and A. Tripathy, "Subscription to YANG Notifications", 964 RFC 8639, DOI 10.17487/RFC8639, September 2019, 965 . 967 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 968 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 969 September 2019, . 971 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 972 "Handling Long Lines in Content of Internet-Drafts and 973 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 974 . 976 [RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG 977 Instance Data", RFC 9195, DOI 10.17487/RFC9195, February 978 2022, . 980 [RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules 981 Describing Capabilities for Systems and Datastore Update 982 Notifications", RFC 9196, DOI 10.17487/RFC9196, February 983 2022, . 985 Appendix A. Example: Additional Auxiliary Data Property Information 987 This section gives an example of how Auxiliary Data Property Module 988 could be defined. It demonstrates how auxiliary data property 989 configuration parameters can be conditionally augmented to the 990 generic data node list. The example is not intended as a complete 991 module for Auxiliary Data Property configuration. 993 module ex-auxiliary-data-property { 994 yang-version 1.1; 995 namespace "http://example.com/auxiliary-data-property"; 996 prefix "dp"; 998 import ietf-module-tags { 999 prefix tags; 1000 } 1001 import ietf-data-node-tags { 1002 prefix ntags; 1003 } 1004 identity critical { 1005 base ntags:other-data-property; 1006 description 1007 "Identity for critical data node tag type."; 1008 } 1009 augment "/tags:module-tags/tags:module/ntags:data-node-tags/ntags:data-node" { 1010 when 'derived-from-or-self(ntags:extended-tag-type, "dp:critical")'; 1011 leaf value { 1012 type string; 1013 description 1014 "The auxiliary information corresponding 1015 to data node instance tagged with 'critical' 1016 extended tag type."; 1017 } 1018 // other auxiliary data property config params, etc. 1019 } 1020 } 1022 Appendix B. Instance Level Tunnel Tagging Example 1024 In the example shown in Figure 2,the 'tunnel-svc' data node is a list 1025 node defined in a 'example-tunnel-pm' module and has 7 child nodes: 1026 'name','create-time','modified-time','average-latency','packet- 1027 loss','min-latency','max-latency' leaf node. In these child nodes, 1028 the 'name' leaf node is the key leaf for the 'tunnel-svc' list. 1029 Following is the tree diagram [RFC8340] for the "example-tunnel-pm" 1030 module: 1032 +--rw tunnel-svc* [name] 1033 | +--rw name string 1034 | +--ro create-time yang:date-and-time 1035 | +--ro modified-time yang:date-and-time 1036 | +--ro average-latency yang:gauge64 1037 | +--ro packet-loss yang:counter64 1038 | +--ro min-latency yang:gauge64 1039 | +--ro max-latency yang:gauge64 1041 To help identify specific data for a customer, users tags on specific 1042 instances of the data nodes are created as follows: 1044 1046 1048 ds:running 1049 1050 1051 1052 example-tunnel-pm 1053 1054 1055 1056 /tp:tunnel-svc[name='foo']/tp:packet-loss 1057 1058 user:customer1_example_com 1059 ietf:critical 1060 1061 1062 1063 /tp:tunnel-svc[name='bar']/tp:modified-time 1064 1065 user:customer2_example_com 1066 1067 1068 1069 1070 1071 1072 1074 Note that the 'ietf:critical' tag is addtional new tag value that 1075 needs to be allocated from "IETF Metric Type Tags" subregistry in 1076 section 9.2. 1078 Appendix C. NETCONF Example 1080 The following is a NETCONF example result from a query of the data 1081 node tags list. For the sake of brevity only a few module and 1082 associated data node results are provided. The example uses the 1083 folding defined in [RFC8792]. 1085 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1087 1088 1089 1090 ietf-interfaces 1091 1093 1094 /if:interfaces/if:interface 1095 ietf:object 1096 1097 1098 /if:interfaces/if:interface/if:last-change 1100 ietf:property 1101 1102 1103 1104 /if:interfaces/if:interface/if:statistics/if:in-errors 1105 1106 ietf:metric 1107 ietf:loss 1108 ietf:non-agg 1109 1110 1111 1112 1113 ietf-ip 1114 1116 1117 /if:interfaces/if:interface/ip:ipv4 1118 ietf:object 1119 1120 1121 /if:interfaces/if:interface/ip:ipv4/ip:enable\ 1122 1123 ietf:property 1124 1125 1126 /if:interfaces/if:interface/ip:ipv4/ip:mtu 1127 ietf:metric 1128 ietf:non-agg 1129 1130 1131 1132 1133 1135 Figure 7: Example NETCONF Query Output 1137 Appendix D. Non-NMDA State Module 1139 As per [RFC8407], the following is a non-NMDA module to support 1140 viewing the operational state for non-NMDA compliant servers. 1142 file "ietf-data-node-tags-state@2022-02-03.yang" 1143 module ietf-data-node-tags-state { 1144 yang-version 1.1; 1145 namespace 1146 "urn:ietf:params:xml:ns:yang:ietf-data-node-tags-state"; 1147 prefix ntags-s; 1149 import ietf-netconf-acm { 1150 prefix nacm; 1151 reference 1152 "RFC 8341: Network Configuration Access Control 1153 Model"; 1154 } 1155 import ietf-module-tags { 1156 prefix tags; 1157 } 1158 import ietf-module-tags-state { 1159 prefix tags-s; 1160 reference 1161 "RFC 8819: YANG Module Tags "; 1162 } 1163 organization 1164 "IETF NetMod Working Group (NetMod)"; 1166 contact 1167 "WG Web: 1168 WG List: 1170 Editor: Qin Wu 1171 1173 Editor: Benoit Claise 1174 1176 Editor: Peng Liu 1177 1179 Editor: Zongpeng Du 1180 1182 Editor: Mohamed Boucadair 1183 "; 1184 // RFC Ed.: replace XXXX with actual RFC number and 1185 // remove this note. 1186 description 1187 "This module describes a mechanism associating data node 1188 tags with YANG data node within YANG modules. Tags may be 1189 IANA assigned or privately defined. 1191 Copyright (c) 2022 IETF Trust and the persons identified as 1192 authors of the code. All rights reserved. 1194 Redistribution and use in source and binary forms, with or 1195 without modification, is permitted pursuant to, and subject 1196 to the license terms contained in, the Simplified BSD License 1197 set forth in Section 4.c of the IETF Trust's Legal Provisions 1198 Relating to IETF Documents 1199 (https://trustee.ietf.org/license-info). 1201 This version of this YANG module is part of RFC XXXX 1202 (https://datatracker.ietf.org/html/rfcXXXX); see the RFC 1203 itself for full legal notices."; 1205 // RFC Ed.: update the date below with the date of RFC publication 1206 // and RFC number and remove this note. 1207 revision 2022-02-04 { 1208 description 1209 "Initial revision."; 1210 reference 1211 "RFC XXXX: Data node Tags in YANG Data 1212 Modules"; 1213 } 1214 identity other-data-property { 1215 description 1216 "Base identity for data property type."; 1217 } 1218 augment "/tags-s:module-tags-state/tags-s:module" { 1219 description 1220 "Augments the Module Tags module with data node tag 1221 attributes."; 1223 container data-node-tags { 1224 config false; 1225 status deprecated; 1226 description 1227 "Contains the list of data nodes and their 1228 associated self describing tags."; 1229 list data-node { 1230 key "ni-id"; 1231 status deprecated; 1232 description 1233 "Lists the data nodes and their associated self 1234 describing tags."; 1235 leaf ni-id { 1236 type nacm:node-instance-identifier; 1237 mandatory true; 1238 status deprecated; 1239 description 1240 "The YANG data node name."; 1241 } 1242 leaf-list tag { 1243 type tags:tag; 1244 status deprecated; 1245 description 1246 "Tags associated with the data node within the 1247 YANG module. See the IANA 'YANG data node Tag 1248 Prefixes' registry for reserved prefixes and the 1249 IANA 'IETF YANG data node Tags'registry for 1250 IETF tags. 1252 The 'operational' state view of this list is 1253 constructed using the following steps: 1255 1) System tags (i.e., tags of 'system' origin) are 1256 added. 1257 2) User configured tags (i.e., tags of 'intended' 1258 origin) are added. 1259 3) Any tag that is equal to a masked-tag is removed."; 1260 reference 1261 "RFC XXXX: Data node Tags in YANG Data 1262 Modules, Section 9"; 1263 } 1264 leaf-list masked-tag { 1265 type tags:tag; 1266 status deprecated; 1267 description 1268 "The list of tags that should not be associated with the 1269 data node within the YANG module. The user can remove 1270 (mask) tags from the operational state datastore by 1271 adding them to this list. It is not an error to add 1272 tags to this list that are not associated with the 1273 data node within YANG module, but they have no 1274 operational effect."; 1275 } 1276 leaf extended-tag-type { 1277 type identityref { 1278 base other-data-property; 1279 } 1280 description 1281 "Type of the extended tag. The extended tag type doesn't 1282 include opm tag, metric-type tag and multi-source tag three 1283 types defined in this document. The specific extended tag 1284 type and associated auxiliary data are defined in the data 1285 node tags extension module."; 1286 } 1287 } 1288 } 1289 } 1290 } 1291 1293 Appendix E. Targeted Data Fetching Example 1295 The following provides targeted data node collection example which 1296 helps reduce amount of data to be fetched. The subscription "id" 1297 values of 22 used below is just an example. In production, the 1298 actual values of "id" might not be small integers. 1300 +-----------+ +-----------+ 1301 | Subscriber| | Publisher | 1302 +-----+-----+ +-----+-----+ 1303 | | 1304 | data Node Tagging Fetching | 1305 | (ni-id, opm-tag = metric) | 1306 |<-----------------------------------+ 1307 | | 1308 | establish-subscription | 1309 +----------------------------------->| 1310 | | 1311 | RPC Reply: OK, id = 22 | 1312 |<-----------------------------------+ 1313 | | 1314 | Notification Message (for 22) | 1315 |<-----------------------------------+ 1316 | | 1318 The subscriber fetches data node tag information from the provider 1319 using 'get-schema' operation. The data node tag information instruct 1320 the receiver to subscribe tagged data node (e.g., performance metric 1321 data nodes) using standard subscribed notification mechanism 1322 [RFC8639]. 1324 Figure 8 illustrates the retrieval of the list of available target 1325 data nodes using the YANG instance file format [RFC9195]: 1327 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1329 1330 1332 acme-router-notification-capabilities 1333 1334 ietf-system-capabilities@2020-03-23 1335 ietf-notification-capabilities@2020-03-23 1336 ietf-data-export-capabilities@2020-03-23 1337 1338 1339 Defines the notification capabilities of an 1340 acme-router.The router only has running, and operational 1341 datastores. Every change can be reported on-change from 1342 running, but only config=true nodes and some config=false data 1343 from operational. Statistics are not reported based on timer 1344 based trigger and counter threshold based trigger. 1345 1346 1347 1349 1350 ietf-interfaces 1351 1353 1354 /if:interfaces/if:interface/if:in-errors 1355 ietf:metric 1356 ietf:loss 1357 1358 1359 1360 1361 1363 Figure 8: List of Available Target Objects 1365 With data node tag information carried in the operation, 1366 the subscriber identifies targeted data node and associated data path 1367 to the datastore node and sends a standard establish-subscription RPC 1368 [RFC8639] to subscribe tagged data nodes that are interests to the 1369 client application from the publisher. Alternatively, the subscriber 1370 can query data node tag list from somewhere (e.g., the network 1371 device, or offline document) using ietf-data-node-tags module defined 1372 in this document and fetch tagged data nodes and associated data path 1373 to the datastore node and sends a standard establish-subscription RPC 1374 [RFC8639] to subscribe tagged data nodes that are interests to the 1375 client application from the publisher. 1377 =============== NOTE: '\' line wrapping per RFC 8792 ================ 1379 1381 1385 1387 ds:operational 1388 1389 1391 /if:interfaces/if:interface/if:statistics/if:in-errors 1392 1393 1394 500 1395 1396 1397 1399 The publisher returns specific object types of operational state 1400 (e.g., in-errors statistics data) subscribed by the client. 1402 Appendix F. Changes between Revisions 1404 Editorial Note (To be removed by RFC Editor) 1406 v06 - v07 1408 * Update use case in section 3 to remove object and subobject 1409 concept and massive related words. 1411 * Change the title into Data Node Tags in YANG Modules. 1413 * Update Model Tag design in section 5.1 based on Balazs's comments. 1415 * Add Instance level tunnel tagging example in the Appendix. 1417 * Add 'type' parameter in the base model and add one more model 1418 extension example in the Appendix. 1420 * Other Appendix Updates. 1422 v05 - v06 1424 * Additional Editorial changes; 1426 * Use the folding defined in [RFC8792]. 1428 v04 - v05 1430 * Add user tag formating clarification; 1432 * Provide guidance to the Designated Expert for evaluation of YANG 1433 data node Tag registry and YANG data node Tag prefix registry. 1435 * Update the figure 1 and figure 2 with additional tags. 1437 * Security section enhancement for user tag managment. 1439 * Change data node name into name in the module. 1441 * Other Editorial changes to address Adrian's comments and comments 1442 during YANG docotor review. 1444 * Open issue: Are there any risks associated with an attacker adding 1445 or removing tags so that a requester gets the wrong data? 1447 v03 - v04 1449 * Remove histogram metric type tag from metric type tags. 1451 * Clarify the object tag and property tag,metric tag are mutual 1452 exlusive. 1454 * Clarify to have two optional node tags (i.e.,object tag and 1455 property tag) to indicate relationship between data nodes. 1457 * Update targeted data node collection example. 1459 v02 - v03 1460 * Additional Editorial changes. 1462 * Security section enhancement. 1464 * Nits fixed. 1466 v01 - v02 1468 * Clarify the relation between data node, object tag, property tag 1469 and metric tag in figure 1 and figure 2 and related description; 1471 * Change Metric Group into Metric Type in the YANG model; 1473 * Add 5 metric types in section 7.2; 1475 v00 - v01 1477 * Merge data node tag use case section into introduction section as 1478 a subsection; 1480 * Add one glossary section; 1482 * Clarify the relation between data node, object tag, property tag 1483 and metric tag in data node Tags Use Case section; 1485 * Add update to RFC8407 in the front page. 1487 Authors' Addresses 1489 Qin Wu 1490 Huawei 1491 101 Software Avenue, Yuhua District 1492 Nanjing 1493 Jiangsu, 210012 1494 China 1495 Email: bill.wu@huawei.com 1497 Benoit Claise 1498 Huawei 1499 De Kleetlaan 6a b1 1500 1831 Diegem 1501 Belgium 1502 Email: benoit.claise@huawei.com 1503 Peng Liu 1504 China Mobile 1505 32 Xuanwumen West St, Xicheng District 1506 Beijing 1507 Email: liupengyjy@chinamobile.com 1509 Zongpeng Du 1510 China Mobile 1511 32 Xuanwumen West St, Xicheng District 1512 Beijing 1513 Email: duzongpeng@chinamobile.com 1515 Mohamed Boucadair 1516 Orange 1517 35000 Rennes 1518 France 1519 Email: mohamed.boucadair@orange.com