[tcpm] draft-ietf-tcpm-rfc793bis-14: Section 3.4

<mohamed.boucadair@orange.com> Wed, 31 July 2019 06:58 UTC

Return-Path: <mohamed.boucadair@orange.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 71308120052 for <tcpm@ietfa.amsl.com>; Tue, 30 Jul 2019 23:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 gGqS5uo6jk4P for <tcpm@ietfa.amsl.com>; Tue, 30 Jul 2019 23:58:34 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E3312001B for <tcpm@ietf.org>; Tue, 30 Jul 2019 23:58:33 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 45z45M6wKkz1010; Wed, 31 Jul 2019 08:58:31 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 45z45M6FQYzDq85; Wed, 31 Jul 2019 08:58:31 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 08:58:31 +0200
From: <mohamed.boucadair@orange.com>
To: Wesley Eddy <wes@mti-systems.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: draft-ietf-tcpm-rfc793bis-14: Section 3.4
Thread-Index: AdVHbVmgxKjaWGDtTrKw8iUTgk+X9A==
Date: Wed, 31 Jul 2019 06:58:30 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312EB757@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/oQBs17Z6Kl9q1PiiOdQK4ZxuRfQ>
Subject: [tcpm] draft-ietf-tcpm-rfc793bis-14: Section 3.4
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: Wed, 31 Jul 2019 06:58:37 -0000

Re-,

Can we update this text as follows: 

OLD:

   Several examples of connection initiation follow.  Although these
   examples do not show connection synchronization using data-carrying
   segments, this is perfectly legitimate, so long as the receiving TCP
   doesn't deliver the data to the user until it is clear the data is
   valid (i.e., the data must be buffered at the receiver until the
          ^^^^           ^^^^^^^
   connection reaches the ESTABLISHED state).  The three-way handshake
                                           ^^^^
   reduces the possibility of false connections.  It is the
   implementation of a trade-off between memory and messages to provide
   information for this checking.

NEW:

   Several examples of connection initiation follow.  Although these
   examples do not show connection synchronization using data-carrying
   segments, this is perfectly legitimate, so long as the receiving TCP
   doesn't deliver the data to the user until it is clear the data is
   valid (e.g., the data is buffered at the receiver until the
          ^^^^           ^^
   connection reaches the ESTABLISHED state given that the three-way handshake
                                            ^^^^^^^^^^^^
   reduces the possibility of false connections).  It is the
   implementation of a trade-off between memory and messages to provide
   information for this checking.


Rationale: 
* The key requirement is: "doesn't deliver the data to the user until it is clear the data is valid". This one is maintained as it is. 
* Waiting for the 3HWS completion is only an example to fulfil the above requirement.
* Allow for future 0-RTT validation methods without requiring an update to RFC793bis: For example, if TFO is promoted to Standard track, there won't be a need to update RFC793bis.

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de
> internet-drafts@ietf.org
> Envoyé : mardi 30 juillet 2019 19:47
> À : i-d-announce@ietf.org
> Cc : tcpm@ietf.org
> Objet : I-D Action: draft-ietf-tcpm-rfc793bis-14.txt
> 
> 
> 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 Specification
>         Author          : Wesley M. Eddy
> 	Filename        : draft-ietf-tcpm-rfc793bis-14.txt
> 	Pages           : 104
> 	Date            : 2019-07-30
> 
> Abstract:
>    This document specifies the Internet's Transmission Control Protocol
>    (TCP).  TCP is an important transport layer protocol in the Internet
>    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 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 updates RFC 5961 due to a
>    small clarification in reset handling while in the SYN-RECEIVED
>    state.
> 
>    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 are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-14
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-14
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt