Transmission Control Protocol (TCP)
draft-ietf-tcpm-rfc793bis-28

[Ballot comment]
I have discussed the open DISCUSS items listed by Ben Kaduk with Wesley Eddy and Martin Duke. Ben's first issue was discussed in the WG and rejected by consensus. The document shepherd also raised that making changes to the protocol that weren't a part of other RFCs or erratas was "out of scope" for this update. Ben's remaining issues were discussed at a previous IESG telechat.

[Ballot comment]
--- EDIT ---
I originally balloted DISCUSS, ending with "As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise." - I see that there was a discussion on the list. I still think that it would be useful to have some additional text so that users don't cut themselves on sharp edges, but this is just my opinion, and so I'm clearing the DISCUSS.
Thanks all for the DISCUSSion.
----

Thank you very much to the authors and WG for writing this -- it's an important piece of work, and seems like it was probably also a large amount of work. Thanks!

Also, thanks to Sarah Banks for the OpsDir review - it was helpful.
Oh, and thanks to Erik, whose text I stole :-)

[Ballot comment]
I support Ben's Discuss point 3.

I would like to thank the author and WG of taking on the task of cleaning up and updating the TCP spec, it is hard work, but very important and helpful to the wider Internet community.

However, having read the shepherd's writeup, I do partly question whether publishing this as Internet Standard rather the Proposed Standard is really the right choice.  The Shepherd's writeup seems to suggest that there are various aspects of the protocol where implementations either all deviate from the standard, or mitigate various issues.  Ideally, I would prefer for IETF consensus to be reached on a standard way of how to address those issues, and then collect those into an rfc793bisbis that accurately represents what a current TCP implementation is expected to look like.  However, I can also see that, RFC 793 is an Internet Standard, and publishing a cleanup of that spec, that doesn't change anything, along with the fact that TCP is deployed everywhere, make is hard to not classify RFC793bis as an Internet Standard ...

But, anyway, I really do appreciate the cleanup work that has happened here.

Regards,
Rob

[Ballot comment]
Thank you to Kyle Rose for the SECDIR review.

I support Ben, Lars, Warren and Zahed’s DISCUSS positions.

** Appendix A.1 and the shepherd write-up which explains why the antiquated text around “security compartments” for multi-level systems is still in this draft.  It’s disappointing that there was no prior IETF consensus action to establish the basis of pruning it.  My suggested addition for Appendix A.1 would be to make a much clearer statement than “the state of IP security options that may be used by MLS systems is not as clean”.  It isn’t clear what is meant by “clean” – is it intended to say that it is not in fact used?

** Section 3.1. Per “[TCP Option]; Options#Size == (DOffset-5)*32;”, I found this notation confusing. What does the “#” in “Options#Size” indicate?

** Section 3.4.  Per “There are security issues that result if an off-path attacker is able to predict or guess ISN values”, a reference might be helpful for this statement.  Perhaps [41] or [Morris185] from [41].

** Section 3.9.2 and 3.9.2.1 The text here discusses various IP options like timestamp, record route and source routing.  Either in this section or in the Security Considerations the security implications of these options should be highlights.  Specifically, Section 4.3 – 4.5 of RFC7126 outline these security issues and has normative guidance to treat these packets as default drop.

** Section 7.  Recommend being more precise on the lack of security services:

OLD
but there are no built-in cryptographic capabilities
  to support any form of privacy, authentication

NEW
but there are no built-in cryptographic capabilities
  to support any form of confidentiality, authentication

** Section 7.
  In order to fully protect TCP connections (including their control
  flags) IPsec or the TCP Authentication Option (TCP-AO) [36] are the
  only current effective methods. Other methods discussed in this
  section may protect the payload

The text should be more precise on what “protect” means.  IPSec and TCP-AO provide different security services.  IPSec will provide confidentiality and integrity, but TCP-AO only provides the latter.

Likewise, the reference to protect the payload needs to be clarified.  Which exact security service does “protect” align with?

** Section 7.  Further discussion on TCP stack fingerprinting would be helpful.  RFC8546 notes that “In particular, the metadata, such as sequences of interpacket timing and packet sizes, can be used to    infer other parameters of the behavior of the protocols in use or to fingerprint protocols and/or specific implementations of those protocols.”  However, it’s more than that – it’s the specific choices of options, their sequence in the packets, etc.  Pretty much everything a tool like nmap does to profile host OSes.

[Ballot discuss]
Many thanks for taking on the task of producing a roll-up update for the
core TCP specification!  I am sure it was a lot of work, but I am happy
to see it done.

That said, I do have a few points that I would like to have a bit more
discussion on before the document is published; I'm happy to see that
Warren already linked to
https://www.ietf.org/blog/handling-iesg-ballot-positions/ on the topic
of what a DISCUSS position can (and cannot) mean.

(1) We incorporate some long-standing enhancements that improve the
security and robustness of TCP (in particular, random ISN and protection
against off-path in-window attacks come to mind), but only at SHOULD or
MAY requirements level.

For example, we currently say:

  A TCP implementation MUST use the above type of "clock" for clock-
  driven selection of initial sequence numbers (MUST-8), and SHOULD
  generate its Initial Sequence Numbers with the expression:

  ISN = M + F(localip, localport, remoteip, remoteport, secretkey)

and:

        +  RFC 5961 [37] section 5 describes a potential blind data
            injection attack, and mitigation that implementations MAY
            choose to include (MAY-12).  TCP stacks that implement
            RFC 5961 MUST add an input check that the ACK value is
            [...]

What prevents us from making a MUST-level requirement for randomized
ISNs?  Is it just the fact that it was only a SHOULD in RFC 6528 and a
perception that promoting to a MUST would be incompatible with retaining
Internet Standard status?

Likewise, what prevents using stronger normative language (e.g., MUST)
for the RFC 5961 protections?

It seems to me that these mechanisms are of general applicability and
provide significant value for use of TCP on the internet, even though
they are not fully robust and do not use cryptographic mechanisms.  If
there are scenarios where their use is harmful or even just not
applicable, that seems like an exceptional case that should get
documented so as to strengthen the general recommendation for the
non-exception cases.


(2) I think this is just a process question to ensure that the IESG
knows what we are approving at Internet Standard maturity, though it
is certainly possible that I misunderstand the situation.

In Section 3.7.3 we see the normative statement (SHLD-6) that "when the
when the effective MTU of an interface varies packet-to- packet, TCP
implementations SHOULD use the smallest effective MTU of the interface
to calculate the value to advertise in the MSS option".  This seems to
originate in RFC 6691 (being obsoleted by this document), but RFC 6691
is only an Informational document and has not had an opportunity to
"accumulate experience at Proposed Standard before progressing", to
paraphrase RFC 6410.

Similarly, Section 3.9.2 has (SHLD-23) "Generally, an application SHOULD
NOT change the DiffServ field value during the course of a connection
(SHLD-23)."  This is a bit harder to track down, as the DiffServ field
was not always known by that name.  I actually failed to find a directly
analogous previous statement of this guidance (presumably my error), and
thus don't know if it had any experience at the PS level or not.

RFC 6410 seems pretty clear that some revisions are okay in Internet
Standards without such "bake time" at PS, but it does seem like
something that should be done consciously rather than by accident.

(3) This is also a process point for explicit consideration by the IESG.

Appendix A.2 appears to discuss a few (rare) scenarios in which the
technical mechanisms of this document fail catastrophically (e.g.,
getting stuck in a SYN|ACK loop and failing to complete the handshake).
Does this meet the "resolved known design choices" and "no known
technical omission" bar required by RFC 2026 even for *proposed*
standard?

(Note that RFC 2026 explicitly says that the IESG may waive this
requirement, at least for PS.)


(AFAICT one such scenario is reported at
https://www.rfc-editor.org/errata_search.php?eid=3305 , which the change
log for this document calls out as "not applicable due to other
changes"; I am not sure which "other changes" are intended, for this
case.)

(4) Another point mostly just to get explicit IESG acknowledgment
(elevating one of Lars' comments to DISCUSS level, essentially).

As the changelog (and gen-art reviewer!) notes:

  Early in the process of updating RFC 793, Scott Brim mentioned that
  this should include a PERPASS/privacy review.  This may be something
  for the chairs or AD to request during WGLC or IETF LC.

I don't see any evidence to suggest that such a review actually
occurred.  Do we want to seek out such a targeted review before
progressing?

[Ballot comment]
Thank you for the editorial changes so that we now talk about "a TCP
implementation" or a "remote TCP peer" rather than just "a TCP" or
"a remote TCP"!

Abstract

                                                It also updates RFC
  5961 by adding a small clarification in reset handling while in the
  SYN-RECEIVED state.  [...]

I'm not sure I found what this clarification was; is SYN-RECEIVED the
correct state?  The ad-hoc diff I constructed between RFC 793 and this
document shows identical text for the "If the RST bit is set" case when
currently in SYN-RECEIVED STATE.

Section 3.1

  Options: [TCP Option]; Options#Size == (DOffset-5)*32; present
  only when DOffset > 5.

My (later) nit-level notation comment aside, the given expression does
not seem to convey the size occupied by the options, but rather the
combined size of the options and the padding.

Section 3.2

  A TCP Option is one of: an End of Option List Option, a No-Operation
  Option, or a Maximum Segment Size Option.

The IANA registry lists some thirty-odd option kinds, so this sentence
just seems false without some additional qualifier ("defined by this
specification", etc.)

Section 3.4

  In response to sending data the TCP endpoint will receive
  acknowledgments.  The following comparisons are needed to process the
  acknowledgments.
      [...]
      SEG.SEQ = first sequence number of a segment

      SEG.LEN = the number of octets occupied by the data in the segment
      (counting SYN and FIN)

      SEG.SEQ+SEG.LEN-1 = last sequence number of a segment

It seems to me that this information from the incoming segment is not
part of processing the *acknowledgment*, but rather part of processing
the data received in that segment (a procedure discussed a few
paragraphs later).

            This clock is a 32-bit counter that typically increments at
  least once every roughly 4 microseconds, [...]
  Maximum Segment Lifetime (MSL), generated ISNs will be unique, since
  it cycles approximately every 4.55 hours, which is much longer than
  the MSL.

Once we put in the "at least" we allow arbitrarily faster clock updates,
and that puts the "approximately every 4.55 hours" estimate in question.
Very fast clock updates would cycle correspondingly faster.  Do we need
to place a lower limit on the clock update interval?  (On first look, it
seems like we might not, since the keyed PRF F() is providing most of
the protection from off-path guessing, and an attacker can always use
direct connections to estimate the clock cycle interval.  OTOH, if it
cycles so fast that it repeats within O(MSL), that might be problematic.)

  parameters and some secret data.  For discussion of the selection of
  a specific hash algorithm and management of the secret key data,
  please see Section 3 of [41].

The guidance in the referenced document seems a bit dated (it indicates
that MD5 is probably still okay for this purpose).  While the known
attacks on MD5 do not directly translate into an attack on ISN
generation, collisions can be found on as little as 64 bytes of input,
and all of the straightforward ways to use pure MD5 as a keyed hash for
this purpose have some undesirable properties.  I'm happy to note that
FreeBSD is using siphash for this purpose, which should be more than
adequate.  I expect that Linux and other major TCP stacks are already
doing something similar, so the guidance to use MD5 may be dated in
practice as well as in utility.

I don't have a great proposal for where to put some updated guidance
(unless there's already some work underway in tcpm?); it is probably not
appropriate to put it inline here, so either an appendix or a separate
document seem plausible.

Section 3.7.1

  The MSS value to be sent in an MSS option should be equal to the
  effective MTU minus the fixed IP and TCP headers.  By ignoring both
  IP and TCP options when calculating the value for the MSS option, if
  there are any IP or TCP options to be sent in a packet, then the
  sender must decrease the size of the TCP data accordingly.  RFC 6691
  [42] discusses this in greater detail.

I note that RFC 6691 is obsoleted by this document; it seems to me that
if we think there is useful content still in that document, we should
include such content in this document instead of referring to a document
we are calling obsolete.  (This is not the only place we do so, to be
clear, but I will try to mention it just once.  I do see the note that
we only claim to incorporate the normative portions of most of the
obsoleted specs, leaving the informational content alone.)

Section 3.8.4

  An implementation SHOULD send a keep-alive segment with no data
  (SHLD-12); however, it MAY be configurable to send a keep-alive
  segment containing one garbage octet (MAY-6), for compatibility with
  erroneous TCP implementations.

Such misbehaved TCP impelementations were misbehaved even in 1989 when
RFC 1122 was published -- do we have a sense for whether they are still
around to any significant degree?

Section 3.8.5

  As a result of implementation differences and middlebox interactions,
  new applications SHOULD NOT employ the TCP urgent mechanism (SHLD-
  13).  However, TCP implementations MUST still include support for the
  urgent mechanism (MUST-30).  Details can be found in RFC 6093 [38].

This "SHOULD NOT employ" has been in force for over a decade (RFC 6093
is dated January 2011).  How long do we have to wait until there are
sufficiently few implementations employing the urgent mechanism that it
no longer needs to be implemented?

Section 3.9.2.3

      An incoming SYN with an invalid source address MUST be ignored
      either by TCP or by the IP layer (MUST-63) (Section 3.2.1.3 of
      [18]).

Requirements of the form "A or B must do X" that are ambiguous about
whether A or B takes the action leave the risk that both will expect the
other party to take the action, and the action will fail to occur.  If
we're in a position to specifically require one (or both!) to check,
that leads to a more robust and verifiable system.  (I assume we're not
in such a position, but it can't hurt to check.)

Section 4

  Destination Address
          The network layer address of the remote endpoint.
  [...]
  Source Address
          The network layer address of the sending endpoint.

These definitions don't seem to work in the context of a receiver
validating the TCP checksum, where the destination address is the local
endpoint's address and the source address is the remote endpoint's
address.  (I note that these definitions are different from what RFC 793
itself used.)

  receive window
          This represents the sequence numbers the local (receiving)
          TCP endpoint is willing to receive.  Thus, the local TCP
          endpoint considers that segments overlapping the range
          RCV.NXT to RCV.NXT + RCV.WND - 1 carry acceptable data or
          control.  Segments containing sequence numbers entirely
          outside of this range are considered duplicates and
          discarded.

Duplicates or injection attacks (when the sequence numbers in the
segment are too large).

Section 5

  The collection of applicable RFC Errata that have been reported and
  either accepted or held for an update to RFC 793 were incorporated
  (Errata IDs: 573, 574, 700, 701, 1283, 1561, 1562, 1564, 1565, 1571,
  1572, 2296, 2297, 2298, 2748, 2749, 2934, 3213, 3300, 3301, 6222).
  Some errata were not applicable due to other changes (Errata IDs:
  572, 575, 1569, 3305, 3602).

I think that EID 1565 belongs in the "not applicable due to other
changes" list, since the text it attempts to modify involves the
now-removed discussion of the IP "precedence" field.

Similarly, EID 2296 also affected text about precedence and security
that is no longer present in a recognizable form.

  The more secure Initial Sequence Number generation algorithm from RFC
  6528 was incorporated.  See RFC 6528 for discussion of the attacks
  that this mitigates, as well as advice on selecting PRF algorithms
  and managing secret key data.

(As I mentioned up in §3.4, that guidance is no longer current.)

Section 9.1

It's not clear to me that RFC 2675 ([5]) needs to be classified as
normative.

The guidance at
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
would suggest that RFC 5961 ([37]) should be classified as normative,
since we replicate its MUST-level requirements with the condition that
"TCP stacks that implement RFC 5961 MUST [...]", which would appear to
make that behavior an "optional feature".

Appendix A.1.2

  The IP security option (IPSO) and compartment defined in [1] was
  refined in RFC 1038 that was later obsoleted by RFC 1108.  The
  Commercial IP Security Option (CIPSO) is defined in FIPS-188, and is
  supported by some vendors and operating systems.  RFC 1108 is now

Should we mention that FIPS-188 is archived and withdrawn by NIST?
(I also didn't find much to define the actual IP option in the PDF I
found,
https://csrc.nist.gov/csrc/media/publications/fips/188/archive/1994-09-06/documents/fips188.pdf,
but I didn't look very hard.)

Appendix A.3

It's fascinating to me that the preferred reference for this modified
Nagle algorithm is an Internet-Draft from 1999, vs something more
recent.

Appendix B

    Every 2nd full-sized segment or 2*RMSS ACK'd | SHLD-19|x| | | | |

This 'x' seems to be in the "MUST" column, not the "SHOULD" column.

  Time Stamp support                            | MAY-10 | | |x| | |

How do we square timestamp support being a "MAY" with SHLD-4,
SHOULD-level guidance to use timestamps to reduce TIME-WAIT?

  Time Exceeded => tell ALP, don't abort        | MUST-56| | | | |x|
  Param Problem => tell ALP, don't abort        | MUST-56| | | | |x|

Is there a double negative between "don't abort" and the 'x' being in
the "MUST NOT" column?

NITS

I made essentially no attempt to de-duplicate the nit-level remarks
against the ballot positions from other ADs (in contrast to the other
comments, where I made some modest effort to de-duplicate).  My
apologies for the extra work to ignore the already-fixed items.

Section 1

  For several decades, RFC 793 plus a number of other documents have
  combined to serve as the core specification for TCP [48].  Over time,
  a number of errata have been filed against RFC 793, as well as
  deficiencies in security, performance, and many other aspects.  The

A naive parse would say that this means a number of errata have been
filed against deficiencies.  I suspect the transition between errata and
deficiencies should refer to deficiencies having been "discovered" or
similar.

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

It's a little surprising to see this described as an "update of RFC 793"
(vs. a "replacement of" or "updated version of") since the relationship
is Obsoletes, not Updates.  I might even consider "into a single
consolidated specification".

Section 3.1

  Options: [TCP Option]; Options#Size == (DOffset-5)*32; present
  only when DOffset > 5.

The "Options#Size" notation seems confusing and is not using any
convention I'm aware of.  It does not appear in RFC 793 or any other RFC
that I can find, either.

Section 3.3.1

  maintenance of a TCP connection requires the remembering of several
  variables.  We conceive of these variables being stored in a

"the remembering of" is a fairly awkward phrase, where something like
just "remembering" or "maintaining state for" would flow more naturally.

Section 3.4

  It is essential to remember that the actual sequence number space is
  finite, though very large.  This space ranges from 0 to 2**32 - 1.

The sense of scale in the broader ecosystem may have evolved out from
under us; QUIC's 62-bit sequence space might be more along the lines of
"very large" these days, with a 32-bit space being merely "large".

  A connection is defined by a pair of sockets.  Connections can be

This is the first instance of the word "socket" in this document.
RFC 793 used the term much more prevalently, but this update has
(beneficially, IMO) moved away from that approach in favor of discussing
IP addresses and port numbers.  Might such a change be appropriate here
as well?  Regardless, we should probably have some introduction to what
we mean by "socket" if we are to retain any uses of the term, IMO, more
than just the glossary entry.

  verify this SYN.  The three way handshake and the advantages of a
  clock-driven scheme are discussed in [68].

I don't have access to the reference, but it's not clear from just it's
abstract whether "advantages of" or "advantages over" a clock-driven
scheme is the intended meaning.

  explanation for this specification is given.  TCP implementors may
  violate the "quiet time" restriction, but only at the risk of causing
  some old data to be accepted as new or new data rejected as old
  duplicated by some receivers in the internet system.

Maybe "old duplicated data"?  The current phrasing feels like it's
missing a word.

                                Hosts that prefer to avoid waiting are
  willing to risk possible confusion of old and new packets at a given
  destination may choose not to wait for the "quiet time".

I think this needs an "and", for "prefer to avoid waiting and are
willing to risk".

  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
  the last emitted segment, if a new connection is started too soon and
  uses any of the sequence numbers in the space-time footprint of the
  last segment of the previous connection incarnation, there is a
  potential sequence number overlap area that could cause confusion at
  the receiver.

This list seems to be missing an "and".
(Also, is it really only the last emitted segment that could cause
problems?)

Section 3.5

                                                            It is the
  implementation of a trade-off between memory and messages to provide
  information for this checking.

I'm not sure this reads well; is "the implementation of" needed?

      If an incoming segment has a security level, or compartment that
      does not exactly match the level and compartment requested for the
      connection, a reset is sent and the connection goes to the CLOSED
      state.  The reset takes its sequence number from the ACK field of

The comma in the first line is no longer needed (it was part of the list
when precedence was still part of the list).

Section 3.6

      In this case, a FIN segment can be constructed and placed on the
      outgoing segment queue.  No further SENDs from the user will be
      accepted by the TCP implementation, and it enters the FIN-WAIT-1
      state.  RECEIVEs are allowed in this state.  All segments
      preceding and including FIN will be retransmitted until
      acknowledged.  When the other TCP peer has both acknowledged the
      FIN and sent a FIN of its own, the first TCP peer can ACK this
      FIN.  Note that a TCP endpoint receiving a FIN will ACK but not
      send its own FIN until its user has CLOSED the connection also.

Naming the two peers (e.g., A and B) can help avoid awkward grammatical
constructions like "can ACK this FIN" and improve clarity.

Section 3.8

  segments may arrive due to network or TCP retransmission.  As
  discussed in the section on sequence numbers the TCP implementation
  performs certain tests on the sequence and acknowledgment numbers in
  the segments to verify their acceptability.

comma after "sequence number".

Section 3.8.6.2.2

  Note that the general effect of this algorithm is to advance RCV.WND
  in increments of Eff.snd.MSS (for realistic receive buffers:
  Eff.snd.MSS < RCV.BUFF/2).  Note also that the receiver must use its
  own Eff.snd.MSS, assuming it is the same as the sender's.

I think the last sentence would be more clear if it was something like
"making the assumption that is the same" or "on the assumption that it
is the same".

Section 3.8.6.3

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

Reference [26] seems reasonable for ACK decimation and ACK compression,
but doesn't seem to cover GRO at all.

Section 3.9.1

        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.  When an
        application issues a series of SEND calls without setting the
        PUSH flag, the TCP implementation MAY aggregate the data
        internally without sending it (MAY-16).

There's a dedicated paragraph a few paragraphs later for when the PUSH
flag is not set; the last sentence might flow better there.

        Some TCP implementations have included a FLUSH call, which will
        empty the TCP send queue of any data that the user has issued
        SEND calls but is still to the right of the current send
        window.  That is, it flushes as much queued send data as

I think "has issued SEND calls for" (add "for").

Section 3.9.2

  When received options are passed up to TCP from the IP layer, TCP
  implementations MUST ignore options that it does not understand
  (MUST-50).

singular/plural mismatch (it/implementations)

Section 3.9.2.2

  Soft Errors
    For ICMP these include: Destination Unreachable -- codes 0, 1, 5,
    Time Exceeded -- codes 0, 1, and Parameter Problem.

    For ICMPv6 these include: Destination Unreachable -- codes 0 and 3,
    Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1,
    2.

    Since these Unreachable messages indicate soft error conditions,

I'm not entirely sure that I'd classify "parameter problem" as an
"unreachable" message per se.

Section 3.10

  Please note in the following that all arithmetic on sequence numbers,
  acknowledgment numbers, windows, et cetera, is modulo 2**32 the size
  of the sequence number space.  Also note that "=<" means less than or

Some punctuation around "the size of the sequence number space" seems in
order.

  equal to (modulo 2**32).

[In formal mathematics this "less than or equal to, modulo N" operator
is not defined.  But it's probably okay in this context.]

Section 3.10.1

        the parameters of the incoming SYN segment.  Verify the
        security and DiffServ value requested are allowed for this
        user, if not return "error: precedence not allowed" or "error:
        security/compartment not allowed."  If passive enter the LISTEN

It's surprising for the error string to mention "precedence" when the
predicate is DiffServ value.

        with "error: insufficient resources".  If Foreign socket was
        not specified, then return "error: remote socket unspecified".

I suspect s/Foreign/remote/ was intended.  (Also occurs later, but I
will just note it once here.)

Section 3.10.3

      -  Since the remote side has already sent FIN, RECEIVEs must be
        satisfied by data already on hand, but not yet delivered to the
        user.  If no text is awaiting delivery, the RECEIVE will get a
        "error: connection closing" response.  Otherwise, any remaining
        text can be used to satisfy the RECEIVE.

I think s/text/data/ should be applied on the last line (since it was
already applied on the second line).

Section 3.10.7.4

  o  Segments are processed in sequence.  Initial tests on
      arrival are used to discard old duplicates, but further
      processing is done in SEG.SEQ order.  If a segment's
      contents straddle the boundary between old and new, only the
      new parts should be processed.

Maybe s/should be/are/?  There's not really optionality about it...

            *  If this connection was initiated with a passive OPEN
              (i.e., came from the LISTEN state), then return this
              connection to LISTEN state and return.  The user need
              not be informed.  If this connection was initiated
              with an active OPEN (i.e., came from SYN-SENT state)
              then the connection was refused, signal the user
              "connection refused".  In either case, all segments on
              the retransmission queue should be removed.  And in

IIUC, what's described here as "removed" is described elsewhere as
"flushed"; it would be good to use consistent terminology when possible.

        +  Once in the ESTABLISHED state, it is possible to deliver
            segment text to user RECEIVE buffers.  Text from segments
            can be moved into buffers until either the buffer is full
            or the segment is empty.  If the segment empties and
            [...]

As above, it seems like (case-insensitive) s/test/data/ would improve
consistency.

Section 4

  internet datagram
          The unit of data exchanged between an internet module and the
          higher level protocol together with the internet header.

"exchanged between an internet module and the higher level protocol"
sounds like a local operation; I would have expected the definition of
an *internet* datagram to involve transfer over the (inter)network.

  segment length
          The amount of sequence number space occupied by a segment,
          including any controls that occupy sequence space.

Should we say that this is a field in the segment header?

  URG
          A control bit (urgent), occupying no sequence space, used to
          indicate that the receiving user should be notified to do
          urgent processing as long as there is data to be consumed
          with sequence numbers less than the value indicated in the
          urgent pointer.

To me, "value indicated in" is synonymous with "value contained in",
which is problematic here since the urgent field is only 16 bits and
sequence numbers 32 bits.  "indicated by" would be an improvement,
though of course if we're willing to spend more words we can increase
clarity further.

Appendix A.1

  RFC 793 requires checking the IP security compartment and precedence
  on incoming TCP segments for consistency within a connection, and

I think the past tense "required" would be more appropriate upon
publication of this document as an RFC obsoleting RFC 793.

[Ballot comment]
Thanks very much for this document and all the work that went into it. Thanks also for the clear and illuminating shepherd write-up.

Below are some comments I hope will be helpful.

1. Regarding in §1,

  The purpose of this document is to bring together all of the IETF
  Standards Track changes that have been made to the base TCP
  functional specification and unify them into an update of [RFC 793].

It also incorporates Informational documents, right? For example, RFC 6691 is Informational, as is 6429. So, these are being elevated, by virtue of their incorporation, to Standards Track. I'm not saying that's a problem, but the quoted text, while technically accurate I suppose (it doesn't say "exclusively Standards Track changes" after all) is misleading.

2. Regarding, in §3.4,

  A new acknowledgment (called an "acceptable ack"), is one for which
  the inequality below holds:

  SND.UNA < SEG.ACK =< SND.NXT

I’m having a hard time seeing why the first part of the inequality is < and not =<. Wouldn’t =< be the case when a single new byte is being acknowledged? (Based on the definition that SND.UNA is the “oldest unacknowledged sequence number” and therefore, presumably needs to be acknowledged.) I do see this text is unchanged from RFC 793 so I am very likely wrong, but I’d appreciate knowing WHY I’m wrong…

3. Regarding, in §3.4,

    even if data rates escalate to 10's of megabits/sec. At 100
    megabits/sec, the cycle time is 5.4 minutes, which may be a little
    short, but still within reason.

I realize this is, again, inherited from RFC 793 but it seems hopelessly quaint in 2021 and not suitable for publication today. I mean, my unexceptional commodity home connection is 1 Gbps and it just goes up from there. At 100 Gbps we’re down to a cycle time of ~300 msec which no longer seems so easy to brush off as "still within reason". I’m not suggesting this document has to fix the problem, and indeed I’m aware there are other documents for this purpose — but does the outdated text have to be retained?

4. The parenthetical reference to “User Telnet” in §3.8.3 seemed equally anachronistic. Seems like it could just be removed.

5. It made me sad while reviewing the document, that certain sections were stingy with subsection numbering. In particular §3.4 has the unnumbered subheadings "Initial Sequence Number Selection", "Knowing When to Keep Quiet", and "The TCP Quiet Time Concept", and §3.5 has "Half-Open Connections and Other Anomalies", "Reset Generation", and "Reset Processing". I think it would make the document more usable if these were numbered, as we tend to do in the modern era, and as the rest of the document does do. (I may have missed some, the list above isn't necessarily exhaustive.)

Nits:

6. I found it odd that figure 11 uses Z and X as the sequence numbers, whereas all the previous illustrations used actual numbers. It works of course, but it's inconsistent.

7. In §3.1:

  The control bits are also know as "flags"

  S/know/known/

8. In §3.1, “one’s complement” should be “ones’ complement”.

9. In §3.3.2:

  transitions are not not explicitly shown

  Presumably the double negation isn’t isn't deliberate. :-)

10. In §3.4:

    next sequence number expected on an incoming segments

    Should be segment, singular.

11. In §3.4:

    sequence space occupying controls

    I think this needs, or at least would be better with, a hyphen: “sequence space-occupying controls”

12. In several places, "anyways" should probably be "anyway". (At least my dictionary suggests the change.)

13. In §3.4:

  Hosts that prefer to avoid waiting are
  willing to risk possible confusion of old and new packets at a given
  destination may choose not to wait for the "quiet time".

“Are willing” should be “and are willing”

14. In §3.6:

    the user can terminate his side gracefully

Perhaps consider a non-gendered pronoun such as "their"?

15. In §3.8.2:

  [RFC 1122] required implementation of Van Jacobson's congestion control
  algorithms slow start and congestion avoidance together with

Seems as though there’s some punctuation missing. Perhaps “RFC 1122 required implementation of Van Jacobson’s congestion control algorithms, slow start, and congestion avoidance, together with“?

16. “Internet” is inconsistently capitalized throughout, probably corresponding to age of the text. But I suppose the RFCEd will fix this.

[Ballot discuss]
[ "Then I said unto you, Dread not, neither be afraid of of this DISCUSS, for it be easy to address" ]

I'm raising one of Erik's comments to a DISCUSS, because I think that it is important enough that it needs addressing:
----
[S3.9.2.1]

* I feel like there should be some additional caveat about security
  implications of support for source routing.  RFC 6274, for example, says
  packets with LSRR (6274s3.13.2.3) and SSRR (6274s3.13.2.4) options should
  be dropped, citing various security concerns.

  I'm not sure there needs to be a lot of text; perhaps just an observation
  that some end systems may not support the source route semantics described
  here for security (or policy) reasons?
----

I realize that this document isn't intended to be a summary of all RFCs which mention anything related to TCP, but this particular point seems like it could do with an extra bit of reinforcement.

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise.

[Ballot comment]
Thank you very much to the authors and WG for writing this -- it's an important piece of work, and seems like it was probably also a large amount of work. Thanks!

Also, thanks to Sarah Banks for the OpsDir review - it was helpful.
Oh, and thanks to Erik, whose text I stole :-)

[Ballot discuss]
[ "Then I said unto you, Dread not, neither be afraid of of this DISCUSS, for it be easy to address" ]

I'm raising one of Erik's comments to a DISCUSS:
----
[S3.9.2.1]

* I feel like there should be some additional caveat about security
  implications of support for source routing.  RFC 6274, for example, says
  packets with LSRR (6274s3.13.2.3) and SSRR (6274s3.13.2.4) options should
  be dropped, citing various security concerns.

  I'm not sure there needs to be a lot of text; perhaps just an observation
  that some end systems may not support the source route semantics described
  here for security (or policy) reasons?
----

I realize that this document isn't intended to be a summary of all RFCs which mention anything related to TCP, but this particular point seems like it could do with an extra bit of reinforcement.

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise.

[Ballot comment]
Thank you very much to the authors and WG for writing this -- it's an important piece of work, and seems like it was probably also a large amount of work. Thanks!

Also, thanks to Sarah Banks for the OpsDir review - it was helpful.

[Ballot comment]
Thank you for the work on this document. I only have minor comments, and some questions.

I have divided comments into "minor" (including the questions) and "nits". Neither require replies strictly speaking, please feel free to address as you see fit. I will appreciate answers to my questions, to improve my understanding. If any clarification comes out of it, I hope it will help improve the document.

Francesca

## minor

1. -----

Figure 1

FP: The figure's capture is "TCP Header Format", but Options and Data are included as well.

2. -----

Figure 2

FP: For consistency, I would have kept the same style as in Figure 1. Additionally, the IPv4 fields below do not have their size explicitly specified, so using the same type of formatting as in Figure 1 would help, IMO.

3. -----

      0
      0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |      0      |
      +-+-+-+-+-+-+-+-+

FP: More of a question than a comment: how come this change, compared to RFC 793? Any particular reason, or was it only for readability?

4. -----

FP: This is surely me missing something but, in section 3.5 I see:

  4.  ESTABLISHED -->        --> ESTABLISHED

  5.  ESTABLISHED -->  --> ESTABLISHED

which is followed by:

  Note that the sequence number of the segment in line 5 is the same as
  in line 4 because the ACK does not occupy sequence number space (if
  it did, we would wind up ACKing ACKs!).

However, later on, in Figure 13:

  2.  (Close)                                              (Close)
      FIN-WAIT-1  -->  ... FIN-WAIT-1
                  <--  <--
                  ...  -->

  3.  CLOSING    -->      ... CLOSING
                  <--      <--
                  ...      -->

I am confused why in this case, in line 3, ACK does in fact occupy sequence number space. What am I missing?

## nit

5. -----

  Initial Sequence Number Selection

FP: I assume this (and following) was not numbered to keep it as close as possible to the original RFC, is that right? For readability, I would suggest numbering these subsections.

[Ballot discuss]

* I found at least one reference that should be normative reference but they are not. Section 3.8.5 : describes --
 
    TCP implementations MUST still include support for the urgent mechanism (MUST-30). Details can be found in RFC 6093 [38]
 
  This to ne makes RFC6093 a must to read and understand to deploy this specification. Hence it should in the normative references.

* (This perhaps more process thing than technical), me and Benjamin Kaduk discussed another issue regarding urgent pointer. This specification specifies -

      Pointer indicates first non-urgent octet      | MUST-62|
 
  RFC1011 rectifies RFC973 to -

      The urgent pointer points to the
        last octet of urgent data (not to the first octet of non-urgent
        data).

  So what does happen to RFC1011 rectification then when 793bis is not bis anymore? Is this a known fact and there is conscious decision not to do anything about it? or was this a unknown fact and that part of RFC1011 need to be obsoleted (how?)?

[Ballot comment]
Thanks a lot to the author and the TCPM working group to produce this document. It has been long since I read the whole TCP specification, I refreshed myself a lot when reviewing this. Thanks for that experience.

I have some comments/questions below. By addressing those, I hope will improve the document even better:

* Section 3.1 : says --
    Note that the list of options may be shorter than the data offset field might imply. The content of the header beyond the End-of-Option option must be header padding (i.e., zero).
 
  Should this be a normative MUST?

* Passive open and active open should be defined/described. Even if these are well known terms in the community, a verbose description of passive/active open will be much appreciated in this document context. if they are defined somewhere else then I have missed that, in that case a reference would be more appropriate.

* Section 3.4 : says --
    There are security issues that result if an off-path attacker is able to predict or guess ISN values.

  A reference to this claim would be highly appreciated. May be we can reuse some ref from 41?
  I also think "Initial Sequence Number Selection", "Knowing When to Keep Quiet" and "The TCP Quiet Time Concept" should be numbered subtitles.

* Section 3.5 : can we put some reference for "security level or compartment"? A pointer to the appendix A.1 should be enough here.

* Section 3.8.1 : says --

  RFC 793 contains an early example procedure for computing the RTO. This was then replaced by the algorithm described in RFC 1122, and subsequently updated in RFC 2988, and then again in RFC 6298.

  I am not sure what am I supposed to do with this information. Suggest to remove this paragraph.

* Section 3.8.5 : describes --
 
    A TCP implementation MUST support a sequence of urgent data of any length (MUST-31). [18]
 
  I am not sure what is the reference for? if this is to say this MUST is taken from [18] as described there then to me this reference also should be normative.

[Ballot comment]
As I am on vacations abroad, I had no time to review this very-much-needed document, hence, I am trusting the Internet directorate review by Bernie Volz:
https://datatracker.ietf.org/doc/review-ietf-tcpm-rfc793bis-25-intdir-telechat-volz-2021-09-22/

Thank you for your time spent on this 'bis' document

-éric

[Ballot discuss]
The IESG needs to approve the following DOWNREFs during the telechat:

  DOWNREF [10] from this Internet Standard to Proposed Standard RFC6298.
  DOWNREF [2] from this Internet Standard to Draft Standard RFC1191.
  DOWNREF [7] from this Internet Standard to Proposed Standard RFC3168.
  DOWNREF [11] from this Internet Standard to Proposed Standard RFC6633.
  DOWNREF [9] from this Internet Standard to Draft Standard RFC5681.
  DOWNREF [5] from this Internet Standard to Proposed Standard RFC2675.
  DOWNREF [4] from this Internet Standard to Proposed Standard RFC2474.

[Ballot comment]
Section 3.1. , paragraph 50, comment:
>      Note: There is ongoing work to extend the space available for TCP
>      options, such as [64].

draft-ietf-tcpm-tcp-edo has been dead for four years, not sure how useful it is
to point to.

Section 3.4. , paragraph 35, comment:
>    Initial Sequence Number Selection

Shouldn't this be a heading starting a new sub-section?

Section 3.4. , paragraph 46, comment:
>    Knowing When to Keep Quiet

Shouldn't this be a heading starting a new sub-section?

Section 3.4. , paragraph 47, comment:
>    The TCP Quiet Time Concept

Shouldn't this be a heading starting a new sub-section?

Section 3.4. , paragraph 49, comment:
>    At 2 megabits/sec. it
>    takes 4.5 hours to use up 2**32 octets of sequence space.  Since the
>    maximum segment lifetime in the net is not likely to exceed a few
>    tens of seconds, this is deemed ample protection for foreseeable
>    nets, even if data rates escalate to 10's of megabits/sec.  At 100
>    megabits/sec, the cycle time is 5.4 minutes, which may be a little
>    short, but still within reason.

It would be nice to see an argument if any considerations change for today's
higher-bandwidth Internet paths.

Section 3.5. , paragraph 37, comment:
>    Half-Open Connections and Other Anomalies

Shouldn't this be a heading starting a new sub-section?

Section 3.5. , paragraph 74, comment:
>    Reset Processing

Shouldn't this be a heading starting a new sub-section?

Section 3.9.1. , paragraph 1, comment:
> 3.9.1.  User/TCP Interface

This section would be much more readable if each command was in its own
sub-section. I find deeply indented text that spans multiple pages difficult to
follow.

Section 5. , paragraph 50, comment:
>    Early in the process of updating RFC 793, Scott Brim mentioned that
>    this should include a PERPASS/privacy review.  This may be something
>    for the chairs or AD to request during WGLC or IETF LC.

Has this review has happened?

Document obsoletes RFC793, but does not cite it as a reference.

Document obsoletes RFC879, but does not cite it as a reference.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "his"; alternatives might be "they", "them", "their".

* Term "traditional"; alternatives might be "classic", "classical",
  "common", "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.3.2. , paragraph 21, nit:
-      Note 2: An unshown transition exists from FIN-WAIT-1 to TIME-WAIT
-              ^^  ^ ^^^^          -------
+      Note 2: The figure omits a transition from FIN-WAIT-1 to TIME-WAIT
+              ^^^ +++ ^^^^^^^ ^^

Section 3.8.6.1. , paragraph 4, nit:
-    paper" situation described in Section 4.2.2.17 of RFC1122.  The
-                                                      ^^^ ^^^
+    paper" situation described in Section 4.2.2.17 of [18].  The
+                                                      ^ ^^

Section 3.8.6.3. , paragraph 3, nit:
-    recomendations to immediately acknowledge out-of-order segments,
+    recommendations to immediately acknowledge out-of-order segments,
+        +

"Table of Contents", paragraph 2, nit:
>  . . . . . . . . . 108 A.4. Low Water Mark Settings . . . . . . . . . . . .
>                                ^^^^^^^^^^
This is normally spelled as one word.

Section 3.1. , paragraph 8, nit:
> ing host. The control bits are also know as "flags". Assignment is managed b
>                                    ^^^^
Did you mean "known"?

Section 3.2. , paragraph 12, nit:
> ue and to the current segment. In addition several variables relating to the
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 3.3.2. , paragraph 15, nit:
> m SYN-RECEIVED to LISTEN on receiving a RST is conditional on having reached
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.3.2. , paragraph 16, nit:
> rationale). These transitions are not not explicitly shown, otherwise the di
>                                  ^^^^^^^
This phrase contains a double negative, or a comma may be missing.

Section 3.3.2. , paragraph 16, nit:
> icult to read. Similarly, receipt of a RST from any state results in a trans
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.4. , paragraph 25, nit:
> The clock component is intended to insure that with a Maximum Segment Lifetim
>                                    ^^^^^^
Did you mean "ensure" (=make sure)? "Insure" means "pay money to insurance
company".

Section 3.4. , paragraph 37, nit:
> owing whether the segment was an old delayed one or not, unless it remembers
>                                  ^^^^^^^^^^^
Make sure that the adjective "old" is correct. Possibly, it should be an adverb
(typically ~ly) that modifies "delayed". Possibly, it should be the first word
in a compound adjective (hyphenated adjective). Possibly, it is correct.

Section 3.4. , paragraph 37, nit:
> e sender to verify this SYN. The three way handshake and the advantages of a
>                                  ^^^^^^^^^
This word is normally spelled with a hyphen.

Section 3.4. , paragraph 47, nit:
> nets, even if data rates escalate to 10's of megabits/sec. At 100 megabits/se
>                                      ^^^^
Apostrophes aren't needed for decades.

Section 3.5. , paragraph 3, nit:
> he ACK field is incorrect and returns a RST (reset) with its SEQ field select
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 25, nit:
> onnection exists, so TCP Peer A sends a RST. The RST is acceptable so TCP Pe
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 29, nit:
> (line 3) and causes TCP A to generate a RST (the ACK in line 3 is not accepta
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 80, nit:
> d, its TCP implementation SHOULD send a RST to show that data was lost (SHLD-
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.7.1. , paragraph 9, nit:
>  not support attachment to links with a MTU greater than 65,575 [5], and the
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.7.5. , paragraph 2, nit:
> s of the SYN segment or by receipt of a RST segment or an ICMP Port Unreachab
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.8.2. , paragraph 4, nit:
> tion, or at least to determine whether or not more urgent data remains to be
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 3.8.3. , paragraph 2, nit:
> hat all have the same sequence number so there will be no way to reorder them
>                                      ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Section 3.8.3. , paragraph 6, nit:
> g accepted that much data. This, so called "shrinking the window," is strong
>                                  ^^^^^^^^^
The expression "so-called" is usually spelled with a hyphen.

Section 3.8.6.2.1. , paragraph 17, nit:
> he operating system will verify the users authority to open a connection with
>                                    ^^^^^
An apostrophe may be missing.

Section 3.8.6.2.2. , paragraph 4, nit:
> ction name can then be used as a short hand term for the connection defined
>                                  ^^^^^^^^^^
This word is normally spelled as one.

Section 3.9.1. , paragraph 27, nit:
> he user level protocol is not well thought out) that the closing side is una
>                              ^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 3.9.2. , paragraph 7, nit:
> aiting delivery, the RECEIVE will get a "error: connection closing" response
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.1. , paragraph 2, nit:
> , this is an error and should receive a "error: connection closing" response
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.2. , paragraph 11, nit:
> arded. An incoming segment containing a RST is discarded. An incoming segment
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.2. , paragraph 11, nit:
> . An incoming segment not containing a RST causes a RST to be sent in respon
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.3. , paragraph 1, nit:
> g segment not containing a RST causes a RST to be sent in response. The ackn
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.10.1. , paragraph 3, nit:
> ED state, delete TCB, and return. Otherwise (no ACK) drop the segment and ret
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Otherwise".

Section 3.10.1. , paragraph 3, nit:
> o ACK, and the segment did not contain a RST. - If the SYN bit is on and the
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.10.1. , paragraph 6, nit:
>  generate an acknowledgement in the later processing steps, saving this extra
>                                    ^^^^^
Did you mean "latter" (=the second of two items)?

Section 3.10.7.4. , paragraph 30, nit:
> aining sequence numbers entirely outside of this range are considered duplic
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 3.10.7.4. , paragraph 32, nit:
> a segment containing RST give rise to a RST in response. SEG.ACK segment ack
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.10.7.4. , paragraph 83, nit:
>  573: Reported by Bob Braden (note: This errata basically is just a reminder
>                                    ^^^^
The demonstrative "This" may not agree with the plural noun "errata". Did you
mean "these"?

Section 3.10.7.4. , paragraph 83, nit:
>  of the "functional specification". Also the 1122 text on the retransmission
>                                    ^^^^
A comma may be missing after the conjunctive/linking adverb "Also".

Section 3.10.7.4. , paragraph 102, nit:
> discussion in 2015 also indicated that that we should not try to add sections
>                                  ^^^^^^^^^
Possible typo: you repeated a word.

Section 5. , paragraph 2, nit:
> firewalls, and other technologies outside of the end-host TCP implementation.
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 8. , paragraph 2, nit:
> beneficial to consider. A.4. Low Water Mark Settings Some operating system ke
>                                  ^^^^^^^^^^
This is normally spelled as one word.

Reference [20] to RFC1644, which was obsoleted by RFC6247 (this may be on
purpose).

Reference [17] to RFC896, which was obsoleted by RFC7805 (this may be on
purpose).

Reference [19] to RFC1349, which was obsoleted by RFC2474 (this may be on
purpose).

These URLs in the document did not return content:
* http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-edo-10.txt
* http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-04.txt
* http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seccomp-prec-00.txt

[Ballot comment]
[ general ]

* Thanks for all this.

* I had several questions around "security/compartment" test, but
  Appendix A.1 was very helpful.

* I debated whether or not the source routing stuff (3.9.2.1) should rise
  to the level of a DISCUSS or not.  Please let me know what you think.

[S2, nit]

* "including examples of A, B, C" -> "A, B, and C", perhaps

[S3.1, nit]

* Urgent Pointer, "is only be interpreted"

  -> "is only to be interpreted"
  -> "is only interpreted"

  or something

[S3.3.2, nit]

* "These transitions are not not explicitly shown" -> double (k)not?

[S3.4, nit]

* "on an incoming segments" -> "on an incoming segment", perhaps

[S3.5, question]

* Is there an example of what possible use a RST w/ data could serve?

  I didn't see anything in S3.10.7(.*) that indicated the data in a segment
  with the RST flag set could get processed (I may have missed it).

[S3.7.1, comment]

* In networks where NAT64 is employed, the default MSS assumed by a sender
  will differ from the default assumed by a receiver, since the address
  families sent and received will be different.

  This may bolster the case for MAY-3 being a SHOULD (or even a MUST ;-) but,
  more to the point, may be a caveat to note w.r.t. SHLD-5.

  Alas, I could find no discussion of MSS option handling in RFC 6146,
  so I wonder if that's something that we missed...

[S3.9.1, nit]

* "use the same local address is used that was used" ->
  "use the same local address that was used", perhaps

[S3.9.2.1]

* I feel like there should be some additional caveat about security
  implications of support for source routing.  RFC 6274, for example, says
  packets with LSRR (6274s3.13.2.3) and SSRR (6274s3.13.2.4) options should
  be dropped, citing various security concerns.

  I'm not sure there needs to be a lot of text; perhaps just an observation
  that some end systems may not support the source route semantics described
  here for security (or policy) reasons?

[S3.9.2.2]

* I feel like ICMPv6 DestUnreach 2 and 4 should be treated as hard errors,
  but haven't found any explicit documentation yet.  Was the intention here
  to imply that ICMP DU 2-4 includes both ICMPv4 and v6, or just ICMPv4?
  If the latter, should we make a statement about ICMPv6?

 
  My expectation doesn't exactly line up with Linux's icmpv6_err_convert()
  behavior, it seems.
 

  I'm fine with the text as is -- given that the TCP/IPv6 Internet generally
  functions just fine today :-) -- just curious for the sake of clarification.

[S3.10.{1,2}, nit]

* These sections introduce "foreign socket" whereas I believe all other
  mentions are "remote socket" (and, indeed, the error strings also say
  "remote socket").

  Maybe s/foreign/remote/g ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tcpm-rfc793bis-24. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Transmission Control Protocol (TCP) Header Flags registry located at:

https://www.iana.org/assignments/tcp-header-flags/

The "Bit" column is renamed below as the "Bit Offset" column.

A new column will be added to the registry called "Assignment Notes".

The registry will be repopulated as follows:

Bit Name Reference Assignment Notes
Offset
--- ---- --------- ----------------
4 Reserved for future use [ RFC-To-be ]
5 Reserved for future use [ RFC-To-be ]
6 Reserved for future use [ RFC-To-be ]
7 Reserved for future use [RFC8311] Previously used by Historic [RFC3540] as NS (Nonce Sum)
8 CWR (Congestion Window Reduced) [RFC3168]
9 ECE (ECN-Echo) [RFC3168]
10 Urgent Pointer field is significant (URG) [ RFC-To-be ]
11 Acknowledgment field is significant (ACK) [ RFC-To-be ]
12 Push Function (PSH) [ RFC-To-be ]
13 Reset the connection (RST) [ RFC-To-be ]
14 Synchronize sequence numbers (SYN) [ RFC-To-be ]
15 No more data from sender (FIN) [ RFC-To-be ]

The registry is to be moved from the existing, standalone page at:

https://www.iana.org/assignments/tcp-header-flags/

to the Transmission Control Protocol (TCP) Parameters registry page located at:

https://www.iana.org/assignments/tcp-parameters/

The reference for the registry will be changed to [ RFC-to-be ].

The existing note for the registry will be removed.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-08-02):

From: The IESG
To: IETF-Announce
CC: Michael Scharf , draft-ietf-tcpm-rfc793bis@ietf.org, martin.h.duke@gmail.com, michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org, tcpm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Transmission Control Protocol (TCP) Specification) to Internet Standard


The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'Transmission Control
Protocol (TCP) Specification'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-08-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the Transmission Control Protocol (TCP).  TCP
  is an important transport layer protocol in the Internet protocol
  stack, and has continuously evolved over decades of use and growth of
  the Internet.  Over this time, a number of changes have been made to
  TCP as it was specified in RFC 793, though these have only been
  documented in a piecemeal fashion.  This document collects and brings
  those changes together with the protocol specification from RFC 793.
  This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
  6429, 6528, and 6691 that updated parts of RFC 793.  It updates RFC
  1122, and should be considered as a replacement for the portions of
  that document dealing with TCP requirements.  It also updates RFC
  5961 by adding a small clarification in reset handling while in the
  SYN-RECEIVED state.  The TCP header control bits from RFC 793 have
  also been updated based on RFC 3168.

  RFC EDITOR NOTE: If approved for publication as an RFC, this should
  be marked additionally as "STD: 7" and replace RFC 793 in that role.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6633: Deprecation of ICMP Source Quench Messages (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc6298: Computing TCP's Retransmission Timer (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc5681: TCP Congestion Control (Draft Standard - Internet Engineering Task Force (IETF))
    rfc3168: The Addition of Explicit Congestion Notification (ECN) to IP (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc2675: IPv6 Jumbograms (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc1191: Path MTU discovery (Draft Standard - Legacy stream)

1. Summary

The document shepherd is Michael Scharf .

The responsible Area Director is Martin Duke .

This document specifies the Transmission Control Protocol (TCP) as "bis" document to RFC 793. It obsoletes RFC 793 as well as a several other RFCs that specified additions to RFC 793. It also updates RFC 1122, and it should be considered as a replacement for the portions of that document dealing with TCP requirements.

The purpose of this document is to bring together all the IETF Standards Track changes that have been made to the base TCP functional specification and unify them into an update of RFC 793. The document focuses on the common basis all TCP implementations must support to interoperate. With one exception, protocol modifications compared to RFC 793 are limited to standards-track RFCs or verified erratas, i.e., changes of TCP standards that already have IETF consensus.

RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The same applies to 793bis. The TCPM working group requests publication of 793bis on Standards Track. If approved, the document should replace RFC 793 as "STD 7".


2. Review and Consensus

The TCPM working group has worked on this document for more than 6 years, and many TCPM contributors have reviewed the specification during that time. In particular, many TCP implementers have provided detailed comments based on operational experience. The document was relatively stable in the latest versions. During and after WGLC, several comprehensive reviews flagged some open issues that all got resolved.

793bis improves the specification of TCP but it does not modify the TCP protocol. TCP is a complex protocol and even minor wording details in the protocol specification can matter. Given the restriction to TCP changes that already have IETF consensus, there has never been any major controversy about the main content.

Nonetheless, several questions were non-trivial and triggered longer discussions in TCPM. These issues can roughly be subdivided in three categories:

1/ Being published in 1981, RFC 793 defines several protocol mechanisms that have become outdated and may not be implemented at all in a modern TCP/IP stack. However, in some cases the corresponding specification in RFC 793 never got updated or obsoleted and is still formally valid. Appendix A.1 summarizes some of these issues. The TCPM consensus for those cases is to document the issues in 793bis, but not to change the TCP standards. The required changes to the TCP standards should be handled by dedicated, narrow-focused RFCs that would have to reach IETF consensus first. This de-risk strategy ensures that each TCP protocol change can be properly and comprehensively reviewed.

2/ There are some known issues in the standards-track specification of TCP that exist but only matter in corner cases. An example is documented in Appendix A.2. In Internet usage of TCP, these conditions are rarely occurring. Common operating systems include different alternative mitigations, and the standard has not been updated yet to codify one of them. Also, there is no known best approach. Given the lack of practical relevance, the TCPM consensus is to describe these known problems, but not to change the TCP standards in 793bis. Again, these problems could be solved by future, dedicated, narrow-focused RFCs that would have to reach IETF consensus first.

3/ There are known deviations between mandatory-to-implement requirements in the TCP standard and some widely deployed implementations. An example are some details in Section 3.8.3, such as the numerical value in MUST-23. Those cases typically do not affect interoperability with other implementations. The TCPM working group has discussed whether to change the standard in such cases (e.g., downgrade MUST-23 to a SHOULD), but finally refrained from going down that road in 793bis, given the huge installed base with a very large variety of TCP implementations. Similar like in the previous cases, 793bis may get updated by narrow-focused RFCs.

There is one important exception to the decision not to include new guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion Control". TCP congestion control was developed after publication of RFC 793 and the state-of-the-art has evolved a lot as compared to RFC 1122. While there are numerous RFCs that specify TCP congestion control, there is no clear normative guidance on the required minimum in all TCP implementations that would be appropriate for 793bis. However, 793bis cannot just stay silent on congestion control. Given the lack of other applicable wording in existing standards, Section 3.8.2 includes new text and is therefore different to the rest of the document. Section 3.8.2 was comprehensively reviewed by the TCPM working group and in particular by TCP implementers. The section is short and straightforward, and the wording was chosen very carefully to reflect existing TCP standards and operational experience in the Internet. Also, given ongoing research, TCP congestion control will most likely further evolve in future. Section 3.8.2 enables such a further evolution while defining important base requirements.

Running code exists - in billions of devices across numerous TCP/IP stacks. Given the very limited scope of modifications in the 793bis document, all TCP implementations that are already compliant to the TCP standards before publication of 793bis should be compliant to 793bis as well.

The shepherd believes that the 793bis document has unanimous support from the entire TCPM working group.


3. Intellectual Property

The editor has stated that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. The editor is not aware of any IPR relevant for the base TCP protocol. Since 793bis does not change the TCP protocol, relevant IPR would have to be disclosed already for the existing RFCs included in 793bis.

There is a Cisco IPR disclosure from year 2004 related to the Internet-Draft that resulted in RFC 5961 (https://datatracker.ietf.org/ipr/421/). RFC 5961 is one source of changes included in 793bis. In all places in 793bis where the recommendations from RFC 5961 are mentioned, 5961 is prominently referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes described in RFC 5961 are optional and not mandatory-to-implement.

It has been suggested that the owner of the IPR disclosed in https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure to make clear whether it applies to 793bis, or not.

The TCPM working group is aware of the IPR disclosure related to RFC 5961, which is known already for a long time. The document shepherd has verified on the TCPM mailing list that the TCPM working group is fine with the proposed text in 793bis related to RFC 5961. In the TCPM working group there are no known concerns regarding this IPR disclosure related to an optional mechanism.


4. Other Points

The intended status listed in the document is "Standards Track". As all main TCP implementations are supposed to comply with 793bis, the document may fulfill the requirements of an "Internet Standard" according to RFC 2026 and RFC 7127.

idnits reports some warnings, such as obsolete references. These are all false positives. The document refers to some obsolete documents to provide historical context.

The IANA section includes many actions:
(1) Update the structure of the TCP flags registry to include a new column called "Assignment Notes"
(2) Rename "Bit" column of the TCP flags registry to "Bit Offset"
(3) Update the TCP flags registry to include all assigned TCP flags, not only those initially assigned in RFC 3168. 10-15 values are assigned.
(4) Move the existing TCP flags registry to be as sub-registry of the TCP registry.
There was unanimous consensus in TCPM with these changes. The modifications neither change any allocation nor any policy in the IANA registry.

All errata to RFC 793 and related RFCs have been considered in this "bis" document.

When Wes started working on a 793bis document in 2013, the document shepherd, as well as many other TCPM contributors, were pretty convinced that writing a 793bis document is an impossible endeavor. Well, after many years, we are proven wrong. Many thanks to Wes as editor!

1. Summary

The document shepherd is Michael Scharf .

The responsible Area Director is Martin Duke .

This document specifies the Transmission Control Protocol (TCP) as "bis" document to RFC 793. It obsoletes RFC 793 as well as a several other RFCs that specified additions to RFC 793. It also updates RFC 1122, and it should be considered as a replacement for the portions of that document dealing with TCP requirements.

The purpose of this document is to bring together all the IETF Standards Track changes that have been made to the base TCP functional specification and unify them into an update of RFC 793. The document focuses on the common basis all TCP implementations must support to interoperate. With one exception, protocol modifications compared to RFC 793 are limited to standards-track RFCs or verified erratas, i.e., changes of TCP standards that already have IETF consensus.

RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The same applies to 793bis. The TCPM working group requests publication of 793bis on Standards Track. If approved, the document should replace RFC 793 as "STD 7".


2. Review and Consensus

The TCPM working group has worked on this document for more than 6 years, and many TCPM contributors have reviewed the specification during that time. In particular, many TCP implementers have provided detailed comments based on operational experience. The document was relatively stable in the latest versions. During and after WGLC, several comprehensive reviews flagged some open issues that all got resolved.

793bis improves the specification of TCP but it does not modify the TCP protocol. TCP is a complex protocol and even minor wording details in the protocol specification can matter. Given the restriction to TCP changes that already have IETF consensus, there has never been any major controversy about the main content.

Nonetheless, several questions were non-trivial and triggered longer discussions in TCPM. These issues can roughly be subdivided in three categories:

1/ Being published in 1981, RFC 793 defines several protocol mechanisms that have become outdated and may not be implemented at all in a modern TCP/IP stack. However, in some cases the corresponding specification in RFC 793 never got updated or obsoleted and is still formally valid. Appendix A.1 summarizes some of these issues. The TCPM consensus for those cases is to document the issues in 793bis, but not to change the TCP standards. The required changes to the TCP standards should be handled by dedicated, narrow-focused RFCs that would have to reach IETF consensus first. This de-risk strategy ensures that each TCP protocol change can be properly and comprehensively reviewed.

2/ There are some known issues in the standards-track specification of TCP that exist but only matter in corner cases. An example is documented in Appendix A.2. In Internet usage of TCP, these conditions are rarely occurring. Common operating systems include different alternative mitigations, and the standard has not been updated yet to codify one of them. Also, there is no known best approach. Given the lack of practical relevance, the TCPM consensus is to describe these known problems, but not to change the TCP standards in 793bis. Again, these problems could be solved by future, dedicated, narrow-focused RFCs that would have to reach IETF consensus first.

3/ There are known deviations between mandatory-to-implement requirements in the TCP standard and some widely deployed implementations. An example are some details in Section 3.8.3, such as the numerical value in MUST-23. Those cases typically do not affect interoperability with other implementations. The TCPM working group has discussed whether to change the standard in such cases (e.g., downgrade MUST-23 to a SHOULD), but finally refrained from going down that road in 793bis, given the huge installed base with a very large variety of TCP implementations. Similar like in the previous cases, 793bis may get updated by narrow-focused RFCs.

There is one important exception to the decision not to include new guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion Control". TCP congestion control was developed after publication of RFC 793 and the state-of-the-art has evolved a lot as compared to RFC 1122. While there are numerous RFCs that specify TCP congestion control, there is no clear normative guidance on the required minimum in all TCP implementations that would be appropriate for 793bis. However, 793bis cannot just stay silent on congestion control. Given the lack of other applicable wording in existing standards, Section 3.8.2 includes new text and is therefore different to the rest of the document. Section 3.8.2 was comprehensively reviewed by the TCPM working group and in particular by TCP implementers. The section is short and straightforward, and the wording was chosen very carefully to reflect existing TCP standards and operational experience in the Internet. Also, given ongoing research, TCP congestion control will most likely further evolve in future. Section 3.8.2 enables such a further evolution while defining important base requirements.

Running code exists - in billions of devices across numerous TCP/IP stacks. Given the very limited scope of modifications in the 793bis document, all TCP implementations that are already compliant to the TCP standards before publication of 793bis should be compliant to 793bis as well.

The shepherd believes that the 793bis document has unanimous support from the entire TCPM working group.


3. Intellectual Property

The editor has stated that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. The editor is not aware of any IPR relevant for the base TCP protocol. Since 793bis does not change the TCP protocol, relevant IPR would have to be disclosed already for the existing RFCs included in 793bis.

There is a Cisco IPR disclosure from year 2004 related to the Internet-Draft that resulted in RFC 5961 (https://datatracker.ietf.org/ipr/421/). RFC 5961 is one source of changes included in 793bis. In all places in 793bis where the recommendations from RFC 5961 are mentioned, 5961 is prominently referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes described in RFC 5961 are optional and not mandatory-to-implement.

It has been suggested that the owner of the IPR disclosed in https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure to make clear whether it applies to 793bis, or not.

The TCPM working group is aware of the IPR disclosure related to RFC 5961, which is known already for a long time. The document shepherd has verified on the TCPM mailing list that the TCPM working group is fine with the proposed text in 793bis related to RFC 5961. In the TCPM working group there are no known concerns regarding this IPR disclosure related to an optional mechanism.


4. Other Points

The intended status listed in the document is "Standards Track". As all main TCP implementations are supposed to comply with 793bis, the document may fulfill the requirements of an "Internet Standard" according to RFC 2026 and RFC 7127.

idnits reports some warnings, such as obsolete references. These are all false positives. The document refers to some obsolete documents to provide historical context.

The IANA section includes many actions:
(1) Update the structure of the TCP flags registry to include a new column called "Assignment Notes"
(2) Rename "Bit" column of the TCP flags registry to "Bit Offset"
(3) Update the TCP flags registry to include all assigned TCP flags, not only those initially assigned in RFC 3168. 10-15 values are assigned.
(4) Move the existing TCP flags registry to be as sub-registry of the TCP registry.
There was unanimous consensus in TCPM with these changes. The modifications neither change any allocation nor any policy in the IANA registry.

All errata to RFC 793 and related RFCs have been considered in this "bis" document.

When Wes started working on a 793bis document in 2013, the document shepherd, as well as many other TCPM contributors, were pretty convinced that writing a 793bis document is an impossible endeavor. Well, after many years, we are proven wrong. Many thanks to Wes as editor!

1. Summary

The document shepherd is Michael Scharf .

The responsible Area Director is Martin Duke .

This document specifies the Transmission Control Protocol (TCP) as "bis" document to RFC 793. It obsoletes RFC 793 as well as a several other RFCs that specified additions to RFC 793. It also updates RFC 1122, and it should be considered as a replacement for the portions of that document dealing with TCP requirements.

The purpose of this document is to bring together all the IETF Standards Track changes that have been made to the base TCP functional specification and unify them into an update of RFC 793. The document focuses on the common basis all TCP implementations must support to interoperate. With one exception, protocol modifications compared to RFC 793 are limited to standards-track RFCs or verified erratas, i.e., changes of TCP standards that already have IETF consensus.

RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The same applies to 793bis. The TCPM working group requests publication of 793bis on Standards Track. If approved, the document should replace RFC 793 as "STD 7".


2. Review and Consensus

The TCPM working group has worked on this document for more than 6 years, and many TCPM contributors have reviewed the specification during that time. In particular, many TCP implementers have provided detailed comments based on operational experience. The document was relatively stable in the latest versions. During and after WGLC, several comprehensive reviews flagged some open issues that all got resolved.

793bis improves the specification of TCP but it does not modify the TCP protocol. TCP is a complex protocol and even minor wording details in the protocol specification can matter. Given the restriction to TCP changes that already have IETF consensus, there has never been any major controversy about the main content.

Nonetheless, several questions were non-trivial and triggered longer discussions in TCPM. These issues can roughly be subdivided in three categories:

1/ Being published in 1981, RFC 793 defines several protocol mechanisms that have become outdated and may not be implemented at all in a modern TCP/IP stack. However, in some cases the corresponding specification in RFC 793 never got updated or obsoleted and is still formally valid. Appendix A.1 summarizes some of these issues. The TCPM consensus for those cases is to document the issues in 793bis, but not to change the TCP standards. The required changes to the TCP standards should be handled by dedicated, narrow-focused RFCs that would have to reach IETF consensus first. This de-risk strategy ensures that each TCP protocol change can be properly and comprehensively reviewed.

2/ There are some known issues in the standards-track specification of TCP that exist but only matter in corner cases. An example is documented in Appendix A.2. In Internet usage of TCP, these conditions are rarely occurring. Common operating systems include different alternative mitigations, and the standard has not been updated yet to codify one of them. Also, there is no known best approach. Given the lack of practical relevance, the TCPM consensus is to describe these known problems, but not to change the TCP standards in 793bis. Again, these problems could be solved by future, dedicated, narrow-focused RFCs that would have to reach IETF consensus first.

3/ There are known deviations between mandatory-to-implement requirements in the TCP standard and some widely deployed implementations. An example are some details in Section 3.8.3, such as the numerical value in MUST-23. Those cases typically do not affect interoperability with other implementations. The TCPM working group has discussed whether to change the standard in such cases (e.g., downgrade MUST-23 to a SHOULD), but finally refrained from going down that road in 793bis, given the huge installed base with a very large variety of TCP implementations. Similar like in the previous cases, 793bis may get updated by narrow-focused RFCs.

There is one important exception to the decision not to include new guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion Control". TCP congestion control was developed after publication of RFC 793 and the state-of-the-art has evolved a lot as compared to RFC 1122. While there are numerous RFCs that specify TCP congestion control, there is no clear normative guidance on the required minimum in all TCP implementations that would be appropriate for 793bis. However, 793bis cannot just stay silent on congestion control. Given the lack of other applicable wording in existing standards, Section 3.8.2 includes new text and is therefore different to the rest of the document. Section 3.8.2 was comprehensively reviewed by the TCPM working group and in particular by TCP implementers. The section is short and straightforward, and the wording was chosen very carefully to reflect existing TCP standards and operational experience in the Internet. Also, given ongoing research, TCP congestion control will most likely further evolve in future. Section 3.8.2 enables such a further evolution while defining important base requirements.

Running code exists - in billions of devices across numerous TCP/IP stacks. Given the very limited scope of modifications in the 793bis document, all TCP implementations that are already compliant to the TCP standards before publication of 793bis should be compliant to 793bis as well.

The shepherd believes that the 793bis document has unanimous support from the entire TCPM working group.


3. Intellectual Property

The editor has stated that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. The editor is not aware of any IPR relevant for the base TCP protocol. Since 793bis does not change the TCP protocol, relevant IPR would have to be disclosed already for the existing RFCs included in 793bis.

There is a Cisco IPR disclosure from year 2004 related to the Internet-Draft that resulted in RFC 5961 (https://datatracker.ietf.org/ipr/421/). RFC 5961 is one source of changes included in 793bis. In all places in 793bis where the recommendations from RFC 5961 are mentioned, 5961 is prominently referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes described in RFC 5961 are optional and not mandatory-to-implement.

It has been suggested that the owner of the IPR disclosed in https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure to make clear whether it applies to 793bis, or not.

The TCPM working group is aware of the IPR disclosure related to RFC 5961, which is known already for a long time. The document shepherd has verified on the TCPM mailing list that the TCPM working group is fine with the proposed text in 793bis related to RFC 5961. In the TCPM working group there are no known concerns regarding this IPR disclosure related to an optional mechanism.


4. Other Points

The intended status listed in the document is "Proposed Standard". As all main TCP implementations are supposed to comply with 793bis, the document may fulfill the requirements of an "Internet Standard" according to RFC 2026 and RFC 7127.

idnits reports some warnings, such as obsolete references. These are all false positives. The document refers to some obsolete documents to provide historical context.

The IANA section includes many actions:
(1) Update the structure of the TCP flags registry to include a new column called "Assignment Notes"
(2) Rename "Bit" column of the TCP flags registry to "Bit Offset"
(3) Update the TCP flags registry to include all assigned TCP flags, not only those initially assigned in RFC 3168. 10-15 values are assigned.
(4) Move the existing TCP flags registry to be as sub-registry of the TCP registry.
There was unanimous consensus in TCPM with these changes. The modifications neither change any allocation nor any policy in the IANA registry.

All errata to RFC 793 and related RFCs have been considered in this "bis" document.

When Wes started working on a 793bis document in 2013, the document shepherd, as well as many other TCPM contributors, were pretty convinced that writing a 793bis document is an impossible endeavor. Well, after many years, we are proven wrong. Many thanks to Wes as editor!