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

Hi Kent,

Some comments in-line…

Nick

From: Kent Watsen <kent+ietf@watsen.net>
Sent: 08 April 2019 21:11
To: NICK HANCOCK <nick.hancock@adtran.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; netconf@ietf.org
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 <nick.hancock@adtran.com<mailto:nick.hancock@adtran.com>> 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 <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> On Behalf Of Mahesh Jethanandani
Sent: 26 March 2019 12:17
To: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
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
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>

_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>
_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>