Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-24.txt
Wesley Eddy <wes@mti-systems.com> Mon, 12 July 2021 19:05 UTC
Return-Path: <wes@mti-systems.com>
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 <tcpm@ietfa.amsl.com>; 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 <tcpm@ietfa.amsl.com>; 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 <tcpm@ietf.org>; Mon, 12 Jul 2021 12:03:06 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id h9so5142937qvs.0 for <tcpm@ietf.org>; 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 <tcpm@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 12:03:03 -0700 (PDT)
From: Wesley Eddy <wes@mti-systems.com>
To: tcpm@ietf.org
References: <162611569026.7615.3785325543750944369@ietfa.amsl.com> <9f310fe4-1e50-4a94-5ac2-c3eeac4feba6@mti-systems.com>
Message-ID: <c8d11b85-f345-4dd0-f3bb-20855825a823@mti-systems.com>
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: <https://mailarchive.ietf.org/arch/msg/tcpm/rGerZEn91PBaBPQUP-oWmzysL4M>
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2021 19:05:27 -0000
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
- [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-24.t… internet-drafts
- Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-… Wesley Eddy
- Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-… Wesley Eddy
- Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-… Martin Duke
- [tcpm] 793bis and RFC3168 tom petch
- Re: [tcpm] 793bis and RFC3168 Gorry Fairhurst
- Re: [tcpm] 793bis and RFC3168 t petch
- Re: [tcpm] 793bis and RFC3168 Gorry Fairhurst
- Re: [tcpm] 793bis and RFC3168 Wesley Eddy
- Re: [tcpm] 793bis and RFC3168 Scharf, Michael
- Re: [tcpm] 793bis and RFC3168 Martin Duke