[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 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.)

> 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.

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