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

NICK HANCOCK <> Wed, 10 April 2019 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D18912038B for <>; Wed, 10 Apr 2019 09:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z3qpJKgOiah7 for <>; Wed, 10 Apr 2019 09:37:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46FE712037D for <>; Wed, 10 Apr 2019 09:37:01 -0700 (PDT)
Received: from ( []) (Using TLS) by with ESMTP id us-mta-340-kjh9CFiFMduIJCd_41VUkw-1; Wed, 10 Apr 2019 12:36:55 -0400
Received: from ([fe80::51a3:972d:5f16:9952]) by ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0382.000; Wed, 10 Apr 2019 11:36:54 -0500
To: Kent Watsen <>
CC: Mahesh Jethanandani <>, "" <>
Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft
Thread-Index: AQHU48WK88pkUu3tWEqeuFS0y837C6Yd+NxQgBURBQCAAjWfgA==
Date: Wed, 10 Apr 2019 16:36:52 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-GB
Content-Language: en-US
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0FEVFJBTiIsImlkIjoiMjQ3ZTZlMzEtMzE2Mi00YmM2LWJiZDMtOWU0OWRlMzFiMzJlIiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiR0IifV19LHsibiI6IlF1ZXN0aW9uMSIsInZhbHMiOltdfSx7Im4iOiJRdWVzdGlvbjIiLCJ2YWxzIjpbXX0seyJuIjoiUXVlc3Rpb24zIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTcuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImhJaE5xR3oyOWQwaktBZkxzXC9LQVZaZkp2NkU3eENGeFQ2NHBjVkdPN3hmWVpMSXhQVEc1NnFQd2h0UnRydmJ1In0=
x-originating-ip: []
MIME-Version: 1.0
X-MC-Unique: kjh9CFiFMduIJCd_41VUkw-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_BD6D193629F47C479266C0985F16AAC7011EA6891Aexmb1corpadtr_"
Archived-At: <>
Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2019 16:37:06 -0000

Hi Kent,

Some comments in-line…


From: Kent Watsen <>
Sent: 08 April 2019 21:11
Cc: Mahesh Jethanandani <>om>;
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.


Kent // contributor

On Mar 26, 2019, at 10:30 AM, NICK HANCOCK <<>> 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”?


From: netconf <<>> On Behalf Of Mahesh Jethanandani
Sent: 26 March 2019 12:17
To: Netconf <<>>
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:<><>

Please indicate your support for or any objections you might have for adopting the two drafts as WG items by April 9.

Mahesh Jethanandani<>

netconf mailing list<><>
netconf mailing list<><>