Re: [auth48] AUTH48: RFC-to-be 9293 <draft-ietf-tcpm-rfc793bis-28> for your review

[[e-mail]]

Greetings,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Would you like to update the title?

Current:

   Full title: Transmission Control Protocol (TCP) Specification

   Short title (displayed in PDF only): TCP Specification

Perhaps: 

   Full title: Transmission Control Protocol (TCP)

   Short title: TCP 
-->


2) <!-- [rfced] Please provide any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search.
-->


3) <!-- [rfced] Section 1: As this document obsoletes RFC 793, would the
following suggested update be more accurate?

Current:
   The purpose of this document is to bring together all of the IETF
   Standards Track changes and other clarifications that have been made
   to the base TCP functional specification and to unify them into an
   updated version of RFC 793.

Perhaps:
   The purpose of this document is to bring together all of the IETF
   Standards Track changes and other clarifications that have been made
   to the base TCP functional specification (RFC 793) and to unify them 
   into an updated version of the specification.
-->


4) <!-- [rfced]  Does the following suggestion improve readability?

Current:

   TCP supports unicast delivery of data.  Anycast applications exist
   that successfully use TCP without modifications, though there is some
   risk of instability due to changes of lower-layer forwarding behavior
   [46].

Perhaps (changing "Anycast applications exist" to "There are anycast applications"):

   TCP supports unicast delivery of data.  There are anycast applications 
   that can successfully use TCP without modifications, though there is some
   risk of instability due to changes of lower-layer forwarding behavior
   [46].
-->


5) <!-- [rfced] Section 3.1: FYI - As discussed in AUTH state, we removed 
the empty line and added the introductory phrase "Control bits:" to the
paragraph that applies to the subsequent list of control bits.

Original:

   Reserved (Rsrvd): 4 bits.
     A set of control bits reserved for future use.  Must be zero in
     generated segments and must be ignored in received segments, if
     corresponding future features are unimplemented by the sending or
     receiving host.

 
     The control bits are also known as "flags".  Assignment is managed
     by IANA from the "TCP Header Flags" registry [63].  The currently
     assigned control bits are CWR, ECE, URG, ACK, PSH, RST, SYN, and
     FIN.

   CWR: 1 bit.
     Congestion Window Reduced (see [6]).

   ECE: 1 bit.
     ECN-Echo (see [6]). ...

Current:

   Reserved (Rsrvd): 4 bits
     A set of control bits reserved for future use.  Must be zero in
     generated segments and must be ignored in received segments if the
     corresponding future features are not implemented by the sending or
     receiving host.

   Control bits: The control bits are also known as "flags".  Assignment 
     is managed by IANA from the "TCP Header Flags" registry [63].  The 
     currently assigned control bits are CWR, ECE, URG, ACK, PSH, RST, SYN, 
     and FIN.

       CWR: 1 bit
         Congestion Window Reduced (see [6]).

       ECE: 1 bit
         ECN-Echo (see [6]). ...
-->


6) <!-- [rfced] Section 3.1, Checksum description: FYI - As previously mentioned
in AUTH state, we adjusted the indentation in the definition of checksum
to present the IPv4 and IPv6 information at the same level of
indentation.

Original (IPv6 information is indented below the IPv4 information):

   Checksum: 16 bits.
     The checksum field is ...
     with zeros.

 
     The checksum also covers ...

     Pseudo header components for IPv4:
          Source Address: ...
          header.

 
       For IPv6, ...

Current (IPv4 and IPv6 info have the same level of indentation):

   Checksum:  16 bits

     The checksum field is ...
     with zeros.

     The checksum also covers ...

     Pseudo-header components for IPv4:
       Source Address:  ...
          header.

     For IPv6, the pseudo-header ...
-->


7) <!-- [rfced] Section 3.1: We are having difficulty parsing the following description:

Current:

     ... and a Next Header value (differing from the IPv6 header
     value in the case of extension headers present in between IPv6 and
     TCP).

Perhaps (removing parentheses, updating "in the case of" to "if there are" and "in between" to "between":

     ... and a Next Header value, which differs from the IPv6 header
     value if there are extension headers present between IPv6 and
     TCP.
-->


8) <!-- [rfced] Section 3.1: Please verify that the cross reference is correct.
MSS is described in Section 3.7.1, and MUST-19 is covered in Section 3.8.2.

Current:

     Maximum Segment Size option support is also part of MUST-19 in
     Section 3.7.2 
-->


9) <!-- [rfced] Table titles: Tables 1, 5, and 6 do not have titles. Would you like to provide them?
-->


10) <!-- [rfced] Section 3.1: FYI, as there is no room to expand acronyms in the table in Appendix B, we have added them here:

Current:
     All TCP options except End of option list (EOL) and No-Operation 
     (NOP) MUST have length fields, including all future options 
     (MUST-68).
-->


11) <!-- [rfced] Section 3.3.1: This text is from RFC 793, but perhaps it can be improved?

Current:
   Before we can discuss very much about the operation of the TCP
   implementation we need to introduce some detailed terminology.

Perhaps (changing "very much about" to "in detail"):
   Before we can discuss the operation of the TCP
   implementation in detail, we need to introduce some detailed terminology.  
-->  


12) <!-- [rfced] Section 3.3.1: FYI - As discussed in AUTH state, we have
converted the lists of Sequence and Segment Variables, which were
artwork, to definition lists.

Original:
    Send Sequence Variables:

      SND.UNA - send unacknowledged
      SND.NXT - send next
      SND.WND - send window
      SND.UP  - send urgent pointer
      SND.WL1 - segment sequence number used for last window update
      SND.WL2 - segment acknowledgment number used for last window
                update
      ISS     - initial send sequence number

    Receive Sequence Variables:

      RCV.NXT - receive next
      RCV.WND - receive window
      RCV.UP  - receive urgent pointer
      IRS     - initial receive sequence number

   ...

   Current Segment Variables:

       SEG.SEQ - segment sequence number
       SEG.ACK - segment acknowledgment number
       SEG.LEN - segment length
       SEG.WND - segment window
       SEG.UP  - segment urgent pointer 
-->


13) <!-- [rfced] Section 3.4: Does the following update improve readability? 

Original:

   Numbering of
   octets within a segment is that the first data octet immediately
   following the header is the lowest numbered, and the following octets
   are numbered consecutively.

Perhaps (changing "Numbering" to "The numbering scheme" and "is that" to "is as follows:"):

   The numbering scheme of
   octets within a segment is as follows: the first data octet immediately
   following the header is the lowest numbered, and the following octets
   are numbered consecutively.
-->


14) <!-- [rfced] Section 3.4: We have updated the comparison wording below. Please
let us know if any updates are necessary.

Original:

   A segment on the retransmission queue is fully acknowledged if the
   sum of its sequence number and length is less or equal than the
   acknowledgment value in the incoming segment.

Current (updated "is less or equal than" to "is less than or equal to"):

   A segment on the retransmission queue is fully acknowledged if the
   sum of its sequence number and length is less than or equal to the
   acknowledgment value in the incoming segment.
-->


15) <!-- [rfced] Section 3.4.2: Does removing "felt" from the sentence below improve readability?

Current:
   In practical use on the Internet today, the error-
   prone conditions are sufficiently unlikely that it is felt safe to
   ignore.  

Perhaps:
   In practical use on the Internet today, the error-
   prone conditions are sufficiently unlikely that it is safe to
   ignore.  
-->


16) <!-- [rfced] Section 3.4.3: We have updated "using a sequence number over" to
"reusing a sequence number". Please let us know if other updates are necessary.

Original:

    Under normal conditions, TCP implementations keep track of the next 
    sequence number to emit and the oldest awaiting acknowledgment so as 
    to avoid mistakenly using a sequence number over before its first use 
    has been acknowledged.  

Current:

    Under normal conditions, TCP implementations keep track of the next 
    sequence number to emit and the oldest awaiting acknowledgment so as 
    to avoid mistakenly reusing a sequence number before its first use 
    has been acknowledged.  
-->


17) <!-- [rfced] Section 3.4.3: Does splitting the following sentence into
multiple sentences improve readability?

Current:

   To summarize: every segment emitted occupies one or more sequence
   numbers in the sequence space, the numbers occupied by a segment are
   "busy" or "in use" until MSL seconds have passed, upon rebooting a
   block of space-time is occupied by the octets and SYN or FIN flags of
   any potentially still in-flight segments, and if a new connection is
   started too soon and uses any of the sequence numbers in the space-
   time footprint of those potentially still in-flight segments of the
   previous connection incarnation, there is a potential sequence number
   overlap area that could cause confusion at the receiver.

Perhaps:

   To summarize: every segment emitted occupies one or more sequence
   numbers in the sequence space, and the numbers occupied by a segment are
   "busy" or "in use" until MSL seconds have passed. Upon rebooting, a
   block of space-time is occupied by the octets and SYN or FIN flags of
   any potentially still in-flight segments. If a new connection is
   started too soon and uses any of the sequence numbers in the space-
   time footprint of those potentially still in-flight segments of the
   previous connection incarnation, there is a potential sequence number
   overlap area that could cause confusion at the receiver.

-->


18) <!-- [rfced] Section 3.7: We having difficulty parsing the following. Would
"correlation" be a better fit than "coherence"?

Current:

   Applications may perform
   writes at the granularity of messages in the upper-layer protocol,
   but TCP guarantees no boundary coherence between the TCP segments
   sent and received versus user application data read or write buffer
   boundaries. 

Perhaps:

   Applications may perform
   writes at the granularity of messages in the upper-layer protocol,
   but TCP guarantees no correlation between the boundaries of TCP 
   segments sent and received and the boundaries of the read or 
   write buffers of user application data. 
-->


19) <!-- [rfced] Section 3.8.5: In the following, should "that TCP" be "then the TCP implementation"?

Current:

   Whenever this point is in advance of
   the receive sequence number (RCV.NXT) at the receiving TCP endpoint,
   that TCP must tell the user to go into "urgent mode"; when the
   receive sequence number catches up to the urgent pointer, the TCP
   implementation must tell user to go into "normal mode".  

Perhaps:

   Whenever this point is in advance of
   the receive sequence number (RCV.NXT) at the receiving TCP endpoint,
   then the TCP implementation must tell the user to go into "urgent mode"; 
   ...
-->


20) <!-- [rfced] Section 3.8.5: We're having difficulty parsing the following. 
Should a TCP receiver handle invalid urgent pointer values gracefully?

Current:
 
   Note that because changes in the urgent pointer correspond
   to data being written by a sending application, the urgent pointer
   cannot "recede" in the sequence space, but a TCP receiver should be
   robust to invalid urgent pointer values.

Perhaps:

   Note that because changes in the urgent pointer correspond
   to data being written by a sending application, the urgent pointer
   cannot "recede" in the sequence space, but a TCP receiver should 
   handle invalid urgent pointer values gracefully.
-->


21) <!-- [rfced] Section 3.8.6: The word "available" is used twice in the sentence below. 

Current:

   There is an assumption that this is related to
   the currently available data buffer space available for this
   connection.

Perhaps:

   There is an assumption that this is related to
   the data buffer space currently available for this
   connection.
-->


22) <!-- [rfced] Section 3.8.6.3: Is there a reference that might be included for
ACK compression?

Current:

   Note that there are several current practices that further lead to a
   reduced number of ACKs, including generic receive offload (GRO) [72],
   ACK compression, and ACK decimation [28].
-->


23) <!-- [rfced] Section 3.9.1 subsections: FYI - As discussed in AUTH state,
we kept the indents but removed the bullets so that the text aligns. Please
review whether the items tagged with <ul empty="true"> elements (i.e.,
bulleted list but without the bullets) should remain as list items or simply
be tagged with <t>.

Original (Section 3.9.1.8):

      There MUST be a mechanism for reporting soft TCP error conditions
      to the application (MUST-47).  Generically, we assume this takes
      the form of an application-supplied ERROR_REPORT routine that may
      be upcalled asynchronously from the transport layer:

      -  ERROR_REPORT(local connection name, reason, subreason)

Current:

      There MUST be a mechanism for reporting soft TCP error conditions
      to the application (MUST-47).  Generically, we assume this takes
      the form of an application-supplied ERROR_REPORT routine that may
      be upcalled asynchronously from the transport layer:

      ERROR_REPORT(local connection name, reason, subreason)
-->


24) <!-- [rfced] Section 3.9.1.2: Should "PUSH bit" be "PSH bit" in the following?

Current:
      If the PUSH flag is set, the application intends the data to be
      transmitted promptly to the receiver, and the PUSH bit will be set
      in the last TCP segment created from the buffer.
-->


25) <!-- [rfced] Section 3.9.1.2: There seems to be some text missing in the
sentence below. Should "The purpose of urgent" instead be "The purpose of
the URGENT flag"?

Current:
    The purpose of
    urgent is to stimulate the receiver to process the urgent data and
    to indicate to the receiver when all the currently known urgent
    data has been received.
-->


26) <!-- [rfced] Section 3.9.1.3: Should "PSH flag" be "PSH bit" in the following?

Current:
   A TCP receiver MAY pass a received PSH flag to the application
   layer via the PUSH flag in the interface (MAY-17)...
-->


27) <!-- [rfced] Section 3.9.1.6: Should "RESET" be "RST" in the following? This
is the only instance of "RESET" used in the document.

Current:
      This command causes all pending SENDs and RECEIVES to be aborted,
      the TCB to be removed, and a special RESET message to be sent to
      the remote TCP peer of the connection.  
-->


28) <!-- [rfced] Section 3.9.2: FYI, we have clarified that RFC 1122 updated RFC 793
in the following sentence. Please let us know if any changes are necessary:

Original:

     RFC 1122 changed this
     specification to require that the TTL be configurable.

Current:

     RFC 1122 updated RFC 793
     to require that the TTL be configurable.
-->


29) <!-- [rfced] Section 3.9.2.1: Should "Time Stamp" be "Timestamp" here?

Current:
   A TCP implementation MAY support the Time Stamp (MAY-10) and Record
   Route (MAY-11) options.
-->


30) <!-- [rfced] Sections 3.10.1-3.10.6: FYI - As discussed in AUTH state, we have
removed a level of indentation for all the text to simplify the XML. We
left the indentation intact for Sections 3.10.7.x (they were not indented
at the top level). We also removed a level of indentation for Sections
3.8 and 3.9.1.1-9. Please let us know if any updates are necessary.
-->


31) <!-- [rfced] Section 3.10.5: We have split the following into multiple
sentences. Please let us know if any updates are required:

Original:

      All queued SENDs and RECEIVEs should be given "connection reset"
      notification, delete the TCB, enter CLOSED state, and return.
      ...
      All queued SENDs and RECEIVEs should be given "connection reset"
      notification; all segments queued for transmission (except for the
      RST formed above) or retransmission should be flushed, delete the
      TCB, enter CLOSED state, and return.

Current:

      All queued SENDs and RECEIVEs should be given "connection reset"
      notification. Delete the TCB, enter CLOSED state, and return.
      ...
      All queued SENDs and RECEIVEs should be given "connection reset"
      notification; all segments queued for transmission (except for the
      RST formed above) or retransmission should be flushed. Delete the
      TCB, enter CLOSED state, and return.
 -->


32) <!-- [rfced] Section 3.10.6: We have placed the following list of states on
separate lines to match RFC 793. Please let us know if any updates are required.

Original:

   CLOSING STATE LAST-ACK STATE TIME-WAIT STATE

   *  Respond with "ok" and delete the TCB, enter CLOSED state, and
      return.

Current:

   CLOSING STATE 
   
   LAST-ACK STATE
   
   TIME-WAIT STATE

   *  Respond with "ok" and delete the TCB, enter CLOSED state, and
      return.
-->


33) <!-- [rfced] Section 3.10.6: Are both state and pointers returned? If so, may
we remove the commas?

Current:
   *  Return "state = LISTEN", and the TCB pointer ...
   *  Return "state = SYN-SENT", and the TCB pointer ...
   *  Return "state = SYN-RECEIVED", and the TCB pointer ...
   *  Return "state = ESTABLISHED", and the TCB pointer ...
   *  Return "state = FIN-WAIT-1", and the TCB pointer ...
   *  Return "state = FIN-WAIT-2", and the TCB pointer ...
   *  Return "state = CLOSE-WAIT", and the TCB pointer ...
   *  Return "state = CLOSING", and the TCB pointer ...
   *  Return "state = LAST-ACK", and the TCB pointer ...
   *  Return "state = TIME-WAIT", and the TCB pointer ...

Perhaps:
   *  Return "state = LISTEN" and the TCB pointer ...
   *  Return "state = SYN-SENT" and the TCB pointer ...
   *  Return "state = SYN-RECEIVED" and the TCB pointer ...
   *  Return "state = ESTABLISHED" and the TCB pointer ...
   *  Return "state = FIN-WAIT-1" and the TCB pointer ...
   *  Return "state = FIN-WAIT-2" and the TCB pointer ...
   *  Return "state = CLOSE-WAIT" and the TCB pointer ...
   *  Return "state = CLOSING" and the TCB pointer ...
   *  Return "state = LAST-ACK" and the TCB pointer ...
   *  Return "state = TIME-WAIT" and the TCB pointer ...

-->


34) <!-- [rfced] Section 3.10.7.1 through 3.10.7.3: We have updated the following
heading titles to match the rest of Section 3.10. Please let us know if
updates are necessary.

Original:

3.10.7.1.  CLOSED State
3.10.7.2.  LISTEN State
3.10.7.3.  SYN-SENT State

Current:

3.10.7.1.  CLOSED STATE
3.10.7.2.  LISTEN STATE
3.10.7.3.  SYN-SENT STATE
-->


35) <!-- [rfced] Sections 3.10.7.2 - 3.10.7.4: The construction of "first check",
"second check", etc., is from RFC 793. The four lists each started
with lowercase, and most did not have punctuation with a few exceptions
(e.g., "fourth, check the SYN bit,"). Would you prefer that 
A) the punctuation be removed in those cases or
B) all the capitalization and punctuation be updated (e.g., "First, check for a RST:")?
-->


36) <!-- [rfced] Section 3.10.7.4: FYI As discussed in AUTH state, we have
adjusted the indentation in this section to ensure that the indentation
of the text below "first check the sequence number" matches the
indentation of the following steps (e.g., "second check the RST
bit"). Please let us know if any updates are necessary.

To show our updates, we have created text files that contain just the section
in question. We have also trimmed the text (marked with "...") to shorten the
files and make comparisons easier.

RFC 793:

   https://www.rfc-editor.org/authors/rfc793_SEGMENT_ARRIVES_elided.txt

   o  Contains some filler lines to make the comparison easier.

Original:

   https://www.rfc-editor.org/authors/rfc793bis_section_3.10.7.4_original_elided.txt

Current:
   https://www.rfc-editor.org/authors/rfc793bis_section_3.10.7.4_updated_bullets_elided.txt

   o This file has bulleted lists to make comparing with 
     draft-ietf-tcpm-rfc793 easier (we used an ordered list 
     for the top-level list to ensure that our structure was 
     correct, but this list style can be changed to bulleted 
     or unbulleted)

  https://www.rfc-editor.org/authors/rfc793bis_section_3.10.7.4_updated_no_bullets_elided.txt

  o  This file uses an unbulleted style to make comparing 
     with RFC 793 easier. 

The following diff files highlight the changes:

   https://www.rfc-editor.org/authors/rfc793_tcpm-rfc793bis_section_3.10.7.4_rfcdiff.html 
      (between RFC 793 and the original draft)

   https://www.rfc-editor.org/authors/rfc793_updated_tcpm-rfc793bis_section_3.10.7.4_rfcdiff.html 
      (between RFC 793 and our updates)

   https://www.rfc-editor.org/authors/tcpm-rfc793bis_updated_section_3.10.7.4_rfcdiff.html 
      (between the original draft and our updates)
-->


37) <!-- [rfced] Section 3.10.7.4, second, third, and fourth checks: FYI, we have
added "STATE" to some of the state labels to match the rest of Section 3.10. 
Please let us know if any updates are necessary. For instance:

Original:
      *  ESTABLISHED

       *  FIN-WAIT-1

       *  FIN-WAIT-2

       *  CLOSE-WAIT


Current:
      *  ESTABLISHED STATE

       *  FIN-WAIT-1 STATE

       *  FIN-WAIT-2 STATE

       *  CLOSE-WAIT STATE
-->


38) <!-- [rfced] Section 3.10.7.4, fourth check: FYI we have updated the following
state names to match the rest of document

Original:
       *  FIN-WAIT STATE-1

       *  FIN-WAIT STATE-2

Current:
       *  FIN-WAIT-1 STATE

       *  FIN-WAIT-2 STATE
-->


39) <!-- [rfced] Section 3.10.7.4, fourth check: Would this paragraph read better
if a colon were used after "error"?

Current:

          -  For implementations that do not follow RFC 5961, the
             original behavior described in RFC 793 follows in this 
             paragraph.  If the SYN is in the window it is an error, 
             send a reset, any outstanding RECEIVEs and SEND should 
             receive "reset" responses, all segment queues should be 
             flushed, the user should also receive an unsolicited 
             general "connection reset" signal, enter the CLOSED state, 
             delete the TCB, and return.

Perhaps:

          -  For implementations that do not follow RFC 5961, the
             original behavior described in RFC 793 follows in this 
             paragraph.  If the SYN is in the window, it is an error: 
             send a reset, any outstanding RECEIVEs and SEND should 
             receive "reset" responses, all segment queues should be 
             flushed, the user should also receive an unsolicited 
             general "connection reset" signal, enter the CLOSED state, 
             delete the TCB, and return.
-->


40) <!-- [rfced] Section 5: Unless we hear otherwise, we will add informative
references to the the errata reports mentioned in this document. -->


41) <!-- [rfced] Section 5: We are having difficulty parsing the following:

Original:
   RFC 6429 is obsoleted in the sense that this
   clarification has been reflected in this update to the base TCP
   specification now.

Current (removing "this update" and "now"):
   RFC 6429 is obsoleted in the sense that this
   clarification has been reflected in this base TCP
   specification.
-->


42) <!-- [rfced] Section 6: FYI, we have added an informative reference for RFC 8311.
Please let us know if any updates are necessary.

Current:
   Bit 7 has since also been updated by RFC 8311 [54].
-->


43) <!-- [rfced] Section 6: Should the range below be instead "0 through 3"? 
Bit 4 is listed as Reserved for future use in the registry.

Current:
   The bits in offsets 0 through 4
   are the TCP segment Data Offset field, and not header flags.
-->


44) <!-- [rfced] Section 7: The following sentence implies that the urgent pointer has been deprecated. 

Current:

   Additionally, see RFC 6093 [39] for
   discussion of security considerations related to the urgent pointer
   field, that has been deprecated.

Perhaps:

   Additionally, see RFC 6093 [39] for
   discussion of security considerations related to the urgent pointer
   field that have been deprecated.
-->


45) <!-- [rfced] Informative References: We have removed the reference to RFC 879
because we removed the I-D change log, which contained the only reference to it.
-->


46) <!-- [rfced] Informative References: As https://www.iana.org/assignments/tcp-header-flags/
has moved to https://www.iana.org/assignments/tcp-parameters/, we have removed 
the entry for the "Transmission Control Protocol (TCP) Header Flags" registry
and have created a cross reference to the "Transmission Control Protocol
(TCP) Parameters" registry.

Original:

   Assignment is managed
   by IANA from the "TCP Header Flags" registry [63].

   ...

   [62]       IANA, "Transmission Control Protocol (TCP) Parameters,
              https://www.iana.org/assignments/tcp-parameters/tcp-
              parameters.xhtml", 2019.

   [63]       IANA, "Transmission Control Protocol (TCP) Header Flags,
              https://www.iana.org/assignments/tcp-header-flags/tcp-
              header-flags.xhtml", 2019.

Current:

   Assignment is managed by IANA from the "TCP Header Flags" registry
   [62]. 

   [62]       IANA, "Transmission Control Protocol (TCP) Parameters",
              <https://www.iana.org/assignments/tcp-parameters/>.  
-->


47) <!-- [rfced] Informative References: We found the following reference;
however, the name of the body of work is "The Linux Kernel
Documentation". We updated the reference accordingly.

Original:

   [73]       "Segmentation Offloads", Linux Networking Documentation ,
              <https://www.kernel.org/doc/html/latest/networking/
              segmentation-offloads.html>.

Current:

   [72]       "Segmentation Offloads", The Linux Kernel Documentation,
              <https://www.kernel.org/doc/html/latest/networking/
              segmentation-offloads.html>.
-->


48) <!-- [rfced] Section A.1.1: We have updated the sentence below to use past tense. 
Please let us know if other updates are needed.

Original:

   The RFC 793/1122 TCP
   specification includes logic intending to have connections use the
   highest precedence requested by either endpoint application, and to
   keep the precedence consistent throughout a connection.  

Current:

   The TCP
   specification as defined by RFCs 793 and 1122 included logic intending 
   to have connections use the highest precedence requested by either 
   endpoint application and to keep the precedence consistent throughout a 
   connection.  
-->


49) <!-- [rfced] Appendix B. FYI - As discussed during AUTH state, we have
converted the TCP Requirement Summary to a table.

Original:
                                                  |        | | | |S| |
                                                  |        | | | |H| |F
                                                  |        | | | |O|M|o
                                                  |        | |S| |U|U|o
                                                  |        | |H| |L|S|t
                                                  |        |M|O| |D|T|n
                                                  |        |U|U|M| | |o
                                                  |        |S|L|A|N|N|t
                                                  |        |T|D|Y|O|O|t
 FEATURE                                          | ReqID  | | | |T|T|e
 - - - - - - - - - - - - - - - - - - - - - - - - -|- - - - |-|-|-|-|-|-
                                                  |        | | | | | |
 Push flag                                        |        | | | | | |
   Aggregate or queue un-pushed data              | MAY-16 | | |x| | |
   Sender collapse successive PSH flags           | SHLD-27| |x| | | |

Current:

    +=================+=========+======+========+=====+========+======+
    |     Feature     |  ReqID  | MUST | SHOULD | MAY | SHOULD | MUST |
    |                 |         |      |        |     |  NOT   | NOT  |
    +=================+=========+======+========+=====+========+======+
    | PUSH flag                                                       |
    +=================+=========+======+========+=====+========+======+
    | Aggregate or    | MAY-16  |      |        | X   |        |      |
    | queue un-pushed |         |      |        |     |        |      |
    | data            |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - + - - - -+- - -+- - - - + - - -+
    | Sender collapse | SHLD-27 |      | X      |     |        |      |
    | successive PSH  |         |      |        |     |        |      |
    | flags           |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - + - - - -+- - -+- - - - + - - -+
    ....

                     Table 1: TCP Requirements Summary
-->


50) <!-- [rfced] Appendix B. In the original artwork for the requirements summary,
some features were marked with hyphens and some were merely indented. We
have used bullets consistently. Please let us know if any updates are
necessary:

Original:

 Window                                           |        | | | | | |
   ...
   Shrink window from right                       | SHLD-14| | | |x| |
   - Send new data when window shrinks            | SHLD-15| | | |x| |
   - Retransmit old unacked data within window    | SHLD-16| |x| | | |
   - Time out conn for data past right edge       | SHLD-17| | | |x| |
   Robust against shrinking window                | MUST-34|x| | | | |
   Receiver's window closed indefinitely          | MAY-8  | | |x| | |
   Use standard probing logic                     | MUST-35|x| | | | |
   Sender probe zero window                       | MUST-36|x| | | | |
     First probe after RTO                        | SHLD-29| |x| | | |
     Exponential backoff                          | SHLD-30| |x| | | |
   Allow window stay zero indefinitely            | MUST-37|x| | | | |
   ...

Current (hyphens used with indented text also):
    +=================+=========+======+========+=====+========+======+
    | Window                                                          |
    +=================+=========+======+========+=====+========+======+
    ...
    | Shrink window   | SHLD-14 |      |        |     |   X    |      |
    | from right      |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | * Send new data | SHLD-15 |      |        |     |   X    |      |
    |   when window   |         |      |        |     |        |      |
    |   shrinks       |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | * Retransmit    | SHLD-16 |      |   X    |     |        |      |
    |   old unacked   |         |      |        |     |        |      |
    |   data within   |         |      |        |     |        |      |
    |   window        |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | * Time out conn | SHLD-17 |      |        |     |   X    |      |
    |   for data past |         |      |        |     |        |      |
    |   right edge    |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | Robust against  | MUST-34 |  X   |        |     |        |      |
    | shrinking       |         |      |        |     |        |      |
    | window          |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | Receiver's      | MAY-8   |      |        |  X  |        |      |
    | window closed   |         |      |        |     |        |      |
    | indefinitely    |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | Use standard    | MUST-35 |  X   |        |     |        |      |
    | probing logic   |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | Sender probe    | MUST-36 |  X   |        |     |        |      |
    | zero window     |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | * First probe   | SHLD-29 |      |   X    |     |        |      |
    |   after RTO     |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | * Exponential   | SHLD-30 |      |   X    |     |        |      |
    |   backoff       |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | Allow window    | MUST-37 |  X   |        |     |        |      |
    | stay zero       |         |      |        |     |        |      |
    | indefinitely    |         |      |        |     |        |      |
    ...
-->


51) <!-- [rfced] Table 8: In the following subsection of the table, we added a row
to capture the normative requirement number for "Send Keep-alive Packets". 
Please let us know if any changes are necessary.

Original:

 Send Keep-alive Packets:                         | MAY-5  | | |x| | |
   - Application can request                      | MUST-24|x| | | | |
   - Default is "off"                             | MUST-25|x| | | | |
   - Only send if idle for interval               | MUST-26|x| | | | |
   - Interval configurable                        | MUST-27|x| | | | |
   - Default at least 2 hrs.                      | MUST-28|x| | | | |
   - Tolerant of lost ACKs                        | MUST-29|x| | | | |
   - Send with no data                            | SHLD-12| |x| | | |
   - Configurable to send garbage octet           | MAY-6  | | |x| | |

Current:
    +=================+=========+======+========+=====+========+======+
    | Send Keep-alive Packets                                         |
    +=================+=========+======+========+=====+========+======+
    | Send Keep-alive | MAY-5   |      |   X    |     |        |      |
    | Packets:        |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | * Application   | MUST-24 |  X   |        |     |        |      |
    |   can request   |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | * Default is    | MUST-25 |  X   |        |     |        |      |
    |   "off"         |         |      |        |     |        |      |
   ...
   
-->


52) <!-- [rfced] Table 8: Is spacing here enough? Note that "Source Route" maybe
could be made a subsection. Perhaps "IP Options - Source Route:". Then
the double dash becomes moot.

Current:

    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | Source Route:   |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | * ALP can       | MUST-51 |  X   |        |     |        |      |
    |   specify       |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | *     Overrides | MUST-52 |  X   |        |     |        |      |
    |       src route |         |      |        |     |        |      |
    |       in        |         |      |        |     |        |      |
    |       datagram  |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | *  Build return | MUST-53 |  X   |        |     |        |      |
    |    route from   |         |      |        |     |        |      |
    |    src route    |         |      |        |     |        |      |
-->


53) <!-- [rfced] Table 8: Similar to the "Send Keep-alive Packets:" subsection,
we added a row to capture the normative requirement number for "Receiving
ICMP Messages from IP".

Current:
    +=================+=========+======+========+=====+========+======+
    | Receiving ICMP Messages from IP                                 |
    +=================+=========+======+========+=====+========+======+
    | Receiving ICMP  | MUST-54 |  X   |        |     |        |      |
    | messages from   |         |      |        |     |        |      |
    | IP              |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | *  Dest Unreach | SHLD-25 |  X   |        |     |        |      |
    |    (0,1,5) =>   |         |      |        |     |        |      |
    |    inform ALP   |         |      |        |     |        |      |
    +- - - - - - - - -+- - - - -+- - - +- - - - +- - -+- - - - +- - - +
    | *  Abort on     | MUST-56 |      |        |     |        |  X   |
    |    Dest Unreach |         |      |        |     |        |      |
    |    (0,1,5) =>nn |         |      |        |     |        |      |
    ...
-->


54) <!-- [rfced] Table 8: Are there supposed to be actions given after the arrows
in the following?

Original:
   Abort on Time Exceeded =>                      | MUST-56| | | | |x|
   Abort on Param Problem =>                      | MUST-56| | | | |x|
-->


55) <!-- [rfced] Acknowledgments: We note that Michael Scharf and Michael Tüxen
are listed twice (as chairs and also reviewers). Are there any updates required?
--> 


56) <!-- [rfced] Terminology:

a) The following were used inconsistently; we chose the latter form, which is used more often. Please let us know if any updates are necessary. 

3-way / three-way - 2 instances
back-off / backoff - 3 instances, normative references close the term
acknowledgement / acknowledgment (66) - 13 instances
data offset field / Data Offset field - 1 instance
ICMP protocol / ICMP - 1 instance 
identification field / Identification field - 1 instance, RFC 1122 capitalizes 
Initial Sequence Number / initial sequence number - 4 instances
passive open / passive OPEN - 3 instances
peer A / Peer A - 1 instance
peer B / Peer B - 1 instance
push flag / PUSH flag - 2 instances
PUSHED / PUSHed - 1 instance
RST's (as a plural) / RSTs - 1 instance
send-sequence number / send sequence number - 1 instance
Slow Start (1) / slow start (4) - when talking about the algorithm (congestion avoidance algo), RFC 5681 uses lowercase
"SYN" / SYN - when not used in a definition, 3 instances
TCP protocol / TCP - 4 instances
TCP Header / TCP header - 3 instances
Window Scaling / window scaling - 1 instance, RFC 7323 only capitalizes Window Scale option and not generic instances.  
Urgent pointer / urgent pointer - 3 instances, RFC 793 uses lowercase
urgent flag / URGENT flag - 2 instances
USER / user - when talking about the interface, 1 instance
Window Scaling (WS) option / Window Scale (WS) option - 1 instance, updated to match RFC 7323


b) The following are used inconsistently. The number of instances are provided in parentheses. Please let us know how we can make these terms consistent. 

acknowledgement (13) / acknowledgment (66)

Algorithms:
	Karn's Algorithm (0) / Karn's algorithm (2)
	Nagle Algorithm (4) / Nagle algorithm (14)
	SWS-Avoidance Algorithm (2) / SWS avoidance algorithm (8)

codepoint (3) / code point (3)

End-of-Option option (1) / End of Option List Option (2) / End of option list (2)

internet (17) / Internet (36)

Option (38) / option (121):
	End-of-Option option (1) / End of Option List Option (2) / End of option list (2)
	Jumbo Payload option (1) / Jumbo Payload Option (1)
	Maximum Segment Size option (2) / Maximum Segment Size Option (4)
	No-Operation option (0) / No-Operation Option (2)
	Record Route option (1)
	SACK option (1) / SACK Option (0)
	Source Route option (1)
	TCP option (13) / TCP Option (2) 
	Timestamp option (4) / Timestamp Option (0) / timestamp option (3)
	Window Scale option (1)

Push:
   push function (2) / Push Function (2) 
   PSH (2) / PSH bit (5) / 
   PSH flag (2) / PUSH flag (13)

quiet time (4) / Quiet Time (3)

Time Stamp (2) / Timestamp (4) / timestamp (4)


c) The following were used consistently but normative reference use different forms. We have updated to use the latter form.

pseudo header / pseudo-header - RFC 8200 hyphenates 

DiffServ / Diffserv - The Diffserv terminology RFC (RFC 3260) uses "Diffserv", and 
it is listed on the terms list (https://www.rfc-editor.org/materials/terms-online.txt).
Note: We left "DiffServ field" as is, but suggest changing to "Diffserv field".
-->


57) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 
and let us know if any changes are needed.  
-->


Thank you.

RFC Editor/jm/ar


On Jul 15, 2022, at 3:46 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2022/07/15

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor 
  that have been included in the XML file as comments marked as 
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

  Please ensure that you review any changes submitted by your 
  coauthors.  We assume that if you do not speak up that you 
  agree to changes submitted by your coauthors.

*  Content 

  Please review the full content of the document, as this cannot 
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions 
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of  
  content are correctly tagged.  For example, ensure that <sourcecode> 
  and <artwork> are set correctly.  See details at 
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the 
  formatted output, as generated from the markup in the XML file, is 
  reasonable.  Please note that the TXT will have formatting 
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g., 
     IETF Stream participants are your working group chairs, the 
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list 
     to preserve AUTH48 conversations; it is not an active discussion 
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out 
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you 
       have dropped the address. When the discussion is concluded, 
       [e-mail] will be re-added to the CC list and 
       its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9293.xml
  https://www.rfc-editor.org/authors/rfc9293.html
  https://www.rfc-editor.org/authors/rfc9293.pdf
  https://www.rfc-editor.org/authors/rfc9293.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9293-diff.html
  https://www.rfc-editor.org/authors/rfc9293-rfcdiff.html (side by side)

This diff file compares an altered original and the RFC 
(in order to make the changes in moved text viewable):
  https://www.rfc-editor.org/authors/rfc9293-alt-diff.html

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9293-xmldiff1.html

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
  https://www.rfc-editor.org/authors/rfc9293.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
  https://www.rfc-editor.org/authors/rfc9293.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9293

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9293 (draft-ietf-tcpm-rfc793bis-28)

Title            : Transmission Control Protocol (TCP) Specification
Author(s)        : W. Eddy, Ed.
WG Chair(s)      : Yoshifumi Nishida, Michael Tüxen, Ian Swett

Area Director(s) : Martin Duke, Zaheduzzaman Sarker