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

[Martin Bjorklund <[e-mail]>]

Hi,

"Eric Voit (evoit)" <[e-mail]> wrote:
> 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.

Eric, can you explain how this would work w/o SSE?  Which mechanism in
HTTP/2 are you referring to?

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

No.

With RFC 8040, the SSE URL is "stable", and if the client has read it
onve, it doesn't have to read it again (modulo some definition of
"stable").  The client can pass a filter in the GET request for the
SSE stream.

With the mechanism in this draft, the SSE URL will vary for each
request that has a different filter (at a minimum), since the filter
is passed a parameter to "establish-subscription" and the SSE URL is
sent back in the reply to "establish-subscription".  With the SSE URL,
the server may hide some state that corresponds to the filter params
etc.  (NOTE the word *may* in the previous sentence.  A server could
as well send back a SSE URL with the filter parameters embedded in the
URL...)

So in general, a client cannot assume that it can re-use a SSE URL
that was returned from a call to "establish-subscription".

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

I disagree.  If the client wants to have a separate HTTP/2 stream for
the notifs, then it should start such a stream.  If the client doesn't
want a separate HTTP/2 stream then that should be ok too.

Compare to NETCONF.  HTTP/2 streams are similar to SSH channels.  A
NETCONF client can open a separate SSH channel for each subscription,
or it can use a single channel.  Up to the client.

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

How would this work?  Once you start SSE on a stream, that stream is
"blocked", right?

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

Isn't this how it is supposed to work?  The draft is silent on how to
delete a subscription, and also on how modify-subscription is supposed
to work.

The draft is also silent on the lifetime of the result of
"establish-subscription".  With NETCONF, the subscription ends if the
session ends, but in RESTCONF there are no sessions, so how long does
the subscription live after it has been created?

Note that the approach in RFC 8040 is doesn't have this issue.


/martin


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