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

Kent Watsen <kent+ietf@watsen.net> Wed, 10 April 2019 18:29 UTC

Return-Path: <0100016a08834944-944143b3-7387-460c-a30e-167524705d55-000000@amazonses.watsen.net>
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 10E5C120129 for <netconf@ietfa.amsl.com>; Wed, 10 Apr 2019 11:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 PKvJOQBLdDnu for <netconf@ietfa.amsl.com>; Wed, 10 Apr 2019 11:29:44 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FC812006D for <netconf@ietf.org>; Wed, 10 Apr 2019 11:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554920983; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=xc9eHRPpLWO8suL9D9qpbx/YIEDYRYyh7/6OO14ui/A=; b=DgTXXvDBcOXpryyFejdF9T1r4S2038BuGlts+30Ms10JKX+3kYFwDcpmm4UChHV6 1Vua7FsI/8NoYYP2jQFosls2G9xILYAsy9RoSNBF3DFPzQv5Y8BjMRyXq4DdtCOeNwx cJ9VsL7LteeO6oYTMuDts0qOO/8kj7+sUhDaNDi4=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <BD6D193629F47C479266C0985F16AAC7011EA6891A@ex-mb1.corp.adtran.com>
Date: Wed, 10 Apr 2019 18:29:43 +0000
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <0100016a08834944-944143b3-7387-460c-a30e-167524705d55-000000@email.amazonses.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>
To: NICK HANCOCK <nick.hancock@adtran.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.10-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/yg5jwnXoMPlxIYkg22bPXNnfZYE>
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: Wed, 10 Apr 2019 18:29:46 -0000

[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...]



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



Thanks,
Kent // contributor