Re: [tcpm] WGLC for 793bis - Review comments

[Wesley Eddy <[e-mail]>]

Thank you for the review and comments.  For the most part, these were 
easy to address in my working copy, but there I think the parts around 
half-duplex CLOSE shouldn't change.  Here are some responses to each, 
with more details:

On 10/11/2020 1:32 PM, Rahul Jadhav wrote:
> This is an incredibly detailed work, covering protocol,
> implementation, and different scenarios aspects. The scenarios/context
> provided for "Quiet Time specification" and "Reset handling", were
> particularly interesting to note for me. Following are my comments:
>
> Section 3.1: "The window size MUST be treated as an unsigned number,
> or else large window sizes will appear like negative windows and TCP
> will now work (MUST-1)."
> [RJ] It should be "TCP will _not_ work (MUST-1)" ... I guess its a typo (?).

You're correct; I've now fixed this in the working copy.

> Section 3.5.1: ... an application that has called CLOSE cannot
> continue to read data from the connection (MAY-1).
> [RJ] shouldn't this be that "an application that has called CLOSE
> _can_ continue to read data from the connection (MAY-1)"? ... Again I
> suppose it's a typo but want to make sure.

This is in reference to the peculiar "half-duplex" implementation option 
for the CLOSE sequence.   The first paragraph of this section discusses 
the normal "full-duplex" option, and this second paragraph covers the 
half-duplex option.  So, this is actually correct as-written.  The RFC 
2525 reference mentioned at the end of the section is clear on this.

> Section 3.5.1: See [18] section 2.17 for discussion.
> [RJ] This reference is broken since section 2.17 no more exists.

It is actually RFC 2525 Section 2.17 (not section 2.17 of 793bis) that 
is referenced here.   The autogenerated hyperlink doesn't seem to 
understand that, but it's clear from the text at least.

> Section 2.1: ... with each TCP segment sent as an Internet Protocol
> (IP) datagram.
> [RJ] Even though recommended, it isn't necessary that each TCP segment
> be sent as a single IP datagram.

Hmmm, this I don't know about.  Are you thinking of IP fragmentation?

> Section 2.1: Anycast applications exist that successfully use TCP
> without modifications, though there is some risk of instability due to
> changes of lower-layer forwarding behavior.
> [RJ] A ref would help.

I think we can add a reference to RFC 7094 here to the document.

https://tools.ietf.org/html/rfc7094

> Small Nits:
> Section 3.3: ...likelihood of reuse of ports and sequency numbers after reboots.
> [RJ] s/sequency/sequence
ACK.
> Section 3.6.5: ...present IPv6 Node Requiements
> [RJ] s/Requiements/Requirements
ACK.