Re: [tcpm] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 04 July 2022 16:06 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 2E068C15AD33; Mon, 4 Jul 2022 09:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.593
X-Spam-Level:
X-Spam-Status: No, score=-6.593 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-g3pHZNEbeX; Mon, 4 Jul 2022 09:05:57 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22804C157B3E; Mon, 4 Jul 2022 09:05:55 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 5039525A13; Mon, 4 Jul 2022 18:05:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1656950753; bh=kU5+Utl7IOhEURuGZU++K8Dn/qtVd/wPLS/GERwkGbs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=CS4RZKmHumaaGOaR/v5WwIs/Ad+YDwYB6SwutEDbiFUgj7CK3HO5bFtquPvNcaqzJ FaJMujfdqfDJLRsUbqNv60HhRO7NwbYXi2CfzJUqxRAbK4lUb+chEG2+cqHZeQgh1L rg0sk8sXL7RTO3lzCqxc00MbwtrzPMKQY/sIL404=
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 xIs3kdEbFRgS; Mon, 4 Jul 2022 18:05:51 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 4 Jul 2022 18:05:51 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Mon, 4 Jul 2022 18:05:51 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2375.028; Mon, 4 Jul 2022 18:05:51 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "touch@strayalpha.com" <touch@strayalpha.com>, Gyan Mishra <hayabusagsm@gmail.com>
CC: Last Call <last-call@ietf.org>, "draft-ietf-tcpm-yang-tcp.all@ietf.org" <draft-ietf-tcpm-yang-tcp.all@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07
Thread-Index: AQHYj1suxwnTXlZYAUSeZXWHLbVT561tgVQAgAAIwQCAAJzegIAANqyg
Date: Mon, 04 Jul 2022 16:05:50 +0000
Message-ID: <4688b79370e94df6b8af107a97be0a7f@hs-esslingen.de>
References: <165690747653.9313.6940379164951428048@ietfa.amsl.com> <DF6CF2BD-8418-4386-BB78-6E011A523FBA@strayalpha.com> <CABNhwV1SN+Ei_TScwUsg1scKhAAoxixfFTtXXghLXEPspU6gZA@mail.gmail.com> <893612ED-91B7-4492-8000-EF2D54AC49BC@strayalpha.com>
In-Reply-To: <893612ED-91B7-4492-8000-EF2D54AC49BC@strayalpha.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.249]
Content-Type: multipart/alternative; boundary="_000_4688b79370e94df6b8af107a97be0a7fhsesslingende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/_aTP7N7JHEVqe7kuYOBm-t4_9yo>
Subject: Re: [tcpm] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 04 Jul 2022 16:06:02 -0000

Joe, all,

„separate protocol specific YANG model” could be the YANG model for BGP, or for any other TCP-based application.

Any application can decide to configure TCP parameters as far as possible in the given operation system, e.g., via the sockets API. That is orthogonal to the internals of the TCP implementation and the TCP protocol. The app configuration can be done in YANG or by other means. For the TCP stack, that does not matter.

As far as I understand Gyan, the concerns regarding draft-ietf-tcpm-yang-tcp are sorted out already.

@all: Please speak up if specific changes are needed in draft-ietf-tcpm-yang-tcp. The authors will have to focus on the IESG feedback.

Thanks

Michael



From: touch@strayalpha.com <touch@strayalpha.com>
Sent: Monday, July 4, 2022 4:38 PM
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Last Call <last-call@ietf.org>; draft-ietf-tcpm-yang-tcp.all@ietf.org; ops-dir@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07


—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>


On Jul 3, 2022, at 10:16 PM, Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

Hi Joe, authors  et all

I reviewed the feedback from my earlier review in March and as this model is geared towards BGP primary.

To address all of my concerns would be complicated for this Yang model, so the plan is that a separate protocol specific yang model would be a follow on to address all of my concerns.

First, there should NEVER be two different YANG models for BGP routers vs. other routers or hosts. TCP is TCP is TCP. If that is an assumption for moving this document forward, TCPM should have a longer discussion about that point specifically.

Second, my observations about your requests below stand, regardless of when/where current or future authors might be considering them.

Joe


On Mon, Jul 4, 2022 at 12:44 AM touch@strayalpha.com<mailto:touch@strayalpha.com> <touch@strayalpha.com<mailto:touch@strayalpha.com>> wrote:
FWIW:

> On Jul 3, 2022, at 9:04 PM, Gyan Mishra via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
>
> Reviewer: Gyan Mishra
> Review result: Not Ready
>
> This draft provides the Yang data mode for TCP.
>
> The draft is well written and is almost ready publication.  I verified the FSM
> state machine and all states are listed.
>
> Minor issues:
> None
>
> Major issues:
> None
>
> Nits:
> I reviewed the TCP Yang data model and has a question related to the FSM state
> machine.
>
> Would it be possible to specify the TCP Header flags SYN, FIN, ACK, RST of BFD
> FSM finite state machine Events and Transition.  I think this would be very
> helpful for the TCP Yang model FSM state machine.  For each state you could
> specify the flags set.

These issues appear to have been raised by you in March during last call review. Some have been addressed by others before; I’ll add my input.

The YANG model represents information about the current TCP connection. It is not (and should not be confused with) a specification of the protocol.

Further, flags are associated with messages that cause state transitions, not states (i.e., the FSM is a Mealy machine, not a Moore machine). There is no “flags set for each state”.

> http://tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm

That page has errors and is not consistent with RFC793 (or it’s pending -bis update). E.g., FIN stands for “finis” (latin for “end”), not “finish”.

> I think the TCP TCB (TCP Control Block) is missing in the Yang model. This is
> important for troubleshooting TCP connection state.

RFC793 (and -bis) indicate that the STATUS command, which might return similar information, is optional.

If there is connection information returned, I do not think it should be the TCB; that is an implementation-dependent parameter, not a universal property of TCP connections. As others have stated in previous responses to you review, the common subset of the TCB is already contained.

I.e., I think the YANG model represents TCP information. It is not - and should not be confused with - a troubleshooting tool.

Joe
--
[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>
Gyan Mishra
Network Solutions Architect
Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>
M 301 502-1347

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm