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

Bob Briscoe <> Mon, 04 November 2019 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E46E41200E7 for <>; Mon, 4 Nov 2019 06:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 ZPeKa8Sxc4r6 for <>; Mon, 4 Nov 2019 06:10:17 -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 6025B120099 for <>; Mon, 4 Nov 2019 06:10:17 -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=fU6DuzkxkcsF6kUqyJX+VKGSkd/nE+qDMkae3fyzMrI=; b=62PsAfmLY1xtKmQaueoWIBagT iuPAl3vf2ecfHSGqswMFNpWYpZKlIPP1anv4fVHgKcZx8kq2PfjcleTpc1X5SXfX1xARrcdj4czIa LeFvzvATHcyYpkg1uf/3jkyu0HYzOajP5/+gXFTqVKN8kG0Z1Eo4DncSFzZbihZB2j9G4JsOAHcAc vkPqMfRhnuUprPAwJsMcnXkkQBufipRAhZHRrSYxZDoeTRxKpPY7xwYWqMMipMYiS6UGs5rSCAmul fDdBcvNbOCsk+FWNRHx0kYXCKFQZ+ZSuBz03h9mOg8bn5mbVdhi7uNxSMxUY9Yg5XQ3SPvVDP5g1M cnxXen0XQ==;
Received: from [] (port=46420 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iRd3f-0006vi-6t; Mon, 04 Nov 2019 14:10:15 +0000
To: "Scharf, Michael" <>
Cc: Richard Scheffenegger <>, "" <>, Mirja Kuehlewind <>
References: <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Mon, 4 Nov 2019 14:10: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="------------1CF86F3A5BA7C2124C4771B1"
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: Mon, 04 Nov 2019 14:10:21 -0000


At the time, I had collected a list of possible process options, 
collected from the preceding ML discussions. I preferred including the 
AccECN assignment in RFC8311 (which was ending WGLC at that time). I do 
not recall you agreeing with me, although you are now arguing for the 
same process, but with a new PS RFC.

Was the decision questioned at the time on the mailing list (2 years 
ago) when it would have been timely to do so?

One then has to ask what new situation has arisen that makes this 
decision need to be revisited.


On 04/11/2019 02:00, Scharf, Michael wrote:
> Bob,
> With chair hat on: There was a discussion „in the room“ during IETF 99 
> and the outcome of a hum „in the room“ is documented in the minutes. 
> In TCPM, consensus is confirmed on the list so that all contributors 
> can comment. Please don’t refer to room discussions as working group 
> „decisions“.
> With chair hat off, I believe there was never a formal consensus 
> decision in TCPM to explicitly violate RFCs. And, anyway, the working 
> group could change past decisions, at least prior to completing a 
> WGLC. In this specific case, as individual contributor, I explicitly 
> and very strongly disagree to move forward with an invalid IANA 
> considerations section.
> Thanks
> Michael
> *Von: *Bob Briscoe <>
> *Gesendet: *Sonntag, 3. November 2019 23:04
> *An: *Scharf, Michael <>
> *Cc: * <>; Mirja Kuehlewind 
> <>; Richard Scheffenegger 
> <>
> *Betreff: *Re: [tcpm] On allocating reserved bits in the TCP header
> Michael,
> 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.
> Background
> 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
> -- 
> ________________________________________________________________
> Bob Briscoe
> _______________________________________________
> tcpm mailing list

Bob Briscoe