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

[Wesley Eddy <[e-mail]>]

Thanks; I've been working on a response for this and should have it back 
to you in about the next day.  It's taken awhile as there is a lot to it.


On 7/27/2022 2:51 PM, Jean Mahoney wrote:
> 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
>>
>>