Re: Diversity and offensive terminology in RFCs

Kyle Rose <krose@krose.org> Thu, 20 September 2018 20:40 UTC

Return-Path: <krose@krose.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 90C02130E19 for <ietf@ietfa.amsl.com>; Thu, 20 Sep 2018 13:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 aoJz7JXz179N for <ietf@ietfa.amsl.com>; Thu, 20 Sep 2018 13:40:45 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3928130E91 for <ietf@ietf.org>; Thu, 20 Sep 2018 13:40:44 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id l194-v6so2627648qke.13 for <ietf@ietf.org>; Thu, 20 Sep 2018 13:40:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7vvWavt0BmqR41UzmCcHSJ49o3i2wYwrUyySbV9ZtZM=; b=p4iXaMXNLs1kJgQvn4chjRt/MDZZwq/sQREEuddX1Ae6O66S04bWgtj8hJq6pD/8PB 4/M5w5YP2dvsnYHKeq5yukhrgX5J4GO17t1qgSlq9n/MgmCdB5lSGz2efV4N120FEBG2 DXjURGNoVWr1KnjgWe832e47tfrvozdf6ZbDM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7vvWavt0BmqR41UzmCcHSJ49o3i2wYwrUyySbV9ZtZM=; b=L4jxiCQj/VmFv3dlzCzSGbbGsuMSzuJ66UBZplnRTHgSU5NjdfkPI6mVaIfWNyj1Kr EdUrIhTidNxnqqoI6eCVkagwR2YJWebfJqzx2I7xUSCt+Wlbxyhr5vcZU7qPtFthcCEp vKAU/9xqMBjDRB8mfukaX3LHtlzQwCtF1HCa9KCUiu7QIzrkJNXPA3WJHfthjrhlrbkv TzhNzLMONNnRQXaZUwtim95hr3b9ncQa9f0ysSLdQh7Esa2wHfzJe1Q4jEMK4m2fAw0q 5W9HOnVf97x8cic998a4LNPi9Hntrov4kcMICTM/i3GVOFydOoR7ePvrbWefUm1HgdZI GhYQ==
X-Gm-Message-State: APzg51AL2TKgP12mF4d1yaGxoHgWKT+Bqccp+HIkyoskZkoyZh36QqLD 3QyvGJinl8j5AzbgakRYbym6w9K9AHWnbvTbFCMsvLTNMyc=
X-Google-Smtp-Source: ANB0VdYD3YRoeXkMAG0R4GhKWx+pKVyu0m/EclcM3Wo48239AkusohCgilmsV3UULKokF4tMybh22H3hW0b2GLG4mgw=
X-Received: by 2002:a37:3492:: with SMTP id b140-v6mr26792656qka.355.1537476043660; Thu, 20 Sep 2018 13:40:43 -0700 (PDT)
MIME-Version: 1.0
References: <cafa1282-ae6a-93de-ea4a-d100af28d8b8@digitaldissidents.org>
In-Reply-To: <cafa1282-ae6a-93de-ea4a-d100af28d8b8@digitaldissidents.org>
From: Kyle Rose <krose@krose.org>
Date: Thu, 20 Sep 2018 16:40:31 -0400
Message-ID: <CAJU8_nWX+xZgzWhQK4+VmKw+1Fo85K5NOZuYwKYgJWmpR_Lxpw@mail.gmail.com>
Subject: Re: Diversity and offensive terminology in RFCs
To: lists@digitaldissidents.org
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006f004f0576538973"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4_GEtv72PoMzGfsAlfk_jPa4JqY>
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, 20 Sep 2018 20:40:48 -0000

If I had to state a position, it would be that our interest as engineers is
in using clear language. Often, this means established language whose
domain-specific meanings remain static as definitions in different domains
drift over time. Authors can make what word choices they like to achieve
clarity, leaving room for individuals to use language they find less loaded
or overloaded or baggage-carrying. Folks who want to help them are welcome
but the IETF has no interest in legislating language that will degrade
clarity.

Kyle

On Thu, Sep 20, 2018 at 5:26 AM Niels ten Oever <lists@digitaldissidents.org>
wrote:

> Hi all,
>
> On the hrpc-list [0] there has been an intense conversation which was
> spurred by the news that the Python community removed Master/Slave
> terminology from its programming language [1].
>
> In the discussion that followed it was remarked that in RFCs terms like
> Master/Slave, blacklist/whitelist, man-in-middle, and other terminology
> that is offensive to some people and groups is quite common.
>
> This is not a discussion that can be resolved in hrpc, but rather should
> be dealt with in the IETF community (because hrpc doesn't make policy
> for terminology in the IETF), which is why I am posting this here.
>
> If people find the discussion worthwhile, we might also be just in time
> to request a BoF on this topic.
>
> Looking forward to discuss.
>
> Best,
>
> Niels
>
>
> [0] https://mailarchive.ietf.org/arch/browse/hrpc/
> [1]
>
> https://motherboard.vice.com/en_us/article/8x7akv/masterslave-terminology-was-removed-from-python-programming-language
>
>
> --
> Niels ten Oever
> Researcher and PhD Candidate
> Datactive Research Group
> University of Amsterdam
>
> PGP fingerprint    2458 0B70 5C4A FD8A 9488
>                    643A 0ED8 3F3A 468A C8B3
>
>