Re: IESG Statement On Oppressive or Exclusionary Language

Joseph Touch <touch@strayalpha.com> Thu, 23 July 2020 20:50 UTC

Return-Path: <touch@strayalpha.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 176883A0D96; Thu, 23 Jul 2020 13:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 DbzeZ2nv3ZbT; Thu, 23 Jul 2020 13:50:31 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 A9C583A0D9F; Thu, 23 Jul 2020 13:50:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lASNFgOwCZkmo6Psd71zNxbbs2POmRymA7Pay6BZHn0=; b=dB4v6tpHE42Rp3ukx/lqlybCP J7Or9Tg/b1k/Ij+ENb/qsKrz3dIsgyJPmenIvlVlzRLogh98GF60zZ274J2ZRH4imRwhGF+VxNEBF RxDyONnWtKibtC0bOfMjXGh9W5vfVUr88p+UAFHl73BS07ucF59xOsRCJ56aqVIDZN3XbeKl4ryf0 Id5VhrwO9WdtvemUBk6Gj2sa/e8DUGGQgOeodQH2FZVbPtf+xWRVqpQQ3JloYSif+ZXXc/yL/to5R LqKREO7Te4YrOWkgWbkiUCZevXwzHcHbrx8oRHcGGGZONI9wAKM+F4flq7ACxTpuyh+RSDNWOxlU9 Juz06RDPQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50661 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1jyiAc-003lS0-SO; Thu, 23 Jul 2020 16:50:31 -0400
Content-Type: text/plain; charset="utf-8"
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: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <159552214576.23902.6025318815034036362@ietfa.amsl.com>
Date: Thu, 23 Jul 2020 13:50:26 -0700
Cc: IETF Announcement List <ietf-announce@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <462DDF07-A04D-4438-B854-1F52E0A7FB3D@strayalpha.com>
References: <159552214576.23902.6025318815034036362@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nn9_MekU7lLsRWCnVv3nn4Nxzfg>
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: Thu, 23 Jul 2020 20:50:33 -0000

Hi, all

I think this doc could be more useful if it leaves the discussion and debate of context to a single background section with at most one paragraph each on a few examples. Instead, it should spend more time providing groups of suggested alternatives with explanations as to when each might be more accurate, e.g.:
	
	primary-secondary	when limited to two instances, one of which is privileged
	primary-replica	when more than two instances are possible, one of which is privileged

I agree that none of this doc should mandate when to use any particular alternate, but it should say that documents SHOULD NOT use the exclusionary language except in direct reference to legacy uses. Leave it to the community and RSE to help clean things up - and yes, tools help here too.

(i.e., I can’t see how we can get around pointing out the correspondence between current and legacy terms in future docs or external standards, not just here).

FWIW: alternates for primary-replica when one is in control could be:

	leader-follower
	commander-subordinate

Recognizing that this doc can never be complete, we should scrub the current RFCs for terms that we think should - or could - be used. Below are a few I found that we either need to provide alternatives for or explain are not currently known as problematic (i.e., a more complete ‘accept/deny’ list). It would also help to point out that the list should include other areas, such as:

	ageist terms
	sexist terms
	disability terms

Joe

--------

Additional “deny” list (note that most of these I either found in RFCs are other tech literature):

	grandfather(ed)
		legacy/legacied

	whitewash
		(none - euphemism that may be better phrased directly)

	black and white (referring to binary decisions with clearly desirable outcomes)
		(none - euphemism that may be better phrased directly)

	gyp (as in to short-change or cheat)
		cheat/swindle

	greybeard (as senior member of a community)
		senior member

	greylist (because it is derived from white/blacklist)
		partial accept/admit

	minon
		follower/subordinate

	dummy
		placeholder

	sanity check / reality check
		validity check / correctness check / confidence check / quick check

	bitch
		complain

	hobbled
		undermined / made less effective by 

	there’s also the question of whether we can avoid gendered terms for people (he/she/guys/dude, his/her)

“Accept” list (or at least I think they are; please point out if otherwise):

	black/red as network security levels

	black and white referring to images (i.e., binary greyscale)

	dark web/net

	grey web/net (as in partially dark)
		FWIW, I prefer “dim” to grey as being more clear, but that’s me

	white pages / yellow pages (refers to historical use of paper of those colors to publish phone directories)

	white paper (a brief though-piece)

	black hole

	black box

	red/green, red/yellow/green

	red (as a warning or error)

Joe