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

[Andy Bierman <[e-mail]>]

On Mon, Oct 1, 2018 at 6:48 AM, Reshad Rahman (rrahman) <[e-mail]>
wrote:

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



The draft mentions RFC 8040 in a few places so the reader is left to assume
that there is no relationship between /streams and /restconf-state/streams.
The RFC 8040 procedures are intentionally ignored and there is no
correlation between
these data models (e.g., same stream name in both is just coincidence with
no meaning).

If this is the intent then it should be stated in the draft.
If not, then something else should be stated in the draft.





> Regards,
>
> Reshad.
>


Andy


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