Joe, Michael, Martin, et al
Here is the mail archive link from March review and feedback to reference from Martin Duke and Michael Scharf.
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
I am bringing this up in case their is anything further that maybe necessary to polish up the draft.
Kind Regards
Gyan
—Dr. Joe Touch, temporal epistemologistOn Jul 3, 2022, at 10:16 PM, Gyan Mishra <hayabusagsm@xxxxxxxxx> wrote:Hi Joe, authors et allI 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--FWIW:
> On Jul 3, 2022, at 9:04 PM, Gyan Mishra via Datatracker <noreply@xxxxxxxx> 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
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tcpm
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
