idnits 2.17.00 (12 Aug 2021) /tmp/idnits8028/draft-ietf-netconf-restconf-notif-04.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 -- The document date (January 31, 2018) is 1570 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) == Outdated reference: draft-ietf-netconf-subscribed-notifications has been published as RFC 8639 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: draft-ietf-netconf-yang-push has been published as RFC 8641 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF E. Voit 3 Internet-Draft A. Tripathy 4 Intended status: Standards Track E. Nilsen-Nygaard 5 Expires: August 4, 2018 Cisco Systems 6 A. Clemm 7 Huawei 8 A. Gonzalez Prieto 9 VMWare 10 A. Bierman 11 YumaWorks 12 January 31, 2018 14 RESTCONF and HTTP Transport for Event Notifications 15 draft-ietf-netconf-restconf-notif-04 17 Abstract 19 This document defines RESTCONF, HTTP2, and HTTP1.1 bindings for the 20 transport of subscription requests and corresponding push updates. 21 Being subscribed may be either publisher defined event streams or 22 nodes/subtrees of YANG Datastores. 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 August 4, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Dynamic YANG Subscription with RESTCONF control . . . . . 3 62 4. Mandatory JSON and datastore support . . . . . . . . . . . . 6 63 5. Notification Messages . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. End-to-End Deployment Guidance . . . . . . . . . . . 9 70 A.1. Call Home . . . . . . . . . . . . . . . . . . . . . . . . 9 71 A.2. TLS Heartbeat . . . . . . . . . . . . . . . . . . . . . . 9 72 Appendix B. RESTCONF over GRPC . . . . . . . . . . . . . . . . . 9 73 Appendix C. Encoded Subscription and Notification Message 74 Examples . . . . . . . . . . . . . . . . . . . . . . 10 75 C.1. RESTCONF Subscription and Events over HTTP1.1 . . . . . . 10 76 C.2. Event Notification over HTTP2 . . . . . . . . . . . . . . 14 77 Appendix D. Changes between revisions . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Mechanisms to support event subscription and push are defined in 83 [I-D.draft-ietf-netconf-subscribed-notifications]. Enhancements to 84 [I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG 85 Datastore subscription and push are defined in 86 [I-D.ietf-netconf-yang-push]. This document provides a transport 87 specification for these protocols over RESTCONF and HTTP. Driving 88 these requirements is [RFC7923]. 90 The streaming of notifications encapsulating the resulting 91 information push can be done with either HTTP1.1 and HTTP2. When 92 using HTTP2 [RFC7540] benefits which can be realized include: 94 o Elimination of head-of-line blocking 95 o Weighting and proportional dequeuing of Events from different 96 subscriptions 98 o Explicit precedence in subscriptions so that events from one 99 subscription must be sent before another dequeues 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 The following terms use the definitions from 108 [I-D.draft-ietf-netconf-subscribed-notifications]: configured 109 subscription, dynamic subscription, notification message, publisher, 110 receiver, subscriber, and subscription. 112 3. Solution 114 Subscribing to event streams is defined in 115 [I-D.draft-ietf-netconf-subscribed-notifications], YANG Datastore 116 subscription is defined in [I-D.ietf-netconf-yang-push]. This 117 section specifies transport mechanisms applicable to both. 119 3.1. Dynamic YANG Subscription with RESTCONF control 121 Dynamic subscriptions for both 122 [I-D.draft-ietf-netconf-subscribed-notifications] and its 123 [I-D.ietf-netconf-yang-push] augmentations are configured and managed 124 via signaling messages transported over [RFC8040]. These 125 interactions will be accomplished via a RESTCONF POST into RPCs 126 located on the publisher. HTTP responses codes will indicate the 127 results of the interaction with the publisher. An HTTP status code 128 of 200 is the proper response to a successful RPC call. The successful will 130 result in a HTTP message with returned subscription URI on a 131 logically separate mechanism than was used for the original RESTCONF 132 POST. This mechanism is via a parallel TCP connection in the case of 133 HTTP 1.x, or in the case of HTTP2 via a separate HTTP stream within 134 the HTTP connection. When a being returned by the publisher, failure 135 will be indicated by 4xx range status codes transported in payload. 136 Anytime hints are returned from the publisher status code 412 is used 137 with the error-tag "operation-failed". 139 Once established, the resulting stream of notification messages are 140 then delivered via SSE for HTTP1.1 and via an HTTP2 DATA frame for 141 HTTP2. 143 3.1.1. Call Flow for HTTP2 145 Requests to [I-D.draft-ietf-netconf-subscribed-notifications] or 146 [I-D.ietf-netconf-yang-push] augmented RPCs are sent on one or more 147 HTTP2 streams indicated by (a) in Figure 2. Notification messages 148 related to a single subscription are pushed on a unique logical 149 channel (b). In the case below, a newly established subscription has 150 its associated messages pushed over HTTP2 stream (7). 152 +------------+ +------------+ 153 | Subscriber | | Publisher | 154 |HTTP2 Stream| |HTTP2 Stream| 155 | (a) (b) | | (a) (b) | 156 +------------+ +------------+ 157 | RESTCONF POST (RPC:establish-subscription) | 158 |--------------------------------------------->| 159 | HTTP 200 OK (URI)| 160 |<---------------------------------------------| 161 | (7)HTTP POST (URI) (7) 162 | |--------------------------------------------->| 163 | | HTTP 200 OK| 164 | |<---------------------------------------------| 165 | | HTTP Data (event-notif)| 166 | |<---------------------------------------------| 167 | RESTCONF POST (RPC:modify-subscription) | | 168 |--------------------------------------------->| | 169 | | HTTP 200 OK| | 170 |<---------------------------------------------| | 171 | | HTTP Data (subscription-modified)| 172 | |<---------------------------------------------| 173 | | HTTP Data (event-notif)| 174 | |<---------------------------------------------| 175 | RESTCONF POST (RPC:delete-subscription) | | 176 |--------------------------------------------->| | 177 | | HTTP 200 OK| | 178 |<---------------------------------------------| | 179 | | HTTP Headers (end of stream)| 180 | (/7)<-----------------------------------------(/7) 181 | 183 Figure 1: Dynamic with HTTP2 185 3.1.2. Call flow for HTTP1.1 187 Requests to [I-D.ietf-netconf-yang-push] RPCs are sent on the TCP 188 connection indicated by (a). Notification messages are pushed on a 189 separate connection (b). This connection (b) will be used for all 190 notification messages across all subscriptions. 192 +--------------+ +--------------+ 193 | Subscriber | | Publisher | 194 |TCP connection| |TCP connection| 195 | (a) (b) | | (a) (b) | 196 +--------------+ +--------------+ 197 | RESTCONF POST (RPC:establish-subscription) | 198 |--------------------------------------------->| 199 | HTTP 200 OK (URI)| 200 |<---------------------------------------------| 201 | |HTTP GET (URI) | 202 | |--------------------------------------------->| 203 | | HTTP 200 OK| 204 | |<---------------------------------------------| 205 | | SSE (event-notif)| 206 | |<---------------------------------------------| 207 | RESTCONF POST (RPC:modify-subscription) | | 208 |--------------------------------------------->| | 209 | | HTTP 200 OK| | 210 |<---------------------------------------------| | 211 | | SSE (subscription-modified)| 212 | |<---------------------------------------------| 213 | | SSE (event-notif)| 214 | |<---------------------------------------------| 215 | RESTCONF POST (RPC:delete-subscription) | | 216 |--------------------------------------------->| | 217 | | HTTP 200 OK| | 218 |<---------------------------------------------| | 219 | | | 220 | | 222 Figure 2: Dynamic with HTTP1.1 224 3.1.3. Configured Subscription over HTTP2 226 With a configured subscription, all information needed to establish a 227 secure relationship with that receiver is available on the publisher. 228 With this information, the publisher will establish a secure 229 transport connection with the receiver and then begin pushing 230 notification messages to the receiver. Since RESTCONF might not 231 exist on the receiver, it is not desirable to require that subscribed 232 content be pushed with any dependency on RESTCONF. Therefore in 233 place of RESTCONF, a TLS secured HTTP2 Client connection must be 234 established with an HTTP2 Server located on the receiver. 235 Notification messages will then be sent as part of an extended HTTP 236 POST to the receiver. 238 POST messages will be addressed to HTTP augmentation code on the 239 receiver capable of accepting and responding to state change 240 notifications and subscribed content notification messages. The 241 first POST message must be a subscription-started notification. 242 Notifications which include any subscribed content must not be sent 243 until the receipt of an HTTP 200 OK for this initial notification. 244 The 200 OK will indicate that the receiver is ready for the delivery 245 of subscribed content. At this point a subscription must be 246 allocated its own HTTP2 stream. Figure 4 depicts this message flow. 248 +------------+ +------------+ 249 | Receiver | | Publisher | 250 |HTTP2 Stream| |HTTP2 Stream| 251 | (a) (b) | | (a) (b) | 252 +------------+ +------------+ 253 | HTTP Post Headers, Data (sub-start, SubID)| 254 |<---------------------------------------------| 255 | HTTP 200 OK | 256 |--------------------------------------------->| 257 | | HTTP Post Headers, Data (event-notif)| 258 | |<---------------------------------------------| 259 | | HTTP Data (event-notif)| 260 | |<---------------------------------------------| 261 | | HTTP Data (sub-terminate)| 262 | |<---------------------------------------------| 263 | |HTTP 200 OK | 264 | |--------------------------------------------->| 266 Figure 3: Configured over HTTP2 268 As the HTTP2 transport is available to the receiver, the publisher 269 should: 271 o take any subscription-priority and copy it into the HTTP2 stream 272 priority, and 274 o take a subscription-dependency if it has been provided and map the 275 HTTP2 stream for the parent subscription into the HTTP2 stream 276 dependency. 278 4. Mandatory JSON and datastore support 280 A publisher MUST support JSON encoding of RPCs and Notifications. 282 A publisher supporting [I-D.ietf-netconf-yang-push] MUST support the 283 "operational" datastore as defined by 284 [I.D.draft-ietf-netmod-revised-datastores]. 286 5. Notification Messages 288 Notification messages transported over NETCONF will be identical in 289 format and content to those encoded using one-way operations defined 290 within [RFC5277], section 4. 292 6. Security Considerations 294 One or more publishers of configured subscriptions could be used to 295 overwhelm a receiver which doesn't even support subscriptions. There 296 are two protections needing support on a publisher. First, 297 notification messages for configured subscriptions MUST only be 298 transmittable over encrypted transports. Clients which do not want 299 pushed content need only terminate or refuse any transport sessions 300 from the publisher. Second, the HTTP transport augmentation on the 301 receiver must send an HTTP 200 OK to a subscription started 302 notification before the publisher starts streaming any subscribed 303 content. 305 One or more publishers could overwhelm a receiver which is unable to 306 control or handle the volume of Event Notifications received. In 307 deployments where this might be a concern, HTTP2 transport such as 308 HTTP2) should be selected. 310 The NETCONF Authorization Control Model [RFC6536] SHOULD be used to 311 control and restrict authorization of subscription configuration. 313 7. Acknowledgments 315 We wish to acknowledge the helpful contributions, comments, and 316 suggestions that were received from: Susan Hares, Tim Jenkins, Balazs 317 Lengyel, Kent Watsen, Michael Scharf, and Guangying Zheng. 319 8. References 321 8.1. Normative References 323 [I-D.draft-ietf-netconf-subscribed-notifications] 324 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., 325 and E. Nilsen-Nygaard, "Custom Subscription to Event 326 Streams", draft-ietf-netconf-subscribed-notifications-06 327 (work in progress), January 2018. 329 [I.D.draft-ietf-netmod-revised-datastores] 330 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 331 and R. Wilton, "Network Management Datastore 332 Architecture", draft-ietf-netmod-revised-datastores-04 333 (work in progress), August 2017. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 341 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 342 . 344 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 345 Layer Security (TLS) and Datagram Transport Layer Security 346 (DTLS) Heartbeat Extension", RFC 6520, 347 DOI 10.17487/RFC6520, February 2012, 348 . 350 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 351 Protocol (NETCONF) Access Control Model", RFC 6536, 352 DOI 10.17487/RFC6536, March 2012, 353 . 355 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 356 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 357 DOI 10.17487/RFC7540, May 2015, 358 . 360 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 361 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 362 . 364 8.2. Informative References 366 [GRPC] "RPC framework that runs over HTTP2", August 2017, 367 . 369 [I-D.ietf-netconf-yang-push] 370 Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy, 371 A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, 372 "Subscribing to YANG datastore push updates", March 2017, 373 . 376 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 377 for Subscription to YANG Datastores", RFC 7923, 378 DOI 10.17487/RFC7923, June 2016, 379 . 381 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 382 RFC 7951, DOI 10.17487/RFC7951, August 2016, 383 . 385 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 386 RFC 8071, DOI 10.17487/RFC8071, February 2017, 387 . 389 [W3C-20150203] 390 "Server-Sent Events, World Wide Web Consortium CR CR- 391 eventsource-20121211", February 2015, 392 . 394 Appendix A. End-to-End Deployment Guidance 396 Several technologies are expected to be seen within a deployment to 397 achieve security and ease-of-use requirements. These are not 398 necessary for an implementation of this specification, but will be 399 useful to consider when considering the operational context. 401 A.1. Call Home 403 Implementations should include the ability to transparently 404 incorporate 'call home' [RFC8071] so that secure TLS connections can 405 originate from the desired device. 407 A.2. TLS Heartbeat 409 HTTP sessions might not quickly allow a subscriber to recognize when 410 the communication path has been lost from the publisher. To 411 recognize this, it is possible for a receiver to establish a TLS 412 heartbeat [RFC6520]. In the case where a TLS heartbeat is included, 413 it should be sent just from receiver to publisher. Loss of the 414 heartbeat should result in any subscription related TCP sessions 415 between those endpoints being torn down. The subscription can then 416 attempt to re-establish. 418 Appendix B. RESTCONF over GRPC 420 An initial goal for this document was to support [GRPC] transport 421 seamlessly without any mapping or extra layering. However there is 422 an incompatibility of RESTCONF and GRPC. RESTCONF uses HTTP GET, and 423 GRPC uses HTTP2's POST rather than GET. As GET is used across 424 RESTCONF for things like capabilities exchange, a seamless mapping 425 depends on specification changes outside the scope of this document. 426 If/when GRPC supports GET, or RESTCONF is updated to support POST, 427 this should be revisited. It is hoped that the resulting fix will be 428 transparent to this document. 430 Appendix C. Encoded Subscription and Notification Message Examples 432 (Note: examples in this section need significant updates) 434 C.1. RESTCONF Subscription and Events over HTTP1.1 436 Subscribers can dynamically learn whether a RESTCONF server supports 437 various types of Event or Yang datastore subscription capabilities. 438 This is done by issuing an HTTP request OPTIONS, HEAD, or GET on the 439 stream. Some examples building upon the Call flow for HTTP1.1 from 440 Section 3.2.2 are: 442 GET /restconf/data/ietf-restconf-monitoring:restconf-state/ 443 streams/stream=yang-push HTTP/1.1 444 Host: example.com 445 Accept: application/yang.data+xml 447 If the server supports it, it may respond 449 HTTP/1.1 200 OK 450 Content-Type: application/yang.api+xml 451 452 yang-push 453 Yang push stream 454 455 xml 456 https://example.com/streams/yang-push-xml 457 458 459 460 json 461 https://example.com/streams/yang-push-json 462 463 464 466 If the server does not support any form of subscription, it may 467 respond 469 HTTP/1.1 404 Not Found 470 Date: Mon, 25 Apr 2012 11:10:30 GMT 471 Server: example-server 473 Subscribers can determine the URL to receive updates by sending an 474 HTTP GET as a request for the "location" leaf with the stream list 475 entry. The stream to use for may be selected from the Event Stream 476 list provided in the capabilities exchange. Note that different 477 encodings are supporting using different Event Stream locations. For 478 example, the subscriber might send the following request: 480 GET /restconf/data/ietf-restconf-monitoring:restconf-state/ 481 streams/stream=yang-push/access=xml/location HTTP/1.1 482 Host: example.com 483 Accept: application/yang.data+xml 485 The publisher might send the following response: 487 HTTP/1.1 200 OK 488 Content-Type: application/yang.api+xml 489 491 https://example.com/streams/yang-push-xml 492 494 To subscribe and start receiving updates, the subscriber can then 495 send an HTTP GET request for the URL returned by the publisher in the 496 request above. The accept header must be "text/event-stream". The 497 publisher uses the Server Sent Events [W3C-20150203] transport 498 strategy to push filtered events from the event stream. 500 The publisher MUST support individual parameters within the POST 501 request body for all the parameters of a subscription. The only 502 exception is the encoding, which is embedded in the URI. An example 503 of this is: 505 // subtree filter = /foo 506 // periodic updates, every 5 seconds 507 POST /restconf/operations/ietf-subscribed-notifications: 508 establish-subscription HTTP/1.1 509 Host: example.com 510 Content-Type: application/yang-data+json 512 { 513 "ietf-subscribed-notifications:input" : { 514 "stream": "push-data" 515 "period" : 5, 516 "xpath-filter" : "/ex:foo[starts-with('bar'.'some']" 517 } 518 } 520 Should the publisher not support the requested subscription, it may 521 reply: 523 HTTP/1.1 501 Not Implemented 524 Date: Mon, 23 Apr 2012 17:11:00 GMT 525 Server: example-server 526 Content-Type: application/yang.errors+xml 527 528 529 application 530 operation-not-supported 531 error 532 Xpath filters not supported 533 534 536 537 538 539 540 542 with an equivalent JSON encoding representation of: 544 HTTP/1.1 501 Not Implemented 545 Date: Mon, 23 Apr 2012 17:11:00 GMT 546 Server: example-server 547 Content-Type: application/yang.errors+json 548 { 549 "ietf-restconf:errors": { 550 "error": { 551 "error-type": "protocol", 552 "error-tag": "operation-not-supported", 553 "error-message": "Xpath filters not supported." 554 "error-info": { 555 "datastore-push:supported-subscription": { 556 "subtree-filter": [null] 557 } 558 } 559 } 560 } 561 } 563 The following is an example of a pushed content for the subscription 564 above. It contains a subtree with root foo that contains a leaf 565 called bar: 567 XML encoding representation: 568 569 570 572 my-sub 573 574 2015-03-09T19:14:56.233Z 575 577 578 some_string 579 580 581 583 Or with the equivalent YANG over JSON encoding representation as 584 defined in [RFC7951]: 586 { 587 "ietf-restconf:notification": { 588 "datastore-push:subscription-id": "my-sub", 589 "eventTime": "2015-03-09T19:14:56.233Z", 590 "datastore-push:datastore-contents": { 591 "example-mod:foo": { "bar": "some_string" } 592 } 593 } 594 } 596 To modify a subscription, the subscriber issues another POST request 597 on the provided URI using the same subscription-id as in the original 598 request. For example, to modify the update period to 10 seconds, the 599 subscriber may send: 601 POST /restconf/operations/ietf-subscribed-notifications: 602 modify-subscription HTTP/1.1 603 Host: example.com 604 Content-Type: application/yang-data+json 606 { 607 "ietf-subscribed-notifications:input" : { 608 "subscription-id": 100, 609 "period" : 10 610 } 611 } 613 To delete a subscription, the subscriber issues a DELETE request on 614 the provided URI using the same subscription-id as in the original 615 request 617 C.2. Event Notification over HTTP2 619 The basic encoding will look as below. It will consists of a JSON 620 representation wrapped in an HTTP2 header. 622 HyperText Transfer Protocol 2 623 Stream: HEADERS, Stream ID: 5 624 Header: :method: POST 625 Stream: HEADERS, Stream ID: 5 627 { 628 "ietf-yangpush:notification": { 629 "datastore-push:subscription-id": "my-sub", 630 "eventTime": "2015-03-09T19:14:56.233Z", 631 "datastore-push:datastore-contents": { 632 "foo": { "bar": "some_string" } 633 } 634 } 635 } 637 Appendix D. Changes between revisions 639 (To be removed by RFC editor prior to publication) 641 v03 - v04 643 o Draft not fully synched to new version of subscribed-notifications 644 yet. 646 o References updated 648 v02 - v03 650 o Event notification reframed to notification message. 652 o Tweaks to wording/capitalization/format. 654 v01 - v02 656 o Removed sections now redundant with 657 [I-D.draft-ietf-netconf-subscribed-notifications] and 658 [I-D.ietf-netconf-yang-push] such as: mechanisms for subscription 659 maintenance, terminology definitions, stream discovery. 661 o 3rd party subscriptions are out-of-scope. 663 o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions 665 o Timeframes for event tagging are self-defined. 667 o Clean-up of wording, references to terminology, section numbers. 669 v00 - v01 671 o Removed the ability for more than one subscription to go to a 672 single HTTP2 stream. 674 o Updated call flows. Extensively. 676 o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions 678 o HTTP is not used to determine that a receiver has gone silent and 679 is not Receiving Event Notifications 681 o Many clean-ups of wording and terminology 683 Authors' Addresses 685 Eric Voit 686 Cisco Systems 688 Email: evoit@cisco.com 690 Ambika Prasad Tripathy 691 Cisco Systems 693 Email: ambtripa@cisco.com 695 Einar Nilsen-Nygaard 696 Cisco Systems 698 Email: einarnn@cisco.com 700 Alexander Clemm 701 Huawei 703 Email: ludwig@clemm.org 704 Alberto Gonzalez Prieto 705 VMWare 707 Email: agonzalezpri@vmware.com 709 Andy Bierman 710 YumaWorks 712 Email: andy@yumaworks.com