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

Lucy Lynch <llynch@civil-tongue.net> Tue, 06 April 2021 00:00 UTC

Return-Path: <llynch@civil-tongue.net>
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 C00753A2D6F for <ietf@ietfa.amsl.com>; Mon, 5 Apr 2021 17:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 ou-JE707FBff for <ietf@ietfa.amsl.com>; Mon, 5 Apr 2021 17:00:31 -0700 (PDT)
Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) by ietfa.amsl.com (Postfix) with ESMTP id B8FC73A2D70 for <ietf@ietf.org>; Mon, 5 Apr 2021 17:00:31 -0700 (PDT)
Received: from [IPv6:2601:1c0:cb00:5dd1:499d:d3d5:50e5:f0c9] ([IPv6:2601:1c0:cb00:5dd1:499d:d3d5:50e5:f0c9]) (authenticated bits=0) by hans.rg.net (8.16.1/8.16.1) with ESMTPSA id 13600QwL071122 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Tue, 6 Apr 2021 00:00:26 GMT (envelope-from llynch@civil-tongue.net)
Content-Type: multipart/alternative; boundary="Apple-Mail-06D8BC6A-F6EF-4D53-83FF-04EB0A1F7A35"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
From: Lucy Lynch <llynch@civil-tongue.net>
In-Reply-To: <792c4815-8c36-e5fa-9fbe-2e1cfa97239f@comcast.net>
Date: Mon, 05 Apr 2021 17:00:20 -0700
Cc: ietf@ietf.org
Message-Id: <1FCC05BC-8903-4E8B-BB6D-7A90DA6337A6@civil-tongue.net>
References: <792c4815-8c36-e5fa-9fbe-2e1cfa97239f@comcast.net>
To: Michael StJohns <mstjohns@comcast.net>
X-Mailer: iPad Mail (18D70)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/-CSsJcagONbh5FR0HyK6BrGBiok>
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 00:00:34 -0000


> On Apr 5, 2021, at 4:31 PM, Michael StJohns <mstjohns@comcast.net> wrote:
> 
> 
> On 4/5/2021 7:11 PM, Michael StJohns wrote:
>> 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. 
>> 
> *sigh* Ignore the above. Joel H reminded me of Poised, Poisson of the previous century and Newtrk of the previous decade.   I'm sure there are others.
> 
> 
> 

And the late and unlamented Problem-Statement which produced two RFCs
(3774 and 3844) I’m sure Melinda and Harold still bear a few scars.


>> 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 model.</minirant>
>> 
>> 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.
>> 
>> Mike
>> 
>> 
>> 
>