From nobody Mon Jul 12 12:05:29 2021 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558F83A1007 for ; Mon, 12 Jul 2021 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNmMq9Hlh6q4 for ; Mon, 12 Jul 2021 12:05:24 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAA23A10BA for ; Mon, 12 Jul 2021 12:03:06 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id h9so5142937qvs.0 for ; Mon, 12 Jul 2021 12:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=naTurUeMONOPz9Znd6zYCJSuesj3PdHb1q8IYmszYjM=; b=tUpuMGbKeRR6jplnV1t6LDKSsz91/7rDUNLru4KnVPNjxSlnCLNVjwMpYPV09IKDyP RuhZJX5+3JAvHgQC7nmecoRjQy4oPTRrZtfA1F33q284oqWgucKO1EPJuA/KaIuotlR6 pdik4S/JjJh/oEi0oOfuXbM5zcm2Br+W2KmM/t47X0RdrWLyziaMhFaSYuh8VA5zcDqk aWQIsRVDcn7vE2OoQRnTmYw2JjK9k+hDwubojkfEllXwMWQKsm/lAfUYHWD1FZFbD5By c+NXarQB5p3JU0WxkYybkDH1Dh3fgXybfIEfOLAzKc2GBFvFr2TdIpR6sGu30OFcVYxl Es3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=naTurUeMONOPz9Znd6zYCJSuesj3PdHb1q8IYmszYjM=; b=SfrzUbfZMoSoAeel+KmFYjqgonfJmhI2fggplseX8BARrSLUPNZmDzWIuHD8pF+8tp TVHAzdhaJ+fSKEnmVCUvjrvhISxzMSCK4wXunARO2Xer+LEb5jS4LzvkNI50hhRmJJ6N sbhumwPU/DQrrfY/XZY8QJZ9ChaaCDSoAdLsABLZq0Fp1LqfIDOfVb52qSrbMdde8+KP TYYCl6xCyyHvWPoOeHdJGY0VkW849+fX9BETGVQ9w9oBMlF4DWrLOTKqSEqujYPXYQMu hPHiDIwYg+maYic/TGTmaWdu4PcZis3oSMlIE20bMcvDjNq/eI40Yb/7EDPI+DvqvAON jK7g== X-Gm-Message-State: AOAM533Cg7IUL+Ir9PGAO5+7ubs+TWaZfXK6mVkBXPg6gv17al5xBqOF TGa+ziTDLsNxQ+asMF7plNzzONqeavoCSAg2 X-Google-Smtp-Source: ABdhPJyhN41wNhKN3NGWdvecK1TJ5BTWXuJtC1OgIt8Uog1yFzR/YbGZr8v757d6WqitQ98ccDkabg== X-Received: by 2002:ad4:58a4:: with SMTP id ea4mr744156qvb.39.1626116584204; Mon, 12 Jul 2021 12:03:04 -0700 (PDT) Received: from [192.168.1.114] (069-135-001-122.biz.spectrum.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id v22sm4623915qkf.50.2021.07.12.12.03.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 12:03:03 -0700 (PDT) From: Wesley Eddy To: tcpm@ietf.org References: <162611569026.7615.3785325543750944369@ietfa.amsl.com> <9f310fe4-1e50-4a94-5ac2-c3eeac4feba6@mti-systems.com> Message-ID: Date: Mon, 12 Jul 2021 15:03:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <9f310fe4-1e50-4a94-5ac2-c3eeac4feba6@mti-systems.com> Content-Type: multipart/alternative; boundary="------------ADEA73B7D6C321FD9C1FF687" Content-Language: en-US Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-24.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 19:05:27 -0000 This is a multi-part message in MIME format. --------------ADEA73B7D6C321FD9C1FF687 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: > > 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, internet-drafts@ietf.org wrote: >> 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/ >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm --------------ADEA73B7D6C321FD9C1FF687 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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:

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, internet-drafts@ietf.org wrote:
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/


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--------------ADEA73B7D6C321FD9C1FF687--