From nobody Mon Jul 4 08:51:39 2022 Return-Path: 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 15794C15AD3C; Mon, 4 Jul 2022 08:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 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, FREEMAIL_FROM=0.001, 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_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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4Rpl8_BAg2Yf; Mon, 4 Jul 2022 08:51:32 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 E0267C157B4F; Mon, 4 Jul 2022 08:51:32 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id m14so8875169plg.5; Mon, 04 Jul 2022 08:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gr74A2Jl8yfj5+xeIZq8EJQVcsPa2LgSaPDJfwpXMYE=; b=Ceq19q0eVduA4cg+lV+Z1a/o2r6YS6EuoIT1dg/VEnonLB5ry/3pA3fV+7JCvAbVwM Mo9hJqsVUN/UyuPZ5u+NlBAp101iFxXLfBIfrPNYO0aB6fP1V5X+FidafgRI6WvDSdAo k7WJ8XqHtuGGeue+X44PiG/xdlKz3GfihdLk3tD9PbrdeOhksF4mvgHm7Vw03dyXr12S 2AzoaE5sJxsOOeQ3XKL43iwpF/g6Hk6CY6r2iJTeQo6dHlUgYG3sOYAu6NW/kMiKPoWf j3JNYjstWiSJ0FAClprvLjKgaVr6ck8Hg2e8y6Rrwgpy8UF/WW8ZD6P5D0Fytp/ft42n VSwg== 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=Gr74A2Jl8yfj5+xeIZq8EJQVcsPa2LgSaPDJfwpXMYE=; b=CFFArZzRW02979ykbUBAPuCMcRd2RKuddTu3nWpWD1y45vWLZ+PEz9VGT+khrdb6JX yBbVz1OSE3KN0gjslGit6ym3Ggrm0XKvLgNgu29vUaO+X9eNFy9Z63Q+WrieE1ET1rY7 uYotthMFcNFrXgn8v2fWSJptIpQrCE8XWyk8YKqq/H0j8Uxrebgx8+iQie7D7eceg9Vn d/0JzWSiEt63NYWUHhWQ49/YeHsZX+deoDe8hM0OA0Ty/5I98AOdDD/zwqb4SztJ6VBW 97rVf3jGwQLQxwn1YzXT65fzkpc/zC4dPvGtIlaP0bv4otBQIZ2I8T8yKIk38lF/vy6N irJw== X-Gm-Message-State: AJIora/hz5g0qhm1FNLAaJgOx5kfNr8ZA5+z9swxG6IHsjNFfrHoo67q nwzcnv1+8g/B3zLOIydIpq+/wngTmzahlUBdZSDxlcX5 X-Google-Smtp-Source: AGRyM1uaJdBng2q2dpj3Zd4pFFDqoeLrRx4+pWge9xZn8A4hnz6bgBDWkHDSqzazdfFFB+gkbTE/HpES+gHcNl3nvrM= X-Received: by 2002:a17:90a:d50d:b0:1ef:9130:f96b with SMTP id t13-20020a17090ad50d00b001ef9130f96bmr2055851pju.235.1656949891882; Mon, 04 Jul 2022 08:51:31 -0700 (PDT) MIME-Version: 1.0 References: <165690747653.9313.6940379164951428048@ietfa.amsl.com> <893612ED-91B7-4492-8000-EF2D54AC49BC@strayalpha.com> In-Reply-To: <893612ED-91B7-4492-8000-EF2D54AC49BC@strayalpha.com> From: Gyan Mishra Date: Mon, 4 Jul 2022 11:51:20 -0400 Message-ID: To: "touch@strayalpha.com" Cc: Last Call , draft-ietf-tcpm-yang-tcp.all@ietf.org, ops-dir@ietf.org, tcpm@ietf.org Content-Type: multipart/alternative; boundary="000000000000b7611e05e2fcb588" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2022 15:51:37 -0000 --000000000000b7611e05e2fcb588 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joe, Michael, Martin, et al Here is the mail archive link from March review and feedback to reference from Martin Duke and Michael Scharf. https://mail.google.com/mail/mu/mp/335/#cv/priority/%5Esmartlabel_personal/= 17f51790451b8ffc Martin Duke comment below =E2=80=9C It was explicitly not the intent of this effort to model every as= pect of TCP implementations. There was strong WG consensus that this would be time-consuming and extremely unlikely to be deployed, as most TCP endpoints don't use YANG. Instead, this document is tightly focused on BGP routers, which do use YANG. To include more aspects of TCP, we would want to see evidence that is relevant to this use case.=E2=80=9D Michael Scharf comment below =E2=80=9C The remaining suggestions in the review (e.g., TCP flags, congest= ion control algorithms, TCB control block, =E2=80=A6) would be additions to the= model beyond the TCP MIB. Also, that would significantly change the scope of the model. As already explained by Martin, there is no consensus in TCPM on such a model. A follow-up RFC could be published in that space, if there was enough energy and community consensus.=E2=80=9D So for the TCP model the focus is on what is covered in the TCP MIB. So per Martin anything beyond would be in a follow on RFC. Separate topic - Here is an earlier discussion thread related to BGP BPM and this draft and how this draft can be referenced for BMP and Michael Scharf mentioned other existing BGP Yang model to reference as this has changed in version 17 from last call comments. - draft-ietf-idr-bgp-model - draft-ietf-netconf-tcp-client-server https://mail.google.com/mail/mu/mp/335/#cv/search/draft-ietf-tcpm-yang-tcp/= 1808a94a342e3f19 I am bringing this up in case their is anything further that maybe necessary to polish up the draft. Kind Regards Gyan On Mon, Jul 4, 2022 at 10:37 AM touch@strayalpha.com wrote: > > =E2=80=94 > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com > > On Jul 3, 2022, at 10:16 PM, Gyan Mishra 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, s= o > the plan is that a separate protocol specific yang model would be a follo= w > 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 > 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, RS= T >> 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=E2=80=99ll add my i= nput. >> >> The YANG model represents information about the current TCP connection. >> It is not (and should not be confused with) a specification of the proto= col. >> >> Further, flags are associated with messages that cause state transitions= , >> not states (i.e., the FSM is a Mealy machine, not a Moore machine). Ther= e >> is no =E2=80=9Cflags set for each state=E2=80=9D. >> >> > >> http://tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateM= achineF-2.htm >> >> That page has errors and is not consistent with RFC793 (or it=E2=80=99s = pending >> -bis update). E.g., FIN stands for =E2=80=9Cfinis=E2=80=9D (latin for = =E2=80=9Cend=E2=80=9D), not =E2=80=9Cfinish=E2=80=9D. >> >> > 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 >> >> -- > > > *Gyan Mishra* > *Network Solutions A**rchitect * > *Email gyan.s.mishra@verizon.com * > > > *M 301 502-1347* > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000b7611e05e2fcb588 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Joe, Michael, Martin, et al=C2=A0

Here is the mail archive link fr= om March review and feedback to reference from Martin Duke and Michael =C2= =A0Scharf.


Martin Duke comment below=C2=A0
<= br>
=E2=80=9C=C2=A0It was explicitly not the intent of this effort to model every asp= ect of TCP implementations. There was strong WG consensus that this would b= e time-consuming and extremely unlikely to be deployed, as most TCP endpoin= ts don't use=C2=A0YANG. Instead, this document is tightly focused on BG= P routers, which do use YANG.=C2=A0

To include more aspects of TCP, we would want to see eviden= ce that is relevant to this use case.=E2=80=9D

Michael Scharf comment below
=E2=80=9C=C2=A0The remaining suggestions in the review (e.g., TCP flags, congestion= control algorithms, TCB control block, =E2=80=A6) would be additions to th= e model beyond the TCP MIB. Also, that would significantly change the scope= of the model. As already explained by Martin, there is no consensus in TCP= M on such a model. A follow-up RFC could be published in that space, if the= re was enough energy and community consensus.=E2=80=9D

So for the TCP model = the focus is on what is covered in the TCP MIB.=C2=A0 So per Martin anythin= g beyond would be in a follow on RFC.

Separate topic - Here is an earlier discussion thread = related to BGP BPM and this draft and how this draft can be referenced for = BMP and Michael Scharf mentioned other existing BGP Yang model to reference= as this has changed in version 17 from last call comments.

  • draft-ietf-idr-bgp-mod= el
  • draft-iet= f-netconf-tcp-client-server

I am bringing this up in case their is an= ything further that maybe necessary to polish up the draft.

Kind Regards=C2=A0

Gyan


On Mon, Jul 4, 2022 at 10:37 AM touch@strayalpha.com <touch@strayalpha.com> wrote:

=E2=80=94
Dr. Joe Touch, temporal epistemologist

On Jul 3, 2022, at 10:16 PM, Gyan M= ishra <hayabu= sagsm@gmail.com> wrote:

Hi Joe, auth= ors =C2=A0et all=C2=A0

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

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 b= e a follow on to address all of my concerns.
<= br>
First, there should NEVER be two different YANG models for BG= P routers vs. other routers or hosts. TCP is TCP is TCP. If that is an assu= mption for moving this document forward, TCPM should have a longer discussi= on about that point specifically.

Second, my obser= vations about your requests below stand, regardless of when/where current o= r future authors might be considering them.

Joe

<= /div>
=

On Mon, Jul 4, 2022 at 12:44 AM touch@strayalpha.com <<= a href=3D"mailto:touch@strayalpha.com" target=3D"_blank">touch@strayalpha.c= om> 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.=C2=A0 I ver= ified 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 F= SM state
> machine.
>
> Would it be possible to specify the TCP Header flags SYN, FIN, ACK, RS= T of BFD
> FSM finite state machine Events and Transition.=C2=A0 I think this wou= ld be very
> helpful for the TCP Yang model FSM state machine.=C2=A0 For each state= you could
> specify the flags set.

These issues appear to have been raised by you in March during last call re= view. Some have been addressed by others before; I=E2=80=99ll 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, n= ot states (i.e., the FSM is a Mealy machine, not a Moore machine). There is= no =E2=80=9Cflags set for each state=E2=80=9D.

> http://tcp= ipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm=

That page has errors and is not consistent with RFC793 (or it=E2=80=99s pen= ding -bis update). E.g., FIN stands for =E2=80=9Cfinis=E2=80=9D (latin for = =E2=80=9Cend=E2=80=9D), not =E2=80=9Cfinish=E2=80=9D.

> 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 simi= lar information, is optional.

If there is connection information returned, I do not think it should be th= e TCB; that is an implementation-dependent parameter, not a universal prope= rty 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 sh= ould not be confused with - a troubleshooting tool.

Joe

--


Gyan Mishra
Network Solutions Architect=C2=A0
<= div style=3D"font-size:1em;margin:0px;line-height:13px">M 301 50= 2-1347


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://= www.ietf.org/mailman/listinfo/tcpm

--

=

Gyan Mishra<= /b>

Network Solut= ions Architec= t=C2=A0

Email gyan.s.mishra@verizon.com

M 301 502-134= 7


=
--000000000000b7611e05e2fcb588--