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

["C. M. Heard" <[e-mail]>]

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-ec
>> n-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-experim
>> entation-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/
>
>