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

Nico Williams <nico@cryptonector.com> Fri, 09 April 2021 22:25 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 415633A1458 for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 15:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.772
X-Spam-Level:
X-Spam-Status: No, score=-0.772 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_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 aFLaLRd1t84v for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 15:25:30 -0700 (PDT)
Received: from donkey.elm.relay.mailchannels.net (donkey.elm.relay.mailchannels.net [23.83.212.49]) (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 EBD9F3A145B for <ietf@ietf.org>; Fri, 9 Apr 2021 15:25:29 -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 691FD321D9A; Fri, 9 Apr 2021 22:25:28 +0000 (UTC)
Received: from pdx1-sub0-mail-a92.g.dreamhost.com (100-96-27-157.trex.outbound.svc.cluster.local [100.96.27.157]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E7624321B83; Fri, 9 Apr 2021 22:25:27 +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.96.27.157 (trex/6.1.1); Fri, 09 Apr 2021 22:25:28 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Chemical-Cellar: 1dba21c978f8b162_1618007128251_141138770
X-MC-Loop-Signature: 1618007128251:627215457
X-MC-Ingress-Time: 1618007128251
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 AE6088A9FB; Fri, 9 Apr 2021 15:25:27 -0700 (PDT)
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=+12CuekkomC+1+ 94hwpTyTZjXcE=; b=MPVLjenkELBwoAgS/O+UeCyXa2Nuztu/uxEQ5z1A/c9Pkd IVkkpY52LSNqregHQ/1XuHZ0L/r2AL1HN7VI3DQY/oyMpMvxiHEkSPBHBfsdkBPg d1ssNK8AJ5H7ZOvTIzd2MBzJifzTJCkn8BIB35369MjS6ROdlRfzm0lDSr6JQ=
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 0039788409; Fri, 9 Apr 2021 15:25:25 -0700 (PDT)
Date: Fri, 09 Apr 2021 17:25:23 -0500
X-DH-BACKEND: pdx1-sub0-mail-a92
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: <20210409222522.GE9612@localhost>
References: <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> <20210409213907.GC9612@localhost> <a9698e3a-bee7-aadc-028e-647b7033a016@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <a9698e3a-bee7-aadc-028e-647b7033a016@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/St6oy_7l-f3DSZy4tm1n8FIRCCI>
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 22:25:34 -0000

On Sat, Apr 10, 2021 at 10:06:39AM +1200, Brian E Carpenter wrote:
> On 10-Apr-21 09:39, Nico Williams wrote:
> > 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.
> 
> Oh yes, but why wouldn't that happen before the draft goes to the
> RFC Editor in the first place?

Because we're talking about all future RFCs, not one?

> >>>  - 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.
> 
> That would be fine, but the proposed future RFC model would
> only treat that as input, not as a done deal.

Sure, but in both cases it's the IETF making these changes, so we get
to.  We might have to merge or sequence TERM with, what is it, RFCED?,
but whatever the case, it can be done.

> > [...]
> > 
> > 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.
> 
> That would definitely needs an update to RFC2026.

Again, that's doable.

> > 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.
> 
> It's much better for everybody, I think, if it was caught earlier.

Yes.

Nico
--