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

On Thu, Sep 27, 2018 at 1:49 PM Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
>
> Kent Watsen <kwatsen@juniper.net> 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
>

+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?

Agreed

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

The RESTCONF procedure starts with the client
examining /restconf-state/streams to determine stream and its location URL
How does this monitoring information relate to the new solution?
I assume both the old and new procedures can be supported by the same
server.
Is it just ignored for a new subscription?

Since all SSE data is always media type test/event-stream, each stream
entry indicates
its secondary encoding format. This leaf is type string, and only 'xml' and
'json' are supported
in RFC 8040. The establish-subscription RPC has its own leaf for this
purpose.

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

It matters if the server wants to pre-check the subscription for NACM issues
when it is created.

I want to make sure the same username is used, and only 1 session
is doing a GET on the subscription resource.

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

Note that the RESTCONF solution avoids this problem because
only the GET on the SSE URI causes resources to be allocated for a
subscription.

One solution proposal:
  - use a timeout and if the client does not connect within that time, the
subscription
    will be suspended or deleted.
 - if the client terminates the SSE GET then either suspend or terminate
the subscription

> /martin
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>