Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options

<> Thu, 01 August 2019 05:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65C2912006B for <>; Wed, 31 Jul 2019 22:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zYozBxk5JYLU for <>; Wed, 31 Jul 2019 22:38:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F2BF120059 for <>; Wed, 31 Jul 2019 22:38:50 -0700 (PDT)
Received: from (unknown [xx.xx.xx.64]) by (ESMTP service) with ESMTP id 45zfGw4kpkz1yj2; Thu, 1 Aug 2019 07:38:48 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by (ESMTP service) with ESMTP id 45zfGw3jJJzDq87; Thu, 1 Aug 2019 07:38:48 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 1 Aug 2019 07:38:48 +0200
From: <>
To: Joe Touch <>
CC: Wesley Eddy <>, "" <>
Thread-Topic: [tcpm] draft-ietf-tcpm-rfc793bis-14: options
Thread-Index: AQHVR9DoIsQIX4hpAESJdvivisWkpablvviA
Date: Thu, 1 Aug 2019 05:38:47 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312F7CAF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330312EB710@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330312F7CAFOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options
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: Thu, 01 Aug 2019 05:38:54 -0000

Hi Joe,

Please see inline.


De : Joe Touch []
Envoyé : mercredi 31 juillet 2019 20:51
Cc : Wesley Eddy;
Objet : Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options

Based on the defined scope and approach of 793bis, as stated in its intro:

On 2019-07-30 23:26, wrote:
Hi Wes,

Below some comments about the options as described in Section 3.1:

* Consider adding some text to ACK the TCP option space problem. Adding a pointer to EDO as * an example * (without recommending it) of how to extend the space for non-SYNs would be useful.

It would be useful to mention the ongoing work, but not to try to repeat it.

[Med] Yes, this is what I had in mind.

* Add an explicit statement about 253/254 as being reserved for experiments with a strong recommendation to make use of shared ExIDs.

It would be useful to note their being assigned for that purpose (not quite RESERVED)

[Med] Indeed.

and to ref 6994 for further details.

Given the focus of this updated is standards-track, it would be useful to remind developers not to deploy options using those codepoints outside carefully controlled experiments and that they are default to being not enabled in any code not under direct control of the developers.

[Med] Sounds reasonable.


* What about obsoleting (?) 6994 and incorporating its main contribution as part of 793bis?

I disagree. First, 6994 is not being obsoleted per se; second, others refer to its approach for other similar experimental fields. It would be a bad idea to try to "obsolete" it.

[Med] This is not a problem. These documents can refer to RFC793bis (if we go that path). BTW, please note (?) in my initial comment, so I’m fine if the WG decides to maintain it, but …

I also don't think it's useful to include these details inside 793bis

[Med] What I had in mind is to import the option layout and key information into 793bis. What I’m hoping with this change is to avoid having discussion similar to (end of the message) each time a new option is discussed.

- these are not details needed for standards-compliant operation

[Med] I’m not sure to parse this comment. RFC6994 is a standard track RFC.

(esp. because they shouldn't be used for final standards-track options).

IMO, 6994 is a lot like congestion control; OK, if not better, as a separate doc.

[Med] That’s OK to maintain it, but there is a value to extract the main messages and incorporate them into 793bis.



-----Message d'origine-----
De : I-D-Announce [<>] De la part de<>
Envoyé : mardi 30 juillet 2019 19:47
À :<>
Cc :<>
Objet : I-D Action: draft-ietf-tcpm-rfc793bis-14.txt

A New Internet-Draft is available from the on-line Internet-Drafts
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

   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

   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:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

I-D-Announce mailing list<>
Internet-Draft directories:

tcpm mailing list<>