Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Sep 2018 18:49:01 +0000

<chair plea>
  Can we try to have a Last Call worthy version on the restcon-notif 
  draft by mid next week?  The chairs would like to Last Call both 
  NN + RN together if possible...
</chair plea>

As I understand it, there are three issues (any others?) as follows:

1) SSE

   Actually, with Reshad's last response, this may not be an issue
   anymore.  Just in case, I also feel that the *restconf*-notif draft
   needs to align as closely as possible to the RFC 8040 notification 
   solution.  Ideally, we just use SSE outright and we're done.

2) HTTP/2

   Not sure where this landed, but my thoughts are this draft needs to
   support both 1.1 and 2.0.  I envision the variation being relatively
   minor, something along the line of: 

     if 1.1, then SSE.
     if 2.0, client MAY open a stream first.

3) resource URIs

   This is likely where we need to spend the most time. We know that 
   establish-subscription returns a dynamically created URI, comparable
   to what a client might get from ietf-restconf-monitoring:restconf-state\
   /streams/stream/access/location.  Are there just two issues?

   a) how does the server ensure only said client accesses the resource?

   b) how does the server know when it's okay to reclaim the resource, 
      when a client doesn't "delete" or "kill" the subscription?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Sep 2018 22:48:54 +0200 (CEST)

Hi,

>    solution.  Ideally, we just use SSE outright and we're done.

+1

>    support both 1.1 and 2.0.

Why?  I don't really understand why restconf-notif, or RESTCONF for
that matter, need special handling for HTTP/2.  Won't RESTCONF "just
work" with HTTP/2?

>    I envision the variation being relatively
>    /streams/stream/access/location.

But it is not quite comparable.  In the 8040 solution, the location
url is static, and then query parameters are provided by the client
in the POST to the SSE location.  Thus, the server can free any
resources associated with the filter when the connection is
terminated.

> Are there just two issues?
> 

The server cannot know this.  I guess it can verify the username.  But
does it matter?

>       when a client doesn't "delete" or "kill" the subscription?

Yes this is not clear.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 27 Sep 2018 21:03:59 +0000

Hi Kent,

On 2018-09-27, 2:49 PM, "Kent Watsen" <[email-masked]> wrote:

    <chair plea>

<RR> I will strive to do so, no promises...    

    1) SSE
    
<RR> Yes, that's the plan.
    
    2) HTTP/2

         if 1.1, then SSE.
         if 2.0, client MAY open a stream first.
<RR> I thought the agreement was to have no http2 in the spec, except maybe as an informational note. RFC8040 doesn't mention http2 at all. 
    
    3) resource URIs

    

<RR> I don't know. Eric, have these been discussed in the past?

Regards,
Reshad.

    Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 27 Sep 2018 21:28:24 +0000

> From: Reshad Rahman, September 27, 2018 5:04 PM
> 
> Hi Kent,
> 
> 
> <RR> I thought the agreement was to have no http2 in the spec, except maybe
> as an informational note. RFC8040 doesn't mention http2 at all.
> 
>     3) resource URIs
> 

With HTTP2, you can require that the same HTTP session be used as was used for the RESTCONF signaling.   For HTTP 1.1, perhaps there could be some comparison of the access credentials used across independent TLS sessions?  

> <RR> I don't know. Eric, have these been discussed in the past?

This was discussed earlier in the thread.  Basically ending the subscription can be done by:

- delete-subscription rpc
- kill-subscription rpc
- loss of TLS heartbeat
- inability to deliver sequential sets of notification messages
     "For connectionless or stateless transports like
      HTTP, a lack of receipt acknowledgment of a sequential set of
      notification messages and/or keep-alives can be used to trigger a
      termination of a dynamic subscription. "   (per SN 1.3)
- " A publisher MAY terminate a dynamic subscription at any time."   (per SN 1.3)

Eric

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Sep 2018 14:33:20 -0700

+1

> that matter, need special handling for HTTP/2.  Won't RESTCONF "just

Agreed

> resources associated with the filter when the connection is

The RESTCONF procedure starts with the client
examining /restconf-state/streams to determine stream and its location URL
How does this monitoring information relate to the new solution?
I assume both the old and new procedures can be supported by the same
server.
Is it just ignored for a new subscription?

Since all SSE data is always media type test/event-stream, each stream
entry indicates
its secondary encoding format. This leaf is type string, and only 'xml' and
'json' are supported
in RFC 8040. The establish-subscription RPC has its own leaf for this
purpose.

> The server cannot know this.  I guess it can verify the username.  But

It matters if the server wants to pre-check the subscription for NACM issues
when it is created.

I want to make sure the same username is used, and only 1 session
is doing a GET on the subscription resource.

> >       when a client doesn't "delete" or "kill" the subscription?

Note that the RESTCONF solution avoids this problem because
only the GET on the SSE URI causes resources to be allocated for a
subscription.

One solution proposal:
  - use a timeout and if the client does not connect within that time, the
subscription
    will be suspended or deleted.
 - if the client terminates the SSE GET then either suspend or terminate
the subscription

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Sep 2018 22:55:54 +0000

>> 2) HTTP/2
>> 
>>    Not sure where this landed, but my thoughts are this draft needs
>>    to support both 1.1 and 2.0.
>

It seems that we're all in agreement - RN should work for both 1.1
and 2.0.  Unclear why this caused a stir. 

Still, I thought there was a perceived common case for a client to
be able to use another HTTP/2 stream to collect logs.  If the client
can do this already and it's completely transparent to the server,
then having a statement just saying that would be good.  This is
what my comment was about.

BTW, Section 3.1 regards how a RESTCONF client can promote HTTP 1.1
to HTTP 2.0.  It looks like a good approach, but should the text be 
in another document, if it's not specific to RN?  

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Sep 2018 01:23:39 +0200

> in another document, if it's not specific to RN?  

The text should be removed. How HTTP/2 sessions are started is defined
in section 3 of RFC 7540.

/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: Fri, 28 Sep 2018 01:34:32 +0000

> in section 3 of RFC 7540.

Perfect.  This applies to all RESTCONF connections. Looking more at 
the first paragraph, the first sentence says:

   For a dynamic subscription, where an HTTP client session doesn't
   already exist, a new client session is initiated from the subscriber.

But this isn't quite right.  Dynamic subscriptions, at least for this
draft are always on top of a RESTCONF connection.  Put together, the
first paragraph should change as:

OLD:
   For a dynamic subscription, where an HTTP client session doesn't
   already exist, a new client session is initiated from the subscriber.
   If the subscriber is unsure if HTTP2 is supported by the publisher,
   HTTP1.1 will be used for initial messages, and these messages will
   include an HTTP version upgrade request as per [RFC7230],
   Section 6.7.  If a publisher response indicates that HTTP2 is
   supported, HTTP2 will be used between subscriber and publisher for
   future HTTP interactions as per [RFC7540].
NEW:
   Dynamic subscriptions are established using the RESTCONF protocol
   [RFC8040].  Section 2 of RFC 8040 describes the transport protocol
   for RESTCONF.

Also, while looking at Section 3.1, the second sentence says:

   A subscriber SHOULD establish the HTTP session over TLS [RFC5246]
   In order to secure the content in transit.

This sentence should be removed, RESTCONF requires TLS.  I imagine
this being a holdover from before, but another notif draft needs to
be written if wanting to support HTTP-based notifications without
requiring TLS, or even RESTCONF.

Similarly, the 3rd paragraph regards a scenario where TLS might not
be in use, which won't ever happen.  For this reason, the first half
of this paragraph should be removed.

Kent // contributor

---

From: Qin Wu <[email-masked]>
Date: Fri, 28 Sep 2018 03:40:25 +0000

I assume both the old and new procedures can be supported by the same server.

Since all SSE data is always media type test/event-stream, each stream entry indicates
its secondary encoding format. This leaf is type string, and only 'xml' and 'json' are supported
in RFC 8040. The establish-subscription RPC has its own leaf for this purpose.

[Qin]: I am lost, should resource URIs returned by establish-subscription same as location URL obtained from
ietf-restconf-monitoring:restconf-state\/streams/stream/access/location.
My understanding is if SSE is supported, let’s say HTTP 1.1, we will use location URL returned from
ietf-restconf-monitoring:restconf-state\/streams/stream/access/location
as input parameter to trigger SSE. In case of SSE being supported, HTTP GET(URI) is not needed ? wrong?
But if SSE is not supported, let’s say HTTP/2, location URL is not needed. HTTP POST(URI) is required.
Please correct me, if I am wrong.

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Sep 2018 11:00:20 -0700

> Please correct me, if I am wrong.

I think sec 3.2 Discovery says use a different /streams container
https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-07#section-3.2

There should be a sub-section added in sec. 3 about coexistence between
RFC 8040 notifications and this document. Obviously vendors need the option
of supporting both in the same server.

How do they interact, starting with the 2 different /streams data models.

It should also be clear in this draft that the "uri" leaf contents are
implementation-specific
and MAY be predictable by a client application. Query parameters MAY be
defined
for use with the GET operation on this uri.

Andy