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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Bob,

On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe <[e-mail]> wrote:

> Spencer,
>
> Good idea. Except herding WG chairs and ADs to a common space-time
> co-ordinate during an IETF is not easy.
> How about at AD Office hours?
>
> on Sunday from 1500 to 1600 in the Istanbul room at IETF 99
>
> Two minds, with but a single thought.

That works for me. Anyone with a dog in this fight, that it doesn't work
for?

Spencer


>
>
> Bob
>
>
> On 07/07/17 15:38, Spencer Dawkins at IETF wrote:
>
> Gorry, since you asked - I don't have an objection to most of the
> alternatives presented in this thread. Since we're most/all in Prague Real
> Soon Now, I suggest that we have a whiteboard session at an appropriate
> break in the action, and make sure we are all on the same page, because
> there are several interconnected parts of the discussion.
>
> Thanks,
>
> Spencer
>
> On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <[e-mail]> wrote:
>
>> 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-heade
>>>>>> r-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-hist
>>>>>> oric.html
>>>>>>         <https://www.ietf.org/iesg/statement/designating-rfcs-as-his
>>>>>> toric.html>
>>>>>>             Current draft text to make RFC 3540 historic:
>>>>>>         https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimenta
>>>>>> tion-03#section-3
>>>>>>         <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experiment
>>>>>> ation-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/
>>>
>>
>>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>