[tsvwg] Process for re-assignment of NS TCP header flag to AccECN

Bob Briscoe <ietf@bobbriscoe.net> Mon, 03 July 2017 09:28 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5778131546; Mon, 3 Jul 2017 02:28:29 -0700 (PDT)
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_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 c2OAVN7XnPM6; Mon, 3 Jul 2017 02:28:27 -0700 (PDT)
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 7843F13153B; Mon, 3 Jul 2017 02:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9ihgR4Crk0JDgl+J3D1WYo6Ggt9XrRpsRy8EdaP8ZqQ=; b=xC+5DopYDlLIXOO5DLZ9tWULz5 gG4qytO8mi376mI186zBIwgrkIfXDEF5WF6NQLxmB/h2EDr8b0aTMNU+4qynmYAiO8KbRNeGY0np/ yUvDPhU0krCQn4j3XS0rt+B+mMxqftfgRx2mzqO9dxEl2E8wB4Q8bdPEoDou46dmXWRKw7fWKfzTt /vDaTLg1UxUxFNYmGQXgaaaNxeDdDL9PLUUFejffHnMgtiSeaX2QKmj+vMrrjMZ+Hv33AbWpNxTBy REkZZIUdhM9c7XpznzPKw/eBlIfGBZw1MPYOHYcyaHWe2DSQenalKP8zlSM6uIYYMQ6zijoTqdL6z Rp+sAKwA==;
Received: from [31.185.128.124] (port=36640 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <ietf@bobbriscoe.net>) id 1dRxeb-0000SI-Sy; Mon, 03 Jul 2017 10:28:26 +0100
To: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, tcpm IETF list <tcpm@ietf.org>, tsvwg IETF list <tsvwg@ietf.org>, "tsv-ads@ietf.org" <tsv-ads@ietf.org>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <6e08e177-6096-4cd7-4388-43b52c9e597a@bobbriscoe.net>
Date: Mon, 3 Jul 2017 10:28:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------07D7B434AEA72D1B6277C2A8"
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/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM>
Subject: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jul 2017 09:28:30 -0000

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, 
tsvwg list,

There has been some offlist discussion (among different sub-groups) to 
narrow down the options here. It is time to see opinions from the two 
affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG 
chairs and ADs.

*==Background to the Process Problem==**
*
In tsvwg the process is in motion to make the ECN nonce [RFC 3540] 
historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 
, we could finally include IANA assignment of the NS flag
     (see 
https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for 
assigning TCP flags is "Standards Action"
https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved 
by the IESG" [RFC2434].

References:
     Process for designating RFCs as historic:
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
     Current draft text to make RFC 3540 historic:
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
     My initial draft for the AD's status change note:
https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through 
IETF LC (after Prague). it is deliberately PS in order to be able to 
relax pre-existing constraints on ECN experiments in standards track 
RFCs. However, if poss, we want to avoid adding motivating text for a 
4th experiment, which could require another cycle of WGLC and delay 
until Nov.

RFC 3692 ("Assigning Experimental and Testing Numbers Considered 
Useful") could also be relevant, although it doesn't seem to help here, 
because it is primarily aimed at larger codepoint spaces, not single bits.


*==Process Options==**
*
There need to be two parts to the process: 1) unassignment and 2) 
reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making 
the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).
Process options:
a) ecn-experimentation assigns flag to itself as reserved for 
experiments and says initially the AccECN experiment will use it 
exclusively
b) ecn-experimentation assigns NS flag exclusively to AccECN
c) AccECN assigns NS flag to itself, with a process exception proposed 
to the IESG to allow an EXP doc to assign to a Standards Action registry
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call 
comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being 
referenced from the IANA registry:
a)  ecn-experimentation
b) accurate-ecn

*==My own preferences==**
*
During discussions, I didn't prefer (c) cos I thought the IESG might 
question why they are being asked to make a process exception for an ECN 
experiment at the same time as a draft is going through that avoids 
raising process exceptions for ECN experiments.

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja Kühlewind wrote:
> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards 
action, because it has become normal tcpm practice for any change to TCP 
to have to start on the experimental track. So this would justify a 
process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not 
sufficiently open and recorded for assignment of a flag in the main TCP 
header.


Bob


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