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

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

> From: Juergen Schoenwaelder, july 11, 2018 1:52 AM
> 
> On Wed, Jul 11, 2018 at 12:15:45AM +0000, Eric Voit (evoit) wrote:
> > > From: Juergen Schoenwaelder, July 10, 2018 6:43 PM
> > >
> > > On Tue, Jul 10, 2018 at 10:27:23PM +0000, Eric Voit (evoit) wrote:
> > > > > From: Lou Berger, July 10, 2018 4:43 PM
> > > > >
> > > > > On 7/10/2018 4:37 PM, Kent Watsen wrote:
> > > > > >
> > > > > >> So in short, after RFC 8071 call home, you get NC/RC client
> > > > > >> and server starting with a <hello> exchange. Ideally, the
> > > > > >> client would indicate its readiness to receive unsolicited
> > > > > >> notifications before you push notifications to the client
> > > > > >> (and the notification sender may even be interested to know
> > > > > >> that it is sending notifications to a remote system that does not
> just drop them).
> > > > > >> So either the clients invokes an RPC to start the
> > > > > >> notification flow or, if you want to optimize one round trip,
> > > > > >> the client includes a special
> > > > > >>
> > > > > >>   :willing-to-receive-unsolicited-notifications
> > > > > >>
> > > > > >> capability in the <hello> exchange.
> > > > > > I agree that a client-advertised capability would be goodness
> > > > > > here, but it only works for NC-clients, there is no corollary for RC-
> clients.
> > > > > >
> > > > > > Maybe clients should send a "willing-to-receive-unsolicited-
> notifications"
> > > > > > RPC instead?
> > > > > 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.
> > > >
> > > > 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 fail to understand section 4.2. The first sentence already leaves
> > > me
> > > puzzled:
> > >
> > >    With HTTP2 connectivity established, a POST of each new
> > >    "subscription-started" state change notification messages will be
> > >    addressed to HTTP augmentation code on the receiver capable of
> > >    accepting and acknowledging to subscription state change
> > >    notifications.
> > >
> > > What does this say? And why is this HTTP2 specific? The publisher is
> > > the RC server, no?
> >
> > Actually no.  This specification does not use RESTCONF for configured
> > subscriptions.  (See other email I just sent to Kent.)
> 
> OK. So you have a solution for sending dynamic subscriptions via RC but no
> solution for sending configured subscriptions via RC since you are actually
> inventing a new protocol for this (which for some unknown reason requires
> HTTP/2).

It has been since IETF 96/97 since we discussed this on the list.   The basics are:

(a) There is no bi-directional signaling with configured subscriptions, hence no need for RESTCONF.  This simplifies interactions, and widens the possible device list.

(b) With HTTP2 there is no need for SSE.  Each subscription becomes its own HTTP2 POST.

(c) With HTTP2 there is no head-of-line blocking between independent subscriptions.
 
> > > So the RC server does HTTP transactions agains the client? This does
> > > not seem to have anything to do with how the call home RFC works.
> > >
> > > I am not saying that what Figure 3 shows won't work, it just has
> > > nothing to do with call home. You are reversing the RC client and
> > > server roles, call home only reverses the connection establishment
> roles. Big difference.
> >
> > Yes this is a big difference.  Especially as RESTCONF is removed as well for
> configured subscriptions.
> >
> > Per the other thread, I am actually quite fine with removing call home for
> configured subscriptions if nobody else sees a need for the receiver to
> initiate this connection.  That would make life simpler.
> >
> 
> The receiver? I read in 4.1:
> 
>    If the above conditions are met, then the publisher MUST initiate a
>    transport session via RESTCONF call home [RFC8071], section 4.1 to
>    that receiver.
> 
> Still puzzled.

Yes, this needs to be updated.  Per the other thread, this requirements statement is left in as a proxy for what type of connection establishment (with underlying security mechanisms) might be required for the HTTP2 connection.   I.e., the HTTP2 still needs to go over TLS, how do we accomplish this.

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