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

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

From: Andy Bierman, July 10, 2018 8:14 PM


On Tue, Jul 10, 2018 at 4:52 PM, Eric Voit (evoit) <evoit=[e-mail]<mailto: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.

<Eric> See other thread.  I am looking for someone to champion existing RESTCONF SSE call flow / use case.   I can’t do it justice as I haven’t seen an implementation.

Eric

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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf