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

["Reshad Rahman (rrahman)" <[e-mail]>]

Hi,


From: 'Andy Bierman' <[e-mail]>
Date: Saturday, September 29, 2018 at 2:00 PM
To: Qin Wu <[e-mail]>
Cc: Martin Bjorklund <[e-mail]>, Netconf <[e-mail]>, "Reshad Rahman (rrahman)" <[e-mail]>
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif


On Thu, Sep 27, 2018 at 8:40 PM Qin Wu <[e-mail]<mailto:[e-mail]>> wrote:

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


[Qin]: I am lost, should resource URIs returned by establish-subscription same as location URL obtained from
ietf-restconf-monitoring:restconf-state\/streams/stream/access/location.
My understanding is if SSE is supported, let’s say HTTP 1.1, we will use location URL returned from
ietf-restconf-monitoring:restconf-state\/streams/stream/access/location
as input parameter to trigger SSE. In case of SSE being supported, HTTP GET(URI) is not needed ? wrong?
But if SSE is not supported, let’s say HTTP/2, location URL is not needed. HTTP POST(URI) is required.
Please correct me, if I am wrong.
<RR> I don’t think there’s the option of SSE not being supported, doesn’t RESTCONF mandate SSE support?



I think sec 3.2 Discovery says use a different /streams container
https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-07#section-3.2

<RR> Right. But using RFC8040 container should also work, or are you saying we could not support RFC8040 container?

Regards,
Reshad.

There should be a sub-section added in sec. 3 about coexistence between
RFC 8040 notifications and this document. Obviously vendors need the option
of supporting both in the same server.

How do they interact, starting with the 2 different /streams data models.

It should also be clear in this draft that the "uri" leaf contents are implementation-specific
and MAY be predictable by a client application. Query parameters MAY be defined
for use with the GET operation on this uri.


Andy