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

[Jean Mahoney <[e-mail]>]

Wesley,

We're just checking in regarding the questions below and this document's 
readiness for publication as an RFC.

   https://www.rfc-editor.org/authors/rfc9293.html
   https://www.rfc-editor.org/authors/rfc9293.pdf
   https://www.rfc-editor.org/authors/rfc9293.txt
   https://www.rfc-editor.org/authors/rfc9293-diff.html (changes inline)
   https://www.rfc-editor.org/authors/rfc9293-rfcdiff.html (changes side 
by side)

This page shows the AUTH48 status of your document:
   https://www.rfc-editor.org/auth48/rfc9293

Best regards,

RFC Editor/jm


On 7/15/22 5:47 PM, [e-mail] wrote:
> 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
>
>