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

[Bob Briscoe <[e-mail]>]

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



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] 
> <mailto:[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]> <mailto:[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]>
>                 <mailto:[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>
>                            
>                     <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>
>                            
>                     <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>
>                            
>                     <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>
>                            
>                     <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>
>                            
>                     <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/
>                 <http://bobbriscoe.net/>
>
>
>
>         -- 
>         ________________________________________________________________
>         Bob Briscoehttp://bobbriscoe.net/ <http://bobbriscoe.net/>
>
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/