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

John C Klensin <john-ietf@jck.com> Fri, 09 April 2021 22:40 UTC

Return-Path: <john-ietf@jck.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 002423A14F5 for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 15:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 w_aJMkDtms5p for <ietf@ietfa.amsl.com>; Fri, 9 Apr 2021 15:40:27 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1892B3A14F6 for <ietf@ietf.org>; Fri, 9 Apr 2021 15:40:27 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lUznZ-000Dyw-HS; Fri, 09 Apr 2021 18:40:21 -0400
Date: Fri, 09 Apr 2021 18:40:15 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Nico Williams <nico@cryptonector.com>, John Scudder <jgs@juniper.net>
cc: ietf@ietf.org
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
Message-ID: <22FA0BD3330356685E400EAF@PSB>
In-Reply-To: <fc12b265-f303-f8bf-da08-ed4616a6dba6@gmail.com>
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> <20210406212509.GS3828@localhost> <046922BE-F850-4B09-8527-D2B014505C44@juniper.net> <20210409160539.GA9612@localhost> <fc12b265-f303-f8bf-da08-ed4616a6dba6@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/N__Qdr3BPEJxsCRtqY-txhhaAdM>
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:40:30 -0000


--On Saturday, April 10, 2021 08:36 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> 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.

There are, of course, already terminology standards about, e.g.,
abbreviations.  They are built into the Style Manual whose
status and future are, as you point out below, uncertain.  Nico,
are you really saying "'direct' the RSE to expand the Style
Manual to incorporate this type of terminology guidance"?  I
agree with Brian that doesn't really work (especially in the
short term), but am trying to be sure I understand what you are
suggesting.
   
>>  - 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.
 
>>  - 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.
> 
>>  - 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.

I agree about weirdness.  However, the RPC (presumably in
coordination with the RSE) and its predecessors have always, at
least theoretically, had the ability to send a document back to
the IESG (or other stream manager organizations) as unacceptable
for the Series until after specified problems are remedied.  At
the discretion of the IESG, that could result in the document
being sent back to the WG, in trying to negotiate, or in
instructing that the document be published unedited (possibly
with a strong disclaimer from the RFC Editor about the document
emitting a bad smell).  Any of those options are rather drastic;
I'd consider it a failure in the system if a document,
especially an IETF Stream consensus document, that required that
sort of mechanism got that far.

And, as Brian and others have more or less pointed out, there
are no guarantees that all aspects of that model will survive
the current discussions about the RFC Editor Function.

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

Right.  But, borrowing from another discussion, plans like "an
AD can override the RPC in a matter like this" have their own
issues, starting from there being absolutely no guarantee that
any particular AD will have expertise in these matters above and
beyond their personal preferences.  And letting ADs dictate the
content and presentation of documents to suit their personal
preferences contradicts most of what we have been saying about
IETF consensus in the last 25 or 30 years.

I continue to believe that we are risking turning something that
should be a process of educating the community and raising
sensitivities -- goals with which the current proposed charter
seems consistent even though I continue to have doubts about it
being the right way to proceed -- into something rigid and a
source of situations that would lead to disputes and require
dispute resolution processes and probably spawn food fights on
this list.  None of that is good for the IETF --and, if it
occurs with any frequency, is likely to cause people to
self-exclude-- no matter the outcome.   I note that the RFC
Editor [Function] has had the ability to say "this terminology
and phrasing is bad for the Series, please fix it" and has been
charged with creating and preserving editorial consistency in
the Series since early in the 1970s.  Despite changes in
personnel and structure, they have been doing that for that
long.   I hope nothing in the RFC Editor future review changes
that, at least without creating an equally or more effective
alternative.  If there is consensus that these terminology
issues represent a problem worth fixing (the draft charter
claims there is and I see no evidence on which to disagree) and
we can, in some way, reach consensus about what is inappropriate
and how to deal with it, I would expect that to make its way
into the editing process (as long as it makes professional
editorial sense).  If we need to start "directing" anyone to do
anything or to talk about "enforcement" procedures and/or
appeals from them, I think we have more fundamental problems
than this particular WG effort could appropriately address...
regardless of how we tune the WG or even if we replace it with a
different model (as, fwiw, I would prefer).

    john