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

From: Wesley Eddy <[email-masked]>
Date: Fri, 8 Oct 2021 15:14:43 -0400

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?

---

From: Lars Eggert <[email-masked]>
Date: Mon, 11 Oct 2021 11:55:16 +0300

Hi,

On 2021-10-8, at 22:14, Wesley Eddy <[email-masked]> wrote:
> 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?

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

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

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

> 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

---

From: <[email-masked]>
Date: Mon, 11 Oct 2021 11:30:48 +0000

Hi Lars, all, 

Commenting on one particular point. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tcpm <[email-masked]> De la part de Lars Eggert
> Envoyé : lundi 11 octobre 2021 10:55
> À : Wesley Eddy <[email-masked]>
> Cc : [email-masked]; [email-masked]; The IESG
> <[email-masked]>; [email-masked]
> Objet : Re: [tcpm] Lars Eggert's Discuss on draft-ietf-tcpm-rfc793bis-25:
> (with DISCUSS and COMMENT)
> 
> Hi,
> 
> >> draft-ietf-tcpm-tcp-edo has been dead for four years, not sure how
> >> useful it is to point to.
> >

Med] I confirm. This was, for example, discussed here: https://mailarchive.ietf.org/arch/msg/tcpm/TrbMCTywezzzSSjkdntF6EtHl18/

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

Med] As can be seen in the thread, the intent was: 

"* Consider adding some text to ACK the TCP option space problem. Adding a pointer to EDO as * an example * (without recommending it) of how to extend the space for non-SYNs would be useful."

I think this is adequately captured by the current wording: "... such as [64]". 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 11 Oct 2021 07:41:35 -0700

> 
> On Oct 11, 2021, at 1:55 AM, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 
> On 2021-10-8, at 22:14, Wesley Eddy <[email-masked] <mailto:[email-masked]>> wrote:

To repeat my post from 9/30/21, which was not responded to:

Were drafts not archived by the IETF, I would agree, but they are, so they remain useful.

Further, it isn’t “dead”; it hasn’t changed. I no longer perform in-place updates when there are no changes.

I discussed how to move it forward with the chairs in July 2020. Based on that discussion the deadline was moved to Nov 2022, largely due to my limited cycles for concurrent drafts, focusing on 2140bis first.

Regardless, it remains a comprehensive description of the issues.

Joe