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

[Lars Eggert <[e-mail]>]

Hi,

On 2021-10-8, at 22:14, Wesley Eddy <[e-mail]> wrote:
> 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.

for an RFC, esp. one that is expected to be quite long-lived, I don't think referring to ongoing work is such a great idea, since that won't age well. Maybe how you are referring to that document could be rephrased?

> 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?

That would be good, and explain why the much shorter cycle times are still not a problem?

> 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.

Actually, we discussed during the call whether this review had happened, whether it still should happen, and if there was anything the document might say about TCP's privacy aspects (ideally citing something with more context).

>>  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.

Nit: R is not a vowel, but it starts with a vowel *sound*.

> 
> 
>> 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.

Wouldn't this read better if either "old" or "delayed" was removed?

Thanks,
Lars