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

NICK HANCOCK <> Tue, 26 March 2019 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAC601202CC for <>; Tue, 26 Mar 2019 07:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wacgNu9O5Flr for <>; Tue, 26 Mar 2019 07:30:38 -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 385021202F1 for <>; Tue, 26 Mar 2019 07:30:36 -0700 (PDT)
Received: from ( []) (Using TLS) by with ESMTP id us-mta-324-ODgt68_jMkevmUcIIX5bZQ-1; Tue, 26 Mar 2019 10:30:33 -0400
Received: from ([fe80::51a3:972d:5f16:9952]) by ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0382.000; Tue, 26 Mar 2019 09:30:32 -0500
To: Mahesh Jethanandani <>, Netconf <>
Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft
Thread-Index: AQHU48WK88pkUu3tWEqeuFS0y837C6Yd+NxQ
Date: Tue, 26 Mar 2019 14:30:31 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, en-GB
Content-Language: en-US
x-originating-ip: []
MIME-Version: 1.0
X-MC-Unique: ODgt68_jMkevmUcIIX5bZQ-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_BD6D193629F47C479266C0985F16AAC7011EA6336Bexmb1corpadtr_"
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: Tue, 26 Mar 2019 14:30:42 -0000

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<><>