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

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

/js

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