Re: [tcpm] On allocating reserved bits in the TCP header

Bob Briscoe <> Sun, 03 November 2019 22:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A26991200F7 for <>; Sun, 3 Nov 2019 14:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lud74ka8nEjU for <>; Sun, 3 Nov 2019 14:04:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1613F1200C1 for <>; Sun, 3 Nov 2019 14:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DyN1FJDqptHIEVNKYxmo328Z7QLGfSprxjEXJtjFi+M=; b=lySBBfOsXYSrh2Nu55i7PaIt/ zCgUDs+MJXKjKPihgLuEYaqyXCPzGRWsF0iwxcuaojsCCaogJ3HvSdcKBLUYSt4cWs8dpoAFdvYkC 7Uu5XV9skM5RFYSo9ylmTPgri4eiaJ1jaiP5Xd6+QMwBwiU4t5I59a0C63Xtmb/BsXJCfR9xPY3xq D898B3PEASyiFYWjQbi+D1rAj3lsz/OqLfzMK2zmbA8N3aqby5yzYeJkgQVcduHZlvdmrBhw8r8h6 Apkq8QbnzpsgHVYPD6tDcLx3ro7kdHsWPCTeXPl7JpKLt8c1rSNInICFWhgYx9rGxIgtrXSg5dAfB Zf1tK/L/g==;
Received: from [] (port=34872 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iRNyq-0002Wy-67; Sun, 03 Nov 2019 22:04:16 +0000
To: "Scharf, Michael" <>
Cc: "" <>, Mirja Kuehlewind <>, Richard Scheffenegger <>
References: <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Sun, 3 Nov 2019 22:04:14 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------480D087E8E98C4C469349A13"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tcpm] On allocating reserved bits in the TCP header
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: Sun, 03 Nov 2019 22:04:21 -0000


On 03/10/2019 12:31, Lars Eggert wrote:
> On 2019-9-10, at 13:50, Scharf, Michael <> wrote:
>> In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules.
> Agreed.
> Lars

If asked this question in isolation, I would go for a quick RFC. But 
this is not in isolation.

The decision on what process to use has already been made - in Jul 2017 
at IETF-99 (it was for the IESG to be asked to make a process 
exception). This is just a choice between processes. There's no 
difference to the technical outcome. Please can we just do it the way we 
already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a referendum 
decision 'cos they didn't get what they wanted in the previous one.

This issue was extensively discussed already. After a long offlist 
thread with the author of RFC8311 and others, a thread on tsvwg ran betw 
3 to 12 Jul 17:
This thread ends by deferring to a meeting arranged at IETF-99 during AD 
Office Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit 
7 and assign it to itself, which would need the IESG to agree a process 
exception. That outcome was recorded on this slide for discussion in the 
subsequent tcpm WG meeting:
The tcpm minutes here:
record that "There is strong but not unanimous consensus in the room for 
assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be 
asked to make a process exception.

I didn't like that decision either, but this is just process. Can we 
move on please.


Bob Briscoe