[tcpm] John Scudder's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Thu, 23 September 2021 02:00 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CF03A1599; Wed, 22 Sep 2021 19:00:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tcpm-rfc793bis@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Michael Scharf <michael.scharf@hs-esslingen.de>, michael.scharf@hs-esslingen.de
X-Test-IDTracker: no
X-IETF-IDTracker: 7.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <163236242658.4897.3790094103078602735@ietfa.amsl.com>
Date: Wed, 22 Sep 2021 19:00:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/bvyCwE4AIevPcSJXgtICX4AEF8Y>
Subject: [tcpm] John Scudder's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Sep 2021 02:00:28 -0000
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.
- [tcpm] John Scudder's No Objection on draft-ietf-… John Scudder via Datatracker
- Re: [tcpm] John Scudder's No Objection on draft-i… Wesley Eddy
- Re: [tcpm] John Scudder's No Objection on draft-i… John Scudder