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

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Thu, 05 March 2020 18:07 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172833A0897; Thu, 5 Mar 2020 10:07:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCigu9vnB2LC; Thu, 5 Mar 2020 10:07:44 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C62D3A088F; Thu, 5 Mar 2020 10:07:44 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 025I6tNK042470; Thu, 5 Mar 2020 10:06:55 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 025I6tmo042469; Thu, 5 Mar 2020 10:06:55 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202003051806.025I6tmo042469@gndrsh.dnsmgr.net>
In-Reply-To: <A3DE5CF4-D65F-41E1-BD9C-4F7209E72A6A@kuehlewind.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Date: Thu, 05 Mar 2020 10:06:55 -0800
CC: Bob Briscoe <in@bobbriscoe.net>, Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs@ietf.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/6tHrm-TwH8zhopGjwOK1M_f2tfs>
Subject: Re: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2020 18:07:46 -0000

> Inline
> 
> > On 5. Mar 2020, at 14:32, Bob Briscoe <in@bobbriscoe.net> 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. 
> > Q1. At what point can/should we apply for a new option kind?
> 
> 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.

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.

> 
> > 
> > 
> > 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 <nsd.ietf@gmail.com> 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
> >>> 
> >>> tcpm@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tcpm
> >> 
> >> -- 
> >> ________________________________________________________________
> >> Bob Briscoe                               
> >> http://bobbriscoe.net/
> > 
> > -- 
> > ________________________________________________________________
> > Bob Briscoe                               
> > http://bobbriscoe.net/
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org