IETF Logo Mail Archive

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

NICK HANCOCK <nick.hancock@adtran.com> Tue, 26 March 2019 14:30 UTC

Return-Path: <nick.hancock@adtran.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC601202CC for <netconf@ietfa.amsl.com>; Tue, 26 Mar 2019 07:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wacgNu9O5Flr for <netconf@ietfa.amsl.com>; Tue, 26 Mar 2019 07:30:38 -0700 (PDT)
Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [63.128.21.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385021202F1 for <netconf@ietf.org>; Tue, 26 Mar 2019 07:30:36 -0700 (PDT)
Received: from ex-hc3.corp.adtran.com (ex-hc2.adtran.com [76.164.174.82]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-ODgt68_jMkevmUcIIX5bZQ-1; Tue, 26 Mar 2019 10:30:33 -0400
Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0382.000; Tue, 26 Mar 2019 09:30:32 -0500
From: NICK HANCOCK <nick.hancock@adtran.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>
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: <BD6D193629F47C479266C0985F16AAC7011EA6336B@ex-mb1.corp.adtran.com>
References: <ED12BA39-09E6-4436-B759-625434D197D6@gmail.com>
In-Reply-To: <ED12BA39-09E6-4436-B759-625434D197D6@gmail.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.48.41]
MIME-Version: 1.0
X-MC-Unique: ODgt68_jMkevmUcIIX5bZQ-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_BD6D193629F47C479266C0985F16AAC7011EA6336Bexmb1corpadtr_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9msQu9x9CC0vHnmgB_M6r6yHh70>
Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=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"?

Nick

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

v2.23.0 | Report a Bug | By Email