Subject: Re: [Netconf] restconf-notif, s3.1 (was: SSE and HTTP/2 in restcon-notif)

From: Kent Watsen <[email-masked]>
Date: Fri, 12 Oct 2018 19:15:29 +0000

[new subject]

Hi Reshad,

Looking at the 07 --> 08 diff, I see that some of the changes below were made to Section 3.1 (Transport Connectivity).  Thanks for that.

Comments:

1) the 1st paragraph refers to "HTTP client session".  Should this be "RESTCONF client session" or maybe just "RESTCONF session"?

2) assuming we do (1), then the 2nd paragraph seems unnecessary, as RESTCONF already requires TLS.

3) unsure if the 3rd paragraph belongs in this section or another, but maybe split it into two paragraphs? - one regarding what happens to dynamic subscriptions when the underlying transport is lost, and another for strategies for maintaining connectivity?  (note: on the latter, unsure if this is something this document needs to say at all, as it's not a subscription-specific thing.)

Kent // contributor

-----Original Message-----
From: Netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Thursday, September 27, 2018 at 9:34 PM
To: Juergen Schoenwaelder <[email-masked]>
Cc: "rrahman=[email-masked]" <rrahman=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif

> The text should be removed. How HTTP/2 sessions are started is defined
> 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

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=4-zpxZ3c2teGtRV9W0TOIBYwvc720tdoMFc59pxbLGU&s=FUTsUvXH79i7IgEKfUvzY7wLgf_qMKx9iBscs6jmAH4&e=

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 12 Oct 2018 20:08:59 +0000

Hi Kent,

On 2018-10-12, 3:24 PM, "Kent Watsen" <[email-masked]> wrote:

    [new subject]
    
    Hi Reshad,

    Comments:
    
    1) the 1st paragraph refers to "HTTP client session".  Should this be "RESTCONF client session" or maybe just "RESTCONF session"?
<RR> Ack. s/HTTP/RESTCONF/ makes sense, and I think that having client also in there is fine because we're talking about the subscriber. So I'd go with "RESTCONF client session" but would be ok with "RESTCONF session". 
    
    2) assuming we do (1), then the 2nd paragraph seems unnecessary, as RESTCONF already requires TLS.
<RR> I was debating that, based on comments on 07, when I was making changes for 08. Can remove if it's viewed as redundant.
    
    3) unsure if the 3rd paragraph belongs in this section or another, but maybe split it into two paragraphs? - one regarding what happens to dynamic subscriptions when the underlying transport is lost, and another for strategies for maintaining connectivity?  (note: on the latter, unsure if this is something this document needs to say at all, as it's not a subscription-specific thing.)
<RR>Splitting makes sense. The section is for transport connectivity so I think it's the right section for that text assuming we keep the text (I'm for keeping it).

Regards,
Reshad.
    
    Kent // contributor

    -----Original Message-----
    From: Netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
    Date: Thursday, September 27, 2018 at 9:34 PM
    To: Juergen Schoenwaelder <[email-masked]>
    Cc: "rrahman=[email-masked]" <rrahman=[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif

    

    
    OLD:

    

    Kent // contributor