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

Michael StJohns <> Mon, 05 April 2021 23:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE92E3A2BE8 for <>; Mon, 5 Apr 2021 16:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Status: No, score=-2.799 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0xx1R3Th0-DZ for <>; Mon, 5 Apr 2021 16:11:20 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 393E03A2BE3 for <>; Mon, 5 Apr 2021 16:11:20 -0700 (PDT)
Received: from ([]) by with ESMTP id TUsplMRDozQhpTYNKl8UPj; Mon, 05 Apr 2021 23:11:18 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20190202a; t=1617664278; bh=jirhOIes1eAfLWXu+vCBnb9g+quqLgphqizVNO3lvlU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=jVIBXV1FwE9tIB7/NZbBIYd82SV5Uqt0eoogUEnaPW2sFTHrQ2gl5Q6yKHXbQMIdT uikk5Xd1Pw5DN/0U0ewM+hvbvopmBNT14bDHbvhoNWJskTYYYpXFki/jJJlu6ctmP5 DZnfH6zF0mMZOEYNvriAijet2UFMGmiqFgtpttT6fzw6lCzFSi3Metu/C2tvW6H+vs jqyyQEDtlC5Pti6re8WmrdiPMcH6TfiTcOm0jZcaUcXm5nCq0q/jDZL/JmyCSYDulv dXy6mjFpmTyOs4LiteJuDyiOANFyMWavPCqIxjSNkrEtmmep6PsLkGbeoqA6qRG3hL Nw9ZyWix2h08A==
Received: from [] ([]) by with ESMTPSA id TYNAlqBZx3gbqTYNBlHvr7; Mon, 05 Apr 2021 23:11:16 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduledrudejfedgudeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpefoihgthhgrvghlucfuthflohhhnhhsuceomhhsthhjohhhnhhssegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeeuvdefgfehgefhfffgleegueekleehhfejkeeggedvveetffdtkedukeefueduheenucfkphepudefkedrkeekrddvtdegrddukeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrvdefngdpihhnvghtpedufeekrdekkedrvddtgedrudekpdhmrghilhhfrhhomhepmhhsthhjohhhnhhssegtohhmtggrshhtrdhnvghtpdhrtghpthhtohepihgvshhgsehivghtfhdrohhrghdprhgtphhtthhopehivghtfhesihgvthhfrdhorhhg
X-Xfinity-VMeta: sc=-100.00;st=legit
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
To:, The IESG <>
References: <>
From: Michael StJohns <>
Message-ID: <>
Date: Mon, 5 Apr 2021 19:11:08 -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: multipart/alternative; boundary="------------2B3929E94A70B30BF9A2D8B0"
Content-Language: en-US
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: Mon, 05 Apr 2021 23:11:23 -0000

For some reason I can't find the original announcement, so I'll just do 
this bare.

Given the general language of RFC 2418, my best take is that _*it's 
inappropriate for the IETF to charter a working group on this topic*_.   
It's not a technical topic, and it does not fit the general WG model.

To my best recollection (which means I may have missed one), we've never 
chartered a WG solely for the purpose of writing documents that purport 
to modify the way the IETF does business. Such documents have usually 
come either as IESG / IAB authored/sponsored BCPs.  Indeed, BCP 95 was 
just such a document.   WGs have been (should be?) for technical 
activities related to specifying how the Internet works.

<minirant>Technical WGs at least have the possibility of achieving 
consensus based on the analysis of tradeoffs of hard facts and good 
analysis.  A "WG" such as TERM may fail of achieving even WG consensus, 
let alone community consensus (especially given the current ongoing 
discussions) and there will be no fall back to fact analysis possible.   
I can't see any way an appeal could be managed in those circumstances 
and I strongly suggest we do not try to place this in the WG 

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.

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.