idnits 2.17.1 draft-tao-netconf-notif-node-tag-capabilities-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 6 instances of too long lines in the document, the longest one being 10 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 (November 2, 2019) is 1636 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 74, but not defined == Unused Reference: 'RFC7950' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC8342' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC8407' is defined on line 329, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 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: May 5, 2020 November 2, 2019 7 Notification Capabilities Model Extension for self-explanation data Node 8 tag capability support 9 draft-tao-netconf-notif-node-tag-capabilities-00 11 Abstract 13 Before a client application subscribes to updates from a datastore, 14 server capabilities related to "Subscription to YANG Datastores" can 15 be advertised using YANG Instance Data format. These server 16 capabilities can be documented at implement time or reported at run- 17 time. 19 This document proposes a YANG module for Data Node tag capability 20 support which augments YANG Push Notification Capabilities model and 21 provide additional self-explanation data node attributes associated 22 with node selector within per-node capabilities. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 5, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Notification Capability Model Extension . . . . . . . . . . . 3 61 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 62 3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Updates to the IETF XML Registry . . . . . . . . . . . . 5 65 4.2. Updates to the YANG Module Names Registry . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 6.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 As described in [I-D.netconf-notification-capabilities], a server 75 supporting YANG-Push MAY have a number of capabilities such as 77 o Supported (reporting) periods for periodic subscriptions 79 o Maximum number of objects that can be sent in an update 81 o Supported dampening periods for on-change subscriptions 83 o The set of data nodes for which on-change notification is 84 supported 86 Notification capability model defined in [I-D.netconf-notification- 87 capabilities] allows a client to discover YANG-Push related 88 capabilities both at implementation-time and run-time. Without using 89 notification capability, it might lead to unexpected failure or 90 additional message exchange for NETCONF clients to discover data 91 models supported by a NETCONF server. 93 When the state of all subscriptions of a particular Subscriber to be 94 fetched is huge, filtering queries of operational state on a server 95 based on server capabilities can greatly reduce the amount of data to 96 be streamed out to the destination. 98 However without self-explanation information on data node conveyed in 99 Notification capability model [I-D.netconf-notification- 100 capabilities], it is hard for NETCONF clients to automatically select 101 which data objects are of interest using machine to machine 102 interface, e.g., identify a set of objects which have a common 103 characteristic, collect specific object type nodes. 105 This document proposes a YANG module for Data Node tag capability 106 support which augments YANG Push Notification Capabilities model and 107 provide additional self-explanation data node tag attributes 108 associated with node selector for queries filtering. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 2. Notification Capability Model Extension 120 The YANG module ietf-notification-capabilities defined in [I- 121 D.netconf-notification-capabilities] specify the following server 122 capabilities related to YANG Push: 124 o a set of capabilities related to the amount of notifications the 125 server can send out 127 o specification of which data nodes support on-change notifications. 129 o Capability values can be specified on server level, datastore 130 level or on specific data nodes (and their contained sub-tree) of 131 a specific datastore. Capability values on a smaller, more 132 specific part of the server's data always override more generic 133 values. 135 o On-change capability is not specified on a server level as 136 different datastores usually have different on-change 137 capabilities. On a datastore level on-change capability for 138 configuration and state data can be specified separately. 140 These server capabilities can be provided either at implementation 141 time or reported at run time. 143 This document augments YANG Push Notification Capabilities model and 144 provide additional data node attributes associated with node selector 145 within per-node capabilities: 147 o specification of which object type nodes they can push to the 148 target recipient. 150 o specification of which group of data nodes they can push to the 151 target recipient. 153 2.1. Tree Diagram 155 The following tree diagram [RFC8340] provides an overview of the data 156 model. 158 module: ietf-notification-node-tag-capabilities 159 augment /inc:datastore-subscription-capabilities/inc:datastore-capabilities 160 /inc:per-node-capabilities: 161 +--ro node-tag tags:tag 162 +--ro group-id string 164 3. YANG Module 166 file "ietf-notification-node-tag-capabilities.yang" 167 module ietf-notification-node-tag-capabilities { 168 yang-version 1.1; 169 namespace urn:ietf:params:xml:ns:yang:ietf-notification-node-tag-capabilities; 170 prefix nntc; 172 import ietf-notification-capabilities { prefix inc ; } 173 import ietf-data-node-tags {prefix ntags;} 174 organization 175 "IETF NETMOD (Network Modeling) Working Group"; 176 contact 177 "WG Web: 178 WG List: 180 Editor: Ran Tao 181 "; 182 description 183 "This module defines an extension to YANG Push 184 Notification Capabilities model and provides additional data node tag 185 attributes associated with node selector for queries filtering. 187 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 188 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 189 'MAY', and 'OPTIONAL' in this document are to be interpreted as 190 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 191 they appear in all capitals, as shown here. 193 Copyright (c) 2019 IETF Trust and the persons identified as 194 authors of the code. All rights reserved. 196 Redistribution and use in source and binary forms, with or 197 without modification, is permitted pursuant to, and subject 198 to the license terms contained in, the Simplified BSD License 199 set forth in Section 4.c of the IETF Trust's Legal Provisions 200 Relating to IETF Documents 201 (http://trustee.ietf.org/license-info). 203 This version of this YANG module is part of RFC XXXX; 204 see the RFC itself for full legal notices."; 205 augment /inc:datastore-subscription-capabilities/inc:datastore-capabilities 206 /inc:per-node-capabilities { 207 description "Allows the get-config operation to use the 208 factory-default datastore as a source"; 209 leaf node-tag { 210 type ntags:node-tag ; 211 description 212 "Tags associated with the data node within YANG module. 213 See the IANA 'YANG Data Node Tag Prefixes' registry 214 for reserved prefixes and the IANA 215 'IETF YANG Data Node Tags' registry for IETF tags."; 216 } 217 leaf group-id { 218 type string; 219 description 220 "This group ID is used to identify a set of data nodes 221 of the same group which have a common characteristic."; 222 } 223 } 224 226 4. IANA Considerations 228 4.1. Updates to the IETF XML Registry 230 This document registers a URI in the "IETF XML Registry" [RFC3688]. 231 Following the format in [RFC3688], the following registration has 232 been made: 234 URI: 235 urn:ietf:params:xml:ns:yang:ietf-notification-node-tag-capabilities 237 Registrant Contact: 238 The IESG. 240 XML: 241 N/A; the requested URI is an XML namespace. 243 4.2. Updates to the YANG Module Names Registry 245 This document registers one YANG module in the "YANG Module Names" 246 registry [RFC6020]. Following the format in [RFC6020], the following 247 registration has been made: 249 name: 250 ietf-notification-node-tag-capabilities 252 namespace: 253 urn:ietf:params:xml:ns:yang:ietf-notification-node-tag-capabilities 255 prefix: 256 nntc 258 reference: 259 RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove 260 this note.) 262 5. Security Considerations 264 The YANG module specified in this document defines a schema for data 265 that is designed to be accessed via network management protocols such 266 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 267 is the secure transport layer, and the mandatory-to-implement secure 268 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 269 is HTTPS, and the mandatory-to-implement secure transport is TLS 270 [RFC8446]. 272 The NETCONF Configuration Access Control Model (NACM) [RFC8341] 273 provides the means to restrict access for particular NETCONF or 274 RESTCONF users to a preconfigured subset of all available NETCONF or 275 RESTCONF protocol operations and content. 277 There are a number of data nodes defined in this YANG module that are 278 writable/creatable/deletable (i.e., config true, which is the 279 default). These data nodes may be considered sensitive in some 280 network environments. Write operations (e.g., edit-config) to these 281 data nodes without proper protection can have a negative effect on 282 network operations. These are the subtrees and data nodes and their 283 sensitivity/vulnerability: 285 6. References 286 6.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 294 and A. Bierman, Ed., "Network Configuration Protocol 295 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 296 . 298 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 299 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 300 . 302 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 303 RFC 7950, DOI 10.17487/RFC7950, August 2016, 304 . 306 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 307 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 308 . 310 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 311 Writing an IANA Considerations Section in RFCs", BCP 26, 312 RFC 8126, DOI 10.17487/RFC8126, June 2017, 313 . 315 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 316 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 317 May 2017, . 319 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 320 Access Control Model", STD 91, RFC 8341, 321 DOI 10.17487/RFC8341, March 2018, 322 . 324 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 325 and R. Wilton, "Network Management Datastore Architecture 326 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 327 . 329 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 330 Documents Containing YANG Data Models", BCP 216, RFC 8407, 331 DOI 10.17487/RFC8407, October 2018, 332 . 334 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 335 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 336 . 338 6.2. Informative References 340 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 341 DOI 10.17487/RFC3688, January 2004, 342 . 344 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 345 the Network Configuration Protocol (NETCONF)", RFC 6020, 346 DOI 10.17487/RFC6020, October 2010, 347 . 349 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 350 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 351 . 353 Authors' Addresses 355 Ran Tao 356 Huawei 357 101 Software Avenue, Yuhua District 358 Nanjing, Jiangsu 210012 359 China 361 Email: taoran20@huawei.com 363 Bo Wu 364 Huawei 365 101 Software Avenue, Yuhua District 366 Nanjing, Jiangsu 210012 367 China 369 Email: lana.wubo@huawei.com