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

Bob Briscoe <in@bobbriscoe.net> Sun, 03 November 2019 22:04 UTC

Return-Path: <in@bobbriscoe.net>
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 A26991200F7 for <tcpm@ietfa.amsl.com>; Sun, 3 Nov 2019 14:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 Lud74ka8nEjU for <tcpm@ietfa.amsl.com>; Sun, 3 Nov 2019 14:04:18 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1613F1200C1 for <tcpm@ietf.org>; Sun, 3 Nov 2019 14:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; 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 [31.185.128.31] (port=34872 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <in@bobbriscoe.net>) id 1iRNyq-0002Wy-67; Sun, 03 Nov 2019 22:04:16 +0000
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, Richard Scheffenegger <rscheff@gmx.at>
References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org>
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net>
Date: Sun, 03 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: <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org>
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 - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ip-3dYTSL3UJqeANZ3H7BAMJpLc>
Subject: Re: [tcpm] On allocating reserved bits in the TCP header
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: Sun, 03 Nov 2019 22:04:21 -0000

Michael,

On 03/10/2019 12:31, Lars Eggert wrote:
> On 2019-9-10, at 13:50, Scharf, Michael <Michael.Scharf@hs-esslingen.de> 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:
https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM
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:
https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7
The tcpm minutes here:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00
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                               http://bobbriscoe.net/