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

"Joel M. Halpern" <> Tue, 06 April 2021 21:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 503D43A3125 for <>; Tue, 6 Apr 2021 14:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TzWgo8OLnWwQ for <>; Tue, 6 Apr 2021 14:10:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C29F3A3103 for <>; Tue, 6 Apr 2021 14:10:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FFKt375jkz1nsLM; Tue, 6 Apr 2021 14:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1617743404; bh=qyd+WosNq71mLnH4YtBlXA3s6UBGfgdYF31GM8zovkM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pfKggFr1rn9rveL0pn2BF/NteNx8lT6ULPIkIvAXpVFpB02ENwYeCnptkSXTQAo+f yYyKbzhBH6zSavijWrANtZ3Kn6cg2dr6/M3SmtXj3XGTZFY9iFho1vbpB33cIRXNOp +HoTP0kWX2b/Wru424Bkn2297ii5vM3T3N9G0Luw=
X-Quarantine-ID: <tar7Cj9QOmUA>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4FFKt31zGKz1nsZ0; Tue, 6 Apr 2021 14:10:03 -0700 (PDT)
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
To: Brian E Carpenter <>, Nico Williams <>
References: <> <> <> <D18D87D95723A68D8E75B6BC@PSB> <20210406152930.GR3828@localhost> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 6 Apr 2021 17:10:02 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Apr 2021 21:10:15 -0000

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.


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