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

From: "C. M. Heard" <[email-masked]>
Date: Mon, 3 Jul 2017 10:14:34 -0700

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 )
>
> 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
> 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
>     Current draft text to make RFC 3540 historic:
>         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
>
> 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
>
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 3 Jul 2017 19:05:15 +0100

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
>
>     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==**
>     *
>     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:
>     https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
>     <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html>
>     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://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==**
>     *
>     a) add text to IANA considerations section of ecn-experientation
>     making the NS flag reserved
>
>     a) ecn-experimentation assigns flag to itself as reserved for
>     experiments and says initially the AccECN experiment will use it
>     exclusively
>     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.
>
>     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.
>
>     sufficiently open and recorded for assignment of a flag in the
>     main TCP header.
>
>
>     Bob
>

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 3 Jul 2017 11:17:35 -0700

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 <[email-masked]> wrote:

> 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".
>
>
>> 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-ec
>> n-03#section-6 )
>>
>> which means "Values are assigned only for Standards Track RFCs approved
>> by the IESG" [RFC2434].
>>
>> References:
>>         https://github.com/bbriscoe/ecn-experimentation/blob/
>> master/status-change-ecn-nonce-rfc3540-to-historic-00.txt
>>
>> 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.
>>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 3 Jul 2017 22:04:22 +0100

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 <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>     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".
>
>
>>     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
>>
>>         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.
>>
>>         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
>>         However, AccECN is EXPerimental, whereas the registry policy
>>         for assigning TCP flags is "Standards Action"
>>         which means "Values are assigned only for Standards Track
>>         RFCs approved by the IESG" [RFC2434].
>>
>>         References:
>>         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.
>>
>>         a) add text to IANA considerations section of
>>         ecn-experientation making the NS flag reserved
>>
>>         experiments and says initially the AccECN experiment will use
>>         it exclusively
>>         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
>>
>>         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.
>>
>>         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/
>
>

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 3 Jul 2017 23:06:09 +0200

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 <[email-masked]> 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
> 
>> (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.
>> 
>> 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". 
>> 
>> 
>>> 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
>>>> 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 )
>>>> 
>>>> However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
>>>> which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].
>>>> 
>>>> References:
>>>> 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.
>>>> 
>>>> a) add text to IANA considerations section of ecn-experientation making the NS flag reserved
>>>> 
>>>> a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
>>>> 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. 
>>>> 
>>>> 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
>>>> 
>> 
>> --

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 4 Jul 2017 08:23:33 +0000

A comment on this statement: “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.”

TCPM decides on the status of documents case-by-case, by working group consensus.

Nothing prevents TCPM from publishing documents on standards track. The requirements in RFC 2026 Section 4.1.1 may be a bit harder to meet for TCP extensions and algorithms, compared to other IETF protocols, given the wide deployment of TCP in very different environments. And, indeed, the TCPM community consensus for some recent documents was to publish work (first) as experimental. These decisions have always been pretty unanimous, as far as I recall. But clearly if the community consensus is standards track, TCPM will submit documents on standards track…

Michael

From: Bob Briscoe [mailto:[email-masked]]
Sent: Monday, July 03, 2017 11:04 PM
To: C. M. Heard <[email-masked]>
Cc: tcpm <[email-masked]>; tcpm-chairs <[email-masked]>; tsvwg <[email-masked]>; tsvwg-chairs <[email-masked]>; tsv-ads <[email-masked]>
Subject: Re: Process for re-assignment of NS TCP header flag to AccECN

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.

Bob

Mike Heard

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:
Mike,

Let's call this option:

Thank you.

Bob

Bob,

Mike Heard

References:

==Process Options==

==My own preferences==

Bob

--

--

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 4 Jul 2017 15:07:58 +0100

Michael,

Actually I had first typed "accepted practice", but realized this would 
probably attract argument, so I changed it to "typical practice".
BTW, I think this is completely understandable - one would expect a high 
bar for standards track changes to TCP, esp. changes to the wire protocol.
My point was that, perversely, an "IETF Review" registry policy ought to 
be more characteristic of a protocol that is critical to the Internet, 
like TCP.

Data points about the RFCs on https://tools.ietf.org/wg/tcpm/

11 	INF
1 	BCP
10 	EXP
12 	PS
1 	DS

Of the 12 PSs,
  6 obsolete previous RFCs,
  2 update previous RFCs,
  4 were new (not based on a previous RFC)

None of the 4 new ones update the TCP wire protocol:
  1 was a new TCP option,
  1 was about numbering TCP options
  1 was a crypto algorithm
  1 (RFC5691) was essentially an update to RFC793, but did not formally 
update it

Bob

On 04/07/17 09:23, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> A comment on this statement: “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.”
>
>
> Nothing prevents TCPM from publishing documents on standards track. 
> The requirements in RFC 2026 Section 4.1.1 may be a bit harder to meet 
> for TCP extensions and algorithms, compared to other IETF protocols, 
> given the wide deployment of TCP in very different environments. And, 
> indeed, the TCPM community consensus for some recent documents was to 
> publish work (first) as experimental. These decisions have always been 
> pretty unanimous, as far as I recall. But clearly if the community 
> consensus is standards track, TCPM will submit documents on standards 
> track…
>
> Michael
>
> *From:*Bob Briscoe [mailto:[email-masked]]
> *Sent:* Monday, July 03, 2017 11:04 PM
> *To:* C. M. Heard <[email-masked]>
> *Cc:* tcpm <[email-masked]>; tcpm-chairs <[email-masked]>; tsvwg 
> <[email-masked]>; tsvwg-chairs <[email-masked]>; tsv-ads 
> <[email-masked]>
> *Subject:* Re: Process for re-assignment of NS TCP header flag to AccECN
>
> Mike,
>
> * 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.
>
> 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.
>
> 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.
>
>     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.
>
>     violation committed by RFC 3540, an experimental RFC that assigned
>     bit 7 in contradiction to the policy in RFC 2780.
>
>     Mike Heard
>
>         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.
>
>         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:
>
>             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
>
>                 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.
>
>                 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 )
>
>                 However, AccECN is EXPerimental, whereas the registry
>                 policy for assigning TCP flags is "Standards Action"
>                 which means "Values are assigned only for Standards
>                 Track RFCs approved by the IESG" [RFC2434].
>
>                 References:
>                 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,
>                 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.
>
>                 a) ecn-experimentation assigns flag to itself as
>                 reserved for experiments and says initially the AccECN
>                 experiment will use it exclusively
>                 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.
>
>                 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
>
>         -- 
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 4 Jul 2017 15:19:49 +0100

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Bob,
>>
>>>     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
>>>         and 2) reassignment. The first seems clear-cut. The second
>>>         is less obvious.
>>>
>>>         a) ecn-experimentation assigns flag to itself as reserved
>>>         for experiments and says initially the AccECN experiment
>>>         will use it exclusively
>>>         exception proposed to the IESG to allow an EXP doc to assign
>>>         to a Standards Action registry
>>>         process exception for an ECN experiment at the same time as
>>>         a draft is going through that avoids raising process
>>>         exceptions for ECN experiments.
>>>

---

From: G Fairhurst <[email-masked]>
Date: Tue, 04 Jul 2017 17:41:09 +0200

On 04/07/2017, 16:19, Bob Briscoe wrote:
> 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.
> quickly between the chairs/ADs/shepherds/catherds.
I will - but need to consult others first.
Gorry
>>>     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:
>>>
>>>>     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
>>>>
>>>>         In tsvwg the process is in motion to make the ECN nonce
>>>>         [RFC 3540] historic. So, in the most recent rev of
>>>>         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
>>>>         standards action, because it has become normal tcpm
>>>>         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
>>>>
>>>
>>>     --

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 7 Jul 2017 09:38:55 -0500

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 <[email-masked]> wrote:

>> 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.
>>
>>> 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 <[email-masked] <mailto:
>>> [email-masked]>> wrote:
>>>
>>> Bob,
>>>>
>>>> violation committed by RFC 3540, an experimental RFC that assigned bit 7 in
>>>> contradiction to the policy in RFC 2780.
>>>>
>>>> Mike Heard
>>>>
>>>>>         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>
>>>>>
>>>>>>         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.
>>>>>>
>>>>     --     ___________________________________________________________
>>>> _____

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 7 Jul 2017 15:52:22 +0100

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:
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         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.
>
>         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 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
>
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>> 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
>                 On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:
>
>                     Mike,
>
>                     Let's call this option:
>                     (e) ecn-experimentation alters the registry policy
>                 of bit 7 of
>                     the TCP header to "IETF Review".
>
>                             Michael*2, Yoshifumi, Gorry, David, Wes,
>                     Mirja, Spencer,
>                             tcpm list, tsvwg list,
>
>                     <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://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.ietf.org/iesg/statement/designating-rfcs-as-historic.html
>                     <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html>>
>                     <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://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>>
>
>                             experiment, which could require another
>                     cycle of WGLC and
>                             delay until Nov.
>
>                             2) Assigning the NS flag to accurate-ecn
>                     (and renaming it
>                             the AE flag).
>                             Process options:
>                                 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.
>
>                 <http://bobbriscoe.net/>
>         Bob Briscoehttp://bobbriscoe.net/ <http://bobbriscoe.net/>
>
>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 10 Jul 2017 08:58:06 -0500

Hi, Bob,

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

> 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

>>> Mirja asked me to post this to the lists. I think she was hoping this would
>>>> talk to my AD about how to handle the process  - and liaise with the TCPM

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Jul 2017 16:15:05 -0700

Wednesday lunch?

Sent using a machine that autocorrects in interesting ways...

> On Jul 10, 2017, at 6:58 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Bob,
> 
>> Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy. 
> That works for me. Anyone with a dog in this fight, that it doesn't work for?
> 
> Spencer
>  
>> 
>> 
>> Bob
>> 
>> 
>>> 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
>>> 
>>>>> 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.
>>>>> 
>>>>> 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.
>>>>> 
>>>>>> On 3 Jul 2017, at 20:17, C. M. Heard <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>>> Bob,
>>>>>>> 
>>>>>>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>> 
>>>>>>>     Mike,
>>>>>>> 
>>>>>>>     Let's call this option:
>>>>>>>     --     ________________________________________________________________

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 11 Jul 2017 22:00:38 +0100

*Fred,**
*For Wed, IETF agenda says "1200-1300  WG Chairs Forum"
I assume some tcpm & tsvwg WG chairs plan to attend?

I feel the need for a doodle here.
*Spencer & Mirja* can you suggest some times you're free as you're 
likely to be the most calendaristically challenged.

BTW, I assume there will be discussion in tcpm on Monday given this will 
be raised during the talk on AccECN.
Also, there's no rule against anyone saying something specific by email 
now, in response to the choices suggested so far on the list (collected 
below) - then we might not need a mtg.

>         e) ecn-experimentation alters the registry policy of bit 7 of 
> the TCP header to "IETF Review"
>         f)  ecn-experimentation alters the registry policy for bits 
> 7-9 to "IETF Review".

Bob

On 11/07/17 00:15, Fred Baker wrote:
> On Jul 10, 2017, at 6:58 AM, Spencer Dawkins at IETF 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>> Hi, Bob,
>>
>> On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe <[email-masked] 
>>     Spencer,f)
>>     Good idea. Except herding WG chairs and ADs to a common
>>     space-time co-ordinate during an IETF is not easy.
>>>     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
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             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
>>>                 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
>>>                 On 3 Jul 2017, at 20:17, C. M. Heard
>>>                 <[email-masked] <mailto:[email-masked]>
>>>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>>>                 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
>>>
>>>                         (e) ecn-experimentation alters the registry
>>>                     policy of bit 7 of
>>>                                 Michael*2, Yoshifumi, Gorry, David,
>>>                         Wes, Mirja, Spencer,
>>>                                 tcpm list, tsvwg list,
>>>
>>>                                 experiment, which could require
>>>                         another cycle of WGLC and
>>>                                 delay until Nov.
>>>
>>>                                 2) Assigning the NS flag to
>>>                         accurate-ecn (and renaming it
>>>                                 the AE flag).
>>>                                 Process options:
>>>                                   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.
>>>

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Jul 2017 14:08:21 -0700

> On Jul 11, 2017, at 2:00 PM, Bob Briscoe <[email-masked]> wrote:
> 
> Fred,
> For Wed, IETF agenda says "1200-1300  WG Chairs Forum"

My comment was in response to yours, that herding WG Chairs and ADs into a common space was "interesting". That is an interval in which we are all supposed to be in one room (actuality may vary).

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 11 Jul 2017 22:22:01 +0100

Fred,

Ah! Sry. I got the wrong end of the stick.
However, some authors will not be there (if that matters).

Bob

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Jul 2017 11:32:57 -0500

Dear All,

On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker <[email-masked]>
wrote:

> My comment was in response to yours, that herding WG Chairs and ADs into a
> common space was "interesting". That is an interval in which we are all
> supposed to be in one room (actuality may vary).

I hadn't thought Fred's suggestion through, until I realized that I haven't
seen an e-mail for the WG Chairs Forum with an agenda YET (which is
disturbing, but not relevant except that it makes us huddling at the
beginning, end, or even middle of that time seem very reasonable). If the
answer is that the chairs are gonna eat lunch and chat in small groups,
that will be very easy for me to break away from.

So, yes, please continue to discuss via e-mail, but Wednesday lunch will be
a time I can be cornered.

Spencer

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Jul 2017 23:30:32 +0200

Hi all,

let’s still meet in the AD office hours because it would actually be good to chat before the tcpm and tsvwg sessions. And then we maybe can catch up with Micheal at the receipt. Who would able able to be there Sunday at 3pm (besides Micheal)?

If we need another meeting, I can probably move my Monday lunch meeting and we could do Monday lunch right after the tcpm session...?

Mirja

> Am 12.07.2017 um 18:32 schrieb Spencer Dawkins at IETF <[email-masked]>:
> 
> Dear All,
> 
> On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker <[email-masked]> wrote:
> 
> 
> I hadn't thought Fred's suggestion through, until I realized that I haven't seen an e-mail for the WG Chairs Forum with an agenda YET (which is disturbing, but not relevant except that it makes us huddling at the beginning, end, or even middle of that time seem very reasonable). If the answer is that the chairs are gonna eat lunch and chat in small groups, that will be very easy for me to break away from.
> 
> So, yes, please continue to discuss via e-mail, but Wednesday lunch will be a time I can be cornered.
> 
> Spencer

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Jul 2017 23:35:56 +0200

Hi again,

I just realized that both the tcpm and tsvwg lists are both (still) cc’ed. For course everybody who want to chat about ECN (and ECN Nonce/accECN) is invited to join but I think we mainly should have a chat with the wg chairs and the AccECN authors.

Mirja

> Am 12.07.2017 um 23:30 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> Hi all,
>