[tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 28 August 2019 15:21 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB74F120043 for <tcpm@ietfa.amsl.com>; Wed, 28 Aug 2019 08:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM0bgp_7OKDn for <tcpm@ietfa.amsl.com>; Wed, 28 Aug 2019 08:21:04 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9C6E12000F for <tcpm@ietf.org>; Wed, 28 Aug 2019 08:21:03 -0700 (PDT)
Received: from MacBook-Pro-5.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8AC601B000A3; Wed, 28 Aug 2019 16:20:58 +0100 (BST)
Message-ID: <5D669BDA.3000506@erg.abdn.ac.uk>
Date: Wed, 28 Aug 2019 16:20:58 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/QnIzQ3GOvOJxOsMmqsnQZXyQKZQ>
Subject: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 28 Aug 2019 15:21:07 -0000
I promised to provide review comments for rev 14 of RFC 793 bis. This review comes in two parts, the first (this) contains what I think are mostly editorial issues and questions about document style for a document to be published in 2020. best wishes, Gorry --- Document Style Parts of this document still has a quant old-fashioned style, somnetimes degenerating into weirdness. I think more needs to be done to bring this document into the current century. See comments below: --- I was amused at the frequent reference to "crash" or "crashing". I'm not sure that presents the correct view of the IETf about the stability of the TCP stack and certainly is not what IO would expect in an RFC that could be promoted to full standard. I think this needs to be changed. e.g. "TCP MUST be prepared to handle an illegal option length (e.g., zero) without crashing;" could I suggest be: "TCP MUST be prepared to handle an illegal option length (e.g., zero);" and this "even if a TCP crashes and loses all knowledge of the sequence numbers it has been using. " could be: "even if a TCP implementation loses knowledge of the sequence numbers it has been using." etc --- OLD: on some machines - if still relevant, I suggest: NEW: in some implementation architectures --- OLD: foreign socket NEW: remote socket - e.g. (a) general information about a connection (e.g., interrupts, remote close, binding of unspecified foreign socket). - what is a foreign socket in modern language - is that a remote peer? - there are other examples, but also later: OLD: If no foreign socket was specified in the OPEN, but the connection is established (e.g., because a LISTENing connection has become specific due to a foreign segment arriving for the local socket), then the designated buffer is sent to the implied foreign socket. Users who make use of OPEN with an unspecified foreign socket can make use of SEND without ever explicitly knowing the foreign socket address. - what is a foreign segment? - and I'm not entirely sure what is mean by a foreign socket address. --- The security-related text "IP security level and compartment of the connection" Appendix - OLD: there has been discussion about ammending the TCP specification to prevent connections from being aborted due to non-matching IP security compartment and DiffServ codepoint values. - Is this statement correct? I'm not aware of the Diffserv discussion being current, and thought (although could be corrected if someone provides refs) that the current proactive was not to verify the DSCP? - This adds unnecessary and unusual terminology to reading the document. In 3.2.1 it's a spurious example and this and it's cross reference could be omitted to increase clarity. I'd also suggest removal from the core of the document the related text in section 3.4, etc. This could all be consolidated in appendix A1 - if this is required for other Specs. The para in section 3.6 starting: The IP security option (IPSO) and compartment defined in [1] was refined in RFC 1038 that was later obsoleted by RFC 1108. - This also appears in pseudo code on page 70 (weird) - I suggest all text (if retained) belongs to this appendix. +++++++++++++++++++++++++++++++++++++++++++++ Editorial comments on the remaining text: --- OLD: A number of enhancements has NEW: The number of enhancements has --- OLD: TCP reliability consists of detecting packet losses (via sequence numbers) and errors (via per-segment checksums), as well as correction of losses and errors via retransmission. - I think this makes it appears that errors are somehow different to loss, and they are not. I suggest we just say "loss". ---- OLD: Data flow is supported bidirectionally over TCP connections, though applications are free to flow data only unidirectionally, - "flow data only" reads weird, can we say send payload data or something? --- OLD: If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent. - Punctuation? NEW: If the ACK control bit is set, this field contains the value of the next sequence number that the sender of the segment is expecting to receive. Once a connection is established, this is always sent. --- multiple OLD: " which" - in all cases I found this is not the correct word, should it be " that", or ", which". --- multiple OLD: "remote TCP" - I found that a little odd, and does not expand the acconym, could we replace by "remote TCP endpoint" or "remote TCP peer". --- multiple OLD: "TCPs" and "a TCP" - This use of a "TCP" as an entity read as very ugly to me. I had to read the sentences several times to parse them, could we explain that we mean, i.e. "TCP endpoints" or "TCP implementations" etc. (usually this seems to mean implementation). --- OLD: When simultaneous attempt occurs, - I think the current term is simultaneous open. NEW: When simultaneous open occurs, --- OLD: An "XXX" indicates a segment which is lost or rejected. - rejected seems odd here. NEW: An "XXX" indicates a segment that is lost (not processed by the receiving TCP endpoint). --- OLD: has been devised. - weird word? NEW: is specified. --- OLD: SYN (pun intended) - I didn't see the pun, can this be explained or omitted? --- OLD: procedure is mildy involved - weird, or explain NEW: procedure is triggered. --- Section 3.5 OLD: until he is NEW: until the TCP receiver is --- Section 3.5 OLD: the other side NEW: the remote TCP peer --- OLD: Avoiding sending segments larger than the smallest MTU within an IP network path, because this results in either packet loss or fragmentation. NEW: Avoiding sending a TCP segment that would result in an I{P datagram larger than the smallest MTU along an IP network path, because this results in either packet loss or packet fragmentation. --- Section 3.8 OLD: retransmission (after a timeout) - move timeout, since this is no longer the norm. NEW: retransmission --- OLD: In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes. - not numbered as a MUST. --- (seventh step) OLD: an push flag NEW: a push flag --- OLD: IF our FIN NEW: If the FIN segment --- OLD: port The portion of a socket that specifies which logical input or output channel of a process is associated with the data. - The definition of "port" appears to be in terms of "socket" which it should not be. - What is a channel etc. This needs redefined in modern language. --- OLD: internet address A source or destination address specific to the host level. NEW: internet address The network layer address. --- OLD: Source Address The source address, usually the network and host identifiers. NEW: Source Address The network layer address of the sending endpoint. --- OLD: Destination Address The destination address, usually the network and host identifiers. NEW: Destination Address The network layer address of the remote endpoint. --- OLD (TOS): containing the Differentiated Services Code Point (DSCP) value and two unused bits. NEW: containing the Differentiated Services Code Point (DSCP) value and the 2-bit ECN codepoint [RFC3168]. --- OLD: The "tcpcrypt" [45]Experimental - insert space OLD: The "tcpcrypt" [45] Experimental --- OLD: like Appropriate Byte Counting (ABC) - Please Insert reference to ABC - RFC3465. --- OLD: * Urgent pointer advance (see Section 3.8.5) (MUST-32). - This is no requirement here. --- OLD: Error responses are given as character strings. - What does that mean? and how are these strings specified - unicode, ascii? - I suspect the present intention is that: NEW: Error responses in this document are identified by character strings. +++++++++++++++++++++++++
- [tcpm] review of rev 14 of RFC 793 bis part 1 of … Gorry Fairhurst
- [tcpm] review of rev 14 of RFC 793 bis part 2 of … Gorry Fairhurst
- Re: [tcpm] review of rev 14 of RFC 793 bis part 2… Joe Touch
- Re: [tcpm] review of rev 14 of RFC 793 bis part 2… Joe Touch
- Re: [tcpm] review of rev 14 of RFC 793 bis part 2… Gorry Fairhurst
- Re: [tcpm] review of rev 14 of RFC 793 bis part 2… Gorry Fairhurst
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Wesley Eddy
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Gorry Fairhurst
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Rodney W. Grimes
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Wesley Eddy
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Jonathan Morton
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Rodney W. Grimes
- [tcpm] 793bis: TCP Quiet Time Wesley Eddy
- Re: [tcpm] 793bis: TCP Quiet Time Yuchung Cheng
- Re: [tcpm] 793bis: TCP Quiet Time Neal Cardwell
- Re: [tcpm] 793bis: TCP Quiet Time Matt Mathis
- Re: [tcpm] 793bis: TCP Quiet Time Joe Touch
- [tcpm] 793bis: variable MTU Wesley Eddy
- [tcpm] 793bis: reset generation section Wesley Eddy
- [tcpm] 793bis: IPv6 jumbograms Wesley Eddy
- [tcpm] 793bis: IP ID Wesley Eddy
- Re: [tcpm] 793bis: IP ID David Borman
- Re: [tcpm] 793bis: variable MTU Gorry Fairhurst
- Re: [tcpm] 793bis: IP ID Gorry Fairhurst
- Re: [tcpm] 793bis: IP ID Michael Tuexen
- Re: [tcpm] 793bis: TCP Quiet Time Matt Mathis
- [tcpm] 793bis: dead gateway detection Wesley Eddy
- [tcpm] 793bis: delayed ACKs Wesley Eddy
- Re: [tcpm] 793bis: IP ID David Borman
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: IP ID David Borman
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: delayed ACKs Yuchung Cheng
- Re: [tcpm] 793bis: TCP Quiet Time Joe Touch
- Re: [tcpm] 793bis: TCP Quiet Time Fernando Gont
- Re: [tcpm] 793bis: IP ID Fernando Gont
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: TCP Quiet Time Matt Mathis
- Re: [tcpm] 793bis: TCP Quiet Time Fernando Gont
- Re: [tcpm] 793bis: TCP Quiet Time Fernando Gont
- Re: [tcpm] 793bis: IP ID Gorry Fairhurst
- Re: [tcpm] 793bis: IP ID Fernando Gont
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: IP ID Fernando Gont
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: IP ID Fernando Gont
- Re: [tcpm] 793bis: IP ID Joe Touch