Subject: [Netconf] HTTP2 configured subscriptions, is SSE over HTTP1.1 necessary too? (was RE: Anyone want just Configured Subscriptions?)

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

From: Andy Bierman, July 10, 2018 6:54 PM

On Tue, Jul 10, 2018 at 1:59 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Jul 10, 2018 at 08:37:30PM +0000, 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?

RFC 8040 (RESTCONF) uses SSE and the client has to fetch an event
stream resource in order to receive events (section 6.3). This is not
a big surprise since HTTP 1/1 is purely client driven. This in fact
implies that the client knows the event stream resource.

SSE should be an available option for configured notifications.
There could be a pre-determined URL for the client to GET
like GET /restconf/SSE/<subscription-id>

<Eric> Earlier versions of draft-ietf-netconf-restconf-notif had an SSE option for configured subscriptions over HTTP1.1.  This could be re-added.

To me it seems that just using HTTP2 mechanisms simplifies things enough where it is not necessary to support SSE as well.   If someone wants to champion/document the SSE over HTTP1.1 path, that would be great.  I am assuming this would be to simplify transition for existing SSE implementations.  And especially for such transition issues, I don’t have sufficient context to document without assistance.

Eric

/js

Andy

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

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

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

> To me it seems that just using HTTP2 mechanisms simplifies things enough where it is not necessary to support SSE as well.   If someone wants to champion/document the SSE over HTTP1.1 path, that wo…

Eric,

perhaps people prefer an 80% solution that can be finished in
reasonable time over a 120% solution that keeps crawling slowly.
Divide and conquer is sometimes a good idea.

/js

---

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

> From: Juergen Schoenwaelder, July 11, 2018 4:52 PM
> 
> > <Eric> Earlier versions of draft-ietf-netconf-restconf-notif had an SSE
> option for configured subscriptions over HTTP1.1.  This could be re-added.
> >
> > To me it seems that just using HTTP2 mechanisms simplifies things
> enough where it is not necessary to support SSE as well.   If someone wants
> to champion/document the SSE over HTTP1.1 path, that would be great.  I
> am assuming this would be to simplify transition for existing SSE
> implementations.  And especially for such transition issues, I don’t have
> sufficient context to document without assistance.
> >
> 
> Eric,
> 
> perhaps people prefer an 80% solution that can be finished in reasonable
> time over a 120% solution that keeps crawling slowly.

It took a while, but we are at a 100% solution for NETCONF.  Things really are done, (pending the completion of Kent's netconf-server work.)  

Cutting things back to 80% would take another 20% time.  And per others' emails, the market demand is now or never.  I.e., we really have fallen behind the market enough that a scope revisit (from my point of view) is simply giving the market to technology competitors such as GNMI which got started multiple years after this effort began.

For RESTCONF, HTTP2, I am hoping work these issues for real (this is the first time we have talked about this in two years) as soon at the other documents in WGLC complete.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Jul 2018 23:41:30 +0000

Hi Eric,

> It took a while, but we are at a 100% solution for NETCONF.  Things 
> really are done, (pending the completion of Kent's netconf-server work.)
> Cutting things back to 80% would take another 20% time.  And per others' 
> emails, the market demand is now or never.

Where is the 100% solution?  The drafts are still churning.  As of right
now, we don't have a set of drafts that we can call another WGLC on.

As I see it, there are only two choices:

 1. reduce the scope to just dynamic subscriptions, hit WGLC around Sep
    and maybe have RFCs by the year's end.  After which, the WG should
    immediately start working on the configured solution, with hope of
    getting it published in 2019 (possibly achievable since must of the
    groundwork has been laid already)

 2. maintain the scope to dynamic + configured, which will take longer
    (maybe not much, hard to say) to reach WGLC, but any NETCONF or 
    RESTCONF based transport notif drafts will be blocked by RFC Editor
    until the client/server suite of drafts completes (read: sometime
    next year), and there is a chance that we'd need to update them
    again then, if only to generate correct/final tree-diagrams.

It's the WG's choice. I know that some have expressed interest in having
just dynamic now.  I don't have a strong opinion either way.  This question
would make for a good hum next week.

Kent // co-chair