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

NICK HANCOCK <nick.hancock@adtran.com> Thu, 11 April 2019 08:26 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 E3B0412011D for <netconf@ietfa.amsl.com>; Thu, 11 Apr 2019 01:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 FJTrqH89MZ2Z for <netconf@ietfa.amsl.com>; Thu, 11 Apr 2019 01:26:21 -0700 (PDT)
Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [216.205.24.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 05FFD12017D for <netconf@ietf.org>; Thu, 11 Apr 2019 01:26:20 -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-335-QONegf9EMreI1k0u1Ge4vQ-1; Thu, 11 Apr 2019 04:26:12 -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; Thu, 11 Apr 2019 03:26:11 -0500
From: NICK HANCOCK <nick.hancock@adtran.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft
Thread-Index: AQHU48WK88pkUu3tWEqeuFS0y837C6Yd+NxQgBURBQCAAjWfgIAA44GAgACFiOA=
Date: Thu, 11 Apr 2019 08:26:10 +0000
Message-ID: <BD6D193629F47C479266C0985F16AAC7011EA68B21@ex-mb1.corp.adtran.com>
References: <ED12BA39-09E6-4436-B759-625434D197D6@gmail.com> <BD6D193629F47C479266C0985F16AAC7011EA6336B@ex-mb1.corp.adtran.com> <01000169fe5c5e14-63eba328-51f5-4ba3-ac17-311909f5bd86-000000@email.amazonses.com> <BD6D193629F47C479266C0985F16AAC7011EA6891A@ex-mb1.corp.adtran.com> <0100016a08834944-944143b3-7387-460c-a30e-167524705d55-000000@email.amazonses.com>
In-Reply-To: <0100016a08834944-944143b3-7387-460c-a30e-167524705d55-000000@email.amazonses.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0FEVFJBTiIsImlkIjoiM2ZhNWJkMTktYmQzNy00YjhhLWI1MjYtOTg2NGE5YmUzMWY2IiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiR0IifV19LHsibiI6IlF1ZXN0aW9uMSIsInZhbHMiOltdfSx7Im4iOiJRdWVzdGlvbjIiLCJ2YWxzIjpbXX0seyJuIjoiUXVlc3Rpb24zIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTcuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ilp0dzZvblhyRjhiaThXdjllR0pFRytTQTFCWEd3eEVnWVEzSGVEdzB4aVUwRnZpUUdta0trNTZVVk5rTW81SDIifQ==
x-originating-ip: [172.20.62.167]
MIME-Version: 1.0
X-MC-Unique: QONegf9EMreI1k0u1Ge4vQ-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Wirycw5J8gOVZQhTaj-cOPbx2oc>
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: Thu, 11 Apr 2019 08:26:24 -0000


> -----Original Message-----
> From: Kent Watsen <kent+ietf@watsen.net>
> Sent: 10 April 2019 20:30
> To: NICK HANCOCK <nick.hancock@adtran.com>
> Cc: Mahesh Jethanandani <mjethanandani@gmail.com>om>; netconf@ietf.org
> Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-
> server draft
> 
> [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.
> >
> > Consequently, I believe that all 3 leafs within the container ‘keepalives’
> should be mandatory.
> 
> Fair enough.
> 
> 
> > 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.
> 
> Still, I think that this is the case already.  Can you please provide a concrete
> example illustrating the concern?

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.

> 
> 
> 
> Thanks,
> Kent // contributor
> 

Nick