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

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

“ It was explicitly not the intent of this effort to model every aspect 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.”

Michael Scharf comment below

“ The remaining suggestions in the review (e.g., TCP flags, congestion
control algorithms, TCB control block, …) 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.”

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 <touch@strayalpha.com>
wrote:

>
> —
> 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 A**rchitect *
> *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
>
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*