Re: [tsvwg] status on L4S terminology improvements

Bob Briscoe <> Thu, 30 July 2020 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E94593A1062 for <>; Thu, 30 Jul 2020 03:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZPadiJAsnmGe for <>; Thu, 30 Jul 2020 03:33:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 613BF3A1066 for <>; Thu, 30 Jul 2020 03:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=k08Q2S4B5WCrGU6C86go0TpKrGMBX1PMSSg6uCC1ieE=; b=4jpLvGzKEEzF/kFLi84gv52VcB tSzuChcRhpW9tkb/PHJRQG2tjIp8SAeaO3/pX9GeiHBFUnNk4V8r9VtUct+R/L5GwUcbyTsduAjA9 L+229QJONfN4s0d79ttF6xMo+OHr/jhT513IPuLJ4vVh04ZJk+Wbb1wwq+fLGKxDxckHGE0IqKQd3 L/e1CL0ZMvc5P4u2BD4+Fm2cTM/Jh6kqSqIm5ScdfL9nUshIalbZueV2v0OiFOdk6LuidHLglZEpQ NV1FJkUJaO0AwWvLbs6XKqbwCPIUb4a4wcwMRBcXkV3PapDZVvKG67YNzcxjP8RK2gm3lGfq3PpWy Z6GawlfA==;
Received: from [] (port=41280 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1k15sK-00Ehpw-GH; Thu, 30 Jul 2020 11:33:24 +0100
To: "Scharf, Michael" <>, Wesley Eddy <>, "" <>
References: <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Thu, 30 Jul 2020 11:33:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tsvwg] status on L4S terminology improvements
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 10:33:33 -0000

Thanks Michael,

All, Greg has pointed out some occurrences of 'legacy' still in l4s-arch 
(there's also one in dualq, but I left it 'cos it was appropriate - 
related to previous uses of the Diffserv field).

I thought I'd gone through a list of terms to search for systematically 
in each draft, but my manual process must have omitted these.
I've put it on my ToDo list to replace 'legacy' in l4s-arch, when I next 
bring the draft into my "working memory" for other reasons.


On 29/07/2020 12:59, Scharf, Michael wrote:
>> Interested parties should check over the current L4S drafts in regard to
>> whether the last couple rounds of editing have fully addressed the
>> tracker issue on "terminology improvements" (reduction of "hype",
>> removal of "classic TCP", and checking all other uses of 'traditional',
>> 'classic', and 'legacy').
>> It looks to me like Greg's comment at the bottom of that ticket
>> summarizes the status decently, and this is now in need of other
>> eyeballs to verify that this has been adequately addressed and can be
>> closed.
> Indeed, the terminology in the documents has improved.
> I don't plan to use some of the remaining "classic" terminology in this document myself. This also includes other related terms such as "'less unscalable' CUBIC", for which IMHO better alternatives could be found.
> Yet, authors of INFO and EXP documents probably have some degree of freedom what language to use - and I am not a native speaker. In the IETF compromises are necessary and one cannot always get 100%...
> As a result, as long as I am the only one who has no plans to use some of the words picked by the authors, maybe it is time for the WG to move on and focus on the other issues.
> Michael

Bob Briscoe