Re: IESG Statement On Oppressive or Exclusionary Language

Fred Baker <fredbaker.ietf@gmail.com> Sun, 02 August 2020 06:10 UTC

Return-Path: <fredbaker.ietf@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 C7E5B3A0870 for <ietf@ietfa.amsl.com>; Sat, 1 Aug 2020 23:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bdvzJeahQqUV for <ietf@ietfa.amsl.com>; Sat, 1 Aug 2020 23:10:52 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 66E663A0846 for <ietf@ietf.org>; Sat, 1 Aug 2020 23:10:52 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id u10so9728617plr.7 for <ietf@ietf.org>; Sat, 01 Aug 2020 23:10:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vBGdWFoCjq5LKKDY+AkEIp7htAU6p9EXsdgMNTAcxUo=; b=Vq4iYNd4A9uzhhYOl8lz/Zk+T9uVApWMrAxSA3Hgd7+9n0NM3xlQGYHEZmN/7pU7Wj g9ib4rtxGQJGX9bppU0hSJzWOfvDS4FOG0wKm+H4VgXq9ceVpwSZVo5IM62siCYrJvvD On8YJM825ObCHIaT1x9EXoPs1uIuOfamAeghyYGaUS01o7cPQNMmJk0bLSOK4dySFCw2 6F4bgKUKDQfy2MXP1i4/dXIE6yY2FTZ1WM0ee8QiKoMoxUE41OavKInU64VdLljjLM7B V0fL8H0jxRlzkbKpoKTJ35U4Y+oSlxA1ZkCEqsKzLy46jM/LqSz3jfJiMszehp81v21E chhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vBGdWFoCjq5LKKDY+AkEIp7htAU6p9EXsdgMNTAcxUo=; b=sceJhsbmg36PLYiwij9stgc7DVzYa95BXCXR0Q36kT1zHq/AoES08//VAcQJ6Mwx3W 7z4WW5hbVzfBnwH1V7RRLVSLqA5Nfz0q7r5BeZIHgQpMxEsLf9+dYlGWTPXUBD6UmYe8 sRPj1u36IUBDzHPoupFiH3kl7cG6pvDPg2cJ4THKxCpOzCjWTEggWmJzBfnMNK2Rz9fI 5RYEJGw4jHTsIn/GQE5szvJhNXRpibWk69Vo6Rl7R1RfXa5m8DJ3CWz4RIkRnH1e3epW nJmhanPfD52K07IDFAgrr8YUEmIJt76kO/vY8tsPXgYZ3gkg4aJ2HXTgoWNRunjV1h4g Gceg==
X-Gm-Message-State: AOAM532Ll+ZYFwd5LEZ6WTKMFvOHDtgV/o3flgZ13o1TxOWUh62iaXWV h6fWimnp422h0LnyOY9Lk0+OL1g3tIk=
X-Google-Smtp-Source: ABdhPJx2CqnvFlwueIDhijNRyMm9B9OO13X3POrzynSbOQaORgIIGCfjsVmsTzeioxJX1qz+csqKqQ==
X-Received: by 2002:a17:90a:3488:: with SMTP id p8mr11975392pjb.211.1596348651641; Sat, 01 Aug 2020 23:10:51 -0700 (PDT)
Received: from ?IPv6:2600:8802:5800:652::199f? ([2600:8802:5800:652::199f]) by smtp.gmail.com with ESMTPSA id q66sm15673742pga.29.2020.08.01.23.10.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Aug 2020 23:10:50 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <159552214576.23902.6025318815034036362@ietfa.amsl.com>
Date: Sat, 01 Aug 2020 23:10:49 -0700
Cc: Mallory Knodel <mknodel@cdt.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <88B9381E-F104-4083-8482-C5ED78636551@gmail.com>
References: <159552214576.23902.6025318815034036362@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EytCs7u3j0DaHabj7pCC2BFzUy4>
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: Sun, 02 Aug 2020 06:10:54 -0000

I am following up on the IESG's invitation of comments from the community.

Attached, please find the result of an grep -w -f ... looking for the words discussed in draft-knodel-terminology:
	Master
	Slave
	Blacklist
	Whitelist

If we are going to enact the proposed policy, I would suggest that we don't try to change RFCs that have already been published, or documents on any kind that derive from another source. The IESG's note comments that these are "complex" to perform, and I would agree with them. I would add that in any context in which a defined term is being used, use the defined term. If you want to change the term, you need to be very clear about it. What we can do that makes sense, IMHO, is not use them in future documents unless their origin is clarified.

I do take some exception to the statement, made in Mallory's draft, that the terms are "inaccurate". I suspect that the terms are being used in a manner entirely in keeping with their definitions. A "master" controller, per lawinsider.com, is "a controller supervising the operation of several local controllers.". Per yourdictionary.com, a "master program" I "The program in control of the machine.". Looking at several sources ("google is your friend"), a slave changes its configuration to agree with its master, and behaves accordingly. Again, Google is your friend, but a blacklist is according to several definitions a list of identities to be denied access, and a whitelist is a list of identities to be accorded access. If the operation is consistent with ambient definitions, it is not "inaccurate". It may be "other than preferred", but it is not "inaccurate".

There is no human being identified by the color of their skin or by the relationship between employer and employee; if there were, are are a few other colors and operating modes that would have to be discussed. There is also long historical precedent, stretching back at least to the period prior to Moses leading Israel out of Egypt.

I have made these comments in hrpc. They were dismissed as originating from a "white male". The issue of exclusionary language in the course of hrpc was reported to the chair of that group, and was not acknowledged. 

> On Jul 23, 2020, at 9:35 AM, The IESG <iesg@ietf.org> wrote:
> 
> The IESG believes the use of oppressive or exclusionary language is 
> harmful.  Such terminology is present in some IETF documents, including 
> standards-track RFCs, and has been for many years. It is at odds with 
> our objective of creating an inclusive and respectful environment in the 
> IETF, and among readers of our documents.
> 
> The IESG realizes that the views of the community about this topic are 
> not uniform. Determining an actionable policy regarding problematic 
> language is an ongoing process. We wanted to highlight that initial 
> discussions about this topic are taking place in the general area (a 
> draft [1] is slated for discussion in GENDISPATCH [2] at IETF 108).  
> Updating terminology in previously published RFCs is a complex endeavor, 
> while making adjustments in the language used in our documents in the 
> future should be more straightforward. 
> 
> The IESG looks forward to hearing more from the community, engaging in 
> those discussions, and helping to develop a framework for handling this 
> issue going forward.
> 
> [1] https://datatracker.ietf.org/doc/draft-knodel-terminology/
> [2] https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03
>