Re: IESG Statement On Oppressive or Exclusionary Language

Nico Williams <nico@cryptonector.com> Sun, 09 August 2020 06:38 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 060CE3A084B for <ietf@ietfa.amsl.com>; Sat, 8 Aug 2020 23:38:14 -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_DNSWL_NONE=-0.0001, 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 eCxa5il83YXy for <ietf@ietfa.amsl.com>; Sat, 8 Aug 2020 23:38:12 -0700 (PDT)
Received: from cheetah.birch.relay.mailchannels.net (cheetah.birch.relay.mailchannels.net [23.83.209.34]) (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 845063A084D for <ietf@ietf.org>; Sat, 8 Aug 2020 23:38:12 -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 B343C640F22; Sun, 9 Aug 2020 06:38:11 +0000 (UTC)
Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-23-22.trex.outbound.svc.cluster.local [100.96.23.22]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 42CCD640DD4; Sun, 9 Aug 2020 06:38:11 +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 06:38:11 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Bored-Bitter: 33b39945798794bb_1596955091507_1955143127
X-MC-Loop-Signature: 1596955091507:817269101
X-MC-Ingress-Time: 1596955091507
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 EA25883C23; Sat, 8 Aug 2020 23:38:10 -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=WKFdeC1CAZHGyU 0aLozmw6CfI2E=; b=P4tz8p6I0L5+myPTdv+e3X+fv6s/Qt+jfyuHXjLnDMLDc5 rQOBKXBa+9zpvuj2dcsNOhDKrGJ0Soga36E9sFNdWUog4PcaF8RSvXSIQIQmxTQ6 NBE5xJDsbJ9duvknJE14/PHZdFhfjFMdd68w7HgqIbPH8EceX94TEKK1UAL/U=
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 2992D83C2B; Sat, 8 Aug 2020 23:38:09 -0700 (PDT)
Date: Sun, 09 Aug 2020 01:38:06 -0500
X-DH-BACKEND: pdx1-sub0-mail-a15
From: Nico Williams <nico@cryptonector.com>
To: Melinda Shore <melinda.shore@gmail.com>
Cc: ietf@ietf.org
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
Message-ID: <20200809063805.GX3100@localhost>
References: <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> <20200809053037.GV3100@localhost> <5c768c35-edb6-0180-737e-fa0c78cb971d@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5c768c35-edb6-0180-737e-fa0c78cb971d@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrkeehgddutdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Jys0b2XLnzqiY395IW2Yc5aS4WI>
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 06:38:14 -0000

On Sat, Aug 08, 2020 at 10:12:25PM -0800, Melinda Shore wrote:
> On 8/8/20 9:30 PM, Nico Williams wrote:
> > 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?
> 
> I don't fully understand your argument, but I'll point out
> [...]

I'm asking for evidence that we have a problem.  I'm quite aware that
there are RFCs that use various terms some/many consider offensive, but
I expect most of those are long in the past, and have to do with DNS.

I'm curious as to whether the rate of usage of these has gone down.  Or
up.  Or sideways.  I'm curious about which areas have the most usage of
potentially offensive language.  And other possibly interesting results
that one might find as part of performing a thorough analysis.  This
seems elementary.  It should be proponents' burden to present such an
analysis.  I'm surprised to not have seen one from them.

> I don't think the IETF is capable of this kind of change (and
> question if it's capable of any kind of change, for that matter),

Ignoring the rhetorical question of whether the IETF is "capable of this
kind of change" or "any kind of change", I agree with this:

> and I expect the most effective approach is to catch problematic
> usages on an informal basis during the review process.  What to do
> about editors who refuse to change problematic language is left
> as an exercise, etc., if there's no WG consensus or IETF
> consensus.  It would be awesome if the RSE kept an eye out for
> things that slip through but I'm not sure that we would want to
> formalize that.

I.e., we (authors, reviewers, shepherds, ADs, RPC staff, RSE) can be
expected to exercise reasonable self-restraint without _prior_ restraint
because we're a polite, professional bunch.

Speaking as someone who long has avoided these terms, I believe we
should try that first.

Certainly proposals for prior restraint have caused some acrimony.  Most
likely the effect of causing more self-restraint has already been
obtained.

Because we're a polite, professional bunch, asking politely seems a lot
better than using a heavy hand.

The gauntlet to traverse in order to publish is such that I expect
editors will not refuse reasonable, polite requests.

Now, some requests may not be reasonable.  Or there may be disagreement
about their reasonableness.  That is to be expected.  We might have to
have these arguments more than once, whether we adopt prior restraint or
not.  But prior restraint is heavy-handed and should be avoided.

Nico
--