IETF Logo Mail Archive

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

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Fri, 27 March 2020 14:50 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 9E9963A0C2C; Fri, 27 Mar 2020 07:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 QwJvnC1-Q2Ci; Fri, 27 Mar 2020 07:50:03 -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 301083A0C25; Fri, 27 Mar 2020 07:50:02 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B555F25A1D; Fri, 27 Mar 2020 15:50:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1585320600; bh=ernVI8Befcqa8O/ocX1eaCpkis8w5vBPAV1aZ2gliA8=; h=From:To:CC:Subject:Date:From; b=E4n2B6UVoh2Lq/dHrVx5Z/WCBmCxr0wTV7+YKryO1umRLDPRLuMs1lsO2+WGbEZza z/vccfXKvjAGhlJOBXnq+9MNmPb3rBzIV7QSWORO63aq0lyS0k7N4ahP/Jc2QRQT4B RZB6AiVqvwdDeishnfgRQRp1Jm9HwA2AP4e8N7fE=
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 gtmcQQpIwYgn; Fri, 27 Mar 2020 15:49:59 +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; Fri, 27 Mar 2020 15:49:59 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Fri, 27 Mar 2020 15:49:59 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Lars Eggert <lars@eggert.org>
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>
Thread-Topic: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04
Thread-Index: AdYERvxPm8xvduWhO0ywtFiDNCmPqg==
Content-Class: urn:content-classes:message
Date: Fri, 27 Mar 2020 14:49:58 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DA3F971@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2DA3F971rznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/SuABVp0YkJ6RbYRO6togL8dVRpU>
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:50:16 -0000

I am not an expert for SNMP under Linux. But, at first sight, /proc/net/snmp provides basically all scalars from the TCP-MIB. The connection table seems missing. But those objects I would only expect when actually managing a Linux system by the SNMP protocol, not in the proc file system.

Search engines find quite a number of implementer questions on „/proc/net/snmp“. So, it seems relatively likely that there is some use. And in the area of SNMP network management, there is often not much public documentation, so a professor may not be able to figure out any details of deployed systems.

Regarding MD5, I get told that there is still running code and operational deployment, even if TCP-AO is getting traction. As users seem to ask for it, my proposal would be to add big warning signs that it is deprecated, i.e., TCP-AO should be used instead. On that aspect, the other authors could maybe also chime in.

Michael


Von: Lars Eggert<mailto:lars@eggert.org>
Gesendet: Freitag, 27. März 2020 15:15
An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>
Cc: Michael Tuexen<mailto:tuexen@fh-muenster.de>; tcpm IETF list<mailto:tcpm@ietf.org>; draft-scharf-tcpm-yang-tcp@ietf.org<mailto:draft-scharf-tcpm-yang-tcp@ietf.org>
Betreff: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

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

v2.23.0 | Report a Bug | By Email