idnits 2.17.1 draft-tao-netconf-notif-node-tag-capabilities-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 187 has weird spacing: '...ecision tags...' -- The document date (March 6, 2020) is 1504 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 102, but not defined == Unused Reference: 'RFC7950' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC8342' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC8407' is defined on line 424, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group R. Tao 3 Internet-Draft B. Wu 4 Intended status: Standards Track Huawei 5 Expires: September 7, 2020 P. Liu 6 H. Cai 7 China Mobile 8 March 6, 2020 10 Self-explanation data Node tag capability 11 draft-tao-netconf-notif-node-tag-capabilities-01 13 Abstract 15 Before a client application subscribes to updates from a datastore, 16 server capabilities related to "Subscription to YANG Datastores" can 17 be advertised using YANG Instance Data format. These server 18 capabilities can be documented at implement time or reported at run- 19 time. 21 This document proposes a YANG module for self-explanation data Node 22 tag capability which augments system capabilities model and provide 23 additional self-explanation data node attributes associated with node 24 selector within per-node capabilities. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 7, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Self-explanation data Node tag capability . . . . . . . . . . 3 63 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 64 3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Updates to the IETF XML Registry . . . . . . . . . . . . 7 67 4.2. Updates to the YANG Module Names Registry . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 6.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 As described in [I-D.netconf-notification-capabilities], a server 77 supporting YANG-Push MAY have a number of capabilities such as 79 o Supported (reporting) periods for periodic subscriptions 81 o Maximum number of objects that can be sent in an update 83 o Supported dampening periods for on-change subscriptions 85 o The set of data nodes for which on-change notification is 86 supported; 88 Notification capability model defined in [I-D.netconf-notification- 89 capabilities] allows a client to discover basic system capability and 90 YANG-Push related capabilities both at implementation-time and run- 91 time. Without using notification capability, it might lead to 92 unexpected failure or additional message exchange for NETCONF clients 93 to discover data models supported by a NETCONF server. 95 When the state of all subscriptions of a particular Subscriber to be 96 fetched is huge, filtering queries of operational state on a server 97 based on server capabilities can greatly reduce the amount of data to 98 be streamed out to the destination. 100 However without self-explanation indication or instruction 101 information associated with data node conveyed in Notification 102 capability model [I-D.netconf-notification-capabilities] or pre- 103 configured selection filter in the YANG Push model, it is hard for 104 NETCONF clients to automatically select which data objects are of 105 interest using machine to machine interface, e.g., identify a set of 106 objects which have a common characteristic, collect specific object 107 type nodes. 109 This document proposes a YANG module for self-explanation data Node 110 tag capability which augments System Capabilities model and provide 111 additional self-explanation data node tag attributes associated with 112 node selector for queries filtering. 114 1.1. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 2. Self-explanation data Node tag capability 124 The YANG module ietf-notification-capabilities defined in [I- 125 D.netconf-notification-capabilities] specify the following server 126 capabilities related to YANG Push: 128 o A set of capabilities related to the amount of notifications the 129 server can send out 131 o Specification of which data nodes support on-change notifications. 133 o Capability values can be specified on server level, datastore 134 level or on specific data nodes (and their contained sub-tree) of 135 a specific datastore. Capability values on a smaller, more 136 specific part of the server's data always override more generic 137 values. 139 o On-change capability is not specified on a server level as 140 different datastores usually have different on-change 141 capabilities. On a datastore level on-change capability for 142 configuration and state data can be specified separately. 144 These server capabilities can be provided either at implementation 145 time or reported at run time. 147 This document augments system capabilities model and provide 148 additional data node self explaination attributes associated with 149 node selector within per-node capabilities: 151 o Specification of which object type nodes, which performance metric 152 nodes, which property related nodes they can push to the target 153 recipient; 155 o Specification of measurement precision or granularity associated 156 with performance metric related data nodes; 158 o Specification of operation type associated with performance metric 159 related data nodes; 161 o Specification of service classification information associated 162 with data nodes; 164 o Specification of task group information associated with a set of 165 data nodes; 167 o Specification of group name of a set of data nodes they can push 168 to the target recipient. 170 o Specification of data source type associated with a set of data 171 nodes; 173 o Specfication of multi-source aggregation assocaited with a set of 174 data nodes; 176 2.1. Tree Diagram 178 The following tree diagram [RFC8340] provides an overview of the data 179 model. 181 module: ietf-self-explanation-capabilities 182 augment /sysc:system-capabilities/sysc:datastore-capabilities/ + 183 sysc:per-node-capabilities/sys:node-selection/sys:node-selector: 184 +--ro self-describing-attributes* [group-id] 185 +--ro group-id string 186 +--ro opm-tag tags:tag 187 +--ro measurement-precision tags:tag 188 +--ro measurement-scale tags:tag 189 +--ro operation-type tags:tag 190 +--ro service-tag* tags:tag 191 +--ro task-tag* tags:tag 192 +--ro data-source-type tags:tag 193 +--ro parent-grouping tags:tag 195 3. YANG Module 197 file "ietf-self-explanation-capabilities.yang" 198 module ietf-self-explanation-capabilities { 199 yang-version 1.1; 200 namespace urn:ietf:params:xml:ns:yang:ietf-self-explanation-capabilities; 201 prefix sec; 202 import ietf-system-capabilities { prefix sysc ; } 203 import ietf-data-node-tags {prefix ntags;} 204 import ietf-module-tags { prefix tags; } 205 organization 206 "IETF NETMOD (Network Modeling) Working Group"; 207 contact 208 "WG Web: 209 WG List: 211 Editor: Ran Tao 212 213 Qin Wu 214 305 4. IANA Considerations 307 4.1. Updates to the IETF XML Registry 309 This document registers a URI in the "IETF XML Registry" [RFC3688]. 310 Following the format in [RFC3688], the following registration has 311 been made: 313 URI: 314 urn:ietf:params:xml:ns:yang:ietf-self-explanation-capabilities 315 Registrant Contact: 316 The IESG. 317 XML: 318 N/A; the requested URI is an XML namespace. 320 4.2. Updates to the YANG Module Names Registry 322 This document registers one YANG module in the "YANG Module Names" 323 registry [RFC6020]. Following the format in [RFC6020], the following 324 registration has been made: 326 name: 327 ietf-self-explanation-capabilities 328 namespace: 329 urn:ietf:params:xml:ns:yang:ietf-self-explanation-capabilities 330 prefix: 331 sec 332 reference: 333 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 334 this note.) 336 5. Security Considerations 338 The YANG module specified in this document defines a schema for data 339 that is designed to be accessed via network management protocols such 340 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 341 is the secure transport layer, and the mandatory-to-implement secure 342 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 343 is HTTPS, and the mandatory-to-implement secure transport is TLS 344 [RFC8446]. 346 The NETCONF Configuration Access Control Model (NACM) [RFC8341] 347 provides the means to restrict access for particular NETCONF or 348 RESTCONF users to a preconfigured subset of all available NETCONF or 349 RESTCONF protocol operations and content. 351 There are a number of data nodes defined in this YANG module that are 352 writable/creatable/deletable (i.e., config true, which is the 353 default). These data nodes may be considered sensitive in some 354 network environments. Write operations (e.g., edit-config) to these 355 data nodes without proper protection can have a negative effect on 356 network operations. These are the subtrees and data nodes and their 357 sensitivity/vulnerability: 359 o /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per- 360 node-capabilities/sys:node-selection/sys:node-selector/sec:self- 361 describing-attributes/sec:node-tag 363 o /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per- 364 node-capabilities/sys:node-selection/sys:node-selector/sec:self- 365 describing-attributes/sec:pm-node-precision 367 o /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per- 368 node-capabilities/sys:node-selection/sys:node-selector/sec:self- 369 describing-attributes/sec:pm-node-operation-type 371 o /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per- 372 node-capabilities/sys:node-selection/sys:node-selector/sec:self- 373 describing-attributes/sec:node-service-tag 375 o /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per- 376 node-capabilities/sys:node-selection/sys:node-selector/sec:self- 377 describing-attributes/sec:node-task-tag 379 6. References 381 6.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 389 and A. Bierman, Ed., "Network Configuration Protocol 390 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 391 . 393 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 394 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 395 . 397 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 398 RFC 7950, DOI 10.17487/RFC7950, August 2016, 399 . 401 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 402 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 403 . 405 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 406 Writing an IANA Considerations Section in RFCs", BCP 26, 407 RFC 8126, DOI 10.17487/RFC8126, June 2017, 408 . 410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 412 May 2017, . 414 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 415 Access Control Model", STD 91, RFC 8341, 416 DOI 10.17487/RFC8341, March 2018, 417 . 419 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 420 and R. Wilton, "Network Management Datastore Architecture 421 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 422 . 424 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 425 Documents Containing YANG Data Models", BCP 216, RFC 8407, 426 DOI 10.17487/RFC8407, October 2018, 427 . 429 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 430 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 431 . 433 6.2. Informative References 435 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 436 DOI 10.17487/RFC3688, January 2004, 437 . 439 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 440 the Network Configuration Protocol (NETCONF)", RFC 6020, 441 DOI 10.17487/RFC6020, October 2010, 442 . 444 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 445 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 446 . 448 Authors' Addresses 450 Ran Tao 451 Huawei 452 101 Software Avenue, Yuhua District 453 Nanjing, Jiangsu 210012 454 China 456 Email: taoran20@huawei.com 458 Bo Wu 459 Huawei 460 101 Software Avenue, Yuhua District 461 Nanjing, Jiangsu 210012 462 China 464 Email: lana.wubo@huawei.com 465 Peng Liu 466 China Mobile 467 32 Xuanwumen West St, Xicheng District 468 Beijing 10053 470 Email: liupengyjy@chinamobile.com 472 Hui Cai 473 China Mobile 474 32 Xuanwumen West St, Xicheng District 475 Beijing 10053 477 Email: caihui@chinamobile.com