Re: [tcpm] Lars Eggert's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)

[Wesley Eddy <[e-mail]>]

I put together a commit that addresses your COMMENT items, except for 
the ones below 
(https://bitbucket.org/weddy/rfc793bis/commits/137a78916261c18440c1b298d0eb705c341a4002):

On 9/20/2021 10:18 AM, Lars Eggert via Datatracker wrote:
> Section 3.1. , paragraph 50, comment:
>>       Note: There is ongoing work to extend the space available for TCP
>>       options, such as [64].
> draft-ietf-tcpm-tcp-edo has been dead for four years, not sure how useful it is
> to point to.

I didn't change this, because I recall it being mentioned in the WG that 
it was felt to be useful to point to, if only to avoid someone proposing 
yet another way of dealing with this.


> Section 3.4. , paragraph 49, comment:
>>     At 2 megabits/sec. it
>>     takes 4.5 hours to use up 2**32 octets of sequence space.  Since the
>>     maximum segment lifetime in the net is not likely to exceed a few
>>     tens of seconds, this is deemed ample protection for foreseeable
>>     nets, even if data rates escalate to 10's of megabits/sec.  At 100
>>     megabits/sec, the cycle time is 5.4 minutes, which may be a little
>>     short, but still within reason.
> It would be nice to see an argument if any considerations change for today's
> higher-bandwidth Internet paths.

Sure; should we add the computed values for 1, 10, and 100 Gbps?


> Section 3.9.1. , paragraph 1, comment:
>> 3.9.1.  User/TCP Interface
> This section would be much more readable if each command was in its own
> sub-section. I find deeply indented text that spans multiple pages difficult to
> follow.

Ok, I can work on this.


> Section 5. , paragraph 50, comment:
>>     Early in the process of updating RFC 793, Scott Brim mentioned that
>>     this should include a PERPASS/privacy review.  This may be something
>>     for the chairs or AD to request during WGLC or IETF LC.
> Has this review has happened?

I think this status has been accepted by the IESG now.


>   * Term "his"; alternatives might be "they", "them", "their".

It looks like the remaining instance refers to Jon Postel.


>   Section 3.3.2. , paragraph 16, nit:
>> icult to read. Similarly, receipt of a RST from any state results in a trans
>>                                       ^
> Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
> "an article", "an hour".

Since "RST" starts with an R, which is not a vowel, I think this warning 
(which occurs multiple times) is spurious.


> Section 3.4. , paragraph 37, nit:
>> owing whether the segment was an old delayed one or not, unless it remembers
>>                                   ^^^^^^^^^^^
> Make sure that the adjective "old" is correct. Possibly, it should be an adverb
> (typically ~ly) that modifies "delayed". Possibly, it should be the first word
> in a compound adjective (hyphenated adjective). Possibly, it is correct.
This seemed alright to me, though I'm fine to change it if you disagree.


> Section 3.10.1. , paragraph 6, nit:
>>   generate an acknowledgement in the later processing steps, saving this extra
>>                                      ^^^^^
> Did you mean "latter" (=the second of two items)?

I think this one is correct as-is.


> These URLs in the document did not return content:
>   * http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-edo-10.txt
>   * http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-04.txt
>   * http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seccomp-prec-00.txt

I think these come from the bibxml automatically, and may better be 
pointed to the appropriate datatracker URLs.  It might be something for 
the RFC Editor?