idnits 2.17.1 draft-voit-netconf-subscription-and-notif-overview-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 214 has weird spacing: '...f-notif netc...' -- The document date (September 19, 2017) is 2410 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF E. Voit 3 Internet-Draft Cisco Systems 4 Intended status: Informational A. Clemm 5 Expires: March 23, 2018 Huawei 6 September 19, 2017 8 Subscription and Notifications Overview 9 draft-voit-netconf-subscription-and-notif-overview-00 11 Abstract 13 Provides an introductory context for NETCONF WG drafts on 14 subscriptions and notifications. Through this document, a reader can 15 understand the scope of each draft, as well as the relationships 16 between each draft. 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 March 23, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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. Phasing of drafts . . . . . . . . . . . . . . . . . . . . 2 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Scope of Drafts . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. draft-ietf-netconf-subscribed-notifications . . . . . . . 3 57 2.2. draft-ietf-netconf-yang-push . . . . . . . . . . . . . . 4 58 2.3. draft-ietf-netconf-netconf-event-notifications . . . . . 4 59 2.4. draft-ietf-netconf-restconf-notif . . . . . . . . . . . . 4 60 2.5. draft-ietf-netconf-notification-messages . . . . . . . . 4 61 3. Relationships between Drafts . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Informative References . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 This document provides an overview of a set of documents that define 70 mechanisms that allow client applications to subscribe to and receive 71 notifications and datastore updates. Specifically, this includes the 72 following documents: 74 o draft-ietf-netconf-subscribed-notifications 75 o draft-ietf-netconf-yang-push 76 o draft-ietf-netconf-netconf-event-notifications 77 o draft-ietf-netconf-restconf-notif 78 o draft-ietf-netconf-notification-messages 80 1.1. Phasing of drafts 82 This set of drivers has two themes: 84 1. an evolved subscription configuration data model and state 85 transition messages, which, when paired with the existing 86 [RFC5277] encoded one-way operation, provides a solution for yang 87 push. 88 2. a new one-way notification operation that can provide robustness, 89 flexibility, and extensibility. 91 For theme 1, drafts [subscribed-notifications], [yang-push], 92 [netconf-event-notifications], and [restconf-notif] provide solutions 93 for an evolved subscription data model, pushing of YANG datastore 94 changes as they happen, and periodic reporting of YANG datastore 95 state. Also enabled is the use of the evolved subscription model and 96 subscription state transition messages on publisher based event 97 streams. 99 For theme 2, solutions are in the early stages for: 101 o automatic determination of which common headers to use, and 102 selection of if/what transport bundling to use without requiring 103 any change to YANG's 'notification' statement 104 o continuing, transparent support for RFC5277-encoded notifications 105 from legacy clients 106 o general strategy to introduce new behavior where a server 107 advertises support for new headers and encodings, and client 108 selects them when available 110 These items are listed so they are explicitly shown not be covered by 111 Theme 1. 113 1.2. Terminology 115 The terms publisher, receiver, and subscriber are defined in 116 [subscribed-notifications]. 118 2. Scope of Drafts 120 This section describes the intent and contents of each draft. 122 2.1. draft-ietf-netconf-subscribed-notifications 124 This document defines the YANG module, RPCs, and Notifications for 125 the customized establishment of subscriptions upon a publisher's 126 event streams. Also defined are delivery mechanisms for instances of 127 the resulting events. Effectively this allows a subscriber to 128 request and receive a continuous, custom influx of publisher- 129 generated information. Included are: 131 o Dynamic and configured subscriptions 132 o Multiple subscriptions / transport 133 o Multiple configured receivers 134 o Establish, modify, delete, kill RPC 135 o State change notifications 136 o Suspend/resume 137 o Filtering full notifications 138 o Stream discovery 139 o Replay (and start time negotiation) 140 o Prioritization 141 o Monitoring / reporting 142 o QoS 143 o Error responses 145 2.2. draft-ietf-netconf-yang-push 147 This document extends the YANG module, RPCs, and Notifications from 148 [subscribed-notifications] to enable the customized establishment of 149 subscriptions to updates from YANG datastores. Using the definitions 150 of this document, a subscriber application may request a continuous, 151 customized stream of updates from a YANG datastore. Included are: 153 o Datastore on-change and periodic triggers 154 o Selecting objects within a datastore to subscribe to 155 o Authorization model per object 156 o RPC for datastore resynchronization 157 o Sending of full YANG trees or yang-patch 158 o Tagging of partial updates 159 o Tagging of on-change object support 160 o Negotiation of filters and period lengths 161 o Datastore-specific error responses and datastore-subscription 162 specific monitoring 164 2.3. draft-ietf-netconf-netconf-event-notifications 166 This document provides a NETCONF binding for 167 [subscribed-notifications]. Included are: 169 o Transport mappings for subscription RPCs and state change 170 notifications 171 o Transport mapping for RFC-5277 event transport 173 2.4. draft-ietf-netconf-restconf-notif 175 This document provides RESTCONF, HTTP2, and HTTP1.1 bindings for the 176 subscribed-notifications. Included are: 178 o Transport mapping for subscription protocol messages 179 o Transport mappings for RFC-5277 one-way operation 180 o Heartbeats and clean-up 182 2.5. draft-ietf-netconf-notification-messages 184 This document defines a new notification message format, using yang- 185 data. Included are: 187 o a new notification mechanism to replace the one way operation of 188 RFC-5277 189 o a set of common, transport agnostic message header objects to 190 support functionality such as event severity, message signing, 191 message loss discovery, message de-duplication, originating 192 process identification. 194 o how to bundle multiple event records into a single notification 195 message. 196 o how to ensure these new capabilities are only used with capable 197 receivers. 199 This mechanism could have future applicability for updates to 200 [RFC7950] and [RFC8040]. 202 3. Relationships between Drafts 204 This section describes the relationships between subscription drafts. 206 RFC-5277 yang-push 207 | | 208 (1)| |(2) 209 v v 210 subscribed-notifications 211 ^ ^ 212 (3)| |(4) 213 | | 214 restconf-notif netconf-event-notifications 215 | | 216 (5)| |(6) 217 v v 218 notification-messages 220 Figure 1: Relationships between drafts 222 A few notes on the figure above. The initial of text leading text of 223 each name has been removed to make the figure more readable. 224 Numbered arrows indicate a relationship of one draft with another. 225 The nature of each arrow is described below. 227 Relationship (1) Until [notification-messages] becomes available, 228 draft [subscribed-notifications] needs RFC-5277's 229 mechanism for encoding one way notifications. 231 Relationship (2) The draft [subscribed-notifications] provides the 232 technical foundation upon which YANG datastore 233 specific push mechanisms are layered as specified 234 in [yang-push]. Key here are: 236 * replacement of event streams with on-change or 237 periodic triggers upon a YANG Datastore. 238 * replacement of event filters with datastore 239 selectors 241 Relationship (3) The [restconf-notif] draft supports 242 [subscribed-notifications] by defining transport 243 specific guidance where some form of HTTP is used 244 underneath. Key here are: 246 * bindings for RPC communications over RESTCONF 247 * bindings for one-way notifications transported 248 over HTTP2 and HTTP1.1 249 * end-to-end deployment guidance for Call Home and 250 TLS Heartbeat 252 Relationship (4) The [netconf-event-notifications] draft supports 253 [subscribed-notifications] by defining NETCONF 254 transport specifics. Key are: 256 * bindings for RPC communications over NETCONF 257 * bindings for one-way notifications transported 258 over NETCONF 260 Relationship (5) The [netconf-event-notifications] draft will not 261 initially have available to it the replacement of 262 RFC-5277 one way operation. When 263 [notification-messages] becomes available, it will 264 be possible to replace the RFC-5277 one-way 265 operation with a solution which includes common 266 headers and the ability to bundle many 267 notifications into a single transportable message. 269 Relationship (6) The [restconf-notif] draft will not initially have 270 available to it the replacement of RFC-5277 one way 271 operation. When [notification-messages] becomes 272 available, it will be possible to replace the 273 RFC-5277 one-way operation with a solution which 274 includes common headers and the ability to bundle 275 many notifications into a single transportable 276 message. 278 4. Security Considerations 280 Not applicable. 282 5. Acknowledgments 284 For his valuable comments framing the value and purposed of this 285 document: Kent Watsen. 287 6. Informative References 289 [netconf-event-notifications] 290 Gonzalez Prieto, A., Clemm, A., Voit, E., Nilsen-Nygaard, 291 E., and A. Tripathy, "NETCONF Support for Event 292 Notifications", July 2017. 294 [notification-messages] 295 Voit, E., Bierman, A., Clemm, A., and T. Jenkins, "YANG 296 Notification Headers and Bundles", July 2017. 298 [restconf-notif] 299 Voit, E., Gonzalez Prieto, A., Tripathy, A., Nilsen- 300 Nygaard, E., Clemm, A., and A. Bierman, "RESTCONF and HTTP 301 Transport for Event Notifications", August 2017. 303 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 304 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 305 . 307 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 308 RFC 7950, DOI 10.17487/RFC7950, August 2016, 309 . 311 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 312 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 313 . 315 [subscribed-notifications] 316 Voit, E., Clemm, A., Gonzalez Prieto, A., Prasad Tripathy, 317 A., and E. Nilsen-Nygaard, "Custom Subscription to Event 318 Notifications", September 2017, 319 . 322 [yang-push] 323 Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy, 324 A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, 325 "Subscribing to YANG datastore push updates", September 326 2017, . 329 Authors' Addresses 331 Eric Voit 332 Cisco Systems 334 Email: evoit@cisco.com 335 Alexander Clemm 336 Huawei 338 Email: ludwig@clemm.org