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

[Robert Raszuk <[e-mail]>]

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 <
[e-mail]> 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:* [e-mail] <[e-mail]>
> *Sent:* Monday, July 4, 2022 4:38 PM
> *To:* Gyan Mishra <[e-mail]>
> *Cc:* Last Call <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
> *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 <[e-mail]> 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 [e-mail] <[e-mail]>
> wrote:
>
> FWIW:
>
> > On Jul 3, 2022, at 9:04 PM, Gyan Mishra via Datatracker <
> [e-mail]> 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 [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
>