Re: USA dominion: Re: IESG Statement On Oppressive or Exclusionary Language

Toerless Eckert <tte@cs.fau.de> Sat, 25 July 2020 04:20 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 50ED63A1280 for <ietf@ietfa.amsl.com>; Fri, 24 Jul 2020 21:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level:
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 9u6iQcXrboEA for <ietf@ietfa.amsl.com>; Fri, 24 Jul 2020 21:20:44 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300263A1281 for <ietf@ietf.org>; Fri, 24 Jul 2020 21:20:43 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DA2C9548047; Sat, 25 Jul 2020 06:20:37 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CD006440043; Sat, 25 Jul 2020 06:20:37 +0200 (CEST)
Date: Sat, 25 Jul 2020 06:20:37 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Joseph Touch <touch@strayalpha.com>
Cc: Ole Troan <otroan@employees.org>, John Levine <johnl@taugh.com>, ietf@ietf.org
Subject: Re: USA dominion: Re: IESG Statement On Oppressive or Exclusionary Language
Message-ID: <20200725042037.GG43465@faui48f.informatik.uni-erlangen.de>
References: <35BE966B-63A2-438F-BD61-570E86ED2E1A@strayalpha.com> <297BF899-553D-44DB-AB56-04280F776F7A@employees.org> <6646575A-E6EA-4B4E-AC1B-F8B84B5A1203@strayalpha.com> <20200724225654.GB43465@faui48f.informatik.uni-erlangen.de> <52BB048D-A4F1-4CEF-B93D-35195C96B7F0@strayalpha.com> <20200725000148.GD43465@faui48f.informatik.uni-erlangen.de> <C1A00770-8146-46F2-AF6E-2899064F2698@strayalpha.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C1A00770-8146-46F2-AF6E-2899064F2698@strayalpha.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/UvSZXD5cJgbn414n4W7MbBO6fXI>
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: Sat, 25 Jul 2020 04:20:46 -0000

On Fri, Jul 24, 2020 at 05:57:26PM -0700, Joseph Touch wrote:
> > If the process is being let run by the people who started it, then it
> > will not result in any word change outside of their their area of interest.
> 
> I have more faith that those interested can step outside of their own experiences. Or at least try.

We could let the folks who claim they will do a good job
outside their own experience prove that for 18 months by having them
only work on words not related to black live matter and then vet
the results and decide if they should continue to work on the
words they came for originally.

> > Ho about my proposal for a language steering group constituted from members
> > from all type of language backgrounds. you did not comment about that.
> 
> Nobody is stopping anyone from participating. We don???t need a steering group. The IETF enforces nothing (not even protocol requirements), certainly not this.

If "this" is meant to ultimately go to RFC editor as rules,
i think  it would be meant to be enforce,

If anything coming out of the process are suggestions that authors can
chose to ignore without penalties, that would actually be a good way to
start the process (independent of my concerns about who is running the process).

> > ...
> > Software components are not humans.
> 
> Yes, but we anthropomorphize them all the time. I appreciate that you are not offended by the way that is done, but this is about what others have raised THIS EXACT ISSUE as their concern.

I understand that, and i do agree that this is something to consider, but
it very much depends on the target audience of our documents:

(a) On one end there is the wish of social justice activists to change language in all
places even where irrelevantor detrimental  to raise awareness of a social issue. Thats
a great and simple partisan position to fight for.

(b) There are people, IMHO primarily children or young adults that do anthropomorphize
without being able to distinguish.

(c) There are adult technical readers of RFC around the world that likely may
not even know and certainly don't care about the non metaphorical meaning
or history of our technical terms, and for whom as i outlined in the prior email
three may be real downsides for a change of text.

(a) always uses (b) as an argument for their initiative, and i do agree
with them.  But i think our readers are (c), not (b).

I am sure there is also (d) adult rascist engineers that explicitly use technical
terms to live their racism and have fun in making it sound as if they could blame
some RFC for it. Changing our language in recognition of those (d)
people is about the worst defeat i can imagine. Trying to do that also just
restarts the euphemism treadmill. Instead of telling the non-white engineering co-worker
"hey you slave, who is your master", they would simply say "hey you secondary,
who is your main". And that poor co-worker probably has even more problems with
the HR department to prove the racism of that guy because the HR department is not on top
of all the newest RFC language.

Maybe i am missing important cases, if o, then i would love to hear simple
example workflows where the change in RFC language would really help.
Short of that i would only worry about whether or not (b) applies to RFCs,
and so far i have not been presented with good evidence for that.

> > If we had a steering group with really diverse backgrounds (as i proposed),
> > such as also from africa and parts of asia, where there is real slavery,
> 
> Surely you???re aware that slavery has occurred on nearly every continent (perhaps less so in Antarctica), in nearly every time period...

I was saying "is",  i was not referring to the past.

[rant]

IMHO the biggest issue today is non-state sanctioned, often international
slavery typically called human traficking (slavery ~= state sanctioned).

I have a real hard time imagining how RFC word changes could have any
positive impact on worldwide human traficking.

On the other hand i can very well imagine how commoditizing end-to-end
encryption through TLS is very much helping worldwide organized crime
especially all the startup, small business organized crime.

How can we even argue about slavery in the context of IETF by
talking about RFC words without ever having had even a discussion
(in my memory) about these impacts of our actual technical work ? 

Where is the IETF working or research group to brainstorm IETF technologies
to help law enforcment fight organized crime such as human traficking,
child pornography, racism and terrorism ?

[/rant]

> > and
> > such a steering group would suggest such language  changes in the IETF, i think that
> > would carry a lot more weight for the IETF community than the USA centric effort
> > that we see happening now.
> 
> This is about what we do AFTER the doc is published, not the doc itself. The ???weight??? is what we do, not what we state we will do.

sorry... can't parse. rephrase ?

Cheers
    Toerless

> Joe