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

[G Fairhurst <[e-mail]>]

On 04/07/2017, 16:19, Bob Briscoe wrote:
> Gorry,
>
> A point I didn't make, but should have done: 2 of the experiments in 
> ecn-experimentation depend on AccECN as a pre-requisite. 
This I realised.
> So it's important not to risk delay to AccECN in an attempt not to 
> delay ecn-experimentation.
>
OK - I will take it to the next Chair's meeting.
> Can you give any clue as to which solutions you do or don't favour? 
> Mirja asked me to post this to the lists. I think she was hoping this 
> would reveal all the pros and cons, so a decision could then be made 
> quickly between the chairs/ADs/shepherds/catherds.
>
I will - but need to consult others first.
>
> Bob
>
Gorry
> On 03/07/17 22:06, Gorry (erg) wrote:
>> 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] 
>> <mailto:[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] 
>>> <mailto:[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
>>>>         <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 Briscoehttp://bobbriscoe.net/
>>>
>>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/