Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16

[Martin Bjorklund <[e-mail]>]

Douglas Hubler <[e-mail]> wrote:
> On Mon, Sep 17, 2018 at 12:23 PM Andy Bierman <[e-mail]> wrote:
> 
> > It seems this draft could be renamed (e.g., s/RESTCONF/HTTP2/) since it
> > does not use RESTCONF in any way.  I don't think RESTCONF notifications
> > are used very much,
> >
> 
> I make liberal use of them, it's become one of my biggest selling point of
> RESTCONF over rolling your own REST API for management.
> 
> 
> > but I don't see why the same SSE delivery of the <notification> element
> > would not work (e.g., different resource to GET for establish-subscription
> > parameters)
> >
> 
> I avoided implementing SSEs over HTTP/1.1  *because* I used a lot of
> notifications and separate session for each subscription obviously doesn't
> scale.  I went w/websockets for now with the idea I'd reimplement when a
> reasonable draft is assembled.  I had hopes for SSE over HTTP/2 because
> seems rather straightforward and in theory should scale.  Obviously with
> websockets, my implementation doesn't interop w/other RESTCONF/NETCONF
> systems/libs but hoping to change that with this draft.

So it seems you support my point to make this draft use SSE.  Then if
you use HTTP/2 you (the client) can simply create one HTTP/2 stream per
notification stream.  This just falls out for free with HTTP/2.

> I don't understand the details surrounding using an RPC to make a dynamic
> subscription.  Unless it's optional, then I can start to understand.

The client would POST to the "rpc" establish-subscripion, and in the
reply to the POST is a "location" leaf (*) that contains a URI.  The
client then GET this URI; this is the SSE event stream.

(*) in RFC 8040 it is called "location", in this draft it is called
"uri" 


/martin