idnits 2.17.00 (12 Aug 2021) /tmp/idnits9350/draft-voit-netconf-restconf-yang-push-02.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 (March 17, 2016) is 2255 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF E. Voit 3 Internet-Draft A. Clemm 4 Intended status: Informational A. Tripathy 5 Expires: September 18, 2016 E. Nilsen-Nygaard 6 A. Gonzalez Prieto 7 Cisco Systems 8 March 17, 2016 10 Restconf, HTTP, and HTTP2 Transport for YANG Push 11 draft-voit-netconf-restconf-yang-push-02 13 Abstract 15 This document defines YANG Subscription and Push mechanisms for 16 Restconf, HTTP, and HTTP2 transports. 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 http://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 September 18, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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 (http://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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Subscription Model . . . . . . . . . . . . . . . . . . . 3 56 3.2. Mechanisms for Subscription Establishment and Maintenance 3 57 3.3. Subscription Multiplexing . . . . . . . . . . . . . . . . 6 58 3.4. Push Data Stream and Transport Mapping . . . . . . . . . 7 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 60 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 61 5.1. Normative References . . . . . . . . . . . . . . . . . . 13 62 5.2. Informative References . . . . . . . . . . . . . . . . . 13 63 Appendix A. Dynamic YANG Subscription when the Subscriber and 64 Receiver are different . . . . . . . . . . . . . . . 14 65 Appendix B. End-to-End Deployment Guidance . . . . . . . . . . . 15 66 B.1. Call Home . . . . . . . . . . . . . . . . . . . . . . . . 16 67 B.2. TLS Heartbeat . . . . . . . . . . . . . . . . . . . . . . 16 68 B.3. Putting it together . . . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 Requirements for subscriptions to YANG datastores are defined in 74 [pub-sub-reqs]. Mechanisms to support YANG subscriptions and 75 datastore object push over a NETCONF are defined in [yang-push]. 76 Restconf support is also needed by the market. This document 77 provides such a specification for Restconf by reusing the YANG data 78 model, and expanding the transport requirements of [yang-push]. 80 These extensions are not limited to just Restconf. There are 81 benefits which can be realized when transporting push updates 82 directly over HTTP such as simplified support for static 83 subscriptions. Additionally if HTTP/2 [RFC7540] transport is used, 84 HTTP/2 capabilities which can be applied include: 86 o Subscription multiplexing over independent HTTP/2 streams 88 o Stream prioritization and stream dependencies 90 o Flow control on independent streams 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 Datastore: a conceptual store of instantiated management information, 99 with individual data items represented by data nodes which are 100 arranged in hierarchical manner. 102 Dynamic Subscription: a Subscription negotiated between Subscriber 103 and Publisher via create, establish, modify, and delete RPC control 104 plane signaling messages. 106 Publisher: an entity responsible for distributing subscribed YANG 107 object data per the terms of a Subscription. In general, a Publisher 108 is the owner of the YANG datastore that is subjected to the 109 Subscription. 111 Receiver: a target to which Publisher pushes updates. In many 112 deployments, the Receiver and Subscriber will be the same entity. 114 Static Subscription: A Subscription installed via a configuration 115 interface. 117 Subscriber: an entity able to request and negotiate a contract for 118 push updates from a Publisher. 120 Subscription: a contract between a Subscriber and a Publisher, 121 stipulating which information the Receiver wishes to have pushed from 122 the Publisher without the need for further solicitation. 124 Subscription Update: a set of data nodes and object values pushed 125 together as a unit and intended to meet the obligations of a single 126 subscription at a snapshot in time. 128 3. Solution 130 This document specifies transport mechanisms that allow subscribed 131 information updates to be pushed from a YANG datastore. 133 3.1. Subscription Model 135 Subscriptions use the base data model and subscription state machine 136 from [yang-push]. 138 3.2. Mechanisms for Subscription Establishment and Maintenance 140 On a Publisher, it must be possible to instantiate a Subscription via 141 dynamic Subscriber signaling, as well as via Static configuration. 143 Dynamic Subscriptions are signaled Subscriptions aimed at the running 144 datastore and are unable to impact the startup configuration. They 145 should always terminate when there is loss of transport session 146 connectivity between the Publisher and Receiver. 148 Static Subscriptions are applied via an operations interface to the 149 startup and running configurations. Loss or non-availability of 150 transport session connectivity will place the Subscription into the 151 suspended state. Logic beyond the scope of this specification will 152 dictate when any particular Subscription should be reactivated. 153 There are three models for Subscription establishment and 154 maintenance: 156 1. Dynamic Subscription: Subscriber and Receiver are the same 158 2. Static Subscription 160 3. Dynamic Subscription: Subscriber and Receiver are different 162 The first two are described in this section. The third is described 163 in Appendix A. This third option can be moved into the body of this 164 specification should the IETF community desire. In theory, all three 165 models may be intermixed in a single deployment. 167 .---------------. 168 | Publisher | 169 '---------------' 170 ^ ^ | ^ 171 | | | | 172 .-----Restconf----' | | '-----Restconf----. 173 | .-----' '-HTTP-. | 174 V | V | 175 .-------------. .------------. .----------. .------------. 176 | Subscriber+ | | Operations | | Receiver | | Subscriber | 177 | Receiver | | /Config | '----------' '------------' 178 '-------------' '------------' ^ ^ ^ 179 ^ (out of scope) : : : 180 : ^ : :....Model 3....: 181 Model 1 :...Model 2...: (out of scope) 183 3.2.1. Dynamic YANG Subscription: Subscriber and Receiver are the same 185 With all Dynamic Subscriptions, as with [yang-push] it must be 186 possible to configure and manage Subscriptions via signaling. This 187 signaling is transported over [restconf]. Once established, 188 streaming Subscription Updates are then delivered via Restconf SSE. 190 3.2.2. Static Subscription 192 With a Static Subscription, all information needed to establish a 193 secure object push relationship with that Receiver must be configured 194 via a configuration interface on the Publisher. This information 195 includes all the signaled information identified in section 3.2.1. 196 This information also include the Receiver address, egress interface 197 instructions, and security credentials required to establish TLS 198 between the Publisher and Receiver. Mechanisms for locally 199 configuring these parameters are outside the scope of this document. 201 With this information, the Publisher will establish a secure 202 transport connection with the Receiver and then begin pushing the 203 streaming updates to the Receiver. Since Restconf might not exist on 204 the Receiver, it is not desirable to require that updates be pushed 205 via Restconf. In place of Restconf, a TLS secured HTTP Client 206 connection must be established with an HTTP Server located on the 207 Receiver. Subscription Updates will then be sent via HTTP Post 208 messages to the Receiver. 210 Post messages will be addressed to HTTP augmentation code on the 211 Receiver capable accepting and responding to Subscription Updates. 212 At least the initial Post message must include the URI for the 213 subscribed resource. This URI can be retained for future use by the 214 Receiver. 216 After successful receipt of an initial Subscription Update for a 217 particular Subscription, this augmentation should reply back with an 218 HTTP status code of 201 (Created). Further successful receipts 219 should result in the return of code of 202 (Accepted). At any point, 220 receipt of any status codes from 300-510 with the exception of 408 221 (Request Timeout) should result in the movement of the Subscription 222 to the suspended state. A sequential series of multiple 408 223 exceptions should also drive the Subscription to a suspended state. 225 Security on an HTTP client/Publisher can be strengthened by only 226 accepting Response code feedback for recently initiated HTTP POSTs. 228 Figure 3 depicts this message flow. 230 +-----------+ +----------+ 231 | Publisher | | Receiver | 232 +-----------+ +----------+ 233 |<--------------TLS------------>| 234 | | 235 |HTTP POST (Sub ID, URI, data1) | 236 |------------------------------>| 237 | HTTP 201 (Created)| 238 |<------------------------------| 239 |HTTP POST (Sub ID, data2) | 240 |------------------------------>| 241 | HTTP 200 or 202 (Accepted)| 242 |<------------------------------| 243 | data3 | 244 |<----------------------------->| 246 If HTTP/2 transport is available to a Receiver, the Publisher should 247 also: 249 o point individual Subscription Updates to a unique HTTP/2 stream 250 for that Subscription, 252 o take any subscription-priority and provision it into the HTTP/2 253 stream priority, and 255 o take any subscription-dependency and provision it into the HTTP/2 256 stream dependency. 258 3.3. Subscription Multiplexing 260 When pushed directly over HTTP/2, it is expected that each 261 Subscription Update will be allocated a separate Stream. The will 262 enable multiplexing, and address issues of Head-of-line blocking with 263 different priority Subscriptions. 265 When pushed via Restconf over HTTP/2, different Subscriptions will 266 not be mapped to independent HTTP/2 streams. When Restconf specifies 267 this mapping, it should be integrated into this specification. 269 Even without HTTP/2 multiplexing, it is possible that updates might 270 be delivered in a different sequence than generated. Reasons for 271 this might include (but are not limited to): 273 o different durations needed to create various Subscription Updates, 275 o marshalling and bundling of multiple Subscription Updates for 276 transport, and 278 o parallel HTTP1.1 sessions 280 Therefore each Subscription Update will include a microsecond level 281 timestamp to ensure that a receiver understands the time when a that 282 update was generated. Use of this timestamp can give an indication 283 of the state of objects at a Publisher when state-entangled 284 information is received across different subscriptions. The use of 285 the latest Subscription Update timestamp for a particular object 286 update can introduce errors. So when state-entangled updates have 287 inconsistent object values and temporally close timestamps, a 288 Receiver might consider performing a 'get' to validate the current 289 state of objects. 291 3.4. Push Data Stream and Transport Mapping 293 Transported updates will contain data for one or more Subscription 294 Updates. Each transported Subscription Update notification contains 295 several parameters: 297 o A global subscription ID correlator, referencing the name of the 298 Subscription on whose behalf the notification is sent. 300 o Data nodes containing a representation of the datastore subtree 301 containing the updates. The set of data nodes must be filtered 302 per access control rules to contain only data that the subscriber 303 is authorized to see. 305 o An event time which contains the time stamp at publisher when the 306 event is generated. 308 3.4.1. Pushing Subscription Updates via Restconf 310 Subscribers can dynamically learn whether a RESTCONF server supports 311 yang-push. This is done by issuing an HTTP request OPTIONS, HEAD, or 312 GET on the stream push-update. E.g.: 314 GET /restconf/data/ietf-restconf-monitoring:restconf-state/ 315 streams/stream=yang-push HTTP/1.1 316 Host: example.com 317 Accept: application/yang.data+xml 319 If the server supports it, it may respond 320 HTTP/1.1 200 OK 321 Content-Type: application/yang.api+xml 322 323 yang-push 324 Yang push stream 325 326 xml 327 https://example.com/streams/yang-push-xml 328 329 330 331 json 332 https://example.com/streams/yang-push-json 333 334 335 337 If the server does not support yang push, it may respond 339 HTTP/1.1 404 Not Found 340 Date: Mon, 25 Apr 2012 11:10:30 GMT 341 Server: example-server 343 Subscribers can determine the URL to receive updates by sending an 344 HTTP GET request for the "location" leaf with the stream list entry. 345 The stream to use for yang push is the push-update stream. The 346 location returned by the publisher can be used for the actual 347 notification subscription. Note that different encodings are 348 supporting using different locations. For example, he subscriber 349 might send the following request: 351 GET /restconf/data/ietf-restconf-monitoring:restconf-state/ 352 streams/stream=yang-push/access=xml/location HTTP/1.1 353 Host: example.com 354 Accept: application/yang.data+xml 356 The publisher might send the following response: 358 HTTP/1.1 200 OK 359 Content-Type: application/yang.api+xml 360 362 https://example.com/streams/yang-push-xml 363 365 To subscribe and start receiving updates, the subscriber can then 366 send an HTTP GET request for the URL returned by the publisher in the 367 request above. The accept header must be "text/event -stream". The 368 publisher handles the connection as an event stream, using the Server 369 Sent Events[W3C-20121211] transport strategy. 371 The publisher MUST support as query parameters for a GET method on 372 this resource all the parameters of a subscription. The only 373 exception is the encoding, which is embedded in the URI. An example 374 of this is: 376 // subtree filter = /foo 377 // periodic updates, every 5 seconds 378 GET /mystreams/yang-push?subscription-id=my-sub&period=5& 379 xpath-filter=%2Fex:foo[starts-with("bar"."some"] 381 Should the publisher not support the requested subscription, it may 382 reply: 384 HTTP/1.1 501 Not Implemented 385 Date: Mon, 23 Apr 2012 17:11:00 GMT 386 Server: example-server 387 Content-Type: application/yang.errors+xml 388 389 390 application 391 operation-not-supported 392 error 393 Xpath filters not supported 394 395 397 398 399 400 401 403 with an equivalent JSON encoding representation of: 405 HTTP/1.1 501 Not Implemented 406 Date: Mon, 23 Apr 2012 17:11:00 GMT 407 Server: example-server 408 Content-Type: application/yang.errors+json 409 { 410 "ietf-restconf:errors": { 411 "error": { 412 "error-type": "protocol", 413 "error-tag": "operation-not-supported", 414 "error-message": "Xpath filters not supported." 415 "error-info": { 416 "datastore-push:supported-subscription": { 417 "subtree-filter": [null] 418 } 419 } 420 } 421 } 422 } 424 The following is an example of a push Subscription Update data for 425 the subscription above. It contains a subtree with root foo that 426 contains a leaf called bar: 428 XML encoding representation: 429 430 431 433 my-sub 434 435 2015-03-09T19:14:56Z 436 438 439 some_string 440 441 442 444 Or with the equivalent YANG over JSON encoding representation as 445 defined in[yang-json] : 447 { 448 "ietf-restconf:notification": { 449 "datastore-push:subscription-id": "my-sub", 450 "eventTime": "2015-03-09T19:14:56Z", 451 "datastore-push:datastore-contents": { 452 "example-mod:foo": { "bar": "some_string" } 453 } 454 } 455 } 457 To modify a subscription, the subscriber issues another GET request 458 on the provided URI using the same subscription-id as in the original 459 request. For example, to modify the update period to 10 seconds, the 460 subscriber may send: 462 GET /mystreams/yang-push?subscription-id=my-sub&period=10& 463 subtree-filter=%2Ffoo' 465 To delete a subscription, the subscriber issues a DELETE request on 466 the provided URI using the same subscription-id as in the original 467 request 469 DELETE /mystreams/yang-push?subscription-id=my-sub 471 3.4.2. Pushing Subscription Updates directly via HTTP 473 For any version of HTTP, the basic encoding will look as below is the 474 above JSON representation wrapped in an HTTP header. Mechanism will 475 be 476 POST (IP+Port) HTTP/1.1 477 From: (Identifier for Network Element) 478 User-Agent: (CiscoYANGPubSub/1.0) 479 Content-Type: multipart/form-data 480 Content-Length: (determined runtime) 481 { 482 "ietf-yangpush:notification": { 483 "datastore-push:subscription-id": "my-sub", 484 "eventTime": "2015-03-09T19:14:56Z", 485 "datastore-push:datastore-contents": { 486 "foo": { "bar": "some_string" } 487 } 488 } 489 } 491 4. Security Considerations 493 Subscriptions could be used to intentionally or accidentally overload 494 resources of a Publisher. For this reason, it is important that the 495 Publisher has the ability to prioritize the establishment and push of 496 updates where there might be resource exhaust potential. In 497 addition, a server needs to be able to suspend existing subscriptions 498 when needed. When this occurs, the subscription status must be 499 updated accordingly and the clients are notified. 501 A Subscription could be used to retrieve data in subtrees that a 502 client has not authorized access to. Therefore it is important that 503 data pushed via a Subscription is authorized equivalently with 504 regular data retrieval operations. Data being pushed to a client 505 needs therefore to be filtered accordingly, just like if the data 506 were being retrieved on-demand. The Netconf Authorization Control 507 Model [RFC6536] applies even though the transport is not NETCONF. 509 One or more Publishers could be used to overwhelm a Receiver which 510 doesn't even support subscriptions. Therefore Updates MUST only be 511 transmittable over Encrypted transports. Clients which do not want 512 pushed data need only terminate or refuse any transport sessions from 513 the Publisher. 515 One or more Publishers could overwhelm a Receiver which is unable to 516 control or handle the volume of Updates received. In deployments 517 where this might be a concern, transports supporting per-subscription 518 Flow Control and Prioritization (such as HTTP/2) should be selected. 520 Another benefit is that a well-behaved Publisher implementation is 521 that it is difficult to a Publisher to perform a DoS attack on a 522 Receiver. DoS attack protection comes from: 524 o the requirement for trust of a TLS session before publication, 526 o the need for an HTTP transport augmentation on the Receiver, and 528 o that the Publication process is suspended when the Receiver 529 doesn't respond. 531 5. References 533 5.1. Normative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, 538 . 540 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 541 Layer Security (TLS) and Datagram Transport Layer Security 542 (DTLS) Heartbeat Extension", RFC 6520, 543 DOI 10.17487/RFC6520, February 2012, 544 . 546 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 547 Protocol (NETCONF) Access Control Model", RFC 6536, 548 DOI 10.17487/RFC6536, March 2012, 549 . 551 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 552 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 553 DOI 10.17487/RFC7540, May 2015, 554 . 556 5.2. Informative References 558 [call-home] 559 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 560 December 2015, . 563 [pub-sub-reqs] 564 Voit, Eric., Clemm, Alexander., and Alberto. Gonzalez 565 Prieto, "Subscribing to datastore push updates", February 566 2016, . 569 [restconf] 570 Bierman, Andy., Bjorklund, Martin., and Kent. Watsen, 571 "RESTCONF Protocol", March 2016, 572 . 575 [W3C-20121211] 576 "Server-Sent Events, World Wide Web Consortium CR CR- 577 eventsource-20121211", December 2012, 578 . 580 [yang-json] 581 Lhotka, Ladislav., "JSON Encoding of Data Modeled with 582 YANG", March 2016, . 585 [yang-push] 586 Clemm, Alexander., Gonzalez Prieto, Alberto., Voit, Eric., 587 Prasad Tripathy, Ambika., and Einar. Nilsen-Nygaard, 588 "Subscribing to YANG datastore push updates", February 589 2016, . 592 Appendix A. Dynamic YANG Subscription when the Subscriber and Receiver 593 are different 595 The methods of Sections 3.2.1 and 3.2.2 can be combined to enable 596 deployment models where the Subscriber and Receiver are different. 597 Such separation can be useful with some combination of: 599 o An operator wants any Subscriptions immediately deleted should TLS 600 connectivity be lost. (I.e., Subscriptions don't default into a 601 'Suspended' state on the Publisher.) 603 o An operator wants the Publisher to include highly restrictive 604 capacity management and security mechanisms outside of domain of 605 existing operational or programmatic interfaces. 607 o Restconf is not desired on the Receiver. 609 o The Publisher doesn't want to maintain Restconf subscriptions with 610 many Receivers. 612 To do this, first the necessary information must be signaled as part 613 of the . This includes all the information 614 described in section 3.3.2, with the exception of the security 615 credentials. (It is assumed that any security credentials required 616 for establishing any transport connections are pre-provisioned on all 617 devices.) 619 Using this set of Subscriber provided information, the same process 620 described within section 3.3.2 will be followed. There is one 621 exception. When an HTTP status code is 201 is received by the 622 Publisher, it will inform the Subscriber of Subscription 623 establishment success via its Restconf connection. 625 After successful establishment, if the Subscriber wishes to maintain 626 the state of Receiver subscriptions, it can simply place a separate 627 on-change Subscription into the "Subscriptions" subtree of the YANG 628 Datastore on the Publisher. 630 Putting it all together, the message flow is: 632 +------------+ +-----------+ +----------+ 633 | Subscriber | | Publisher | | Receiver | 634 +------------+ +-----------+ +----------+ 635 | Restconf PUT: | | 636 | | | 637 |--------------------->| | 638 | | | 639 | |<-----------TLS------------>| 640 | | | 641 | |HTTP POST (Sub ID, data1, | 642 | |(stream ID, URI?)) | 643 | |--------------------------->| 644 | | HTTP 201 (Created)| 645 | |<---------------------------| 646 | Success: HTTP 204| | 647 |<---------------------| | 648 | |HTTP POST (Sub ID, data2) | 649 | |--------------------------->| 650 | | HTTP 200 or 202 (Accepted)| 651 | |<---------------------------| 652 | | data3 | 653 | |<-------------------------->| 654 | | | 656 Appendix B. End-to-End Deployment Guidance 658 Several technologies are expected to be seen within a deployment to 659 achieve security and ease-of-use requirements. These are not 660 necessary for an implementation of this specification, but will be 661 useful to consider when considering the operational context. 663 B.1. Call Home 665 Pub/Sub implementations should have the ability to transparently 666 incorporate lower layer technologies such as Call Home so that secure 667 TLS connections are always originated from the Publisher. There is a 668 Restconf Call home function in [call-home]. For security reasons, 669 this should be implemented when applicable. 671 B.2. TLS Heartbeat 673 Unlike NETCONF, HTTP sessions might not quickly allow a Subscriber to 674 recognize when the communication path has been lost from the 675 Publisher. To recognize this, it is possible for a Receiver (usually 676 the subscriber) to establish a TLS heartbeat [RFC6520]. In the case 677 where a TLS heartbeat is included, it should be sent just from 678 Receiver to Publisher. Loss of the heartbeat should result in the 679 Subscription being terminated with the Subscriber (even when the 680 Subscriber and Receiver are different). The Subscriber can then 681 attempt to re-establish the subscription if desired. If the 682 Subscription remains active on the Publisher, future receipt of 683 objects associated with that (or any other unknown) subscription ID 684 should result in a being returned to the 685 Publisher from the Receiver. 687 B.3. Putting it together 689 If Subscriber and receiver are same entity then subscriber can direct 690 send create_subscription message to publisher. Once the subscription 691 moved to accepted state, the receiver can use Server Sent Events 692 [W3C-20121211] transport strategy to subscriber event notifications 693 for the data as defined in [restconf]. 695 Authors' Addresses 697 Eric Voit 698 Cisco Systems 700 Email: evoit@cisco.com 702 Alexander Clemm 703 Cisco Systems 705 Email: alex@cisco.com 706 Ambika Prasad Tripathy 707 Cisco Systems 709 Email: ambtripa@cisco.com 711 Einar Nilsen-Nygaard 712 Cisco Systems 714 Email: einarnn@cisco.com 716 Alberto Gonzalez Prieto 717 Cisco Systems 719 Email: albertgo@cisco.com