Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Apr 2019 19:11:00 +0000

Hi Nick,

You will notice in the latest tcp-client-server update [1] that there is now a "presence" statement on the "keepalives" containers.  Do you think any more "mandatory true" statements are needed?

I don't understand your last comment or, rather, I think it is the case already that the TCP keepalives configuration is outside the SSH/TLS configuration.  Note the "keepalives" configuration inside the SSH/TLS configuration is actually to separately configure keepalives at the SSH/TLS levels - makes sense?

[1] https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-01 <https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-01>

Kent // contributor

> On Mar 26, 2019, at 10:30 AM, NICK HANCOCK <[email-masked]> wrote:
> 
> I support this work to provide the ability to configure TCP keepalives for NETCONF connections as we need this support in our implementations and support the adoption of these drafts.
>  
> I also have the following comments on the actual YANG implementation and usage within the client/server model.
>  
> The leafs within the “tcp-keepalives” container are optional. Given that a server supports the feature “tcp-client-keepalives”, TCP keepalives would be disabled per default through missing configuration, which I believe is desirable behavior. However, there is currently nothing to prevent a client configuring, say, just ‘max-probes’ only resulting in an incomplete but valid configuration. Would not adding a ‘presence’ statement to the container “tcp-keepalives” and making its child nodes mandatory or adding default values be a more practical solution that defines a predictable behavior?
>  
> Since TCP is a layer below the security layer and independent of the choice of security protocol, I was wondering what the motivation was for locating the TCP keepalives configuration within the SSH/TLS configuration. Wouldn’t this be better located as a sibling nod to the choice “transport”?
>  
> Nick
>  
>  <>From: netconf <[email-masked] <mailto:[email-masked]>> On Behalf Of Mahesh Jethanandani
> Sent: 26 March 2019 12:17
> To: Netconf <[email-masked] <mailto:[email-masked]>>
> Subject: [netconf] Adoption poll for tcp-client-server and http-client-server draft
>  
> This is the start of a two week poll for WG adoption of the two drafts:
> 
> https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 <https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00>
> https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 <https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00>
> 
> Please indicate your support for or any objections you might have for adopting the two drafts as WG items by April 9.
> 
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>_______________________________________________
> netconf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: NICK HANCOCK <[email-masked]>
Date: Wed, 10 Apr 2019 16:36:52 +0000

Hi Kent,

Some comments in-line…

Nick

From: Kent Watsen <[email-masked]>
Sent: 08 April 2019 21:11
To: NICK HANCOCK <[email-masked]>
Cc: Mahesh Jethanandani <[email-masked]>; [email-masked]
Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft

Hi Nick,

You will notice in the latest tcp-client-server update [1] that there is now a "presence" statement on the "keepalives" containers.  Do you think any more "mandatory true" statements are needed?
[Nick] Given that ‘max-probes’ and ‘probe-interval’ are optional in the current revision, a client or operator has the option not to configure them. Since they are also without default values, the actual behavior after the ‘idle–time’ expires would be defined by the specific implementation and not by the operator. On the other hand, for the YANG model to specify arbitrary default values may not really be helpful to an operator as meaningful values would surely depend on the operators specific requirements.
Consequently, I believe that all 3 leafs within the container ‘keepalives’ should be mandatory.

I don't understand your last comment or, rather, I think it is the case already that the TCP keepalives configuration is outside the SSH/TLS configuration.  Note the "keepalives" configuration inside the SSH/TLS configuration is actually to separately configure keepalives at the SSH/TLS levels - makes sense?
[Nick] My initial expectation was that since the security layer runs over the TCP connections, the tcp-client-parameters would be configured independently of the security protocol, i.e., to be found directly under ‘endpoint’ and not under ssh or tls.

[1] https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-01<https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-01>

Kent // contributor

On Mar 26, 2019, at 10:30 AM, NICK HANCOCK <[email-masked]<mailto:[email-masked]>> wrote:

Nick

From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Mahesh Jethanandani
Sent: 26 March 2019 12:17
To: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: [netconf] Adoption poll for tcp-client-server and http-client-server draft

https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00<https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00>
https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00<https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00>

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Apr 2019 19:20:08 +0200

Sorry, this is impossible to read without an HTML rendering engine.

/js

> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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, 10 Apr 2019 18:29:43 +0000

[Even though I do have an HTML-rendering SMTP client, I also found this message difficult to read, mostly due to the inline-level not changing.  It took me awhile to realize that I have to search for "[Nick]".  I've converted this message to plain-text...]

> Consequently, I believe that all 3 leafs within the container ‘keepalives’ should be mandatory.

Fair enough.

> [Nick] My initial expectation was that since the security layer runs over the TCP connections, the tcp-client-parameters would be configured independently of the security protocol, i.e., to be foun…

Still, I think that this is the case already.  Can you please provide a concrete example illustrating the concern?

Thanks,
Kent // contributor

---

From: NICK HANCOCK <[email-masked]>
Date: Thu, 11 Apr 2019 08:26:10 +0000

> -----Original Message-----
> Sent: 10 April 2019 20:30
> [Even though I do have an HTML-rendering SMTP client, I also found this
> message difficult to read, mostly due to the inline-level not changing.  It took
> me awhile to realize that I have to search for "[Nick]".  I've converted this
> message to plain-text...]

Thanks for the feedback, I'll avoid HTML in the future.

> 
> 
> 
> > You will notice in the latest tcp-client-server update [1] that there is now a
> "presence" statement on the "keepalives" containers.  Do you think any
> more "mandatory true" statements are needed?
> >
> > [Nick] Given that ‘max-probes’ and ‘probe-interval’ are optional in the
> current revision, a client or operator has the option not to configure them.
> Since they are also without default values, the actual behavior after the
> ‘idle–time’ expires would be defined by the specific implementation and not
> by the operator. On the other hand, for the YANG model to specify arbitrary
> default values may not really be helpful to an operator as meaningful values
> would surely depend on the operators specific requirements.
> >
> > I don't understand your last comment or, rather, I think it is the case
> already that the TCP keepalives configuration is outside the SSH/TLS
> configuration.  Note the "keepalives" configuration inside the SSH/TLS
> configuration is actually to separately configure keepalives at the SSH/TLS
> levels - makes sense?
> >
> > [Nick] My initial expectation was that since the security layer runs over the
> TCP connections, the tcp-client-parameters would be configured
> independently of the security protocol, i.e., to be found directly under
> ‘endpoint’ and not under ssh or tls.
> 

No real concern. If I read the cases 'ssh' and 'tls' as 'ssh over tcp' 
and 'tls over tcp', it makes sense. Initially the duplication of the 
TCP configuration bugged me.

Nick