Re: [Netconf] SSE and HTTP/2 in restcon-notif

["Eric Voit (evoit)" <[e-mail]>]

> From: Reshad Rahman, September 27, 2018 5:04 PM
> 
> Hi Kent,
> 
> 
> On 2018-09-27, 2:49 PM, "Kent Watsen" <[e-mail]> wrote:
> 
> 
>     <chair plea>
>       Can we try to have a Last Call worthy version on the restcon-notif
>       draft by mid next week?  The chairs would like to Last Call both
>       NN + RN together if possible...
>     </chair plea>
> 
> <RR> I will strive to do so, no promises...
> 
>     As I understand it, there are three issues (any others?) as follows:
> 
>     1) SSE
> 
>        Actually, with Reshad's last response, this may not be an issue
>        anymore.  Just in case, I also feel that the *restconf*-notif draft
>        needs to align as closely as possible to the RFC 8040 notification
>        solution.  Ideally, we just use SSE outright and we're done.
> <RR> Yes, that's the plan.
> 
>     2) HTTP/2
> 
>        Not sure where this landed, but my thoughts are this draft needs to
>        support both 1.1 and 2.0.  I envision the variation being relatively
>        minor, something along the line of:
> 
>          if 1.1, then SSE.
>          if 2.0, client MAY open a stream first.
> <RR> I thought the agreement was to have no http2 in the spec, except maybe
> as an informational note. RFC8040 doesn't mention http2 at all.
> 
>     3) resource URIs
> 
>        This is likely where we need to spend the most time. We know that
>        establish-subscription returns a dynamically created URI, comparable
>        to what a client might get from ietf-restconf-monitoring:restconf-state\
>        /streams/stream/access/location.  Are there just two issues?
> 
>        a) how does the server ensure only said client accesses the resource?

With HTTP2, you can require that the same HTTP session be used as was used for the RESTCONF signaling.   For HTTP 1.1, perhaps there could be some comparison of the access credentials used across independent TLS sessions?  

>        b) how does the server know when it's okay to reclaim the resource,
>           when a client doesn't "delete" or "kill" the subscription?
> 
> <RR> I don't know. Eric, have these been discussed in the past?

This was discussed earlier in the thread.  Basically ending the subscription can be done by:

- delete-subscription rpc
- kill-subscription rpc
- loss of TLS heartbeat
- inability to deliver sequential sets of notification messages
     "For connectionless or stateless transports like
      HTTP, a lack of receipt acknowledgment of a sequential set of
      notification messages and/or keep-alives can be used to trigger a
      termination of a dynamic subscription. "   (per SN 1.3)
- " A publisher MAY terminate a dynamic subscription at any time."   (per SN 1.3)

Eric

> Regards,
> Reshad.
> 
> 
> 
>     Kent // contributor
> 
> 
> 
> 
>