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

[Bob Briscoe <[e-mail]>]

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. So it's 
important not to risk delay to AccECN in an attempt not to delay 
ecn-experimentation.

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.


Bob

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 Briscoe                               http://bobbriscoe.net/