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

Bob Briscoe <in@bobbriscoe.net> Mon, 04 November 2019 18:08 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 86182120C41 for <tcpm@ietfa.amsl.com>; Mon, 4 Nov 2019 10:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 z4mHGFC865Qv for <tcpm@ietfa.amsl.com>; Mon, 4 Nov 2019 10:08:06 -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 95694120C3B for <tcpm@ietf.org>; Mon, 4 Nov 2019 10:08:05 -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=XPndH8fkXJ2iaTHFh5gqT/Joz58ejTvSj2tQIhPUhwk=; b=L2fPYtJjFZEWWVi5Dll+hwXW5 LRaxP9t7v4Bd8YeL9Lh08LJu2MREN+vTTc9PGq68xuaWkIspAsTHKlxWokXR7Zy77NsqSWUlLxGcF 69/oQPJKxlsOhV+ektp6grSff6EA3bprP9CvZCHH0EEZtTxqCJofiUlY952Se/VOL4nxoCzhEm5xX NXYR1WcF5egEoIui44lsGlCnyiFFgYocqWuGoUBNeZnlo06s62KYYeMiiVd4FPMEo/uXGR0kIvBYm SMUdbrUDLR0Dr2Lhb6ccGhy/PBz9R/IFxXFuPAqKqIRgUsM11yXA8J5BXqiInHJnANsANp2jiCCuw 76AjkW7fA==;
Received: from [31.185.128.31] (port=47426 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 1iRgln-0007X5-I6; Mon, 04 Nov 2019 18:08:03 +0000
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Cc: Richard Scheffenegger <rscheff@gmx.at>, "tcpm@ietf.org" <tcpm@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
References: <6EC6417807D9754DA64F3087E2E2E03E2D437915@rznt8114.rznt.rzdir.fht-esslingen.de> <13123FDD-D69C-4D67-9F1B-B9B27FB6A234@eggert.org> <7c24fae0-36d1-30a1-88a8-c93c65116595@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4D9D3B@rznt8114.rznt.rzdir.fht-esslingen.de> <9df28a2e-d902-dd4c-b87d-df0fec38813c@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <3fb7e1e0-f9d9-8471-7661-7b1579de20d9@bobbriscoe.net>
Date: Mon, 4 Nov 2019 18:08:02 +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: <6EC6417807D9754DA64F3087E2E2E03E2D4DD8C8@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: multipart/alternative; boundary="------------3FD48B6388ACFC430A26B7F0"
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/VPVUMHT90yMO4YoyaZzguf9VMpA>
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: Mon, 04 Nov 2019 18:08:10 -0000

Michael,

You said decisions are finalized on the ML. Then when I asked whether 
the decision had been questioned on the ML at the time 2 yrs ago, you 
didn't answer.

That begs an answer to my other question:
> One then has to ask what new situation has arisen that makes this 
> decision need to be revisited.


Bob

On 04/11/2019 16:39, Scharf, Michael wrote:
>
> Bob,
>
> The IETF consensus for RFC 8311 was to return the status of the bit to 
> „reserved“ and this RFC was published by TSVWG, not by TCPM. I was not 
> much in the loop, but I have agreed to the approach taken by RFC 8311 
> for the bit. The formal implications of the „reserved“ status 
> according to RFC 8311 follow from RFC 2780, which does not foresee an 
> IESG allocation.
>
> I have already argued during IETF 99 for a standards track solution. 
> By that time, this would have implied a new small PS document, not 
> RFC8311. The other variant of using 793bis proposed by Joe has not 
> really been realistic 2 years ago.
>
> BTW, given the potential solution via 793bis, we are in a different 
> situation now, no?
>
> At the end of the day,  we need to find a solution that has strong 
> TCPM consensus, or, better, even unanimous consensus. And, to me it 
> sounds like a bad idea to have an IETF last call discussion about 
> process violations for a document with possibly rather rough WG 
> consensus, most notably regarding a change of the main TCP header that 
> affects every single Internet device. I really suggest to think about 
> alternatives.
>
> Best regards
>
> Michael
>
> *Von: *Bob Briscoe <mailto:in@bobbriscoe.net>
> *Gesendet: *Montag, 4. November 2019 15:10
> *An: *Scharf, Michael <mailto:Michael.Scharf@hs-esslingen.de>
> *Cc: *Richard Scheffenegger <mailto:rscheff@gmx.at>; tcpm@ietf.org 
> <mailto:tcpm@ietf.org>; Mirja Kuehlewind <mailto:ietf@kuehlewind.net>
> *Betreff: *Re: [tcpm] On allocating reserved bits in the TCP header
>
> Michael,
>
> 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.
>
>
>
> Bob
>
> 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 <mailto:in@bobbriscoe.net>
>> *Gesendet: *Sonntag, 3. November 2019 23:04
>> *An: *Scharf, Michael <mailto:Michael.Scharf@hs-esslingen.de>
>> *Cc: *tcpm@ietf.org <mailto:tcpm@ietf.org>; Mirja Kuehlewind 
>> <mailto:ietf@kuehlewind.net>; Richard Scheffenegger 
>> <mailto:rscheff@gmx.at>
>> *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<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 Briscoehttp://bobbriscoe.net/
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/