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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 06 April 2021 20:58 UTC

Return-Path: <brian.e.carpenter@gmail.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 D8AEB3A308F for <ietf@ietfa.amsl.com>; Tue, 6 Apr 2021 13:58:44 -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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ycs9JFx4glcj for <ietf@ietfa.amsl.com>; Tue, 6 Apr 2021 13:58:40 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F30F3A3089 for <ietf@ietf.org>; Tue, 6 Apr 2021 13:58:40 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id d124so2487615pfa.13 for <ietf@ietf.org>; Tue, 06 Apr 2021 13:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mw0FZQbrtZX+ipj0lHq9gd3ZZ4nbF/T/XEqrtC+IpiY=; b=MzRSnnA8uRPJ+6S3JgQgtAMqZZ6DzxEyihp+U9fxI6uZi3Jd19cqN8K5M3V5DoVvvf E+rBWoLUHlpNrfdgIQffSxZZn0ngDeLaCXywXyRTnWuMr793q/EJ3anSgH9UUcFcwBPI 4CkUfi6Wv1gBSWEgAuMu2gUAHJtNZhHk1DjfmQLsWieCVKWyOlhvyuJ9CprLZTZI2dw5 vW1zyk3atpKnkuCaWwerJtyWYy+CArgVYDSSzWxzor9J/4yi6f8WNthvkIs1zE6xHHWO f3f1FaAUCqpyRpeUWyDJbspgczxWOINthIzS9pwkRXG/WF/MK0dseCdCwDjfNUrItde1 1vxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mw0FZQbrtZX+ipj0lHq9gd3ZZ4nbF/T/XEqrtC+IpiY=; b=fKZJxwfYRcqUIhNvuLEfuI5n0Tfx5RMJqmjD4+L7YFzu4tus6/kGiWf6WfSSGhvRUt 11oOqmfrC7dcCCxvyVmsykLmprsmvfB1QR6YJbMGXJBz5tA3rwas0ud9CTTguwR5NUwr f4xE1llDAOgqBs3zRR4fi1o5WSrjvZ0bGz4zgf2ojrPY4GIn3DxyT1FW8PwNW7xfwk5F 1EWe6qG3w/kAWg+TOCR028lvVvl8FcyM/zwWFMJcweIdCIzxGsiKm60XV+32lY5U5w2/ 1fH/fQrziVGM4I6dzsBiDAq2fQegSvZIrhLS+jFnTkJ8BmSj67GtGXTJrdfnzdy3RfjK 1y5A==
X-Gm-Message-State: AOAM533HFLo+kj8iFR3KfQOc6Ub+48tI4h68TrvZrnayzHadw/WKqFuA oSYXvC5ekrZbi2b4MwsASuK/a95aoWRJwA==
X-Google-Smtp-Source: ABdhPJxjQ4K2XUwHDiPyhb8K8na5zhvVf6DieYxQVM4wXST/aruatIZ6262ycvsf8zDztgvmApJJWg==
X-Received: by 2002:a05:6a00:2b4:b029:1f6:6f37:ef92 with SMTP id q20-20020a056a0002b4b02901f66f37ef92mr4639pfs.56.1617742718140; Tue, 06 Apr 2021 13:58:38 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id f6sm20527525pfk.11.2021.04.06.13.58.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Apr 2021 13:58:37 -0700 (PDT)
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
To: Nico Williams <nico@cryptonector.com>
Cc: ietf@ietf.org
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <f52c46cf-03fb-6692-3a87-9b7db639f2e9@gmail.com>
Date: Wed, 7 Apr 2021 08:58:31 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20210406152930.GR3828@localhost>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/gxCWNvcZ0AJQUFOaxehWAblZi4I>
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 20:58:45 -0000

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.

Regards
   Brian Carpenter

On 07-Apr-21 03:29, Nico Williams wrote:
> On Tue, Apr 06, 2021 at 12:08:55AM -0400, John C Klensin wrote:
>> [...]
> 
> I think this is the most helpful message yet on this topic.  I'm afraid
> that my saying so might cause others to ignore it, but I hope that's not
> the case.
> 
>> Despite having community consensus that the problems it intended
>> to address were important, I watched NEWTRK leave scars that
>> have not healed.  Others would probably disagree, but I suggest
>> it demonstrated the willingness of the IESG to decide that its
>> experience and perspective in IETF process matters were more
>> valid and important than the consensus of the WG, so much so
>> that there was no reason to try to ascertain IETF rough
>> consensus before dismissing the WG's key results without an IETF
>> Last Call.  I have no reason to believe the current IESG would,
>> or even might, do that but, to the extent to which the IESG has
>> proposed this as a WG, if it is going to be chartered as a WG,
>> it would be very desirable to design a different mechanism for
>> managing Last Calls and evaluating community consensus than the
>> same IESG.    And that is probably just another argument for
>> "not as an IETF WG".
> 
> There is a big difference between the IESG saying "we will not go
> forward with this work in spite of it having WG and possibly IETF
> consensus" and the IESG saying "we must go forward with this work in
> spite of it lacking consensus".  The former is painful but within the
> IESG's privilege.  The latter is outside the by-laws of the
> organization.  The IAB would be a better body for pursuing publication
> of work that lacks IETF consensus, would it not?
> 
>>>> Since the proposed charter for Term will effect more than
>>>> just the  standards process (e.g. it potentially effects all
>>>> of the current and  future RFC streams), it would appear this
>>>> should be handled either as  an IAB activity (either
>>>> authored, or referred to a workshop), or  deferred until the
>>>> RFCED group completes its work and can have this  assigned as
>>>> a work item.
> 
> Ah, I'm hardly the first to think the IAB is a better home for this.
> 
>> I would go a bit further.  Because responsibility for
>> determining the appropriateness of vocabulary in the RFC Series
>> has traditionally been the responsibility of the RFC [Series]
>> Editor (going more or less back to the beginning of Jon Postel's
>> administration and continuing through Heather's), launching this
>> effort now would likely have the effect of adding an unneeded
>> additional impediment to the RFCED group reaching consensus on
>> its core tasks and/or setting us up for additional future work
>> to harmonize the two.
> 
> Yes.  I would be perfectly happy and content with the RSE questioning
> the use of the terminology in question in I-Ds on the RFC-Editor queue.
> I would be perfectly happy and content with the RSE disallowing the use
> of various terminology in I-Ds on the RFC-Editor queue.
> And I've said so before.
> 
> One of the many reasons to prefer this approach is that it allows the
> RSE great flexibility, which -considering how painful this process has
> been thus far- should be highly desired as new terminology controversies
> arise.
> 
>>>> My first preference is to do this as an IAB Workshop report
>>>> with no  BCP tag and with as dispassionate an analysis and
>>>> output language as  possible.  E.g. explanatory language vs
>>>> directive.
>>
>> Agreed.  There is no doubt in my mind that we have language and
>> terminology problems, especially when those are considered
>> broadly and cross culturally.  I think it is reasonable and
>> appropriate that we do as much as possible to educate the
>> community, and especially would-be I-D or RFC authors, about the
>> issues.  That requires analysis, explanation, and guidance, not
>> directions or rules (and especially not directions or rules on
>> which we will not be able to agree and that will cause further
>> divisions in the community because of the lack of agreement.  I
>> think it is also reasonable and appropriate for people who find
>> what they think is inappropriate language in a draft in a WG or
>> submitted for Last Call to raise those issues, both in the hope
>> of getting the language fixed and to facilitate education of the
>> authors.   But, if there are any lessons from any of our recent
>> efforts in WGs designed to specify important aspects of the
>> standards process or from the intensity and tone of the recent
>> discussions of terminology on the IETF list, those lessons are
>> that there is no community consensus (even rough consensus) that
>> this work should be done in a way that would (or might)
>> establish specific directions for vocabulary or behavior and
>> that, absent such consensus, the results are as likely to be
>> destructive as helpful.
> 
> +1
> 
> Nico
>