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

Nico Williams <nico@cryptonector.com> Tue, 06 April 2021 21:26 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07A53A3177 for <ietf@ietfa.amsl.com>; Tue, 6 Apr 2021 14:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 HiOWTdpTJ2dC for <ietf@ietfa.amsl.com>; Tue, 6 Apr 2021 14:26:16 -0700 (PDT)
Received: from bee.birch.relay.mailchannels.net (bee.birch.relay.mailchannels.net [23.83.209.14]) (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 A32213A3176 for <ietf@ietf.org>; Tue, 6 Apr 2021 14:26:15 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E3470482BDC; Tue, 6 Apr 2021 21:26:13 +0000 (UTC)
Received: from pdx1-sub0-mail-a92.g.dreamhost.com (100-105-161-106.trex.outbound.svc.cluster.local [100.105.161.106]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7EE564822F2; Tue, 6 Apr 2021 21:26:13 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a92.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.105.161.106 (trex/6.1.1); Tue, 06 Apr 2021 21:26:13 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Celery-Bored: 2a87cd150da6b464_1617744373776_1749711849
X-MC-Loop-Signature: 1617744373776:3110032661
X-MC-Ingress-Time: 1617744373776
Received: from pdx1-sub0-mail-a92.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a92.g.dreamhost.com (Postfix) with ESMTP id 4B8818A9FB; Tue, 6 Apr 2021 21:26:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=h/haRCbro7ImyA tbZo3L2Q8J+B0=; b=Y8KLiBDuiSs3wvgXMVI0ktr7LTftORvrxlvY+vAR9KZB/X GqlILsH1JRZJ/ir2pg3997Z+uRNA3UFxHU6UDQ90Z6xFhgedi2Lej0dr4+jBDkEd 2i+61zIn5JSqSfgVF/JQ03HCG/btC5YgKSx822qDU0iz4GaQM2yu5elP11Z/U=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a92.g.dreamhost.com (Postfix) with ESMTPSA id 1246D8A9FF; Tue, 6 Apr 2021 21:26:10 +0000 (UTC)
Date: Tue, 6 Apr 2021 16:26:08 -0500
X-DH-BACKEND: pdx1-sub0-mail-a92
From: Nico Williams <nico@cryptonector.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, ietf@ietf.org
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
Message-ID: <20210406212509.GS3828@localhost>
References: <6.2.5.6.2.20210401013907.0b3b7fe8@elandnews.com> <89383942-204e-a94e-3350-42bfb4165ba0@comcast.net> <792c4815-8c36-e5fa-9fbe-2e1cfa97239f@comcast.net> <D18D87D95723A68D8E75B6BC@PSB> <20210406152930.GR3828@localhost> <f52c46cf-03fb-6692-3a87-9b7db639f2e9@gmail.com> <130eadf6-70c2-9035-6ac2-b20dea7e9dba@joelhalpern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <130eadf6-70c2-9035-6ac2-b20dea7e9dba@joelhalpern.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/IRR9FGXqsZ9g9DbeLlFGUoChgx0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2021 21:26:21 -0000

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
--