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

Robert Raszuk <robert@raszuk.net> Mon, 04 July 2022 19:15 UTC

Return-Path: <robert@raszuk.net>
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 63B2AC15791C for <tcpm@ietfa.amsl.com>; Mon, 4 Jul 2022 12:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.595
X-Spam-Level:
X-Spam-Status: No, score=-1.595 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 X0g07P87vvWM for <tcpm@ietfa.amsl.com>; Mon, 4 Jul 2022 12:15:15 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16192C15AD32 for <tcpm@ietf.org>; Mon, 4 Jul 2022 12:15:15 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id t25so17140000lfg.7 for <tcpm@ietf.org>; Mon, 04 Jul 2022 12:15:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hteH9VyG4cTXmL+UAeGizoE6SQbQDalvljovZAX+PYk=; b=UD2+TIowP38u17sUeb1EZ/DpDFA5H+zYDbMNx7T4bmZZDx1m/Yh4jQUUMWr2TXyUsD LLMXsmwVHuCEPrCnUk1dnTpo+Bd3EHBeUJKFSbDe4EPvYe+ZO0hzSoI6UMRnc034Qe1r WT9c7htKKOSlzLUrx04Uwpmgpno538NCXI7pqLz0n1ifKL7F4SVUcKXKFID/LWllqNmH QmVvphuab5hjR5QMHJmgnyLzCnPXjVZTVr0s0iPBzIuTNUoW1IsEytOd3uUp79IU2e23 TkBmUe9YLpFKgDYAxye4hRa6Coi4nx4WJxDV7SrrztE7dqYtUgttR6oEjM2JR7F5AIL3 Nh7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hteH9VyG4cTXmL+UAeGizoE6SQbQDalvljovZAX+PYk=; b=hJ0Webj7KCAEE9i+lmNQT9rrlxmHDvzjdRrmL4DMUzgIjtxUiErLLMUMFL7YocVzUc emBl3qkwgyKt80fSK6SUxObKGzuZNKHI1e1T0z2ZOHQ1loKF0gb70ZtM6Kj3Oc035c8T BXz31UeB+/j4oMClqDvhOa9qVkofLMeLRqBINnW2darxY4U4DPeunPPuJrsru3VStlnH YUOiuQy+lsyH4CM4Y3NF0Vfqg0LbMNO0FNeHzeyirlIAtJ1ZaXbh64/Rperi9oZ1vLic o9HMkSh2Wq7J2q753Jol8sM0eohjiVfONNd6e/FCWr+CwhG+q+2uTvphWWlCoVDyqhl3 3pIw==
X-Gm-Message-State: AJIora+RUAlFzaPvaPcHoTydAYaATKq9iNGhyojtd6V0JfzPDhdcomZq X1P05+4QpZdrYM+kyKLFvHulDNhYs8Gkn/c3Dvm2sQ==
X-Google-Smtp-Source: AGRyM1sTzfdquZ2ywTp4u2CxMckMXDTbrSj/PNMvDWxxBHea5+6QbaHkQVdZOMSYPu35z1CNOD0Z4/rTG3btwt1p8ZY=
X-Received: by 2002:ac2:4e4e:0:b0:47f:b3c0:2f3d with SMTP id f14-20020ac24e4e000000b0047fb3c02f3dmr19210521lfr.15.1656962112613; Mon, 04 Jul 2022 12:15:12 -0700 (PDT)
MIME-Version: 1.0
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> <4688b79370e94df6b8af107a97be0a7f@hs-esslingen.de>
In-Reply-To: <4688b79370e94df6b8af107a97be0a7f@hs-esslingen.de>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 04 Jul 2022 21:15:11 +0200
Message-ID: <CAOj+MMGxUxqFko1R5yVkpc6Ujw6SJcOjB209YNKuGJo+MOZfvA@mail.gmail.com>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Cc: "touch@strayalpha.com" <touch@strayalpha.com>, Gyan Mishra <hayabusagsm@gmail.com>, 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>
Content-Type: multipart/alternative; boundary="00000000000021003305e2ff8ecd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/_M4GIwIb0v5LWXtXLp4IncTgaBs>
Subject: Re: [tcpm] [Last-Call] 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 19:15:19 -0000

Hi,

> 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.

While clients running on top of TCP can configure its parameters I would at
least expect to be able to report such values (local and remote) when using
the TCP YANG model. For example I can not find the Urgent Flag in the
current YANG model. Same for elementary window size of any given
connection, same for connection duration, .

Inability to do so to me sounds like a half baked model. IMHO it is not
ready to be even declared as MVP.

Many thx,
Robert


On Mon, Jul 4, 2022 at 6:06 PM Scharf, Michael <
Michael.Scharf@hs-esslingen.de> wrote:

> 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
>
>
>
> On Jul 3, 2022, at 10:16 PM, Gyan Mishra <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 <touch@strayalpha.com>
> wrote:
>
> FWIW:
>
> > On Jul 3, 2022, at 9:04 PM, Gyan Mishra via Datatracker <
> 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://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>