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

Kent Watsen <kent@watsen.net> Tue, 26 March 2019 14:52 UTC

Return-Path: <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@amazonses.watsen.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A10B12032C; Tue, 26 Mar 2019 07:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 iFTnC3cu4Dxs; Tue, 26 Mar 2019 07:52:45 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3BC120306; Tue, 26 Mar 2019 07:52:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553611963; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=BTaMq4uUMWPT9AwwnpydH7oJmQvO+zFFPzIjkYU/N/o=; b=NInVSQCDwp3js///NQRb5ZIthyKXoqKNfAQHs8tMWBVgNhaI7G8HE/eJfbpDHKFi 8Fw2OdNiG72y2splnJAXjYKbztIoPnZf2V+OV71ggwFPSkvNI1/sUcZmf/WtLFBQPtY J/1OlzGAJmkVPW5rm5+H7vPwbORYZ+gRrABhB+o8=
Content-Type: multipart/alternative; boundary="Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E"
Mime-Version: 1.0 (1.0)
From: Kent Watsen <kent@watsen.net>
X-Mailer: iPad Mail (16D57)
In-Reply-To: <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de>
Date: Tue, 26 Mar 2019 14:52:42 +0000
Cc: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "tcpm@ietf.org" <tcpm@ietf.org>, Netconf <netconf@ietf.org>
Content-Transfer-Encoding: 7bit
Message-ID: <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@email.amazonses.com>
References: <ED12BA39-09E6-4436-B759-625434D197D6@gmail.com> <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-SES-Outgoing: 2019.03.26-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Ryi7zpmPZvrD-QsL6dinUAOLqIY>
Subject: Re: [tcpm] [netconf] Adoption poll for tcp-client-server and http-client-server draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 14:52:47 -0000

Wait, I don’t think we need to do anything drastic here.

Michael, please note that the TCP modules here are intended to be very limited in scope, just the bare minimum necessary to support the NETCONF/RESTCONF that (in case you don’t know) are layered on top of SSH and TLS, and hence TCP.  The bare minimum appears to be just addresses, ports, and keep-alives.   The NETCONF WG has NO interest in extending this module beyond this minimal amount.

Additionally, please see Slide 9 here [1] and note that this module is part of a rather large eco-system of interrelated modules.  The point being is that the reason for it being  structured the way it is (e.g., as groupings) is pretty well justified.

My proposal is as follows:

  1) Let’s (as co-authors) get the draft-kwatsen-netconf-tcp-client-server-00
      with it’s current scope to RFC status ASAP (a couple months), so that this
      five-year NETCONF project can end.  Happy to tweak it as you see fit.  
      Which WG does this is not important, but for a time-expediency perspective,
      I recommend the NETCONF WG due to the heavy interlinking mentioned
      before.

  2) TCPM takes over the RFC, publishing a bis with all the extra parameters
       that are in draft-scharf-tcpm-yang-tcp.  TCPM could even do this work
       in parallel, so as to not cause any scheduling delays.

Thoughts?  Can we have a short-term collaboration and then let TCPM take over?

[1] https://datatracker.ietf.org/meeting/104/materials/slides-104-netconf-crypto-types-clientserver-suite-of-drafts-00.pdf


PS: Let’s (+ co-chairs) meet up today/tomorrow.

Kent // contributor 


> On Mar 26, 2019, at 3:19 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> Dear Michael,
> 
> please note that a configuration model for NETCONF is on the NETCONF
> charter for ~5 years. To establish NETCONF session, we obviously need
> to establish TCP connections. This is what this work does. It is
> entirely orthogonal to draft-scharf-tcpm-yang-tcp, which talks about
> TCP protocol engine internals. If the TCPM chair has an issue with a
> generic solution to establish TCP connection not being done in TCPM,
> we should perhaps just hardcode how to establish TCP connections for
> NETCONF and RESTCONF and call it the day and then TCPM can pick up the
> pieces and start work on a generic solution.
> 
> /js
> 
>> On Tue, Mar 26, 2019 at 01:02:49PM +0000, Scharf, Michael wrote:
>> Hi Mahesh,
>> 
>> As chair of the TCPM working group, I believe that the document draft-kwatsen-netconf-tcp-client-server-00 belongs into the TCPM working group. The document is about a generic YANG model for an interface for TCP "for an SSH, TLS, or HTTP based application". I fail to see a reason why such a generic TCP model should be done in NETCONF.
>> 
>> Thus, as a chair of TCPM, I object to adoption in NETCONF.
>> 
>> I also want to note that it would have been possible to send a note to the TCPM list prior to starting an adoption call, as the TCPM list is monitored by many TCP implementers who could be affected by such a YANG model. YANG models can be used in different use cases. TCPM has a tradition of being very open to presentations from other working groups if they relate to TCP. I have added the TCPM list in CC.
>> 
>> As an individual contributor to the IETF, I happen to be an author of draft-scharf-tcpm-yang-tcp, which actually was submitted last year. Given that different working groups seem to be involved, I believe that it would make sense to join efforts. Shouldn't we have a chat on the best next steps?
>> 
>> Thanks
>> 
>> Michael
>> 
>> 
>>> -----Original Message-----
>>> From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh
>>> Jethanandani
>>> Sent: Tuesday, March 26, 2019 12:17 PM
>>> 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-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
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> netconf mailing list
>>> netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>> 
>> _______________________________________________
>> netconf mailing list
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf