idnits 2.17.1 draft-voit-netconf-restconf-notif-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 -- The document date (June 15, 2016) is 2866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 3 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: December 17, 2016 E. Nilsen-Nygaard 6 A. Gonzalez Prieto 7 Cisco Systems 8 June 15, 2016 10 Restconf and HTTP Transport for Event Notifications 11 draft-voit-netconf-restconf-notif-00 13 Abstract 15 This document defines Event Notification YANG Subscription and Push 16 mechanisms for 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 December 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Mechanisms for Subscription Establishment and Maintenance 4 56 3.2. Subscription Multiplexing . . . . . . . . . . . . . . . . 6 57 3.3. Push Data Stream and Transport Mapping . . . . . . . . . 7 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 62 6.2. Informative References . . . . . . . . . . . . . . . . . 14 63 Appendix A. Proxy YANG Subscription when the Subscriber and 64 Receiver are different . . . . . . . . . . . . . . . 14 65 Appendix B. End-to-End Deployment Guidance . . . . . . . . . . . 16 66 B.1. Call Home . . . . . . . . . . . . . . . . . . . . . . . . 16 67 B.2. TLS Heartbeat . . . . . . . . . . . . . . . . . . . . . . 16 68 Appendix C. Issues being worked and resolved . . . . . . . . . . 16 69 C.1. Unresolved Issues . . . . . . . . . . . . . . . . . . . . 16 70 C.2. Agreement in principal . . . . . . . . . . . . . . . . . 17 71 C.3. Resolved Issues . . . . . . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 Mechanisms to support Event subscription and push are defined in 77 [rfc5277bis]. Enhancements to [rfc5277bis] which enable YANG 78 Datastore subscription and push are defined in [yang-push]. This 79 document provides a transport specification for these Restconf and 80 HTTP. This has been driven by Requirements for subscriptions to YANG 81 datastores are defined in [pub-sub-reqs]. 83 Beyond based transport bindings, there are benefits which can be 84 realized when transporting updates directly HTTP/2[RFC7540] which cn 85 be realized via an implementation of this transport specification 86 including: 88 o Subscription multiplexing over independent HTTP/2 streams 90 o Stream prioritization and stream dependencies 92 o Flow control on independent streams 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 Configured Subscription: a Subscription installed via a configuration 101 interface which persissts across reboots. 103 Data Node: An instance of management information in a datastore. 105 Data Node Update: A data item containing the current value/property 106 of a Data Node at the time the Data Node Update was created. 108 Dynamic Subscription: a Subscription negotiated between Subscriber 109 and Publisher via create, establish, modify, and delete RPC control 110 plane signaling messages. 112 Event: an occurrence of something that may be of interest. (e.g., a 113 configuration change, a fault, a change in status, crossing a 114 threshold, status of a flow, or an external input to the system.) 116 Event Notification: a set of information intended for a Receiver 117 indicating that one or more Event(s) have occurred. Details of the 118 Event(s) may be included within. 120 Event Stream: a continuous, ordered set of Events grouped under an 121 explicit criteria. 123 Notification: the communication of an occurrence, perhaps triggered 124 by the occurrence of an Event. 126 Publisher: an entity responsible for streaming Event Notifications 127 per the terms of a Subscription. 129 Receiver: a target to which a Publisher pushes Event Notifications. 130 For Dynamic Subscriptions, the Receiver and Subscriber will often be 131 the same entity. 133 Subscriber: an entity able to request and negotiate a contract for 134 the receipt of Event Notifications from a Publisher 136 Subscription: a contract between a Subscriber and a Publisher 137 stipulating which information the Receiver wishes to have pushed from 138 the Publisher without the need for further solicitation. 140 3. Solution 142 Event subscription is defined in [rfc5277bis], YANG Datastore 143 subscription is defined in [yang-push]. This section specifies 144 transport mechanisms applicable to both. 146 3.1. Mechanisms for Subscription Establishment and Maintenance 148 There are three models for Subscription establishment and 149 maintenance: 151 1. Dynamic Subscription: Here the Subscriber and Receiver are the 152 same. A Subscription ends with a subscription-terminated 153 notification, or by a loss of transport connectivity. 155 2. Configured Subscription: Receiver(s) are specified on Publisher 156 in startup and running config. Subscription is not terminated 157 except via an operations interface. (Subscriptions may be 158 Suspended, with no Event Notifications sent however.) 160 3. Proxy Subscription: Subscriber and Receiver are different. 161 Subscription ends when a Subscription End-time is reached, or the 162 Publisher process is restarted. 164 The first two are described in this section. The third is described 165 in Appendix A. This third option can be moved into the body of this 166 specification should the IETF community desire. In theory, all three 167 models may be intermixed in a single deployment. 169 .---------------. 170 | Publisher | 171 '---------------' 172 ^ ^ | ^ 173 | | | | 174 .-----Restconf----' | | '-----Restconf----. 175 | .-----' '-HTTP-. | 176 V | V | 177 .-------------. .------------. .----------. .------------. 178 | Subscriber+ | | Operations | | Receiver | | Subscriber | 179 | Receiver | | /Config | '----------' '------------' 180 '-------------' '------------' ^ ^ ^ 181 ^ (out of scope) : : : 182 : ^ : :....Model 3....: 183 Model 1 :...Model 2...: (out of scope) 185 3.1.1. Dynamic YANG Subscription over RESTCONF 187 Dynamic Subscriptions are configured and manage Subscriptions via 188 signaling. This signaling is transported over [restconf]. Once 189 established, streaming Event Notifications are then delivered via 190 Restconf SSE. 192 3.1.2. Configured Subscription over HTTP 194 With a Configured Subscription, all information needed to establish a 195 secure relationship with that Receiver is configured on the 196 Publisher. With this information, the Publisher will establish a 197 secure transport connection with the Receiver and then begin pushing 198 the Event Notifications to the Receiver. Since Restconf might not 199 exist on the Receiver, it is not desirable to require that such Event 200 Notifications be pushed via Restconf. Nor is there value which 201 Restconf provides on top of HTTP. Therefore in place of Restconf, a 202 TLS secured HTTP Client connection must be established with an HTTP 203 Server located on the Receiver. Event Notifications will then be 204 sent via HTTP Post messages to the Receiver. 206 Post messages will be addressed to HTTP augmentation code on the 207 Receiver capable of accepting and responding to Event Notifications. 208 At least the initial Post message must include the URI for the 209 subscribed resource. This URI can be retained for operational 210 tracking and debugging use by the Receiver. 212 After successful receipt of an initial Event Notification for a 213 particular Subscription, the Reciever should reply back with an HTTP 214 status code of 201 (Created). Further successful receipts should 215 result in the return of code of 202 (Accepted). At any point, 216 receipt of any status codes from 300-510 with the exception of 408 217 (Request Timeout) should result in the movement of the Subscription 218 to the suspended state. A sequential series of multiple 408 219 exceptions should also drive the Subscription to a suspended state. 221 Security on an HTTP client/Publisher can be strengthened by only 222 accepting Response code feedback for recently initiated HTTP POSTs. 224 Figure 2 depicts this message flow. 226 +-----------+ +----------+ 227 | Publisher | | Receiver | 228 +-----------+ +----------+ 229 |<--------------TLS------------>| 230 | | 231 |HTTP POST (Sub ID, URI, data1) | 232 |------------------------------>| 233 | HTTP 201 (Created)| 234 |<------------------------------| 235 |HTTP POST (Sub ID, data2) | 236 |------------------------------>| 237 | HTTP 200 or 202 (Accepted)| 238 |<------------------------------| 239 | data3 | 240 |<----------------------------->| 242 If HTTP/2 transport is available to a Receiver, the Publisher should 243 also: 245 o point individual Event Notifications to a unique HTTP/2 stream for 246 that Subscription, 248 o take any subscription-priority and provision it into the HTTP/2 249 stream priority, and 251 o take any subscription-dependency and provision it into the HTTP/2 252 stream dependency. 254 3.2. Subscription Multiplexing 256 When pushed directly over HTTP/2, it is expected that the Event 257 Notifications from a single Subscription will be allocated a separate 258 HTTP/2 stream. This will enable multiplexing, and address issues of 259 Head-of-line blocking with different priority Subscriptions. 261 When pushed via Restconf over HTTP/2, different Subscriptions will 262 not be mapped to independent HTTP/2 streams. When Restconf specifies 263 this mapping, support may be appended on top of this specification. 265 With or without independent queueing of multiplexed subscriptions, it 266 is possible that updates might be delivered in a different sequence 267 than generated. Reasons for this might include (but are not limited 268 to): 270 o replay of pushed updates 272 o temporary loss of transport connectivity, with update buffering 273 and different dequeuing priorities per Subscription 275 o population, marshalling and bundling of independent Subscription 276 Updates, and 278 o parallel HTTP1.1 sessions 280 Therefore each Event Notification 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 Event Notification 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 a Publisher. 291 3.3. Push Data Stream and Transport Mapping 293 Transported updates will contain data for one or more Event 294 Notifications. Each transported Event Notification will contain 295 several parameters: 297 o A Subscription ID correlator 299 o Event Notification(s) . (Note 1: These must be filtered per access 300 control rules to contain only data that the Subscriber is 301 authorized to see. Note 2: these Event Notifications might be 302 Data Node Update(s).) 304 o A timestamp indication when the Event Notification was generated 305 on the Publisher. 307 3.3.1. Subscription and Updates via Restconf 309 Subscribers can dynamically learn whether a RESTCONF server supports 310 various types of Event or Yang datastore subscription. This is done 311 by issuing an HTTP request OPTIONS, HEAD, or GET on the stream. Some 312 examples building upon the existing RESTCONF mechanisms are below: 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 any form of subscription, it may 338 respond 340 HTTP/1.1 404 Not Found 341 Date: Mon, 25 Apr 2012 11:10:30 GMT 342 Server: example-server 344 Subscribers can determine the URL to receive updates by sending an 345 HTTP GET request for the "location" leaf with the stream list 346 entry.The stream to use for may be selected from the Event Stream 347 list provided in the capabilities exchange. Note that different 348 encodings are supporting using different Event Stream locations. For 349 example, the Subscriber 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 uses the Server Sent Events[W3C-20121211] transport 369 strategy to push filtered Event Notifications from the Event stream,. 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 pushed Event Notification 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.3.2. Subscription and Updates directly via HTTP 473 For any version of HTTP, the basic encoding will look as below. It 474 consists of a JSON representation wrapped in an HTTP header. 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 Event Notifications where there might be resource exhaust potential. 497 In addition, a server needs to be able to suspend existing 498 Subscriptions when needed. When this occurs, the subscription status 499 must be updated accordingly and the Receivers notified. 501 A Subscription could be used to attempt retrieve information for 502 which a Receiver has no authorized access. Therefore it is important 503 that data pushed via a Subscription is authorized equivalently with 504 regular data retrieval operations. Data being pushed to a Receiver 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 Event Notifications 511 for Configured Subscriptions MUST only be transmittable over 512 Encrypted transports. Clients which do not want pushed Event 513 Notifications need only terminate or refuse any transport sessions 514 from the Publisher. 516 One or more Publishers could overwhelm a Receiver which is unable to 517 control or handle the volume of Event Notifications received. In 518 deployments where this might be a concern, transports supporting per- 519 subscription Flow Control and Prioritization (such as HTTP/2) should 520 be selected. 522 Another benefit is that a well-behaved Publisher implementation is 523 that it is difficult to a Publisher to perform a DoS attack on a 524 Receiver. DoS attack protection comes from: 526 o the requirement for trust of a TLS session before publication, 528 o the need for an HTTP transport augmentation on the Receiver, and 530 o that the Publication process is suspended when the Receiver 531 doesn't respond. 533 5. Acknowledgments 535 We wish to acknowledge the helpful contributions, comments, and 536 suggestions that were received from: Andy Bierman, Sharon Chisholm, 537 Yan Gang, Peipei Guo, Susan Hares, Tim Jenkins, Balazs Lengyel, 538 Hector Trevino, Kent Watsen, and Guangying Zheng. 540 6. References 542 6.1. Normative References 544 [restconf] 545 Bierman, Andy., Bjorklund, Martin., and Kent. Watsen, 546 "RESTCONF Protocol", March 2016, 547 . 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 556 Layer Security (TLS) and Datagram Transport Layer Security 557 (DTLS) Heartbeat Extension", RFC 6520, 558 DOI 10.17487/RFC6520, February 2012, 559 . 561 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 562 Protocol (NETCONF) Access Control Model", RFC 6536, 563 DOI 10.17487/RFC6536, March 2012, 564 . 566 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 567 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 568 DOI 10.17487/RFC7540, May 2015, 569 . 571 6.2. Informative References 573 [call-home] 574 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 575 December 2015, . 578 [pub-sub-reqs] 579 Voit, Eric., Clemm, Alexander., and Alberto. Gonzalez 580 Prieto, "Subscribing to datastore push updates", February 581 2016, . 584 [rfc5277bis] 585 Gonzalez Prieto, Alberto., Clemm, Alexander., Voit, Eric., 586 Prasad Tripathy, Ambika., and Einar. Nilsen-Nygaard, 587 "NETCONF Event Notifications", March 2016, 588 . 591 [W3C-20121211] 592 "Server-Sent Events, World Wide Web Consortium CR CR- 593 eventsource-20121211", December 2012, 594 . 596 [yang-json] 597 Lhotka, Ladislav., "JSON Encoding of Data Modeled with 598 YANG", March 2016, . 601 [yang-push] 602 Clemm, Alexander., Gonzalez Prieto, Alberto., Voit, Eric., 603 Prasad Tripathy, Ambika., and Einar. Nilsen-Nygaard, 604 "Subscribing to YANG datastore push updates", February 605 2016, . 608 Appendix A. Proxy YANG Subscription when the Subscriber and Receiver 609 are different 611 The properties of Dynamic and Configured Subscriptions can be 612 combined to enable deployment models where the Subscriber and 613 Receiver are different. Such separation can be useful with some 614 combination of: 616 o An operator doesn't want the subscription to be dependent on the 617 maintenance of transport level keep-alives. (Transport 618 independence provides different scalability characteristics.) 620 o There is not a transport session binding, and a transient 621 Subscription needs to survive in an environment where there is 622 unreliable connectivity with the Receiver and/or Subscriber. 624 o An operator wants the Publisher to include highly restrictive 625 capacity management and Subscription security mechanisms outside 626 of domain of existing operational or programmatic interfaces. 628 To build a Proxy Subscription, first the necessary information must 629 be signaled as part of the . Using this set 630 of Subscriber provided information; the same process described within 631 section 3 will be followed. There is one exception. When an HTTP 632 status code is 201 is received by the Publisher, it will inform the 633 Subscriber of Subscription establishment success via its Restconf 634 connection. 636 After a successful establishment, if the Subscriber wishes to track 637 the state of Receiver subscriptions, it may choose to place a 638 separate on-change Subscription into the "Subscriptions" subtree of 639 the YANG Datastore on the Publisher. 641 Putting it all together, the message flow is: 643 +------------+ +-----------+ +----------+ 644 | Subscriber | | Publisher | | Receiver | 645 +------------+ +-----------+ +----------+ 646 | Restconf PUT: | | 647 | | | 648 |------------------------>| | 649 | | | 650 | |<-----------TLS------------>| 651 | | | 652 | |HTTP POST (Sub ID, data1, | 653 | |(stream ID, URI?)) | 654 | |--------------------------->| 655 | | HTTP 201 (Created)| 656 | |<---------------------------| 657 | Success: HTTP 204| | 658 |<------------------------| | 659 | |HTTP POST (Sub ID, data2) | 660 | |--------------------------->| 661 | | HTTP 200 or 202 (Accepted)| 662 | |<---------------------------| 663 | | data3 | 664 | |<-------------------------->| 665 | | | 667 Appendix B. End-to-End Deployment Guidance 669 Several technologies are expected to be seen within a deployment to 670 achieve security and ease-of-use requirements. These are not 671 necessary for an implementation of this specification, but will be 672 useful to consider when considering the operational context. 674 B.1. Call Home 676 Pub/Sub implementations should have the ability to transparently 677 incorporate lower layer technologies such as Call Home so that secure 678 TLS connections are always originated from the Publisher. There is a 679 Restconf Call home function in [call-home]. For security reasons, 680 this should be implemented when applicable. 682 B.2. TLS Heartbeat 684 Unlike NETCONF, HTTP sessions might not quickly allow a Subscriber to 685 recognize when the communication path has been lost from the 686 Publisher. To recognize this, it is possible for a Receiver (usually 687 the subscriber) to establish a TLS heartbeat [RFC6520]. In the case 688 where a TLS heartbeat is included, it should be sent just from 689 Receiver to Publisher. Loss of the heartbeat should result in the 690 Subscription being terminated with the Subscriber (even when the 691 Subscriber and Receiver are different). The Subscriber can then 692 attempt to re-establish the subscription if desired. If the 693 Subscription remains active on the Publisher, future receipt of 694 objects associated with that (or any other unknown) subscription ID 695 should result in a being returned to the 696 Publisher from the Receiver. 698 Appendix C. Issues being worked and resolved 700 (To be removed by RFC editor prior to publication) 702 C.1. Unresolved Issues 704 RT1 - Integration specifics for Restconf capability discovery on 705 different types of Streams 707 RT2 - In what way to we position "Event notifications" model in this 708 document vs. current solution in Restconf. 710 RT3 - Do we include 3rd party signaled subscriptions within models 711 that need to be supported generically, or for a particular type of 712 transport. 714 RT6 - We need to define encodings of rfc5277bis notifications for 715 both Restconf and HTTP. 717 RT7 - HTTP native option doesn't currently use SSE. But we should 718 evaluate moving to that as possible. It will make development 719 integration easier and more consistent. 721 C.2. Agreement in principal 723 RT4 - Need to add into document examples of 5277bis Event streams. 724 Document only includes yang-push examples at this point. 726 C.3. Resolved Issues 728 RT5 - Doesn't make sense to use Restconf for Configured 729 subscriptions. HTTP will be used. 731 Authors' Addresses 733 Eric Voit 734 Cisco Systems 736 Email: evoit@cisco.com 738 Alexander Clemm 739 Cisco Systems 741 Email: alex@cisco.com 743 Ambika Prasad Tripathy 744 Cisco Systems 746 Email: ambtripa@cisco.com 748 Einar Nilsen-Nygaard 749 Cisco Systems 751 Email: einarnn@cisco.com 753 Alberto Gonzalez Prieto 754 Cisco Systems 756 Email: albertgo@cisco.com