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

Nico Williams <nico@cryptonector.com> Fri, 09 April 2021 21:39 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 1B5073A1285 for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 14:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 TBM7NV_5B9cX for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 14:39:19 -0700 (PDT)
Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) (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 E4C093A1282 for <ietf@ietf.org>; Fri, 9 Apr 2021 14:39:18 -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 9823B1223BB; Fri, 9 Apr 2021 21:39:16 +0000 (UTC)
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (100-96-133-83.trex.outbound.svc.cluster.local [100.96.133.83]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 40ED71225D1; Fri, 9 Apr 2021 21:39:14 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.133.83 (trex/6.1.1); Fri, 09 Apr 2021 21:39:16 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Ski-Tasty: 51589ae345bf0905_1618004356411_1430132729
X-MC-Loop-Signature: 1618004356411:3250181487
X-MC-Ingress-Time: 1618004356411
Received: from pdx1-sub0-mail-a40.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTP id 04F2C7EE2D; Fri, 9 Apr 2021 21:39:14 +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=2jAUsCXg0CwV44 pZMy3fVp/FLKA=; b=lZU4LX9CcaSfnvqjeuWXYP1iRTGQDMs59ektaGqSO9zoDa 5/bOQ1qjMWlFXTrs6eOup5lZb7HrRu5Ubi6Njb1Nt0zyTZkA0zagsUm6jOrgdWLc PhSVji5tL+JXNm2aoWZXKhPUSgMZjRTsE7cy5OvskW0OrePGHR55L6cCzLSSU=
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-a40.g.dreamhost.com (Postfix) with ESMTPSA id 329D289ABD; Fri, 9 Apr 2021 21:39:11 +0000 (UTC)
Date: Fri, 9 Apr 2021 16:39:08 -0500
X-DH-BACKEND: pdx1-sub0-mail-a40
From: Nico Williams <nico@cryptonector.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: John Scudder <jgs@juniper.net>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
Message-ID: <20210409213907.GC9612@localhost>
References: <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> <20210406212509.GS3828@localhost> <046922BE-F850-4B09-8527-D2B014505C44@juniper.net> <20210409160539.GA9612@localhost> <fc12b265-f303-f8bf-da08-ed4616a6dba6@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fc12b265-f303-f8bf-da08-ed4616a6dba6@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/jadsnIgBwRaeQcx_0qFTAgWNe_Y>
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: Fri, 09 Apr 2021 21:39:24 -0000

On Sat, Apr 10, 2021 at 08:36:59AM +1200, Brian E Carpenter wrote:
> On 10-Apr-21 04:05, Nico Williams wrote:
> > My proposal, fleshed out:
> > 
> >  - direct the RSE to develop terminology standards;
> 
> We don't yet know the future of the "RSE" role, but what is certain
> is that the IETF can't "direct" that person in any plausible model.

Tell me more.  I mean, I don't buy this assertion.  I'm quite certain
that the IETF could impose some requirements on publication within the
IETF stream.

> >  - direct the RPC to enforce the RSE's terminology standards;
> 
> Generally speaking the RPC applies the agreed style guide, so
> any terminology standards or guidelines would be part of the style
> guide. We don't yet know the future of how the style guide is
> maintained.

Right, well, maybe TERM WG needs to provide input to the style guide.
That's essentially what it would be doing as proposed, only without
saying so.  So I don't see the problem with phrasing it in this way
(style guide update) instead.

> >  - whenever an author or authors, as well as the responsible AD,
> >    disagree with editorial changes made or proposed by the RPC, they may
> >    override the RPC's change,
> 
> That's always been a matter of negotiation. I don't see that changing,
> but if it does, it will be an RFC Series policy matter. We don't yet know
> the future of how RFC Series policy is set.

See above.

> >  - but if the RPC feels strongly about it, they may request a WG LC on
> >    this issue.
> 
> That seems very weird. The RPC as an organisation has no standing in
> the IETF process.

They would be applying the style guide.

> >  - There would be no IESG or IETF involvement in resolving any such
> >    disputes.
> 
> That's self-contradictory. You just suggested a WG LC, i.e. part of the
> IETF process. And of course if a draft is changed after IETF LC,
> it needs agreement from at least the AD, and possibly a repeat of the
> IETF LC and IESG approval.

To be more precise, the IESG as a whole would get no say apart from the
responsible AD, and there would be no IETF LC.

We're talking about a s/X/Y/g substitution that would be recommended or
required by the STYLE guide and which may not get applied.  The idea
with eliding IESG approval and IETF LC at this stage is that if this was
controversial, it would have been caught earlier, and to avoid divisive
later controversy like what we're seeing.

Nico
--