Re: [tsvwg] Call for comments on the suggested publication timeline for draft-white-tsvwg-l4sops

Bob Briscoe <ietf@bobbriscoe.net> Thu, 24 March 2022 13:35 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14803A1760 for <tsvwg@ietfa.amsl.com>; Thu, 24 Mar 2022 06:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 0c2caiULTjqh for <tsvwg@ietfa.amsl.com>; Thu, 24 Mar 2022 06:35:15 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A2A3A1607 for <tsvwg@ietf.org>; Thu, 24 Mar 2022 06:35:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:Cc:References:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/yUmOjPpy6lLCry2PUzxvUTomoPKnnQ2ZGE9x0UwE6Y=; b=gbiZvBvQZ0iPBAKiWuNgSElJQY SK9dSlTYYtZu8uFt0X78Y9+W1PPhTr4sLZK+sE9bQntEzPXEdscY9CfDRt7fg3q7s4jJzn8RP9NoA 7iX+qWWtAd5E8K+bOWUiK8iu4utkUoEXNWQvi0SAtWV/ZVUAIg3qWmR8GrFI9+8gTsjbyedBUNTYm XsIg2U/hOnfloxBX0RIiwcKoIU2gsaDmlGZI4OgwO1xDaVcagvhE97m0D4tF/jwo3begBoYnGYDe9 G2laXCp+8KCM5QX5ROysji6uECwJxggg403BuGzql0H6uzSuB1Z4kanfCzOT/cTAxyH6KP5pg+MWc EUBuwl9g==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:50838 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <ietf@bobbriscoe.net>) id 1nXNcR-0006aV-PL; Thu, 24 Mar 2022 13:35:08 +0000
Message-ID: <dd4d69b6-71c3-ad68-9394-d4f4d95607d8@bobbriscoe.net>
Date: Thu, 24 Mar 2022 13:35:06 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-GB
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References: <28c48d28-3110-d3a8-d405-b13dcbb224c9@erg.abdn.ac.uk> <80FF9110-6C90-4DBE-B205-120A89A67F33@cablelabs.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, Greg White <g.white@CableLabs.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
In-Reply-To: <80FF9110-6C90-4DBE-B205-120A89A67F33@cablelabs.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/oSKI3eRxPLAvpluouHs1YGHbh30>
Subject: Re: [tsvwg] Call for comments on the suggested publication timeline for draft-white-tsvwg-l4sops
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2022 13:35:26 -0000

Gorry,

I can see the two sides of this.
* Sebastian's point that publication could improve visibility for 
network and server operators is a good one.
* But if I were on the IESG and asked to approve publication of 
operational guidance before there was any operational experience, I 
would be concerned.

Similarly, because some of the points in the draft do not have much real 
experience to back them up, they might have to be removed in order to 
get it approved for publication. For instance, we have been arguing about:
* likely traffic patterns;
* likelihood of shared queue Classic ECN being deployed;
* likelihood of hash collisions
* likelihood that good classic ECN bottleneck detection can be implemented;
* likelihood that network equipment can be configured in certain ways; 
etc. etc.
Without some real-world experience on these matters, I'm not sure what 
the value of this document as an RFC would be.

I think Sebastian's point might be slightly reworded to say this draft 
needs 'visible status'. Visibility comes from Internet discussion 
forums, blogs and articles. Not yet being published as an RFC doesn't 
really change visibility (e.g. anyone interested in the implications of 
QUIC would have read a draft without waiting for RFC publication). 
Rather, publication changes the status of the guidance once it is visible.

How about this compromise:
* We agree now that this draft is intended to give guidance based on 
'early' or 'initial' operational experience (e.g. 1 year), and aim to 
publish once there is some experience, but not wait until experience is 
exhaustive.
* Where l4sops is cited in ecn-l4s-id (from the requirement on 
coexistence in Classic ECN AQMs), we edit to say explicitly that l4sops 
is being kept open as a living document for a short while to capture 
initial operational experience.

Then, if ecn-l4s-id is published as an RFC, the visible status of the 
coexistence issue ought to be no less than if two RFCs are published 
about it.
And this extra explanation of the draftiness of the citation should make 
it more likely that people who need to read l4sops will understand its 
status and not dismiss it as "not worth reading yet".

HTH



Bob

On 21/03/2022 17:53, Greg White wrote:
> Hi Gorry,
>
> A few points of clarification.
>
> The draft in question is actually https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4sops/
>
> Also, there remains one "ToDo" in the document that I briefly mentioned today, and for which I'm hoping to get input from the WG.  Aside from that one item, I'm not aware of any other areas where it is considered incomplete.
>
> Is the deadline for responses to your question possibly *April* 8?
>
> -Greg
>
>
>
> On 3/21/22, 8:28 AM, "tsvwg on behalf of Gorry Fairhurst" <tsvwg-bounces@ietf.org on behalf of gorry@erg.abdn.ac.uk> wrote:
>
>      The presentation in TSVWG on Monday 21st March 2022 indicated that the
>      authors thought the document was complete and ready for review. The
>      chairs previously indicated that publication could be delayed to wait
>      for initial experience.  The chairs would appreciate feedback, to help
>      decide.
>
>      So, does the WG have a  preference regarding when to publish the L4S Ops
>      draft:
>
>      (1)  If the work is thought complete, there could be value in having a
>      frozen draft while experience is gained, this could be updated with
>      initial experience, before requesting publication as an RFC.
>
>      (2) The WG would not intentionally delay the request for the IESG to
>      publish: If the work is thought complete, then we can finish this draft
>      and publish in the short-term. The WG retains the option to decide to
>      subsequently publish an updated RFC in the future.
>
>      Please could send an email to tsvwg, or to the tsvwg chairs by 8th March
>      2022.
>
>      Before any publication, the ID will be subject to normal review and WGLC
>      comments.
>
>      Best wishes,
>
>      Gorry Fairhurst
>      (tsvwg co-chair)
>
>

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