Re: WG Review: Effective Terminology in IETF Documents (term)

"Joel M. Halpern" <> Tue, 06 April 2021 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF3073A319C for <>; Tue, 6 Apr 2021 14:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.821
X-Spam-Status: No, score=-2.821 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rSu7ZiiqlsFw for <>; Tue, 6 Apr 2021 14:30:41 -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 896873A319B for <>; Tue, 6 Apr 2021 14:30:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FFLKs1Sf1z1nsXG; Tue, 6 Apr 2021 14:30:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1617744641; bh=K1fhdoc+ao/iHv8iqORcv4gSO4aL7+xEj8RPHrX8csQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lYpBGqNCQxmqvhO3MepILaTBNnsH7VNLKSTu56leT2aUNC+rEoBgmHbMtcaKfYtd1 +3Y9S7bAC/LOd2+o2+8bCtblAG2OdJL9r1d4tW86GdD6On1hLaDBwKNoTOtwFIiIKz P4sNUk2CcBZTsii0YvTVTNaUKMh/PKyWBLODqOZc=
X-Quarantine-ID: <kdiq3g501kcU>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4FFLKr4HzLz1nsZ0; Tue, 6 Apr 2021 14:30:40 -0700 (PDT)
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
To: Nico Williams <>
Cc: Brian E Carpenter <>,
References: <> <> <> <D18D87D95723A68D8E75B6BC@PSB> <20210406152930.GR3828@localhost> <> <> <20210406212509.GS3828@localhost>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 6 Apr 2021 17:30:39 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <20210406212509.GS3828@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Apr 2021 21:30:46 -0000

I was, as can be seen below, responding to both you and Brian on the 
issue of whether this is an issue that the IETF can structurally 
address.  It can.  It does not need to wait for the RFC Series policy 
making body to exist and to agree.

On the other hand, regarding your followup comment, for the IESG to 
decide that some terms should be banned without having a community 
process would be a very bad result.  Fortunately, they have not proposed 
to do so.


On 4/6/2021 5:26 PM, Nico Williams wrote:
> On Tue, Apr 06, 2021 at 05:10:02PM -0400, Joel M. Halpern wrote:
>> On 4/6/2021 4:58 PM, Brian E Carpenter wrote:
>>> Nico raises a point that has been in my mind: why is this an IETF issue,
>>> since presumably it applies to all RFC streams?
>>> I believe that the charter is good enough as it is, but I also believe
>>> that the IESG should consider not only whether there is consensus on the
>>> charter text, but also the basic question whether this issue should be
>>> handled by the IETF at all, rather than by the RFC Editor. There is a
>>> strong case for the latter.
>> While this (terminology) could be handled on a series-wide basis, it does
>> not have to be.  The IETF can adopt policies for conent of the IETF stream
>> that are more restrictive than the RFC Editor.  While I think getting the
>> eventual RFC Series quasi-wg to look at this is worth-while, I do not see
>> why that should gate the IETF looking at the quesiton.
> That's a fine answer to a question Brian did not ask.
> It also doesn't address any of John Klensin's points, which I think
> really do need to be addressed.
> At this point I think the best compromise is for the IESG to indicate
> its terminology preferences to the RSE and hope the RSE enforces them
> (which, they almost certainly would).  And also maybe the IAB should
> publish an RFC on terminology if they like.  And maybe we can have an
> RFC asking the RSE to develop a style guide that addresses these issues.
> All of those are outcomes I can get behind.
> Nico