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

[Bob Briscoe <[e-mail]>]

Mike,

It may not be so straightforward.
* It is relatively easy to justify changing the policy for the flag that 
is released by making the Nonce historic, which ecn-experimentation is 
already giving rationale for.
* Strictly it would require text to justify changing the registry policy 
for the other 2 flags that are still assigned to RFC3168 on the 
standards track.

This is actually a symptom of a larger problem with the registry for 
these flags. The registry assigns bits to single RFCs as individual 
binary flags, but they are not being used like this. AccECN used 
combinations of the ECN flags and states of the TCP state-machine that 
had not yet been used together, in order to increase the available state 
space. RFC 3168 and RFC3540 also did this, and I'm sure people can think 
of many other TCP-based protocols that have done this.

However, we still imagine that individual flags are assigned to 
individual RFCs. Option (e) reinforces this delusion, whereas option (f) 
challenges it. Hence option (e) 'feels' more acceptable, as long as you 
screw up your eyes and avoid thinking too much.



I doubt anyone wants to "go there" right now. But here's text that could 
be used in "an RFC" (TBA) to change the whole TCP flags registry policy 
to reflect what is actually happening in practice:

option (g)

    It has become typical practice for the TCP maintenance working group
    to expect any change to TCP to be documented as an experimental RFC
    and for the experiment to be deployed and proved in practice before
    committing technology to the standards track.

    RFC3168 assigned the CWR and ECE flags for its own use as single
    bits and RFC3540 assigned the NS flag for its own use as another
    single bit. However, during TCP's  handshake both these RFCs use
    combinations of these bits as codepoints, not independent binary
    flags. RFC3168 and RFC3540 also give these bits different meanings
    when used after the handshake. So these three bits are effectively
    being used in combination with the SYN and ACK flags to increase the
    available state space in novel ways. Assigning TCP header flags as
    individual bits wastes all the combinations that these two RFCs and
    other existing RFCs do not use.

    The present document [ecn-experimentation] recognizes that
    * assigning TCP flags individually and exclusively to standards
    track RFCs is no longer typical practice;
    * the TCP flags are actually being used in novel ways that are not
    amenable to simple registration by IANA;
    * current innovation in this space is in spite of the "standards
    action" registry policy rather than because of it.

    Therefore the registry policy as a whole is changed to "IETF Review".




Bob


On 03/07/17 19:17, C. M. Heard 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/