Re: IESG Statement On Oppressive or Exclusionary Language

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 29 July 2020 05:25 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 BCED63A0FA5 for <ietf@ietfa.amsl.com>; Tue, 28 Jul 2020 22:25:50 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-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 hjPUMnjCQkUj for <ietf@ietfa.amsl.com>; Tue, 28 Jul 2020 22:25:49 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 E2DE33A0FA1 for <ietf@ietf.org>; Tue, 28 Jul 2020 22:25:48 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 0D3D629BB17; Wed, 29 Jul 2020 01:25:47 -0400 (EDT)
Date: Wed, 29 Jul 2020 01:25:46 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
Message-ID: <20200729052546.GC59671@straasha.imrryr.org>
Reply-To: ietf@ietf.org
References: <526464f6-b82a-688b-cfaf-5a7e28ae18b0@lounge.org> <E16E1747-984B-4530-A9FD-7B59DA6F49E5@akamai.com> <1ae2ff5e-09e9-d230-a96b-763d4290d5e2@lounge.org> <972E831C-265A-4297-BAE3-7F167946FC78@akamai.com> <d13a2085-172a-e92c-6b12-c9d61ed384b5@lounge.org> <D5CC0F87-FF6A-4824-B930-A43875C2FF1E@akamai.com> <d7604baf-7caf-85d3-21af-b765295951f1@lounge.org> <E9923B2A-7A94-4EA1-9890-16801D82285D@akamai.com> <19456FE4-8781-4F4E-943B-9A430080A0E8@gmail.com> <63692C48-CFDF-42F4-A704-3C063293174E@strayalpha.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <63692C48-CFDF-42F4-A704-3C063293174E@strayalpha.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/PDr2rSO_AVjr5ObE92phoU711e8>
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: Wed, 29 Jul 2020 05:25:51 -0000

On Mon, Jul 27, 2020 at 09:28:41AM -0700, Joseph Touch wrote:

> > The potential for a small but motivated group to hijack the process
> > and dictate policy is great, and the argument that the process was
> > open to everyone is not convincing. We all have limited time, and
> > arguing language policy at the IETF is not a good use of time for
> > most of us.  
> 
> You could say the same for the documents at the core of many current WGs. 

But Yoav explained in detail why this case is different, by nature of
its scope and difficulty of achieving rough consensus from the community
large, and not just a few brave and/or foolhardy enough to take the bait
and spend time discussing a not terribly fun topic.

> We’re not trying to ban words; we’re trying to help those who might
> not realize otherwise when certain words have current connotations
> they might not have intended.

You say we, but I don't consider myself sufficiently elevated above the
hoi polloi to be quite so paternalistic.  The authors know what they
intended, and their peers in the WG, IETF LC, IEST and finally the RSE
will read the documents and will suggest clearer/better language where
that intent is liable to be misunderstood by others.

The documents will *organically* on average end up roughly reflecting
the values (biases) of the community of IETF participants.  Thus, for
example, we've collectively valued privacy over various operational
advantages of third-party access to cleartext, a bias that is not
necessarily representative of the world at large.  We're probably even
somewhat unwelcoming to those who don't share those values.  That's the
nature of rough consensus, the process achieving it can also sometimes
be noticeably rough.

Being an outlier in an IETF WG, when your particular use cases are not
the mainstream ones of the WG as a whole, can make for an especially
rough ride.  Your problems will be judged unimportant, and solutions
will be judged as unnecessary added complexity.  Of all the ways in
which the IETF is exclusionary, this is by far the most oppressive.

The language used in IETF documents will reflect the norms of the time
in which they were written, and so it should be.  No prior restraint is
needed or desirable.  Whatever words are justly or fashionably taboo at
a point in time will encounter enough friction that there's no point in
trying to compile lists, have the lists reviewed, ...

If, in a particular technical area, some potential taboo words have no
adequate replacement, or replacing them would require rewriting too many
textbooks, published papers, prior standards, ... it should be possible
for the WG and broader IETF community to accept them in light of the
historical and technical context in which they are used to convey their
narrow technical meaning.

No policing is needed to discourage the use of terms that become
culturally loaded.  The battle to keep using them is lost before the
first shots are fired.  What remains worth fighting for is not the lost
neutrality of now controversial words, but rather the right to be
treated as an adult human being, capable of expressing ideas in
context, and not be prejudged or attacked for using the clearest
reasonably concise language at one's disposal.

Noone should be afraid to use existing terms of art that were clear
enough last year, but if in the document review process alternative
terms find more support, they should be used instead.  Corrections for
clarity and style are a normal part of the document review process.

-- 
    Viktor.