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

["Gorry (erg)" <[e-mail]>]

I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

> On 3 Jul 2017, at 20:17, C. M. Heard <[e-mail]> wrote:
> 
> Bob,
> 
> I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.
> 
> Mike Heard
> 
>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <[e-mail]> wrote:
> 
>> 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 )
>>>> 
>>>> 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/
>