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

["Eric Voit (evoit)" <[e-mail]>]

Hi Douglas,

From: Douglas Hubler, September 18, 2018 5:35 PM


On Tue, Sep 18, 2018 at 3:40 PM Martin Bjorklund <[e-mail]<mailto:[e-mail]>> wrote:
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.

yes, with caveat that I haven't attempted actual implementation yet.

<Eric> Agree that SSE over HTTP2 should work.  However to me using SSE here seems redundant as HTTP2 provides the necessary mechanisms.  But I won’t get in the way if people really do want to go in this direction.

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

I see.  But if a client reads the YANG as

 module my-module {
    ...
    notification my-event {
    }
}

and client knew base stream URI was:

   /restconf/my-streams

Couldn't the client then deduce SSE URL as:

 GET  /restconf/my-streams/my-module:my-event?...

Thereby saving a trip to server?

<Eric> Yes, it would be possible to set something up to deduce the URL.  draft-ietf-netconf-restconf-notif doesn’t currently attempt this as being able to deduce the URL doesn’t stop the extra trip to the server.

The reason it doesn’t get rid of the extra round trip has to do with HTTP2 streams.  If we are going to use HTTP2, there is still a need to initiate the GET (or POST) in a separate stream other than the one being used for RESTCONF signaling.

Someone could write a specification which gets around this by forcing every RESTCONF transaction on its own HTTP2 stream.  But nobody has proposed such a specification.  Plus there are QoS scenarios where you might want multiple subscriptions on the same HTTP2 stream.  So if someone wanted this, we would still need to refine draft-ietf-netconf-restconf-notif requirements with the ability to modify or delete an existing subscription on a different HTTP2 stream.  This could be done of course, but someone would need to drive the definition.

Eric


Would it be wrong for a client to make any assumptions?  I realize this ASSUMEs a transport protocol, but could/would there be a one-time, capability check the client could make to test for available transports?

I really appreciate your time explaining, I have been following the emails best I could but I think some basic things are still eluding me.