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

[Martin Bjorklund <[e-mail]>]

Hi,

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>
> 
> 
> 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.

+1

> 2) HTTP/2
> 
>    Not sure where this landed, but my thoughts are this draft needs to
>    support both 1.1 and 2.0.

Why?  I don't really understand why restconf-notif, or RESTCONF for
that matter, need special handling for HTTP/2.  Won't RESTCONF "just
work" with HTTP/2?

>    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.
> 
> 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.

But it is not quite comparable.  In the 8040 solution, the location
url is static, and then query parameters are provided by the client
in the POST to the SSE location.  Thus, the server can free any
resources associated with the filter when the connection is
terminated.


> Are there just two issues?
> 
>    a) how does the server ensure only said client accesses the resource?

The server cannot know this.  I guess it can verify the username.  But
does it matter?

>    b) how does the server know when it's okay to reclaim the resource, 
>       when a client doesn't "delete" or "kill" the subscription?

Yes this is not clear.


/martin