Re: IESG Statement On Oppressive or Exclusionary Language

Nadim Kobeissi <nadim@symbolic.software> Sat, 08 August 2020 03:14 UTC

Return-Path: <nadim@symbolic.software>
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 63F1A3A0B9B for <ietf@ietfa.amsl.com>; Fri, 7 Aug 2020 20:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=symbolic.software
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 GP0ECkLArKh9 for <ietf@ietfa.amsl.com>; Fri, 7 Aug 2020 20:14:48 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 9BCCC3A0B90 for <ietf@ietf.org>; Fri, 7 Aug 2020 20:14:48 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id r4so3286584wrx.9 for <ietf@ietf.org>; Fri, 07 Aug 2020 20:14:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Wk6PlL1y+ojLFF+j66Ne2L/IaQ96H8F6s7MgLPpxU+0=; b=K4fKLMX6z2njRmbay7i9dOwWxC+YPtr09qSGLzeapivocUAzeIlfTdWe5yRIk2BT4P 1BM44+LPwTTWNAjaDnlHITngc4voQCE+FMLLAo8wCuPdbL3wJw8Z0C0r2CNa9bppAaRh E4deZJnLVJxEZI/0Qs1UB4P6G+WDfGUz3K0vM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Wk6PlL1y+ojLFF+j66Ne2L/IaQ96H8F6s7MgLPpxU+0=; b=HQdrq859mnXeYZ46Y7ZUkMOyqNe5bOmVS0h95FJqRX72rhKS3zk5gvZX6xH0M25hLR HW/8Zr9vvC9bdUWK9Zx27E2rQQINgX9zr/5IZ049od7xi1oX5R17HkaBDmQW+KIOlJYF dC5lFhSHdHVTOpWj0auBawk387F2vxdy4npjo7A6Oxw0dzmytb2NSfz+fLL6mqnJj/yg 6BVGbENRIPrNhrl/q15KrJhJ+mPUtoO0wNCgW73dOnWmbmpt0RLu86/SOE53HouWR5hS n+88Eh6oVAPHs5nIVyzwvkV7hPF9IznF2ubL7ZJR1kDtl6XF4KItIcMKl7YjXK52CWD+ fOYQ==
X-Gm-Message-State: AOAM53339UVuCuJAyV4qcr0Tus7ZmB1uk7iQSajadFlQOvJSsS0FASib jdwo30TfjtHjwbJh2+vLsKke5OrrOlKfqA==
X-Google-Smtp-Source: ABdhPJx8tNTIcQk+YEjn//dVIH0V9ytTjxrmeInpa1/MlyEeIA3Gi0qSF1/WAx4GkzyVav0oWbQL1w==
X-Received: by 2002:adf:ed0c:: with SMTP id a12mr14299811wro.24.1596856486559; Fri, 07 Aug 2020 20:14:46 -0700 (PDT)
Received: from localhost ([176.160.172.33]) by smtp.gmail.com with ESMTPSA id 130sm12265500wme.26.2020.08.07.20.14.45 for <ietf@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2020 20:14:46 -0700 (PDT)
From: Nadim Kobeissi <nadim@symbolic.software>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3652.0.5.2.1\))
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
Date: Sat, 08 Aug 2020 05:14:45 +0200
References: <159552214576.23902.6025318815034036362@ietfa.amsl.com>
To: ietf@ietf.org
In-Reply-To: <159552214576.23902.6025318815034036362@ietfa.amsl.com>
Message-Id: <0A939CE4-3CDE-47CC-AB61-714DC0F37AD6@symbolic.software>
X-Mailer: Apple Mail (2.3652.0.5.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XKikRaujzMZw7-tkz7WnQHbB2mk>
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, 08 Aug 2020 03:14:50 -0000

This entire subject is so toxic, unnecessary and divisive that it could pass for a Trojan Horse (hopefully not, too, an “offensive” term to Trojans) with the specific intent of dividing and IETF, sowing discord between its members and to introduce notions of sectarianism and tribalism that were on their way *out* of the IETF since its diversification from a US-dominated organization and into a truly international and truly inclusive organization.

I became familiar with the IETF after humble beginnings as a Lebanese immigrant. At no point have I ever witnessed anyone being “excluded” or “hurt” by the usage of terms such as “master program”, “master branch”, “blacklist” or “whitelist”. None of these terms have any historical relationship to specifically the history of slavery in the United States of America. They are simply technical terms.

There have been repeated calls for an empirical survey to actually determine if there are people who feel in any way disenfranchised by these terms. These calls have been dismissed, ignored or even suggested to be certainly in bad faith. In fact, the response to these calls has consistently been that unless we accept that surely this harm must exist, then we as individuals lack empathy, cannot think correctly, and hold sin in our hearts that must be purged. The legitimization of such religious and cult-like rhetoric in the IETF is disturbing. The dangers of legitimizing this religious thinking must be recognized, given a name and must be quelled before the impact on the IETF’s productivity becomes infected with cult-like notions.

In fact, the way that people who reasonably disagree with this topic have been treated for expressing their views is exponentially more “exclusionary” than any exclusion I’ve seen by virtue of using the term “blacklist” somewhere.

It is shameful to waste so much of people’s time and to cause so much damage to the collective psychology of the IETF in order to push through requested changes that seem entirely borne out of some personal guilt complex that is not necessarily shared by other IETF members or indeed the global community, who largely sees this as an American cultural phenomenon that defies explanation. Virtually nobody outside of North America cares about this topic at all. We’re not growing up in the Middle East feeling “marginalized” because we see the term “whitelist”. Even the suggestion of this is so patronizing that I wonder if the people who think like this view the entire world as constituted of children.

This entire topic is harmful to the IETF’s collective psychology and its ability to collaborate. The IESG should follow its mandate and stop sowing discord among IETF members with these unnecessary, tribalistic and mentally troubled topics. This discussion as a whole has been nothing but a net harm to the IETF, and is causing quantifiable damage to the ability of its members to work together to produce a more performant, secure and indeed inclusive Internet.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 23 Jul 2020, at 6:35 PM, The IESG <iesg@ietf.org> wrote:
> 
> The IESG believes the use of oppressive or exclusionary language is 
> harmful.  Such terminology is present in some IETF documents, including 
> standards-track RFCs, and has been for many years. It is at odds with 
> our objective of creating an inclusive and respectful environment in the 
> IETF, and among readers of our documents.
> 
> The IESG realizes that the views of the community about this topic are 
> not uniform. Determining an actionable policy regarding problematic 
> language is an ongoing process. We wanted to highlight that initial 
> discussions about this topic are taking place in the general area (a 
> draft [1] is slated for discussion in GENDISPATCH [2] at IETF 108).  
> Updating terminology in previously published RFCs is a complex endeavor, 
> while making adjustments in the language used in our documents in the 
> future should be more straightforward. 
> 
> The IESG looks forward to hearing more from the community, engaging in 
> those discussions, and helping to develop a framework for handling this 
> issue going forward.
> 
> [1] https://datatracker.ietf.org/doc/draft-knodel-terminology/
> [2] https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03
> 
>