Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-24.txt

From: [email-masked]
Date: Mon, 12 Jul 2021 11:48:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : Transmission Control Protocol (TCP) Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-24.txt
	Pages           : 108
	Date            : 2021-07-12

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-24

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-24

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 12 Jul 2021 14:57:35 -0400

This revision has changes resulting from Martin's AD review and 
subsequent comments from Yuchung and Joe.

A few things to specifically check over since I wasn't sure if the 
thread totally converged on them, and they should be confirmed:

(1) urgent pointer "receding"

I think the key to understand is that the only time an application can 
set this is when data is written, so it should not "recede" since you 
can't write backwards.   There was already a paragraph saying:

    To send an urgent indication the user must also send at least one
    data octet.

I'm not sure if this completely satisfies Martin's comment, but for now, 
I added this sentence:

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

(2) PUSH check in SWS timer expiration

I think Martin is right, and if the intention is that if the SWS timer 
expires, it's okay to send, even if PUSH isn't set.  This:

    or if data is PUSHed and the override timeout occurs.

was changed to:

    or if the override timeout occurs.

(3) unnecessary Step 4 for LISTEN state when SEGMENT ARRIVES

Changed:

          fourth other text or control

             Any other control or text-bearing segment (not containing
             SYN) must have an ACK and thus would be discarded by the ACK
             processing.  An incoming RST segment could not be valid,
             since it could not have been sent in response to anything
             sent by this incarnation of the connection.  So, if this
             unlikely condition is reached, the correct behavior is to
             drop the segment and return.

to:

       fourth other data or control

          This should not be reached.  Drop the segment and return.  Any
          other control or data-bearing segment (not containing SYN) must
          have an ACK and thus would have been discarded by the ACK
          processing in the second step, unless it was first discarded by
          RST checking in the first step.

Although maybe if we agree that it's totally pointless to have, then 
this "fourth" step can just be removed entirely.

On 7/12/2021 2:48 PM, [email-masked] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 12 Jul 2021 15:03:02 -0400

Sorry, one more thing to ask the working group ...

In a couple of places, Martin suggested changing "text" to "data".  I 
agree, this probably makes more sense to a modern reader and is merely 
editorial.

Should we change that not just in a couple of places Martin noted, but 
across the board in the document?

On 7/12/2021 2:57 PM, Wesley Eddy wrote:
> I'm not sure if this completely satisfies Martin's comment, but for 
> now, I added this sentence:
>

---

From: Martin Duke <[email-masked]>
Date: Thu, 15 Jul 2021 12:15:40 -0700

On Mon, Jul 12, 2021 at 11:57 AM Wesley Eddy <[email-masked]> wrote:

> I'm not sure if this completely satisfies Martin's comment, but for now, I
> added this sentence:
>
I am completely satisfied with this text. IMO 793 does not explicitly
prohibit receding, but it is a bad idea so we should discourage it, while
being robust to receiving it given an *extremely* small chance that some
implementation somewhere is doing it.