idnits 2.17.1 draft-wang-netconf-bulk-subscribed-notifications-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 9 instances of too long lines in the document, the longest one being 29 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 179 has weird spacing: '...roup-id str...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 3, 2019) is 1633 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: 'RFC8639' is mentioned on line 151, but not defined == Missing Reference: 'RFC3877' is mentioned on line 119, but not defined == Unused Reference: 'RFC8126' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC8407' is defined on line 451, 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 Z. Wang 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: May 6, 2020 November 3, 2019 7 Bulk Subscription to YANG Event Notification 8 draft-wang-netconf-bulk-subscribed-notifications-00 10 Abstract 12 This document defines a YANG data model and associated mechanism that 13 allows subscriber applications to bulk subscribe to publishers' event 14 streams based on their requirements. And it also allows the 15 publishers to report multiple event streams or subscriptions into a 16 single notification message based on group identifier affiliation. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 6, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Model Overview . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Bulk Subscription YANG Module . . . . . . . . . . . . . . . . 5 56 4. Bulk Notification YANG Module . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5.1. Updates to the IETF XML Registry . . . . . . . . . . . . 8 59 5.2. Updates to the YANG Module Names Registry . . . . . . . . 8 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 7.2. Informative References . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 The Subscription to YANG Notifications specification [RFC8639] uses A 69 "stream" name in dynamic subscription protocol operation for 70 identifying the targeted event stream against which the subscription 71 is applied. Notification Message Headers and Bundles [I-D. ietf- 72 netconf-notification-messages] uses subscription-id for identifying 73 the targeted subscription. However the dynamic subscription protocol 74 operation lack the capability to identify a set of event streams or a 75 set of subscriptions which have a common characteristic. A group 76 identifier associated with an event stream enables the ability to 77 perform protocol operation on a set of event stream via a single 78 transaction. The group identifier provides a more optimal mechanism 79 for protocol operation which would otherwise require multiple atomic 80 transactions on a per event stream basis. Following are some of the 81 use-cases where such identifier can be used. 83 o For establishing a Dynamic Subscription, the subscriber may send a 84 a single request the creation of a subscription for each of event 85 stream's groups and perform creation of a subscription for all 86 event steam's that are part of that group. 88 o The subscriber in dynamic subscription domain may choose to delete 89 a dynamic subscription or end a dynamic subscription that is not 90 associated with the specific transport session and domain. In 91 such case, the subscriber can perform delete-subscription or kill- 92 subscription signaling using the group ID associated with a 93 specific set of event streams. 95 o Multiple notifications (e.g., multiple notifications associated 96 with creation of a subscription or decomssion of subscription) 97 bundled into one transportable message 99 This document defines a YANG data model and associated mechanism that 100 allows subscriber applications to bulk subscribe to publishers' event 101 streams based on their requirements. And it also allows the 102 publishers to report multiple event streams or subscriptions into a 103 single notification message based on group identifier affiliation. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 This document uses the following terms: 115 Event: Something that happens which may be of interest or trigger 116 the invocation of the rule. A fault, an alarm, a change in 117 network state, network security threat, hardware malfunction, 118 buffer untilization crossing a threshold, network connection 119 setup, an external input to the system, for example [RFC3877]. 121 Client: Defined in [RFC8342]. 123 Configuration: Defined in [RFC8342]. 125 Configured subscription: Defined in [RFC8639] 127 Configuration datastore: Defined in [RFC8342]. 129 Event record: A set of information detailing an event [RFC8639]. 131 Event stream: A continuous, chronologically ordered set of events 132 aggregated under some context [RFC8639]. 134 Notification message: Information intended for a receiver 135 indicating that one or more events have occurred [RFC8639]. 137 Publisher: An entity responsible for streaming notification messages 138 per the terms of a subscription [RFC8639]. 140 Receiver: A target to which a publisher pushes subscribed event 141 records. For dynamic subscriptions, the receiver and subscriber 142 are the same entity [RFC8639]. 144 Subscriber: A client able to request and negotiate a contract for 145 the generation and push of event records from a publisher. For 146 dynamic subscriptions, the receiver and subscriber are the same 147 entity [RFC8639]. 149 Subscription: A contract with a publisher, stipulating the 150 information that one or more receivers wish to have pushed from 151 the publisher without the need for further solicitation [RFC8639]. 153 2. Model Overview 155 The YANG data model for the Bulk Subscriptions and Notifications has 156 been split into two modules: 158 o The ietf-bulk-subscription.yang module defines a list for 159 classifying different event streams into groups. Each group is 160 associated with a group identifier and a set of event streams. A 161 stream group is identified by a "group-id" string. This string is 162 used both as an index within the bulk subscription module and to 163 associate subscription with a group of streams, as shown in the 164 subscription augmentation. 166 o The ietf-bulk-notification.yang module augment the YANG structure 167 of ietf-notification-messages.yang [draft-ietf-netconf- 168 notification-messages], a "group-id" is added to the "message- 169 header" of the ietf-notification-messages.yang to identify the 170 group to which a set of notifications belongs. 172 The following tree diagrams [RFC8340] provide an overview of the data 173 model for "ietf-bulk-subscription.yang" module and the "ietf-bulk- 174 notification.yang" module. 176 module: ietf-bulk-subscription 177 +--rw groups 178 +--rw group* [group-id] 179 +--rw group-id string 180 +--rw stream* string 182 augment /sn:subscriptions/sn:subscription/sn:target: 183 +--:(stream-group) 184 +--rw group-id? -> /groups/group/group-id 185 augment /sn:establish-subscription/sn:input/sn:target: 186 +--:(stream-group) 187 +-- group-id? -> /groups/group/group-id 189 module: ietf-bulk-notification 190 augment-structure /nm:message/nm:message-header: 191 +--rw message-type identityref 192 +--rw group-id? string 194 3. Bulk Subscription YANG Module 196 file "ietf-bulk-subscription@2019-10-14.yang" 197 module ietf-bulk-subscription { 198 yang-version 1.1; 199 namespace "urn:ietf:params:xml:ns:yang:ietf-bulk-subscription"; 200 prefix bs; 202 import ietf-subscribed-notifications { 203 prefix sn; 204 } 205 import ietf-yang-types { 206 prefix yang; 207 } 209 organization 210 "IETF NETCONF (Network Configuration) Working Group"; 211 contact 212 ""; 213 description 214 "NETCONF Protocol Data Types and Protocol Operations. 216 Copyright (c) 2011 IETF Trust and the persons identified as 217 the document authors. All rights reserved. 219 Redistribution and use in source and binary forms, with or 220 without modification, is permitted pursuant to, and subject 221 to the license terms contained in, the Simplified BSD License 222 set forth in Section 4.c of the IETF Trust's Legal Provisions 223 Relating to IETF Documents 224 (http://trustee.ietf.org/license-info). 226 This version of this YANG module is part of RFC 6241; see 227 the RFC itself for full legal notices."; 229 revision 2019-10-14 { 230 description 231 "Initial revision"; 232 reference 233 "FOO"; 234 } 236 container groups { 237 list group { 238 key "group-id"; 239 leaf group-id { 240 type string; 241 description 242 "This group ID is used as an index within the bulk subscription module"; 243 } 244 leaf-list stream { 245 type string; 246 description 247 "A continuous, chronologically ordered set of events aggregated under some context"; 248 } 249 description 250 "List for group that classify different event streams into groups."; 251 } 252 description 253 "Container for event stream group"; 254 } 255 augment "/sn:subscriptions/sn:subscription/sn:target" { 256 case stream-group { 257 leaf group-id { 258 type leafref { 259 path "/bs:groups/bs:group/bs:group-id"; 260 } 261 description 262 "This group ID is used to associate subscription with a group of streams"; 263 } 264 description 265 "Augment the subscribed-notifications module with event stream group inforamtion."; 266 } 267 } 268 augment "/sn:establish-subscription/sn:input/sn:target" { 269 case stream-group { 270 leaf group-id { 271 type leafref { 272 path "/bs:groups/bs:group/bs:group-id"; 273 } 274 description 275 "This group ID is used to associate subscription with a group of streams"; 276 } 277 description 278 "Augment the establish-subscription RPC with event stream group inforamtion."; 279 } 280 } 281 } 283 285 4. Bulk Notification YANG Module 287 file "ietf-bulk-notification@2019-09-23.yang" 288 module ietf-bulk-notification { 289 yang-version 1.1; 290 namespace "urn:ietf:params:xml:ns:yang:ietf-bulk-notification"; 291 prefix bn; 293 import ietf-yang-structure-ext { 294 prefix sx; 295 } 296 import ietf-notification-messages { 297 prefix nm; 298 } 300 organization 301 "IETF NETCONF (Network Configuration) Working Group"; 302 contact 303 ""; 304 description 305 "NETCONF Protocol Data Types and Protocol Operations. 307 Copyright (c) 2011 IETF Trust and the persons identified as 308 the document authors. All rights reserved. 310 Redistribution and use in source and binary forms, with or 311 without modification, is permitted pursuant to, and subject 312 to the license terms contained in, the Simplified BSD License 313 set forth in Section 4.c of the IETF Trust's Legal Provisions 314 Relating to IETF Documents 315 (http://trustee.ietf.org/license-info). 317 This version of this YANG module is part of RFC 6241; see 318 the RFC itself for full legal notices."; 320 revision 2019-09-23 { 321 description 322 "Initial revision"; 323 reference 324 "FOO"; 325 } 326 sx:augment-structure "/nm:message/nm:message-header" { 327 leaf group-id { 328 type string; 329 description 330 "to identify the group to which a set of notifications belongs."; 331 } 332 description 333 "Group related informations are added to the 'message-header' of the ietf-notification-messages 334 to identify the group to which a set of notifications belongs."; 335 } 336 } 337 338 5. IANA Considerations 340 5.1. Updates to the IETF XML Registry 342 This document registers two URIs in the IETF XML registry [RFC3688]. 343 Following the format in [RFC3688], the following registrations are 344 requested to be made: 346 --------------------------------------------------------------------- 347 URI: urn:ietf:params:xml:ns:yang:ietf-bulk-subscription 348 Registrant Contact: The IESG. 349 XML: N/A, the requested URI is an XML namespace. 351 URI: urn:ietf:params:xml:ns:yang:ietf-bulk-notification 352 Registrant Contact: The IESG. 353 XML: N/A, the requested URI is an XML namespace. 354 --------------------------------------------------------------------- 356 5.2. Updates to the YANG Module Names Registry 358 This document registers two YANG modules in the YANG Module Names 359 registry [RFC7950]. . Following the format in [RFC6020], the 360 following registration has been made: 362 --------------------------------------------------------------------- 363 Name: ietf-bulk-subscription 364 Namespace: urn:ietf:params:xml:ns:yang:ietf-bulk-subscription 365 Prefix: trig 366 Reference: RFC xxxx 368 Name: ietf-bulk-notification 369 Namespace: urn:ietf:params:xml:ns:yang: ietf-bulk-notification 370 Prefix: evt 371 Reference: RFC xxxx 372 --------------------------------------------------------------------- 374 6. Security Considerations 376 The YANG module specified in this document defines a schema for data 377 that is designed to be accessed via network management protocols such 378 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 379 is the secure transport layer, and the mandatory-to-implement secure 380 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 381 is HTTPS, and the mandatory-to-implement secure transport is TLS 382 [RFC8446]. 384 The NETCONF Configuration Access Control Model (NACM) [RFC8341] 385 provides the means to restrict access for particular NETCONF or 386 RESTCONF users to a preconfigured subset of all available NETCONF or 387 RESTCONF protocol operations and content. 389 There are a number of data nodes defined in this YANG module that are 390 writable/creatable/deletable (i.e., config true, which is the 391 default). These data nodes may be considered sensitive in some 392 network environments. Write operations (e.g., edit-config) to these 393 data nodes without proper protection can have a negative effect on 394 network operations. These are the subtrees and data nodes and their 395 sensitivity/vulnerability: 397 o /groups/group/group-id 399 o /groups/group/stream 401 o /sn:subscriptions/sn:subscription/sn:target/sn:stream/bs:group-id 403 o sn:establish-subscription/sn:input/sn:target/sn:stream /bs:group- 404 id 406 7. References 408 7.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 416 and A. Bierman, Ed., "Network Configuration Protocol 417 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 418 . 420 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 421 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 422 . 424 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 425 RFC 7950, DOI 10.17487/RFC7950, August 2016, 426 . 428 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 429 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 430 . 432 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 433 Writing an IANA Considerations Section in RFCs", BCP 26, 434 RFC 8126, DOI 10.17487/RFC8126, June 2017, 435 . 437 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 438 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 439 May 2017, . 441 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 442 Access Control Model", STD 91, RFC 8341, 443 DOI 10.17487/RFC8341, March 2018, 444 . 446 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 447 and R. Wilton, "Network Management Datastore Architecture 448 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 449 . 451 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 452 Documents Containing YANG Data Models", BCP 216, RFC 8407, 453 DOI 10.17487/RFC8407, October 2018, 454 . 456 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 457 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 458 . 460 7.2. Informative References 462 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 463 DOI 10.17487/RFC3688, January 2004, 464 . 466 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 467 the Network Configuration Protocol (NETCONF)", RFC 6020, 468 DOI 10.17487/RFC6020, October 2010, 469 . 471 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 472 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 473 . 475 Authors' Addresses 476 Michael Wang 477 Huawei 478 101 Software Avenue, Yuhua District 479 Nanjing, Jiangsu 210012 480 China 482 Email: wangzitao@huawei.com 484 Qin Wu 485 Huawei 486 101 Software Avenue, Yuhua District 487 Nanjing, Jiangsu 210012 488 China 490 Email: bill.wu@huawei.com