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

+++++++++++++++++++++++++