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

[Bob Briscoe <[e-mail]>]

Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP 
header to "IETF Review".

Having a different policy for certain bits within a registry might send 
IANA into a spin, but I am sure they could write suitable text into the 
registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit 
field during the 3-way hand-shake. While the ECN Nonce and AccECN use 
the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN 
uses the combinations that RFC3168 and the Nonce do not use. So to cover 
all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 
to "IETF Review".


On 03/07/17 18:14, C. M. Heard wrote:
>
> Bob,
>
> Couldn't the text in the IANA considerations of ecn-experimentation 
> (which needs to be updated in any case) both change the NS flag to 
> Reserved for ECN Experimentation and change the allocation policy for 
> that flag from Standards Action to IETF Review, thereby updating RFC 
> 2780? That would avoid the churn needed to add motivating text for a 
> 4th experiment to ecn-experimentation and would allow AccECN to assign 
> the NS bit itself without a process exception.
>
> Mike Heard
>
> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:
>
>     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
>     <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
>     <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
>     <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
>     <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
>     <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/