Re: [Netconf] HTTP2 configured subscriptions, is RESTCONF call home necessary? (was RE: Anyone want just Configured Subscriptions?)

[Juergen Schoenwaelder <[e-mail]>]

Why is this discussion HTTP/2 specific?

What you are proposing in draft-ietf-netconf-restconf-notif-06.txt is
that you have a RC client using RPCs to push notification data to an
RC server. LMAP is doing something like this to send measurement
results to a collector. The point is that you do not need call home
for this but instead:

- you embed a RC client into the server on the device
- you embed a RC server into the client on the managing system
- you need to provision client config so that the device knows how
  and when to contact the server
- you define RPCs in a YANG model implemented by the RC server on
  the managing system do ship notification content towards the
  RC server on the managing system

This is what LMAP has done. In contrast, a call home solution does
not require additional clients and servers and instead you call home
and let the client start the notification stream, which is sent using
SSE as defined in RFC 8040.

/js

On Tue, Jul 10, 2018 at 11:52:54PM +0000, Eric Voit (evoit) wrote:
> Changing the thread title, as we have moved off the original topic...
> 
> > From: Kent Watsen, July 10, 2018 6:36 PM
> > 
> 
> Adding back in Lou's comment before mine to provide the context needed to understand my answer...
> 
> >>> (Lou) or an an error when an unsolicited notification is received by a client that doesn't support it.  (optimizing for what I think suspect will be the common case in the long term...)
> 
> > > Effectively this is what draft-ietf-netconf-restconf-notif, section
> > > 4.2 defines now.  A successful POST of a "subscription-started"
> > > notification must occur before events are sent.  Failure to receiver
> > > an OK for the POST means an error to the publisher.
> > 
> > But if we use RESTCONF Call Home, the receiver is the HTTP-client, can an HTTP
> > client process a POST?
> 
> Considering Lou's comment, my response points out that a receiver must "OK" a "subscription-started" before the publisher can send events.  In this case the publisher is the HTTP2 client.  Otherwise there is an error.
> 
> Since there is no RESTCONF is needed at all for configured subscriptions, the function draft-ietf-netconf-restconf-notif needs to include is the safe establishment of a secure tunnel between Publisher (HTTP2 client) and Receiver (HTTP2 server).  Perhaps Call Home is not necessary at all here, and perhaps it is always safe for the publisher to initiate the encrypted tunnel.  We can debate the pros/cons of each scenario for sure.  Perhaps Call Home simply isn't needed here.  And that would be excellent.  My understanding is that Call Home does provide some protections here, so I left RESTCONF call-home in to spur this debate.
> 
> Assuming that someone does want call-home for configured subscription encrypted tunnel establishment, steps C1-C7 of RFC8071 remain the same.  It is just step C8 which changes so that a receiver starts to listening for the POST of notifications to its HTTP server rather than starting RESTCONF.   Likewise Steps S1-S5 and S7 of RFC8071 remain the same.  The only difference would be that step S6 initiates an HTTP2 client connection towards the receiver, and then POSTs a "subscription-started" notification.  These specifics absolutely do need to be in draft-ietf-netconf-restconf-notif.  They are not yet as I was awaiting this discussion first.
> 
> > > Some form of RESTCONF Call Home with capability advertisement could
> > > also occur before the "subscription-started" POST.  However, this
> > > advertisement of client capabilities might not be needed for all
> > implementations.
> > 
> > I don't know how.  RESTCONF Call Home just starts the RESTCONF protocol,
> > and there is no capability-exchange in RESTCONF.
> 
> I could have worded this better.  What I meant is that outside the current scope of draft-ietf-netconf-restconf-notif, some TBD exchange of receiver capabilities could be defined.  This would let the publisher know that sending a "subscription-started" is supported.   I don't believe this necessary/essential here, as you won't start pushing events until the receiver says "OK".
> 
> Eric
> 
> > Kent // contributor
> > 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>