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

Joseph Touch <touch@strayalpha.com> Fri, 27 March 2020 15:03 UTC

Return-Path: <touch@strayalpha.com>
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 4B42E3A0C17; Fri, 27 Mar 2020 08:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 tz93qcU2X_rc; Fri, 27 Mar 2020 08:03:02 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856C33A08F4; Fri, 27 Mar 2020 08:03:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lhsCjhbMQ5K0pJ9OIoKW2E0pQ4nQQGfk8w3+65YV1wE=; b=OfVZDF6cbA7g8PQ1uHPA937hF rdClJbKT+V8u1V0nncF/DKE1cyGxvWZfk/FtVe5oxSDTjGONEYeWWC5V3/EEpd1LM85Z17sbkL3XJ e8rfSx5DR5QXmOTL7zBWCAD3UmHSiz0Lp0C0NDOerSXn0hygh3l6Xx2f19g3g9CWN7E6kJ39ekHuX LPPjF69BAq/061iZTthxK3e72wxmvzUxsaFUM/M9nIy1Nx6Uik6NCLCmuNVuG68a4/Qd2xiKZDZc4 eW2YOsWiHEOGSsH2FQENDPG+6UKT8pqRQdR39YW8h4WskLa5s7EzqmxCBd14d69ehyV3p9JRhEx16 NoLHc04JQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61297 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1jHqVY-003rdO-NI; Fri, 27 Mar 2020 11:02:57 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_76043DB5-84F0-40F3-AAD4-53D13B654A95"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DA3F971@rznt8114.rznt.rzdir.fht-esslingen.de>
Date: Fri, 27 Mar 2020 08:02:51 -0700
Cc: Lars Eggert <lars@eggert.org>, "draft-scharf-tcpm-yang-tcp@ietf.org" <draft-scharf-tcpm-yang-tcp@ietf.org>, tcpm IETF list <tcpm@ietf.org>, Michael Tuexen <tuexen@fh-muenster.de>
Message-Id: <A8AAB673-0F59-462C-B1C3-125123556D6E@strayalpha.com>
References: <6EC6417807D9754DA64F3087E2E2E03E2DA3F971@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/dlmIbeJHdv6i8n4NveSiw2Uyg5Q>
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 15:03:04 -0000

Hi, all,

I agree with Lars that, in effect, encoding certain stats in the YANG model runs the risk of making them “expected” in an implementation; if that’s desired, the process should be inverted (decide what we think is necessary THEN add it; don’t let the model drive the requirements). 

That would be a LOT of work, equivalent to extending the API for TCP. If that happens, we need to be VERY careful to not burden implementers with implementation details or requirements.

As to MD5, agreed that it’s important to include, but I would even go so far as to put it under a subtree of “Deprecated” components to make it very clear to everyone who uses them.

Joe


> On Mar 27, 2020, at 7:49 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> 
> 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 <mailto: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
>  
>  
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>