Re: IESG Statement On Oppressive or Exclusionary Language

Nico Williams <nico@cryptonector.com> Sun, 09 August 2020 05:30 UTC

Return-Path: <nico@cryptonector.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 4DA333A0317 for <ietf@ietfa.amsl.com>; Sat, 8 Aug 2020 22:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=cryptonector.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 cTYywZQzmvxx for <ietf@ietfa.amsl.com>; Sat, 8 Aug 2020 22:30:46 -0700 (PDT)
Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (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 DC09C3A02F9 for <ietf@ietf.org>; Sat, 8 Aug 2020 22:30:45 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B3EFF700357; Sun, 9 Aug 2020 05:30:44 +0000 (UTC)
Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-19-29.trex.outbound.svc.cluster.local [100.96.19.29]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 379C07002D6; Sun, 9 Aug 2020 05:30:44 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a15.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Sun, 09 Aug 2020 05:30:44 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Print-Cooperative: 4d632e0c0ac5b249_1596951044493_918256983
X-MC-Loop-Signature: 1596951044492:1802216691
X-MC-Ingress-Time: 1596951044492
Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id D09BD83C0F; Sat, 8 Aug 2020 22:30:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bzvUskhAquRAEl 5MmfXIcRJz7ug=; b=UWEitv2QoC7p+Wa7s/n0aDmx+vLwE7vcQ+iwS9y+W62jv4 cQrFqcTHQfo+DrUfwnjbpdlnUuY4uLQotJZkhrjYO5qS0psr391j2TQbdyJSxhZD T0loXE4+DmEh661kdngKg8qxZ8NSO/03WGqwOAVOqFq/qY7F9rMgoNqQPWjk0=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTPSA id E1C5583C1C; Sat, 8 Aug 2020 22:30:41 -0700 (PDT)
Date: Sun, 09 Aug 2020 00:30:39 -0500
X-DH-BACKEND: pdx1-sub0-mail-a15
From: Nico Williams <nico@cryptonector.com>
To: John C Klensin <john-ietf@jck.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, ietf@ietf.org
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
Message-ID: <20200809053037.GV3100@localhost>
References: <20200807171546.GP40202@straasha.imrryr.org> <737B9515-C538-4EEB-8A5D-672987A0FE86@akamai.com> <20200807190716.GQ40202@straasha.imrryr.org> <845bd95e-0d95-a164-40f9-e9c45feed6dc@gmail.com> <6D464C5C-D9CB-47A1-A8BB-CD8CAD21B779@cooperw.in> <B5969C0B-EF25-40CF-BFB4-8E062C90CA24@gmail.com> <90fd8bff-c81c-5518-65c6-b929132a4bdd@comcast.net> <44B55324558FD335BADB4165@PSB> <56fd2677-df6a-8ff2-6093-6e8d42442973@joelhalpern.com> <60160A936BE682CEDE0704E1@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <60160A936BE682CEDE0704E1@PSB>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrkeehgdelhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/oN1GKwwSx8Qzy5oK2oWDAYmJUic>
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, 09 Aug 2020 05:30:47 -0000

On Sat, Aug 08, 2020 at 11:48:27PM -0400, John C Klensin wrote:
> > Such a list would, it seems to me, help genart reviewers at
> > least keep the question in mind.
> 
> Yes, but that takes me/us back to suggestions made weeks ago,
> i.e.,
> 
> (i) We treat this IESG statement and the underlying I-D as
> having done a great job of increasing the community's
> sensitivity to the issues of choices of language, largely
> independent or how those issues are defined.
> 
> (ii) We conclude that we really don't need to get to an official
> vocabulary, especially an official negative or discouraged
> vocabulary/ work list.
> 
> (iii) With the community's new-found sensitivity, we encourage
> document reviewers, especially within WGs in addition to IETF LC
> (or any particular review team) to spot unfortunate language as
> they read through documents.  When should language is spotted
> (again, preferably early in the document life cycle) it should
> lead to discussions with authors about whether the language is
> appropriate and possible alternative.  Reviews during IETF Last
> Call (or later) and public comments on the language should be
> viewed as a last resort although possibly a necessary one.

Exactly.  We don't need an official list of verboten language.  If we
do, I'll have to ask why not an IANA registry.  (FCFS might be "fun".
Obviously this is a reductio ad absurdum argument.)

Anyways, where is the evidence that we have a language problem?  I'm not
asking for evidence that the items on the proposed... verbotenlist are
offensive[*].  I'm asking for evidence that we [still] use them
regularly.

Can we see a thorough analysis of their use in IETF RFCs, together with
trend lines?  It's a small bit of research[**].

Propoent(s) should do the bare minimum of analysis to demonstrate that
there is a problem at least in those dimensions that are amenable to
statistical analysis (actual use, as opposed to actual offensiveness).

Supposing a proper analysis demonstrates no current or recent usage,
then what?  Would proponent(s) drop the matter, or press on?  If press
on, is the reason fear that uninformed authors might make use of these
terms and that uninformed reviewers, shepherds, ADs, and RPC staff might
allow their use to go unchallenged?  Would that be sufficient?  Would
such a fear be well-founded?  Are there other motivations I might be
missing?

[*] Their offensiveness may be subjective, though we can objectively
    agree that some/many claim that they are offensive, and perhaps
    whether that is sufficient to ban them.

[**] First, download all the RFCs, and maybe also all I-Ds, then write
     some regular expressions to search through them, then analyze the
     result paying close attention to the possibility of false
     positives.