IETF Logo Mail Archive

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

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

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 4E037120494; Tue, 26 Mar 2019 08:53:45 -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 7e99S7tO0Xxb; Tue, 26 Mar 2019 08:53:43 -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 4E2C01204A6; Tue, 26 Mar 2019 08:53:43 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 363E625A15; Tue, 26 Mar 2019 16:53:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553615621; bh=dscI/wWifN4+KJ1F4gIraW40RhkoAOGb6fpym7rLxAs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JqX2J6w7XKxjUydLt4vNDVwbYPjDzkgA178V/sbGPnEd6ElE7UDdlZ3F6IkoSZCyI 52SfclhlwsEddKR3i1jgGdTEyN2gRRR+1l1DvNAleHv3aRw7satADkUG8Wm8PfF5hs 5pvpc/3JabXBjGaudgQSHUq9+bK/jCQR6yx1dqhk=
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 Doe80OWyQiH9; Tue, 26 Mar 2019 16:53:40 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (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 16:53:40 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 16:53:40 +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++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAABHsoIAAAwaAgAARMKA=
Date: Tue, 26 Mar 2019 15:53:39 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28398B@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>
In-Reply-To: <20190326153403.sb4dzynlv2fxhvym@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/tcpm/OqCyiV3GmzCxadMaPpiV5GyMkCE>
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 15:53:45 -0000

> -----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>; Netconf
> <netconf@ietf.org>; 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.

Michael

v2.23.0 | Report a Bug | By Email