idnits 2.17.1 draft-ietf-netmod-node-tags-00.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 63 instances of too long lines in the document, the longest one being 19 characters in excess of 72. -- The draft header indicates that this document updates RFC8407, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 377 has weird spacing: '...ct-name nac...' == Line 460 has weird spacing: '...dentify multi...' == Line 618 has weird spacing: '...present a pro...' == Line 904 has weird spacing: '...dentify multi...' -- The document date (December 28, 2020) is 1186 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) == Missing Reference: 'I-D.netconf-notification-capabilities' is mentioned on line 137, but not defined == Missing Reference: 'I-D.ietf-netmod-yang-instance-file-format' is mentioned on line 1007, but not defined Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group Q. Wu 3 Internet-Draft Huawei 4 Updates: 8407 (if approved) B. Claise 5 Intended status: Standards Track Cisco 6 Expires: July 1, 2021 L. Geng 7 Z. Du 8 China Mobile 9 M. Boucadair 10 Orange 11 December 28, 2020 13 Self Describing Data Object Tags 14 draft-ietf-netmod-node-tags-00 16 Abstract 18 This document defines a method to tag data objects associated with 19 operation and management data in YANG Modules. This YANG data object 20 tagging method can be used to classify data objects from different 21 YANG modules and identify characteristics data. It also can provide 22 input, instruction, indication to selection filter and filter queries 23 of operational state on a server during a "pub/sub" service for YANG 24 datastore updates. When the state of all subscriptions of a 25 particular Subscriber to be fetched is huge, the amount of data to be 26 streamed out to the destination can be greatly reduced and only 27 targeted to the characteristics data. These data object tags may be 28 registered as well as assigned during the module definition; assigned 29 by implementations; or dynamically defined and set by users. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 1, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Self Describing Data Object Tags Use Case . . . . . . . . 4 67 1.1.1. Massive Data Object Collection . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 2. Data Object Tag Values . . . . . . . . . . . . . . . . . . . 6 70 2.1. IETF Tags Prefix . . . . . . . . . . . . . . . . . . . . 7 71 2.2. Vendor Tags Prefix . . . . . . . . . . . . . . . . . . . 7 72 2.3. User Tags Prefix . . . . . . . . . . . . . . . . . . . . 7 73 2.4. Reserved Tags Prefix . . . . . . . . . . . . . . . . . . 7 74 3. Data Object Tag Management . . . . . . . . . . . . . . . . . 7 75 3.1. Module Design Tagging . . . . . . . . . . . . . . . . . . 8 76 3.2. Implementation Tagging . . . . . . . . . . . . . . . . . 8 77 3.3. User Tagging . . . . . . . . . . . . . . . . . . . . . . 9 78 4. Data Object Tags Module Structure . . . . . . . . . . . . . . 9 79 4.1. Data Object Tags Module Tree . . . . . . . . . . . . . . 9 80 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 12 82 6.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 12 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 7.1. YANG Data Object Tag Prefixes Registry . . . . . . . . . 13 85 7.2. IETF YANG Data Object Tags Registry . . . . . . . . . . . 14 86 7.3. Updates to the IETF XML Registry . . . . . . . . . . . . 16 87 7.4. Updates to the YANG Module Names Registry . . . . . . . . 16 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 92 10.2. Informative References . . . . . . . . . . . . . . . . . 17 93 Appendix A. NETCONF Example . . . . . . . . . . . . . . . . . . 18 94 Appendix B. Non-NMDA State Module . . . . . . . . . . . . . . . 19 95 Appendix C. Targeted data object collection example . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 98 1. Introduction 100 As described in [I.D-ietf-netmod-module-tags], the use of tags for 101 classification and organization is fairly ubiquitous not only within 102 IETF protocols, but in the internet itself (e.g., "#hashtags"). A 103 module tag defined in [I.D-ietf-netmod-module-tags] is a string 104 associated only with a module name at module level. 106 At the time of writing this document (2020), there are many data 107 models that have been specified or are being specified by various 108 different SDOs and Open Souce community. They cover many of the 109 networking protocols and techniques. However data objects defined by 110 these technology specific data models might represent a portion of 111 fault, configuration, accounting, performance, security management 112 categories information at different locations in various different 113 ways, lack consistent classification criteria and representation for 114 a specific service, feature or data source. 116 This document defines self-describing data object tags and associates 117 them with data objects within YANG module, which 119 o Provide dictionary meaning for specific targeted data objects; 121 o Indicate relationship between data objects within the same YANG 122 module or from different YANG modules; 124 o Identify key performance metric data objects and the absolute 125 XPath expression identifying the element path to the node; 127 The self describing data object tags can be used by the client to 128 classify data objects from different YANG modules and identify 129 characteristics data. In addition, it can provide input, 130 instruction, indication to selection filter and filter queries of 131 configuration or operational state on a server based on these data 132 object tags, .e.g., return specific object type of operational state 133 related to system-management. NETCONF clients can discover data 134 objects with self describing data object tags supported by a NETCONF 135 server via operation. The self describing data object 136 tag capability can also be advertised via Capability Notification 137 Model [I-D.netconf-notification-capabilities] by the NETCONF server 138 or some place where offline document are kept. These data object 139 tags may be registered as well as assigned during the module 140 definition; assigned by implementations; or dynamically defined and 141 set by users. 143 This document defines a YANG module [RFC7950] which augments module 144 tag model and provides a list of data object entries to allow for 145 adding or removing of self describing tags as well as viewing the set 146 of self describing tags associated with specific data objects within 147 YANG modules. 149 This document defines an extension statement to be used to indicate 150 self describing tags that SHOULD be added by the module 151 implementation automatically (i.e., outside of configuration). 153 This document also defines an IANA registry for tag prefixes as well 154 as a set of globally assigned tags. 156 Section 6 provides guidelines for authors of YANG data models. 158 The YANG data model in this document conforms to the Network 159 Management Datastore Architecture defined in [RFC8342]. 161 1.1. Self Describing Data Object Tags Use Case 163 1.1.1. Massive Data Object Collection 165 Among data object tags, the opm (object, property subobject, metric 166 subobject) tags can be used to tackle massive data objects collection 167 and only capture YANG data objects associated with performance 168 metrics data modelled with YANG (See Figure 1). 170 /-----\ /-----\ 171 /Property\ /Property\ 172 |Subobject+------+ +-------+Subobject| 173 \ A / | | \ B / 174 +- ---+ +--V-------------V-+ ----- +---------------+ 175 | YANG Data Node | | YANG Data Node| 176 | /Data Object 1 |-------------------| /Data Object 3| 177 /---\ +--^-------------^-+ /---\ +-------^-------+ 178 Metric\ | | | Metric | 179 |Subobject------+ | +--------|Subobject /--+-\ 180 \ C / | \ D / Property 181 \-+-/ | \-+-/ |Subobject 182 | +------+ | \ G / 183 | |Metric+----+ \----/ 184 | |Group |----+ 185 /----\ | +------+ | 186 Property | | 187 |Subobject | | 188 \ E / | | 189 \--+-/ | /----\ 190 | +-------------------+ /Metric\ 191 | | YANG Data Node <-------|Subobject 192 +---> /Data Object 2 | \ F / 193 +-------------------+ \----/ 195 Figure 1: The Relation between Object, Property and Metric 197 In Figure 1, object can contain other objects called subobjects. 198 Property and metric objects are both subobjects belonging to specific 199 object. Both object and subobjects can be modeled as YANG data nodes 200 [RFC7950]. Object can be one of container, leaf-list and list. 201 Property subobject is a leaf node. Metric subobject can be one of 202 container, leaf-list, list, leaf node. Object contains zero or many 203 property subobjects, zero or many metric subobjects. 205 The use of opm tags would be to help filter discrete categories of 206 YANG data objects scattered across the same or different YANG modules 207 supported by a device and capture all network performance data or all 208 property data in the single view of the truth (see Figure 2). In 209 Figure 2, tunnel-svc data object is a container node in the tunnel-pm 210 module and can be seen as the root object for property subobjects 211 (e.g., tunnel-svc/create-time) and metric subobjects (e.g.,tunnel- 212 svc/avg-latency). Name, create-time, modified-time are property 213 subobjects under tunnel-svc container. Avg-latency,packet loss are 214 metric subobjects under tunnel-svc container node. In addition, not 215 all metric subobjects need to be tagged, e.g., only specific category 216 (e.g., loss related) metric subobjects need to be tagged with metric- 217 group tag which can further reduce amount data to be fetched. 219 +------------------------+--------------------------------------------+ 220 | Data | Object Property Metric Module | 221 | Object | Tag Subobject Subobject Name | 222 | | Tag Tag | 223 +------------------------+--------------------------------------------+ 224 | | ietf: | 225 |tunnel-svc | object tunnel-pm| 226 | | ietf: | 227 |tunnel-svc/name | property tunnel-pm| 228 | | ietf: | 229 |tunnel-svc/create-time | property tunnel-pm| 230 | | ietf: | 231 |tunnel-svc/modified-time| property tunnel-pm| 232 | | | 233 |tunnel-svc/avg-latency | ietf: tunnel-pm| 234 | | metric | 235 |tunnel-svc/packet-loss | ietf: tunnel-pm| 236 | | metric | 237 |tunnel-svc/min-latency | ietf: tunnel-pm| 238 | | metric | 239 |tunnel-svc/ max-latency | ietf: tunnel-pm| 240 | | metric | 241 +------------------------+--------------------------------------------+ 243 Figure 2: Example of OPM Tags Used in the YANG Module 245 If data objects in these YANG modules are suitably tagged and learnt 246 by the client from a live server, the client can retrieve paths to 247 all targeted data objects and then use an XPath query defined 248 [RFC8639] [RFC8641] to list all tagged data objects which reflect 249 network characteristics 251 1.2. Terminology 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 255 "OPTIONAL" in this document are to be interpreted as described in BCP 256 14 [RFC2119] [RFC8174] when, and only when, they appear in all 257 capitals, as shown here. 259 2. Data Object Tag Values 261 All data object tags SHOULD begin with a prefix indicating who owns 262 their definition. An IANA registry (Section 7.1) is used to support 263 registering data object tag prefixes. Currently 3 prefixes are 264 defined. 266 No further structure is imposed by this document on the value 267 following the registered prefix, and the value can contain any YANG 268 type 'string' characters except carriage-returns, newlines and tabs. 269 Therefore, designers, implementers, and users are free to add or not 270 add any structure they may require to their own tag values. 272 2.1. IETF Tags Prefix 274 An IETF tag is a data object tag that has the prefix "ietf:". All 275 IETF data object tags are registered with IANA in a registry defined 276 later in this document (Section 7.2). 278 2.2. Vendor Tags Prefix 280 A vendor tag is a tag that has the prefix "vendor:". These tags are 281 defined by the vendor that implements the module, and are not 282 registered; however, it is RECOMMENDED that the vendor include extra 283 identification in the tag to avoid collisions such as using the 284 enterprise or organization name following the "vendor:" prefix (e.g., 285 vendor:vendor-defined-classifier). 287 2.3. User Tags Prefix 289 A user tag is any tag that has the prefix "user:". These tags are 290 defined by the user/administrator and are not meant to be registered. 291 Users are not required to use the "user:" prefix; however, doing so 292 is RECOMMENDED as it helps avoid prefix collisions. 294 2.4. Reserved Tags Prefix 296 Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is 297 reserved for future use. These tag values are not invalid, but 298 simply reserved in the context of specifications (e.g., RFCs). 300 3. Data Object Tag Management 302 Tags can become associated with a data object within YANG module in a 303 number of ways. Tags may be defined and associated at the module 304 design time, at implementation time without the need of live server, 305 or via user administrative control . As the main consumer of data 306 object tags are users, users may also remove any tag from a live 307 server, no matter how the tag became associated with a data object 308 within a YANG module. 310 3.1. Module Design Tagging 312 A data object definition MAY indicate a set of data object tags to be 313 added by the module implementer. These design time tags are 314 indicated using a set of extension statements which include: 316 opm-tag extension statement: Classify management and operation data 317 into object, property subobject and metric subobject three 318 categories. Object can contain other objects called subobjects. 319 Property and metric objects are both subobjects belonging to 320 specific object. Both object and subobjects can be modeled as 321 data nodes [RFC7950]. Object can be one of container, leaf-list 322 and list. Property subobject is a leaf node. Metric subobject 323 can be one of container, leaf-list, list, leaf. Object contains 324 zero or many property subobjects, zero or many metric subobjects. 325 See opm-tag example in Figure 2 and Figure 3. 327 metric-group extension statement: Provide meric subobjects 328 classification (e.g., loss, jitter, delay) within the YANG module. 330 multi-source-tag extension statement: Identify multi-source 331 aggregation type (e.g., aggregated, non-aggregated) related to 332 metric subobject. 'aggregated' multi-source aggregation type 333 allows a large number of measurements on metric subobjects from 334 different sources of the same type (e.g.,line card, each 335 subinterface of aggregated Ethernet interface) being combined into 336 aggregated statistics and report as one metric subobject. 'non- 337 aggregated' multi-source aggregation type allows measurement from 338 each source of the same type (e.g.,line card, each subinterface of 339 aggregated Ethernet interface) be reported separately. 341 Among these extension statements, the metric-group, multi-source-tag 342 extension statements are context information related and can be used 343 to correlate data object from the different modules. 345 If the data node is defined in an IETF standards track document, the 346 data object tags MUST be IETF Tags (2.1). Thus, new data object can 347 drive the addition of new IETF tags to the IANA registry defined in 348 Section 7, and the IANA registry can serve as a check against 349 duplication. 351 3.2. Implementation Tagging 353 An implementation MAY include additional tags associated with data 354 object within a YANG module. These tags SHOULD be IETF Tags (i.e., 355 registered) or vendor specific tags. 357 3.3. User Tagging 359 Data object tags of any kind, with or without a prefix, can be 360 assigned and removed by the user from a live server using normal 361 configuration mechanisms. In order to remove a data object tag from 362 the operational datastore, the user adds a matching "masked-tag" 363 entry for a given data object within the ietf-data-object-tags 364 Module. 366 4. Data Object Tags Module Structure 368 4.1. Data Object Tags Module Tree 370 The tree associated with the "ietf-data-object-tags" module follows. 371 The meaning of the symbols can be found in [RFC8340]. 373 module: ietf-data-object-tags 374 augment /tags:module-tags/tags:module: 375 +--rw data-object-tags 376 +--rw data-object* [object-name] 377 +--rw object-name nacm:node-instance-identifier 378 +--rw tag* tags:tag 379 +--rw masked-tag* tags:tag 381 5. YANG Module 383 file "ietf-data-object-tags@2019-05-03.yang" 384 module ietf-data-object-tags { 385 yang-version 1.1; 386 namespace "urn:ietf:params:xml:ns:yang:ietf-data-object-tags"; 387 prefix ntags; 389 import ietf-netconf-acm { 390 prefix nacm; 391 } 392 import ietf-module-tags { 393 prefix tags; 394 } 396 organization 397 "IETF NetMod Working Group (NetMod)"; 398 contact 399 "WG Web: 400 WG List: 401 Editor: Qin Wu 402 Editor: Benoit Claise 403 Editor: Liang Geng 404 Editor: Zongpeng Du 405 Editor: Mohamed Boucadair "; 406 description 407 "This module describes a mechanism associating self-describing 408 tags with YANG data object within YANG modules. Tags may be IANA 409 assigned or privately defined. 411 Copyright (c) 2020 IETF Trust and the persons identified as 412 authors of the code. All rights reserved. 414 Redistribution and use in source and binary forms, with or 415 without modification, is permitted pursuant to, and subject to 416 the license terms contained in, the Simplified BSD License set 417 forth in Section 4.c of the IETF Trust's Legal Provisions 418 Relating to IETF Documents 419 (https://trustee.ietf.org/license-info). 421 This version of this YANG module is part of RFC XXXX 422 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 423 full legal notices."; 425 revision 2019-05-03 { 426 description 427 "Initial revision."; 428 reference 429 "RFC XXXX: YANG Data Object Tags"; 430 } 432 extension opm-tag { 433 argument tag; 434 description 435 "The argument 'tag' is of type 'tag'. This extension statement 436 is used by module authors to indicate the opm tags that SHOULD be 437 added automatically by the system. Opm Tag is used to classify 438 operation and management data into object, property subobject, and metric 439 subobject three categories. Object can contain other objects called subobjects. 440 Property and metric objects are both subobjects belonging to specific object. 441 Both object and subobjects can be modeled as data nodes. Object can be one of 442 container, leaf-list and list. Property subobject is a leaf node. Metric subobject 443 can be one of container, leaf-list, list, leaf. Object contains zero or many 444 property subobjects, zero or many metric subobjects. As such the origin of the 445 value for the pre-defined tags should be set to 'system'[RFC8342]."; 446 } 448 extension metric-group { 449 argument tag; 450 description 451 "The argument 'tag' is of type 'tag'.The metric-group can be 452 used to provide metric subobject classification 453 (e.g., loss, jitter, packet loss) within the YANG module."; 454 } 456 extension multi-source-tag { 457 argument tag; 458 description 459 "The argument 'tag' is of type 'tag'.The multi-source-tag can be 460 used to identify multi-source aggregation type (e.g., aggregated, 461 non-aggregated) related to metric subobject. 463 'aggregated' multi-source aggregation type allows a large number of 464 measurements on metric subobjects from different sources of the same 465 type (e.g.,line card, each subinterface of aggregated Ethernet interface) 466 being combined into aggregated statistics and report as one metric subobject 467 value. 'non-aggregated' multi-source aggregation type allows measurement from 468 each source of the same type (e.g.,line card, each subinterface of aggregated 469 Ethernet interface) be reported separately."; 470 } 472 augment "/tags:module-tags/tags:module" { 473 description 474 "Augment the Module Tags module with data object tag attributes"; 475 container data-object-tags { 476 description 477 "Contains the list of data objects and their associated data object tags"; 478 list data-object { 479 key "object-name"; 480 description 481 "A list of data objects and their associated data object tags"; 482 leaf object-name { 483 type nacm:node-instance-identifier; 484 mandatory true; 485 description 486 "The YANG data object name."; 487 } 488 leaf-list tag { 489 type tags:tag; 490 description 491 "Tags associated with the data object within the YANG module. See 492 the IANA 'YANG Data Object Tag Prefixes' registry for reserved 493 prefixes and the IANA'IETF YANG Data Object Tags' registry for 494 IETF tags. 496 The 'operational' state [RFC8342] view of this list is 497 constructed using the following steps: 499 1) System tags (i.e., tags of 'system' origin) are added. 500 2) User configured tags (i.e., tags of 'intended' origin) 501 are added. 502 3) Any tag that is equal to a masked-tag is removed."; 503 } 504 leaf-list masked-tag { 505 type tags:tag; 506 description 507 "The list of tags that should not be associated with the data 508 object within the YANG module. The user can remove (mask) tags from the 509 operational state datastore [RFC8342] by adding them to 510 this list. It is not an error to add tags to this list 511 that are not associated with the data object within YANG module, 512 but they have no operational effect."; 513 } 514 } 515 } 516 } 517 } 518 520 6. Guidelines to Model Writers 522 This section updates [RFC8407]. 524 6.1. Define Standard Tags 526 A module MAY indicate, using data object tag extension statements, a 527 set of data object tags that are to be automatically associated with 528 data object within the module (i.e., not added through 529 configuration). 531 module example-module-A { 532 //... 533 import ietf-data-node-tags { prefix ntags; } 534 container top { 535 ntags:opm-tag "ietf:object"; 536 list X { 537 leaf foo { 538 ntags:opm-tag "ietf:property"; 539 } 540 } 541 container Y { 542 leaf bar { 543 ntags:opm-tag "ietf:metric"; 544 } 545 } 546 } 547 // ... 548 } 550 Figure 3: Data object tag example 552 The module writer can use existing standard data object tags, or use 553 new data object tags defined in the data object definition, as 554 appropriate. For IETF standardized modules, new data object tags 555 MUST be assigned in the IANA registry defined below, see 556 Section Section 7.2. 558 7. IANA Considerations 560 7.1. YANG Data Object Tag Prefixes Registry 562 IANA is asked to create a new registry "YANG Data Object Tag 563 Prefixes" grouped under a new "Protocol" category named "YANG Data 564 Object Tag Prefixes". 566 This registry allocates tag prefixes. All YANG Data Object Tags 567 SHOULD begin with one of the prefixes in this registry. 569 Prefix entries in this registry should be short strings consisting of 570 lowercase ASCII alpha-numeric characters and a final ":" character. 572 The allocation policy for this registry is Specification Required 573 [RFC8126]. The Reference and Assignee values should be sufficient to 574 identify and contact the organization that has been allocated the 575 prefix. 577 The initial values for this registry are as follows. 579 +----------+----------------------------------+-----------+----------+ 580 | Prefix | Description | Reference | Assignee | 581 +----------+----------------------------------+-----------+----------+ 582 | ietf: | IETF Tags allocated in the IANA | [This | IETF | 583 | | IETF YANG Data Object Tags registry document]| | 584 | | | | | 585 |vendor: | Non-registered tags allocated by | [This | IETF | 586 | | the module implementer. | document] | | 587 | | | | | 588 | user: | Non-registered tags allocated by | [This | IETF | 589 | | and for the user. | document] | | 590 +----------+----------------------------------+-----------+----------+ 592 Other standards organizations (SDOs) wishing to allocate their own 593 set of tags should allocate a prefix from this registry. 595 7.2. IETF YANG Data Object Tags Registry 597 IANA is asked to create 3 new registries "IETF OPM Tags","IETF Metric 598 Group Tags","IETF Multiple Source Tags" grouped under a new 599 "Protocol" category. These 3 registries should be included below 600 "YANG Data Object Tag Prefixes" when listed on the same page. 602 3 registries allocate tags that have the registered prefix "ietf:". 603 New values should be well considered and not achievable through a 604 combination of already existing IETF tags. 606 The allocation policy for these three registries is IETF Review 607 [RFC8126]. 609 The initial values for these three registries are as follows. 611 +----------------------------+--------------------------+-----------+ 612 | OPM Tag | Description | Reference | 613 +----------------------------+--------------------------+-----------+ 614 | | | | 615 | ietf:object |Represent specific object | [This | 616 | |type(e.g., interfaces). | document] | 617 | | | | 618 | ietf:property |Represent a property | [This | 619 | |subobject (e.g.,ifindex) | document] | 620 | |assoiciated with specific | | 621 | |object (e.g.,interfaces). | | 622 | | | | 623 | ietf:metric |Represent metric subobject| [This | 624 | |(e.g., ifstatistics) | document] | 625 | |associated with specific | | 626 | | object(e.g.,interfaces) | | 627 +----------------------------+--------------------------+-----------+ 628 +----------------------------+--------------------------+-----------+ 629 | Metric Group Tag | Description | Reference | 630 +----------------------------+--------------------------+-----------+ 631 | ietf:delay |Represent the metric group| [This | 632 | |which metric subobjects | document] | 633 | |belong to (i.e., delay) | | 634 | | | | 635 | ietf:jitter |Represent the metric group| [This | 636 | |which metric subobjects |document] | 637 | |belong to (i.e., jitter) | | 638 | | | | 639 | ietf:loss |Represent the metric group| [This | 640 | |which metric subobjects | document] | 641 | |belong to (i.e.,loss) | | 642 +----------------------------+--------------------------+-----------+ 643 +----------------------------+--------------------------+-----------+ 644 | Multiple Source Tag | Description | Reference | 645 +----------------------------+--------------------------+-----------+ 646 |ietf:non-agg |Relate to multiple source | [This | 647 | |aggregation type(i.e., | document] | 648 | |aggregated statistics) | | 649 | | | | 650 |ietf:agg |Relate to multiple source | [This | 651 | |aggregation type(i.e., non| document] | 652 | |aggregated statistics) | | 653 +----------------------------+--------------------------+-----------+ 655 Each YANG data object can have one opm tag, zero or one metric-group 656 tag, zero or one multi-source tag. 658 7.3. Updates to the IETF XML Registry 660 This document registers a URI in the "IETF XML Registry" [RFC3688]. 661 Following the format in [RFC3688], the following registration has 662 been made: 664 URI: 665 urn:ietf:params:xml:ns:yang:ietf-data-object-tags 666 Registrant Contact: 667 The IESG. 668 XML: 669 N/A; the requested URI is an XML namespace. 671 7.4. Updates to the YANG Module Names Registry 673 This document registers one YANG module in the "YANG Module Names" 674 registry [RFC6020]. Following the format in [RFC6020], the following 675 registration has been made: 677 name: 678 ietf-data-object-tags 679 namespace: 680 urn:ietf:params:xml:ns:yang:ietf-data-object-tags 681 prefix: 682 ntags 683 reference: 684 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 685 this note.) 687 8. Security Considerations 689 The YANG module defined in this memo is designed to be accessed via 690 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 691 secure transport layer and the mandatory-to-implement secure 692 transport is SSH [RFC6242]. 694 This document adds the ability to associate data object tag meta-data 695 with data object within the YANG modules. This document does not 696 define any actions based on these associations, and none are yet 697 defined, and therefore it does not by itself introduce any new 698 security considerations. 700 Users of the data object tag meta-data may define various actions to 701 be taken based on the data object tag meta-data. These actions and 702 their definitions are outside the scope of this document. Users will 703 need to consider the security implications of any actions they choose 704 to define. 706 9. Acknowledgements 708 The authors would like to thank Ran Tao for his major contributions 709 to the initial modeling and use cases. The authors would also like 710 to acknowledge the comments and suggestions received from Juergen 711 Schoenwaelder, Andy Bierman, Lou Berger,Jaehoon Paul Jeong, Wei Wang, 712 Yuan Zhang, Ander Liu, Peng Liu, YingZhen Qu, Boyuan Yan. 714 10. References 716 10.1. Normative References 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, 720 DOI 10.17487/RFC2119, March 1997, 721 . 723 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 724 RFC 7950, DOI 10.17487/RFC7950, August 2016, 725 . 727 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 728 Writing an IANA Considerations Section in RFCs", BCP 26, 729 RFC 8126, DOI 10.17487/RFC8126, June 2017, 730 . 732 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 733 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 734 May 2017, . 736 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 737 and R. Wilton, "Network Management Datastore Architecture 738 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 739 . 741 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 742 Documents Containing YANG Data Models", BCP 216, RFC 8407, 743 DOI 10.17487/RFC8407, October 2018, 744 . 746 10.2. Informative References 748 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 749 DOI 10.17487/RFC3688, January 2004, 750 . 752 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 753 the Network Configuration Protocol (NETCONF)", RFC 6020, 754 DOI 10.17487/RFC6020, October 2010, 755 . 757 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 758 and A. Bierman, Ed., "Network Configuration Protocol 759 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 760 . 762 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 763 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 764 . 766 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 767 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 768 . 770 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 771 E., and A. Tripathy, "Subscription to YANG Notifications", 772 RFC 8639, DOI 10.17487/RFC8639, September 2019, 773 . 775 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 776 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 777 September 2019, . 779 Appendix A. NETCONF Example 781 The following is a fictional NETCONF example result from a query of 782 the data object tags list. For the sake of brevity only a few module 783 and associated data object results are imagined. 785 786 787 788 ietf-interfaces 789 790 791 /if:interfaces/if:interface 792 ietf:object 793 794 795 /if:interfaces/if:interface/if:last-change 796 ietf:property 797 798 799 800 /if:interfaces/if:interface/if:statistics/if:in-errors 801 802 ietf:metric 803 804 805 806 807 ietf-ip 808 809 810 /if:interfaces/if:interface/ip:ipv4 811 ietf:object 812 813 814 /if:interfaces/if:interface/ip:ipv4/ip:enable 815 ietf:property 816 817 818 /if:interfaces/if:interface/ip:ipv4/ip:mtu 819 ietf:metric 820 821 822 823 824 826 Appendix B. Non-NMDA State Module 828 As per [RFC8407] the following is a non-NMDA module to support 829 viewing the operational state for non-NMDA compliant servers. 831 file "ietf-data-object-tags-state@2019-05-03.yang" 832 module ietf-data-object-tags-state { 833 yang-version 1.1; 834 namespace "urn:ietf:params:xml:ns:yang:ietf-data-object-tags-state"; 835 prefix ntags-s; 837 import ietf-netconf-acm { 838 prefix nacm; 839 } 840 import ietf-module-tags { 841 prefix tags; 842 } 843 organization 844 "IETF NetMod Working Group (NetMod)"; 845 contact 846 "WG Web: 847 WG List: 848 Editor: Qin Wu 849 Editor: Benoit Claise 850 Editor: Liang Geng 851 Editor: Zongpeng Du "; 852 description 853 "This module describes a mechanism associating self-describing 854 tags with YANG data object within YANG modules. Tags may be IANA 855 assigned or privately defined. 857 Copyright (c) 2020 IETF Trust and the persons identified as 858 authors of the code. All rights reserved. 860 Redistribution and use in source and binary forms, with or 861 without modification, is permitted pursuant to, and subject to 862 the license terms contained in, the Simplified BSD License set 863 forth in Section 4.c of the IETF Trust's Legal Provisions 864 Relating to IETF Documents 865 (https://trustee.ietf.org/license-info). 867 This version of this YANG module is part of RFC XXXX 868 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 869 full legal notices."; 871 revision 2019-05-03 { 872 description 873 "Initial revision."; 874 reference 875 "RFC XXXX: YANG Data Object Tags"; 876 } 878 extension opm-tag { 879 argument tag; 880 description 881 "The argument 'tag' is of type 'tag'. This extension statement 882 is used by module authors to indicate the opm tags that SHOULD be 883 added automatically by the system. Opm Tag is used to classify 884 operation and management data into object, property subobject, and metric 885 subobject three categories. Object can contain other objects called subobjects. 886 Property and metric objects are both subobjects belonging to specific object. 887 Both object and subobjects can be modeled as data nodes. Object can be one of 888 container, leaf-list and list. Property subobject is a leaf node. Metric subobject 889 can be one of container, leaf-list, list, leaf. Object contains zero or many 890 property subobjects, zero or many metric subobjects. As such the origin of the value 891 for the pre-defined tags should be set to 'system'[RFC8342]."; 892 } 893 extension metric-group { 894 argument tag; 895 description 896 "The argument 'tag' is of type 'tag'.The metric-group can be 897 used to provide metric subobject classification 898 (e.g., loss, jitter, packet loss)within the YANG module."; 899 } 900 extension multi-source-tag { 901 argument tag; 902 description 903 "The argument 'tag' is of type 'tag'.The multi-source-tag can be 904 used to identify multi-source aggregation type (e.g., aggregated, 905 non-aggregated) related to metric subobject. 907 'aggregated' multi-source aggregation type allows a large number of 908 measurements on metric subobjects from different sources of the same 909 type (e.g.,line card, each subinterface of aggregated Ethernet interface) 910 being combined into aggregated statistics and report as one metric subobject 911 value. 'non-aggregated' multi-source aggregation type allows measurement from 912 each source of the same type (e.g.,line card, each subinterface of aggregated 913 Ethernet interface) be reported separately."; 914 } 916 augment "/tags:module-tags/tags:module" { 917 description 918 "Augment the Module Tags module with data object tag attributes"; 919 container data-object-tags { 920 config false; 921 status deprecated; 922 description 923 "Contains the list of data objects and their associated self describing tags"; 924 list data-object { 925 key "object-name"; 926 status deprecated; 927 description 928 "A list of data objects and their associated self describing tags"; 930 leaf object-name { 931 type nacm:node-instance-identifier; 932 mandatory true; 933 status deprecated; 934 description 935 "The YANG data object name."; 936 } 937 leaf-list tag { 938 type tags:tag; 939 status deprecated; 940 description 941 "Tags associated with the data object within the YANG module. See 942 the IANA 'YANG Data Object Tag Prefixes' registry for reserved 943 prefixes and the IANA'IETF YANG Data Object Tags' registry for 944 IETF tags. 946 The 'operational' state [RFC8342] view of this list is 947 constructed using the following steps: 949 1) System tags (i.e., tags of 'system' origin) are added. 950 2) User configured tags (i.e., tags of 'intended' origin) 951 are added. 952 3) Any tag that is equal to a masked-tag is removed."; 953 } 954 leaf-list masked-tag { 955 type tags:tag; 956 status deprecated; 957 description 958 "The list of tags that should not be associated with the data 959 object within the YANG module. The user can remove (mask) tags from the 960 operational state datastore [RFC8342] by adding them to 961 this list. It is not an error to add tags to this list 962 that are not associated with the data object within YANG module, 963 but they have no operational effect."; 964 } 965 } 966 } 967 } 968 } 969 971 Appendix C. Targeted data object collection example 973 The following subsections provides targeted data object collection 974 example which helps reduce amount of data to be fetched. The 975 subscription "id" values of 22 used below is just an example. In 976 production, the actual values of "id" might not be small integers. 978 +-----------+ +-----------+ 979 | Subscriber| | Publisher | 980 +------+----+ +-----+-----+ 981 | | 982 | | 983 |Telemery data Tagging Advertisement 984 | (data object name, opm-tag = metric) 985 |<---------------------------------| 986 | | 987 | establish-subscription | 988 |--------------------------------->| 989 | | 990 | | 991 | RPC Reply: OK, id = 22 | 992 |<---------------------------------| 993 | | 994 | | 995 | Notification Message (for 22) | 996 | <--------------------------------| 997 | | 998 | | 1000 The publisher advertises telemetry data object capability to the 1001 subscriber to instruct the receiver to subscribe tagged data object 1002 (e.g., performance metric data object) using standard subscribed 1003 notification mechanism [RFC8639]. 1005 The following XML example [W3C.REC-xml-20081126] illustrates the 1006 advertisment of the list of available target objects using YANG 1007 instance file format [I-D.ietf-netmod-yang-instance-file-format]: 1009 1010 1012 acme-router-notification-capabilities 1013 1014 ietf-system-capabilities@2020-03-23 1015 ietf-notification-capabilities@2020-03-23 1016 ietf-data-export-capabilities@2020-03-23 1017 1018 1019 Defines the notification capabilities of an acme-router. 1020 The router only has running, and operational datastores. 1021 Every change can be reported on-change from running, but 1022 only config=true nodes and some config=false data from operational. 1023 Statistics are not reported based on timer based trigger and counter 1024 threshold based trigger. 1025 1026 1027 1032 1033 ds:operational 1034 1035 \ 1036 /if:interfaces/if:interface/if:statistics/if:in-errors\ 1037 1038 1039 metric 1040 loss 1041 1042 1043 1044 1045 1046 1048 With telemetry data tagging information carried in the Telemetry data 1049 Tagging Advertisement, the subscriber identifies targeted data object 1050 and associated data path to the datastore node and sends a standard 1051 establish-subscription RPC [RFC8639] to subscribe tagged data objects 1052 that are interests to the client application from the publisher. 1054 1056 1059 1061 ds:operational 1062 1063 1065 /if:interfaces/if:interface/if:statistics/if:in-errors 1066 1067 1068 500 1069 1070 1071 1073 The publisher returns specific object type of operational state 1074 (e.g., in-errors statistics data) subscribed by the client. 1076 Authors' Addresses 1078 Qin Wu 1079 Huawei 1080 101 Software Avenue, Yuhua District 1081 Nanjing, Jiangsu 210012 1082 China 1084 Email: bill.wu@huawei.com 1086 Benoit Claise 1087 Cisco 1088 De Kleetlaan 6a b1 1089 Diegem 1831 1090 Belgium 1092 Email: bclaise@cisco.com 1094 Liang Geng 1095 China Mobile 1096 32 Xuanwumen West St, Xicheng District 1097 Beijing 10053 1099 Email: gengliangyjy@hotmail.com 1100 Zongpeng Du 1101 China Mobile 1102 32 Xuanwumen West St, Xicheng District 1103 Beijing 10053 1105 Email: duzongpeng@chinamobile.com 1107 Mohamed Boucadair 1108 Orange 1109 Rennes 35000 1110 France 1112 Email: mohamed.boucadair@orange.com