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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 11 Jul 2018 00:15:45 +0000

> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Jul 2018 00:27:42 +0000

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

My opening thought is that we should nix configured subscriptions entirely
for the first round of these drafts.  Only support dynamic subscriptions.

My second thought is that, when we get around to defining configured 
subscriptions, we should consider supporting both "publisher is the 
transport-server" (for the awesome alignment of security credentials)
as well as "publishing is the <transport>-client (for when there's a
need for that).  IMO, this just comes down to "notif" modules, one for
each variation, I envision a dozen or so in time.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jul 2018 07:51:54 +0200

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

> 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 si…

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 11 Jul 2018 15:15:58 +0000

> From: Juergen Schoenwaelder, july 11, 2018 1:52 AM
> 
> > > > > >> 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
> > > > > >>
> > > > > (optimizing for what I think suspect will be the common case in
> > > > > the long
> > > > > term...)
> > > >
> > > 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.
> > > >
> > > occur before the "subscription-started" POST.  However this
> > > advertisement of client capabilities might not be needed for all
> implementations.
> > > >
> > >
> > > 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.
> >
> > 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.
> >
> 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jul 2018 22:48:38 +0200

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