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

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Jul 11, 2018 at 03:15:58PM +0000, Eric Voit (evoit) wrote:
> > 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.

OK. I am getting slowly convinced that mixing dynamic subscriptions
that run over RESTCONF with configured subscriptions that run over a
newly defined protocol into one document is likely not helpful.

/js

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