Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

Lars Eggert <lars@eggert.org> Fri, 27 March 2020 14:15 UTC

Return-Path: <lars@eggert.org>
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 DBE553A0909; Fri, 27 Mar 2020 07:15:27 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 aFWYNtkaGTt1; Fri, 27 Mar 2020 07:15:26 -0700 (PDT)
Received: from vs22.mail.saunalahti.fi (vs22.mail.saunalahti.fi [193.64.193.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DFF3A081E; Fri, 27 Mar 2020 07:15:26 -0700 (PDT)
Received: from vs22.mail.saunalahti.fi (localhost [127.0.0.1]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 81DAB2027E; Fri, 27 Mar 2020 16:15:24 +0200 (EET)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 80B4B200B7; Fri, 27 Mar 2020 16:15:24 +0200 (EET)
Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw01.mail.saunalahti.fi (Postfix) with ESMTPSA id 56B7740006; Fri, 27 Mar 2020 16:15:20 +0200 (EET)
Received: from stickers.eggert.org (stickers.eggert.org [172.24.110.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 0CF23684669; Fri, 27 Mar 2020 16:15:14 +0200 (EET)
From: Lars Eggert <lars@eggert.org>
Message-Id: <E71A3E5E-0490-40B0-B967-0FEF0A5C5D4F@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B86DEC0B-8C00-4EB6-AFED-99DC109E46E5"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 27 Mar 2020 16:15:13 +0200
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DA3F752@rznt8114.rznt.rzdir.fht-esslingen.de>
Cc: Michael Tuexen <tuexen@fh-muenster.de>, tcpm IETF list <tcpm@ietf.org>, "draft-scharf-tcpm-yang-tcp@ietf.org" <draft-scharf-tcpm-yang-tcp@ietf.org>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2DA3F752@rznt8114.rznt.rzdir.fht-esslingen.de>
X-MailScanner-ID: 0CF23684669.A9CD6
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/TdhsNAANDa0y0ckuicOHjt8o4q0>
Subject: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04
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: Fri, 27 Mar 2020 14:15:28 -0000

Hi,

On 2020-3-27, at 15:52, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> But, wait a second: I recommend to have a look at the output of „cat /proc/net/snmp“ under Linux (just tested on Debian Buster)…
> 
> As far as I can see, these are the object definitions from the TCP-MIB. If implemented on Linux, why does the TCP-MIB not matter?

/proc/net/snmp provides the scalars (a small subset of 4022), and obviously just in text form. Are you aware of any uses?

> However, we have learnt from that: We have explicitly decided not to include extended statistics in draft-scharf-tcpm-yang-tcp. The draft currently only includes basic stats.

Well, basic stats and AO detail. (And why still MD5? We obsoleted 2385 ten years ago.)

> It is well understood that there *are* challenges with coming up for a YANG model for TCP. But if RFC 4898 got it wrong, we could learn from that, IMHO.

You are much more optimistic than I am.

Lars