Re: [Gendispatch] draft charter text: terminology-related WG

Dan Harkins <dharkins@lounge.org> Fri, 12 February 2021 01:24 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE003A0CF4 for <gendispatch@ietfa.amsl.com>; Thu, 11 Feb 2021 17:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 67JV9k1aysNS for <gendispatch@ietfa.amsl.com>; Thu, 11 Feb 2021 17:24:53 -0800 (PST)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D42D3A0CDD for <gendispatch@ietf.org>; Thu, 11 Feb 2021 17:24:53 -0800 (PST)
Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QOE0AY4E6LHA6@wwwlocal.goatley.com> for gendispatch@ietf.org; Thu, 11 Feb 2021 19:24:53 -0600 (CST)
Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QOE00NDO6JWO6@trixy.bergandi.net> for gendispatch@ietf.org; Thu, 11 Feb 2021 17:23:57 -0800 (PST)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 11 Feb 2021 17:23:57 -0800
Date: Thu, 11 Feb 2021 17:24:50 -0800
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <3e265d14-9993-8922-3cc6-855609f61829@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, gendispatch@ietf.org
Message-id: <41eb17bd-8c51-9b89-7e0b-6686e9e1a90e@lounge.org>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_DKJFRDqVhcFjCthS2N5X0w)"
Content-language: en-US
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local)
References: <A531C377-33A4-4138-BE28-788FF5FE267E@sn3rd.com> <CABcZeBPxQrzQZZ2ec+cvpovdkJaXcQ4f8Ged7Om1QPg7UrZ_Ew@mail.gmail.com> <d8312f55-c1c8-7d55-3d0f-e8617be30a94@lounge.org> <3e265d14-9993-8922-3cc6-855609f61829@cs.tcd.ie>
X-PMAS-Software: PreciseMail V3.3 [210211] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/i-d7HlWgrkmrVlC7JZQSXDwIJCQ>
Subject: Re: [Gendispatch] draft charter text: terminology-related WG
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2021 01:24:56 -0000

   Howdy Stephen,

On 2/11/21 4:48 PM, Stephen Farrell wrote:
>
> Hi Dan,
>
> (Top quoting as this is just a question, but I know you care
> about this and have also been active in IEEE...)
>
> Via mail to new-work/secdir today, I see that IEEE 802 (and
> I've no idea if people are co-ordinating or not) seem to be
> starting a fairly similar acctivity. [1]

   I was not aware of this. Thanks for pointing it out.

> My question is just: do you think the same about IEEE's
> efforts, or is there any interesting difference?

   Yes, I would like to see IEEE 802.1 define "non-inclusive" and 
"insensitive"
before they go about requiring the replacement of terms. I will have to see
about insisting on that.

   There was a back channel effort by an IESG member to get IEEE 802.11 to
change the term "master key" in their standard and I put the kibosh on it
because that is just blind substitution of words without thinking. A "master
key" is a term of art that derives from locksmithing. There is nothing
insensitive about that term and it defies reason to say that some class of
people have been excluded from locksmithing, and by inference will be 
excluded
from wi-fi, because this term was used.

   You seem to think I'm against these efforts. I'm not against making our
documents more clear, more precise, and more accessible. I'm against blind
word substitution and I'm against banning of certain words. And I think it
is quite galling that affluent, credentialed, white people are at the
forefront of this effort to define how groups of people who are not white,
affluent, and credentialed behave when they read common terms of art.
That's patronizing and it's offensive. So I'm against patronizing and
offensive behavior, even if it's done with the best of intentions, but
not necessarily against cleaning up our documents.

   regards,

   Dan.

> Ta,
> S.
>
> [1] https://www.ieee802.org/1/files/public/docs2021/dr-PAR-0221-v01.pdf
>
> On 12/02/2021 00:25, Dan Harkins wrote:
>>
>>
>> On 2/11/21 1:56 PM, Eric Rescorla wrote:
>>>
>>> On Thu, Feb 11, 2021 at 12:39 PM Sean Turner <sean@sn3rd.com 
>>> <mailto:sean@sn3rd.com>> wrote:
>>>
>>>     Hi!,
>>>
>>>     Here is some proposed charter text to address the
>>>     terminology-related WG.
>>>
>>>     Cheers,
>>>     spt
>>>
>>>
>>> This looks like a great start. A few small comments below.
>>>
>>>
>>>     Effective Terminology in IETF Documents (TERM)
>>>     ----
>>>
>>>     The mission of the IETF as specified in BCP 95 is to produce high
>>>     quality, relevant technical documents that influence the way
>>>     people design, use, and manage the Internet. As RFC 7322 explains,
>>>     "The ultimate goal of the RFC publication process is to produce
>>>     documents that are readable, clear, consistent, and reasonably
>>>     uniform." RFCs and Internet-drafts are most effective when they
>>>     use terminology that is clear, precise, and widely accessible to
>>>     readers from varying backgrounds and cultures.
>>>
>>>     In the years leading up to the chartering of this working group,
>>>     there has been discussion in the IETF, in other standards
>>>     organizations, and in the technology industry about the use of
>>>     certain terms (such as “master/slave” and “blacklist/whitelist”)
>>>     in technical documentation and whether those and other terms have
>>>     effects on inclusivity. While opinions vary among IETF
>>>     participants about this topic, there is general agreement that the
>>>     IETF community would benefit from informational recommendations
>>>     about using effective and inclusive terminology in IETF documents.
>>>     The TERM working group is therefore chartered to produce an
>>>     Informational RFC containing recommendations on terminology to use
>>>     in technical work produced by the IETF.
>>>
>>>
>>> I think it might be helpful to scope out a little more what this RFC 
>>> might contain. Perhaps:
>>>
>>> These recommendations will consist of (1) general principles for 
>>> judging when language is inclusive or exclusive (2) a list of 
>>> specific terms to avoid and recommendations for alternatives.
>>
>>    I agree with (1), in fact I would like to see some principles for 
>> what defines "inclusive"
>> and "exclusive". Right now it seems like how one defines pornography, 
>> i.e. "I know it when
>> I see it". The problem with that is that we end up with some 
>> self-appointed New Moral Majority
>> defining for everyone what "exclusive" or "inclusive" is, and I'm 
>> sorry but hell no. I'd
>> rather add some new fangled version of the Parental Advisory Notice 
>> that the previous group
>> of morality busybodies put on albums back in the 80s and 90s into the 
>> boilerplate of RFCs
>> and I-Ds.
>>
>>    As far as (2) is concerned, you only call out for a list of terms 
>> to avoid and their
>> replacement terms, which seems to play to the conspiracy that this 
>> whole thing is about
>> policing speech-- "you can't say that." Is "inclusive" merely the 
>> alternative to the bad
>> word that has been defined as "exclusive" or are there some words 
>> that would make RFCs be
>> more clear, precise, and widely accessible that don't have a naughty 
>> synonym?
>>
>>    regards,
>>
>>    Dan.
>>
>>
>

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius