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

[Andy Bierman <[e-mail]>]

On Tue, Jul 10, 2018 at 4:52 PM, Eric Voit (evoit) <
evoit=[e-mail]> 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".
>
>
It is very expensive to implement both HTTP client and server roles in both
peers.
IMO the existing RESTCONF SSE notifications need to be supported.

I am concerned that not enough reviews of configured notifications
are being done because it is a low priority for many vendors.
It is clearly redundant if CallHome is used, but potentially useful for
binary push and line-card push (UDP or TCP).

It is hard to say if the correct pieces are being defined now to support
fancy binary push standards later.


Eric
>

Andy


>
> > Kent // contributor
> >
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>