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

[Jean Mahoney <[e-mail]>]

*AD, please see the Wesley's questions at the bottom of this message.

Wesley,

Thank you for your response. We have updated the document with your 
feedback:

https://www.rfc-editor.org/authors/rfc9293-lastrfcdiff.html (this 
changes side by side)

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


We also have two new questions and a followup question:

1) <!-- [rfced] Section 3.9.1.1: Please review the placement of commas 
in the
following. We note that "local IP address," has a comma following it, but
the other options have the comma before.

Current:

       Format: OPEN (local port, remote socket, active/passive [,
       timeout] [, Diffserv field] [, security/compartment] [local IP
       address,] [, options]) -> local connection name
-->


2) <!-- [rfced] Sections 3.9.1.2 and 3.9.1.3: In the following format 
statements,
should square brackets be used to indicate optional items? FYI, we have
updated "push flag" to "PUSH flag" and "urgent flag" to "URGENT flag" in
the second format statement.

Current:

    Format: SEND (local connection name, buffer address, byte count,
    PUSH flag (optional), URGENT flag [,timeout])
    ...

    Format: RECEIVE (local connection name, buffer address, byte
    count) -> byte count, URGENT flag, PUSH flag (optional)
-->


3) <!-- [rfced] Terminology:

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)

-->


Best regards,

RFC Editor/jm



On 7/28/22 10:10 AM, Wesley Eddy wrote:
>
> Hello, here are response to each each of the questions below.
>
> *Also, for ADs, there is a request at the very end of this message to 
> add 2 sentences that I think should take AD approval.*
>
>
> On 7/15/2022 6: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
>> -->
>
> Yes, this update is fine.
>
>
>> 2) <!-- [rfced] Please provide any keywords (beyond those that appear in the
>> title) for use onhttps://www.rfc-editor.org/search.
>> -->
>
> Keywords:
>
> TCP
>
> TCPM
>
> transport layer
>
> internet transport
>
>
>
>> 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.
>> -->
>
> Yes, this change is fine.
>
>
>> 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].
>> -->
>
> Yes, this change is fine.
>
>
>> 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]). ...
>> -->
>
> Yes, this change is good.
>
>
>> 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 ...
>> -->
>
> Yes, this change is good.
>
>
>> 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.
>> -->
>
> Yes, this change is good.
>
>
>> 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
>> -->
>
> I think there was a mistake here.  I think instead of MUST-19, it 
> looks like this should have been MUST-14 and linked to Section 3.7.1.
>
>
>> 9) <!-- [rfced] Table titles: Tables 1, 5, and 6 do not have titles. Would you like to provide them?
>> -->
>
> Thank you, here are suggested titles:
>
> Table 1: Mandatory Option Set
>
> Table 5: Segment Acceptability Tests
>
> Table 6: Segment Acceptability Tests
>
>
>> 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).
>> -->
>
> Yes, this looks good; thanks.
>
>
>> 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.
>> -->
>
> Yes, that change seems good.
>
>
>> 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
>> -->
>
> Yes, this change looks good.
>
>
>> 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.
>> -->
>
> Yes, this change is fine.
>
>
>> 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.
>> -->
>
> Yes, this change is good.
>
>
>> 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.
>> -->
>
> Yes, this change is fine.
>
>
>> 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.
>> -->
>
> Yes, this is a good change; thank you.
>
>
>> 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.
>>
>> -->
>
> Yes, this is a very good change; thank you!
>
>
>> 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.
>> -->
>
> Yes, this change is fine.
>
>
>> 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";
>>     ...
>> -->
>
> Yes, this is a good change.
>
>
>> 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.
>> -->
>
> I'm not sure about this one.  It doesn't seem much better or worse to 
> me, as it's not very specific in either case.  I would propose to 
> leave it with the prior "robust" wording.
>
>
>> 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.
>> -->
>
> Yes, good change, thanks.
>
>
>> 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].
>> -->
>
> Yes, actually reference [28] also works for both ACK compression and 
> ACK decimation (both are discussed in RFC 3449).  It would be fine to 
> repeat the reference to [28], if you think that is more clear.
>
>
>> 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)
>> -->
>
> Yes, this change looks good, thanks.
>
>
>> 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.
>> -->
>
> Yes, thank you, that will be a good change for consistency.
>
>
>> 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.
>> -->
>
> Yes, thank you, I agree with your change.
>
>
>> 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)...
>> -->
>
> Yes, this change is fine.
>
>
>> 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.
>> -->
>
> Yes, thank you, this change would be fine.
>
>
>> 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.
>> -->
>
> This change is good, thanks.
>
>
>> 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.
>> -->
>
> Yes, thank you, that is a good change.
>
>
>> 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.
>> -->
>
> This looks good; thanks.
>
>
>> 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.
>>   -->
>
> Yes, this is fine, thanks.
>
>
>> 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.
>> -->
>
> Yes, thank you, this is good.
>
>
>> 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 ...
>>
>> -->
>
> Yes, these changes are fine.
>
>
>> 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
>> -->
>
> Thank you, this change is fine.
>
>
>> 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:")?
>> -->
>
> Option B looks like it would be an improvement, so I think that 
> approach is best.
>
>
>> 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)
>> -->
>
> Thanks; these changes look good to me.
>
>
>> 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
>> -->
>
> Yes, this change looks okay to me.
>
>
>> 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
>> -->
>
> Thank you, this is also a good change.
>
>
>> 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.
>> -->
>
> Yes, good idea.
>
>
>> 40) <!-- [rfced] Section 5: Unless we hear otherwise, we will add informative
>> references to the the errata reports mentioned in this document. -->
>
> Great; thank you.
>
>
>> 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.
>> -->
>
> Yes, this is an improvement.  To make it possibly even better, what about:
>
> RFC 6429 is obsoleted in the sense that the clarification it describes 
> has been reflected within 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].
>> -->
>
> Thank you.
>
>
>> 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.
>> -->
>
> You are correct.
>
>
>> 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.
>> -->
>
> This one is not quite right.  Can I suggest instead:
>
> Additionally, see RFC 6093 [39] for discussion of security 
> considerations related to the urgent pointer field, which also 
> discourages new applications from using the urgent pointer.
>
>
>> 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.
>> -->
>
> Ok.
>
>
>> 46) <!-- [rfced] Informative References: Ashttps://www.iana.org/assignments/tcp-header-flags/
>> has moved tohttps://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/>.
>> -->
>
> Very good; thanks.
>
>
>> 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>.
>> -->
>
> Ok; since this is just a webpage, it's possible that it changes 
> periodically, but I agree with you that this is currently the correct 
> way to indicate it.
>
>
>> 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.
>> -->
>
> Ok, thank you.
>
>
>> 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
>> -->
>
> This looks great; thank you for your help!
>
>
>> 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    |         |      |        |     |        |      |
>>      ...
>> -->
>
> Thank you, this consistency in the style is good.
>
>
>> 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"         |         |      |        |     |        |      |
>>     ...
>>     
>> -->
>
> Looks good, thank you.
>
>
>> 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    |         |      |        |     |        |      |
>> -->
>
> The spacing here looks fine to me.
>
>
>> 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 |         |      |        |     |        |      |
>>      ...
>> -->
>
> I think this is right though I had an error in the "=>nn", which 
> should have just been left out entirely, so that it would just read 
> "Abort on Dest Unreach (0,1,5)".  If you can please remove the "=>nn", 
> that will fix it.
>
>
>> 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|
>> -->
>
> Those do not need the arrows.  I should have left the arrows out, so 
> you can please remove them.
>
>
>> 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?
>> -->
>
> They both contributed reviews and were helpful as chairs, so I thought 
> this might be appropriate.  I'll trust your judgement either way on 
> whether to change this or not.
>
>
>> 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
>
> These all look good to me; thank you.
>
>
>> 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)
>
> The later cases of all of these (with lower-case 'a' in algorithm) 
> seem most appropriate.
>
>
>> codepoint (3) / code point (3)
>
> I think the first ("codepoint") is most consistent with other RFCs I'm 
> aware of.
>
>
>> End-of-Option option (1) / End of Option List Option (2) / End of option list (2)
>
> I think the middle "End of Option List Option" is best.
>
>
>> internet (17) / Internet (36)
>
> This one is more tricky.  I think in most cases we will use capital-I 
> "Internet" when referencing *the* Internet (or Internet Protocol, or 
> Internet protocol stack, etc.), and lowercase-i "internet" for any 
> internetworks in-general, so has to be considered on a case-by-case 
> basis as to which form is intended.
>
> I've checked all the instances, and I think the only changes that 
> might be helpful are:
>
> - in section 3.8.3, change "Internet path" to "internetwork path".
>
> - in section 3.8.6.3, change "Intenet" to "network".
>
>
>> Option (38) / option (121):
>> 	End-of-Option option (1) / End of Option List Option (2) / End of option list (2)
> Middle case ("End of Option List Option") is best.
>
>> 	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)
>
> All of the capital 'O' versions seem like the best route to me.  We 
> need at least some of them to have capital 'O' for some tool 
> processing, so all of them may as well.
>
>
>> Push:
>>     push function (2) / Push Function (2)
>
> I don't think there's a need to capitalize this, though at least in 
> Table 7, it looks like the 'P' should be capitalized for consistency 
> with other rows, but the 'F' need not be.
>
>
>>     PSH (2) / PSH bit (5) /
>
> I think these are fine as-is.
>
>
>>     PSH flag (2) / PUSH flag (13)
>
> I think in these cases "PSH flag" could be "PSH bit" to distinguish 
> between the PUSH flag in the API description, and the PSH bit in the 
> header.
>
>
>> quiet time (4) / Quiet Time (3)
>
> This should be fine lower case, except in headings where it's okay to 
> capitalize.
>
>
>> Time Stamp (2) / Timestamp (4) / timestamp (4)
>
> Let's use always a single word "timestamp" for consistency with RFC 
> 7323, and it should be capitalized when its referring to the Timestamp 
> Option.
>
>
>> 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
>
> Let's match RFC 8200.
>
>
>> 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".
>> -->
>
> These changes are fine with me; thank you.
>
>
>> 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.
>> -->
>
> I did not notice any changes needed.
>
>
> *For AD approval:*
>
> During the time just prior to AUTH48, I got some inputs offline from 
> Fernando Gont, that I think are essentially editorial changes, and 
> would be good to apply:
>
> 1. There is currently text that reads:
>
>    The clock component is intended to ensure that with a
>    Maximum Segment Lifetime (MSL), generated ISNs will be unique, since
>    it cycles approximately every 4.55 hours, which is much longer than
>    the MSL.
>
> Can we append to this?: "Please note that for modern networks that 
> support high data rates where the connection might start and quickly 
> advance sequence numbers to overlap within the MSL, it is recommended 
> to implement the Timestamp Option as mentioned later in Section 3.4.3."
>
> 2. Can we append a sentence at the end of the security considerations 
> section, and a reference to RFC 5927:
>
> "Since ICMP message processing also can interact with TCP connections, 
> there is potential for ICMP-based attacks against TCP connections.  
> These are discussed in RFC 5927 [add reference], along with 
> mitigations that have been implemented."
>
>