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

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Tue, 26 March 2019 16:21 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 23D14120598; Tue, 26 Mar 2019 09:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=hs-esslingen.de
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 eTJLNnpS7svt; Tue, 26 Mar 2019 09:21:09 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D145D120582; Tue, 26 Mar 2019 09:21:08 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8D89D25A13; Tue, 26 Mar 2019 17:21:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553617266; bh=gL7mQybliCPIsetwd/vPs8p9LoKnyjTY32lT03TCc18=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZIyJa/U8QohJzZeTy2l/gZNa1SgIrZQTV9IacWQtZyqjjwuypDJUiDP1fkg3EcmZr qzpshzCnl5pSIbiJ0UE/v8yn+oAP2K01SqohEF24/oMDKDdBZ/wu8nb6YQoLv+M+Ig ddJymdFixqyUIp5okOTDLuMrj1iwZzvOfcNNs7wU=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvr5KA60tPPa; Tue, 26 Mar 2019 17:21:05 +0100 (CET)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 17:21:05 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 17:21:04 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft
Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAABHsoIAAAwaAgAARMKD///kKgIAAETOQ
Date: Tue, 26 Mar 2019 16:21:04 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D283B33@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <ED12BA39-09E6-4436-B759-625434D197D6@gmail.com> <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326161039.og3ylq7fenoffvpi@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190326161039.og3ylq7fenoffvpi@anna.jacobs.jacobs-university.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.29.249]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/84vj1EjPzL8ow9Np5wWFaE3Zlx8>
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 16:21:12 -0000

> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> Sent: Tuesday, March 26, 2019 5:11 PM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> Cc: Mahesh Jethanandani <mjethanandani@gmail.com>om>; Netconf
> <netconf@ietf.org>rg>; tcpm@ietf.org
> Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-
> server draft
> 
> On Tue, Mar 26, 2019 at 03:53:39PM +0000, Scharf, Michael wrote:
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> > > Sent: Tuesday, March 26, 2019 4:34 PM
> > > To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> > > Cc: Mahesh Jethanandani <mjethanandani@gmail.com>om>; Netconf
> > > <netconf@ietf.org>rg>; tcpm@ietf.org
> > > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-
> > > server draft
> > >
> > > On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote:
> > > > Hi Juergen,
> > > >
> > > > The document includes TCP keepalives configuration and this is actually
> > > about TCP protocol engine internals, no?
> > >
> > > I think we are talking about a client or server using setsockopt()
> > > calls. This is not about globally changing TCP engine behavior.
> >
> > There is a grey area between setsockopt() style configuration and TCP stack
> configuration. And one can easily end up in the question if other parameters
> of the TCP stack need to be optimized in an actual NETCONF/RESTCONF
> implementation for some reason, possibly on a per-connection basis. Then
> one gets into details of the TCP stack.
> >
> > > > And I fail to see the benefit of doing TCP YANG modeling specific to
> > > NETCONF or RESTCONF. For instance, on a router, I believe that
> NETCONF,
> > > RESTCONF, BGP and LDP could use the same TCP stack, as well as possibly
> all
> > > other TCP-based protocols running on the NE. And if HTTP is included,
> YANG
> > > models have a pretty broad applicability beyond routers. So what makes
> > > NETCONF or RESTCONF so special that NETCONF needs its own model?
> > > >
> > > > As I mentioned, in the last years TCPM has been extremely open to
> TCP-
> > > related needs in other working groups and we have quite successful
> cross-
> > > area work.
> > > >
> > >
> > > The models are not NETCONF/RESTCONF specific unless process forces us
> > > to make them NETCONF/RESTCONF specific. What makes
> > > NETCONF/RESTCONF
> > > special is that we started this 5 years ago. I do not care at the end
> > > who owns the document as long as process does not bring us more delay.
> >
> > It is reasonable to ask for a fast solution. And, well, a solution will be
> actually be faster if there are no "surprises" late in the publication process. So
> it may be better to discuss early what the best approach would be, and
> where to home what.
> >
> 
> We had objects to configure TCP connections over which we run TLS and
> SSH over which we run RESTCONF and NETCONF in the making for ~5 years.
> And I also know RFCs that include YANG objects to establish TCP connections.
> Is the keep alive the reason for TCPM to claim control of this? Or the
> fact that we moved to more generic groupings?

Standardizing generic groupings including protocol-specific configuration without talking to the working group owning the protocol is probably not the right approach - no matter what the protocol is and where it is homed in the IETF.

As a TCPM chair, I speak up because I believe such a document needs to be reviewed by TCP implementers early. That expertise can be found in TCPM.

Note that it is perfectly possible that the TCPM working group decides that the specific problem at hand does not have to be solved in TCPM. We could have discussed that yesterday in TCPM.

Michael

 
> Anyway, I am just saying you should be aware of the history and scope
> of this work and then the WG chairs can settle this somehow.
> 
> /js
> 
> --
> 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/>