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

[Bob Briscoe <[e-mail]>]

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/