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