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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Mon, 20 Sep 2021 07:18:56 -0700

Lars Eggert has entered the following ballot position for
draft-ietf-tcpm-rfc793bis-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The IESG needs to approve the following DOWNREFs during the telechat:

  DOWNREF [10] from this Internet Standard to Proposed Standard RFC6298.
  DOWNREF [2] from this Internet Standard to Draft Standard RFC1191.
  DOWNREF [7] from this Internet Standard to Proposed Standard RFC3168.
  DOWNREF [11] from this Internet Standard to Proposed Standard RFC6633.
  DOWNREF [9] from this Internet Standard to Draft Standard RFC5681.
  DOWNREF [5] from this Internet Standard to Proposed Standard RFC2675.
  DOWNREF [4] from this Internet Standard to Proposed Standard RFC2474.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

Section 3.4. , paragraph 35, comment:
>    Initial Sequence Number Selection

Shouldn't this be a heading starting a new sub-section?

Section 3.4. , paragraph 46, comment:
>    Knowing When to Keep Quiet

Shouldn't this be a heading starting a new sub-section?

Section 3.4. , paragraph 47, comment:
>    The TCP Quiet Time Concept

Shouldn't this be a heading starting a new sub-section?

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.

Section 3.5. , paragraph 37, comment:
>    Half-Open Connections and Other Anomalies

Shouldn't this be a heading starting a new sub-section?

Section 3.5. , paragraph 74, comment:
>    Reset Processing

Shouldn't this be a heading starting a new sub-section?

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.

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?

Document obsoletes RFC793, but does not cite it as a reference.

Document obsoletes RFC879, but does not cite it as a reference.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

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

 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.3.2. , paragraph 21, nit:
-       Note 2: An unshown transition exists from FIN-WAIT-1 to TIME-WAIT
-               ^^  ^ ^^^^           -------
+       Note 2: The figure omits a transition from FIN-WAIT-1 to TIME-WAIT
+               ^^^ +++ ^^^^^^^ ^^

Section 3.8.6.1. , paragraph 4, nit:
-    paper" situation described in Section 4.2.2.17 of RFC1122.  The
-                                                      ^^^ ^^^
+    paper" situation described in Section 4.2.2.17 of [18].  The
+                                                      ^ ^^

Section 3.8.6.3. , paragraph 3, nit:
-    recomendations to immediately acknowledge out-of-order segments,
+    recommendations to immediately acknowledge out-of-order segments,
+        +

"Table of Contents", paragraph 2, nit:
>  . . . . . . . . . 108 A.4. Low Water Mark Settings . . . . . . . . . . . .
>                                 ^^^^^^^^^^
This is normally spelled as one word.

Section 3.1. , paragraph 8, nit:
> ing host. The control bits are also know as "flags". Assignment is managed b
>                                     ^^^^
Did you mean "known"?

Section 3.2. , paragraph 12, nit:
> ue and to the current segment. In addition several variables relating to the
>                                   ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 3.3.2. , paragraph 15, nit:
> m SYN-RECEIVED to LISTEN on receiving a RST is conditional on having reached
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.3.2. , paragraph 16, nit:
> rationale). These transitions are not not explicitly shown, otherwise the di
>                                   ^^^^^^^
This phrase contains a double negative, or a comma may be missing.

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

Section 3.4. , paragraph 25, nit:
> The clock component is intended to insure that with a Maximum Segment Lifetim
>                                    ^^^^^^
Did you mean "ensure" (=make sure)? "Insure" means "pay money to insurance
company".

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.

Section 3.4. , paragraph 37, nit:
> e sender to verify this SYN. The three way handshake and the advantages of a
>                                  ^^^^^^^^^
This word is normally spelled with a hyphen.

Section 3.4. , paragraph 47, nit:
> nets, even if data rates escalate to 10's of megabits/sec. At 100 megabits/se
>                                      ^^^^
Apostrophes aren't needed for decades.

Section 3.5. , paragraph 3, nit:
> he ACK field is incorrect and returns a RST (reset) with its SEQ field select
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 25, nit:
> onnection exists, so TCP Peer A sends a RST. The RST is acceptable so TCP Pe
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 29, nit:
> (line 3) and causes TCP A to generate a RST (the ACK in line 3 is not accepta
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 80, nit:
> d, its TCP implementation SHOULD send a RST to show that data was lost (SHLD-
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.7.1. , paragraph 9, nit:
>  not support attachment to links with a MTU greater than 65,575 [5], and the
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.7.5. , paragraph 2, nit:
> s of the SYN segment or by receipt of a RST segment or an ICMP Port Unreachab
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.8.2. , paragraph 4, nit:
> tion, or at least to determine whether or not more urgent data remains to be
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 3.8.3. , paragraph 2, nit:
> hat all have the same sequence number so there will be no way to reorder them
>                                      ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Section 3.8.3. , paragraph 6, nit:
> g accepted that much data. This, so called "shrinking the window," is strong
>                                  ^^^^^^^^^
The expression "so-called" is usually spelled with a hyphen.

Section 3.8.6.2.1. , paragraph 17, nit:
> he operating system will verify the users authority to open a connection with
>                                     ^^^^^
An apostrophe may be missing.

Section 3.8.6.2.2. , paragraph 4, nit:
> ction name can then be used as a short hand term for the connection defined
>                                  ^^^^^^^^^^
This word is normally spelled as one.

Section 3.9.1. , paragraph 27, nit:
> he user level protocol is not well thought out) that the closing side is una
>                               ^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 3.9.2. , paragraph 7, nit:
> aiting delivery, the RECEIVE will get a "error: connection closing" response
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.1. , paragraph 2, nit:
> , this is an error and should receive a "error: connection closing" response
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.2. , paragraph 11, nit:
> arded. An incoming segment containing a RST is discarded. An incoming segment
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.2. , paragraph 11, nit:
> . An incoming segment not containing a RST causes a RST to be sent in respon
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.3. , paragraph 1, nit:
> g segment not containing a RST causes a RST to be sent in response. The ackn
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.10.1. , paragraph 3, nit:
> ED state, delete TCB, and return. Otherwise (no ACK) drop the segment and ret
>                                   ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Otherwise".

Section 3.10.1. , paragraph 3, nit:
> o ACK, and the segment did not contain a RST. - If the SYN bit is on and the
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

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

Section 3.10.7.4. , paragraph 30, nit:
> aining sequence numbers entirely outside of this range are considered duplic
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 3.10.7.4. , paragraph 32, nit:
> a segment containing RST give rise to a RST in response. SEG.ACK segment ack
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.10.7.4. , paragraph 83, nit:
>  573: Reported by Bob Braden (note: This errata basically is just a reminder
>                                     ^^^^
The demonstrative "This" may not agree with the plural noun "errata". Did you
mean "these"?

Section 3.10.7.4. , paragraph 83, nit:
>  of the "functional specification". Also the 1122 text on the retransmission
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Also".

Section 3.10.7.4. , paragraph 102, nit:
> discussion in 2015 also indicated that that we should not try to add sections
>                                   ^^^^^^^^^
Possible typo: you repeated a word.

Section 5. , paragraph 2, nit:
> firewalls, and other technologies outside of the end-host TCP implementation.
>                                   ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 8. , paragraph 2, nit:
> beneficial to consider. A.4. Low Water Mark Settings Some operating system ke
>                                  ^^^^^^^^^^
This is normally spelled as one word.

Reference [20] to RFC1644, which was obsoleted by RFC6247 (this may be on
purpose).

Reference [17] to RFC896, which was obsoleted by RFC7805 (this may be on
purpose).

Reference [19] to RFC1349, which was obsoleted by RFC2474 (this may be on
purpose).

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

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 20 Sep 2021 10:09:57 -0700

Hi, all,

> On Sep 20, 2021, at 7:18 AM, Lars Eggert via Datatracker <[email-masked]> wrote:
> 
> ...
> …

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

—
Joe Touch, temporal epistemologist
www.strayalpha.com