Subject: Re: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn

From: Bob Briscoe <[email-masked]>
Date: Thu, 5 Mar 2020 13:32:56 +0000

Yoshi, Mirja, (or anyone on the list who can point me at the correct 
process document)

I need advice on whether to take out the text about using an 
experimental option kind now that AccECN is intended for stds track.
Q1. At what point can/should we apply for a new option kind?
Q2. Are implementers still expected to use an experimental option kind 
until a stds track draft is approved as an RFC?

This is also pressing for Ilpo, who tells me he is planning to submit 
his implementation of AccECN to Linux netdev for upstreaming by the end 
of this week. He expects some discussion so there will be time before it 
goes through. But I'm sure he wants  to obey the IETF's rules.

Bob

On 27/02/2020 09:16, Bob Briscoe wrote:
> Yoshi, all,
>
> I am preparing a revision (...-10) with all the recent queued up 
> changes except those needed to change from EXP to PS. Then I shall 
> follow that with a second revision (...-11) for the change from EXP to PS.
>
> Reason: To enable implementers to separate out changes in the diffs 
> resulting from IETF procedure.
>
>
> Bob
>
> On 24/01/2020 08:06, Yoshifumi Nishida wrote:
>> Hi everyone,
>>
>> Sorry for taking long time. After several discussions among the 
>> chairs, we've concluded the rough consensus of the WG is that this 
>> document should target PS..
>>
>> As tcpm is a relatively small community, it's sometimes not easy to 
>> assess the consensus in the group.
>> However, as far as we've checked, most of people don't have issues on 
>> publishing it as a PS doc.
>>
>> This will mean the updated version of this draft will require further 
>> detailed reviews since the current version was written for an 
>> experimental doc. This might take extra time compared to publishing 
>> an EXP draft.
>> In addition, there are possibilities that other ECN proposals will be 
>> published in the future (and they can be PS as well). This draft 
>> should be carefully reviewed not to prevent such activities.
>>
>> Thanks,
>> --
>> Yoshi on behalf of tcpm co-chairs
>>
>>
>> On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi folks,
>>
>>     We would like to get feedback for the intended status
>>     of draft-ietf-tcpm-accurate-ecn.
>>     The current intended status of this draft is experimental, but
>>     we've seen some voices that PS is more preferable for the draft
>>     during Singapore meeting and on the ML. So, we would like to
>>     check the consensus on it.
>>
>>     There are some on-going related discussions such as flag
>>     registration policy, SCE, ECN++, etc, however, we believe the
>>     intended status discussions is independent from them and can
>>     proceed it separately.. (If you have concerns on it, please share
>>     your opinion here)
>>
>>     We appreciate your feedback.
>>
>>     Thanks,
>>     --
>>     Yoshi on behalf of tcpm co-chairs.
>>
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 5 Mar 2020 14:41:51 +0100

Inline

> On 5. Mar 2020, at 14:32, Bob Briscoe <[email-masked]> wrote:
> 
> Yoshi, Mirja, (or anyone on the list who can point me at the correct process document)
> 

https://tools.ietf.org/html/rfc6994

> I need advice on whether to take out the text about using an experimental option kind now that AccECN is intended for stds track. 

Options are registered based on standard actions, so they will be assigned on publication of the RFC.

> Q2. Are implementers still expected to use an experimental option kind until a stds track draft is approved as an RFC?

Yes. However, the document should only describe the final option. TFO notes in the IANA section that the experimental option exists and implementation should mitigate.

> 
> This is also pressing for Ilpo, who tells me he is planning to submit his implementation of AccECN to Linux netdev for upstreaming by the end of this week. He expects some discussion so there will be time before it goes through. But I'm sure he wants  to obey the IETF's rules.

I guess the idea is that it doesn’t go into main line kernel before the RFC is approved… I know that’s not the reality.

I guess you can check with Yuchung what he did for TFO but I guess they’ve upstreamed it before the draft was published...

>> I am preparing a revision (...-10) with all the recent queued up changes except those needed to change from EXP to PS. Then I shall follow that with a second revision (...-11) for the change from EXP to PS.
>> 
>> Reason: To enable implementers to separate out changes in the diffs resulting from IETF procedure.
>> 
>> 
>> Bob
>> 
>>> Sorry for taking long time. After several discussions among the chairs, we've concluded the rough consensus of the WG is that this document should target PS..
>>> 
>>> As tcpm is a relatively small community, it's sometimes not easy to assess the consensus in the group.
>>> However, as far as we've checked, most of people don't have issues on publishing it as a PS doc.
>>> 
>>> This will mean the updated version of this draft will require further detailed reviews since the current version was written for an experimental doc. This might take extra time compared to publishing an EXP draft.
>>> In addition, there are possibilities that other ECN proposals will be published in the future (and they can be PS as well). This draft should be carefully reviewed not to prevent such activities.
>>> 
>>> Thanks,
>>> --
>>> On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida <[email-masked]> wrote:
>>> Hi folks,
>>> 
>>> We would like to get feedback for the intended status of draft-ietf-tcpm-accurate-ecn. 
>>> The current intended status of this draft is experimental, but we've seen some voices that PS is more preferable for the draft during Singapore meeting and on the ML. So, we would like to check the consensus on it.
>>> 
>>> There are some on-going related discussions such as flag registration policy, SCE, ECN++, etc, however, we believe the intended status discussions is independent from them and can proceed it separately.. (If you have concerns on it, please share your opinion here)
>>>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 5 Mar 2020 10:06:55 -0800 (PST)

> I guess the idea is that it doesn?t go into main line kernel before the RFC is approved? I know that?s not the reality.

Though this may not be the reality what should occur is anything not RFC approved should be off by default and require some user interaction to enable.
Traditionally from my experience (4 decades?) this is how "new" things have been handled.
It might be desirable to have a document discussing this issue for implementors and vendors?

> 
> I guess you can check with Yuchung what he did for TFO but I guess they?ve upstreamed it before the draft was published...

I think you mean RFC published?  Drafts are "published" when submitted to the IETF.

-- 
Rod Grimes                                                 [email-masked]