[tcpm] John Scudder's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-tcpm-rfc793bis-25: No Objection

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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


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



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

Thanks very much for this document and all the work that went into it. Thanks
also for the clear and illuminating shepherd write-up.

Below are some comments I hope will be helpful.

1. Regarding in §1,

  The purpose of this document is to bring together all of the IETF
  Standards Track changes that have been made to the base TCP
  functional specification and unify them into an update of [RFC 793].

It also incorporates Informational documents, right? For example, RFC 6691 is
Informational, as is 6429. So, these are being elevated, by virtue of their
incorporation, to Standards Track. I'm not saying that's a problem, but the
quoted text, while technically accurate I suppose (it doesn't say "exclusively
Standards Track changes" after all) is misleading.

2. Regarding, in §3.4,

  A new acknowledgment (called an "acceptable ack"), is one for which
  the inequality below holds:

   SND.UNA < SEG.ACK =< SND.NXT

I’m having a hard time seeing why the first part of the inequality is < and not
=<. Wouldn’t =< be the case when a single new byte is being acknowledged?
(Based on the definition that SND.UNA is the “oldest unacknowledged sequence
number” and therefore, presumably needs to be acknowledged.) I do see this text
is unchanged from RFC 793 so I am very likely wrong, but I’d appreciate knowing
WHY I’m wrong…

3. Regarding, in §3.4,

     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.

I realize this is, again, inherited from RFC 793 but it seems hopelessly quaint
in 2021 and not suitable for publication today. I mean, my unexceptional
commodity home connection is 1 Gbps and it just goes up from there. At 100 Gbps
we’re down to a cycle time of ~300 msec which no longer seems so easy to brush
off as "still within reason". I’m not suggesting this document has to fix the
problem, and indeed I’m aware there are other documents for this purpose — but
does the outdated text have to be retained?

4. The parenthetical reference to “User Telnet” in §3.8.3 seemed equally
anachronistic. Seems like it could just be removed.

5. It made me sad while reviewing the document, that certain sections were
stingy with subsection numbering. In particular §3.4 has the unnumbered
subheadings "Initial Sequence Number Selection", "Knowing When to Keep Quiet",
and "The TCP Quiet Time Concept", and §3.5 has "Half-Open Connections and Other
Anomalies", "Reset Generation", and "Reset Processing". I think it would make
the document more usable if these were numbered, as we tend to do in the modern
era, and as the rest of the document does do. (I may have missed some, the list
above isn't necessarily exhaustive.)

Nits:

6. I found it odd that figure 11 uses Z and X as the sequence numbers, whereas
all the previous illustrations used actual numbers. It works of course, but
it's inconsistent.

7. In §3.1:

   The control bits are also know as "flags"

   S/know/known/

8. In §3.1, “one’s complement” should be “ones’ complement”.

9. In §3.3.2:

   transitions are not not explicitly shown

   Presumably the double negation isn’t isn't deliberate. :-)

10. In §3.4:

    next sequence number expected on an incoming segments

    Should be segment, singular.

11. In §3.4:

    sequence space occupying controls

    I think this needs, or at least would be better with, a hyphen: “sequence
    space-occupying controls”

12. In several places, "anyways" should probably be "anyway". (At least my
dictionary suggests the change.)

13. In §3.4:

  Hosts that prefer to avoid waiting are
  willing to risk possible confusion of old and new packets at a given
  destination may choose not to wait for the "quiet time".

“Are willing” should be “and are willing”

14. In §3.6:

    the user can terminate his side gracefully

Perhaps consider a non-gendered pronoun such as "their"?

15. In §3.8.2:

  [RFC 1122] required implementation of Van Jacobson's congestion control
  algorithms slow start and congestion avoidance together with

Seems as though there’s some punctuation missing. Perhaps “RFC 1122 required
implementation of Van Jacobson’s congestion control algorithms, slow start, and
congestion avoidance, together with“?

16. “Internet” is inconsistently capitalized throughout, probably corresponding
to age of the text. But I suppose the RFCEd will fix this.