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

Kyle Rose <krose@krose.org> Fri, 31 July 2020 12:23 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 F0C413A1454 for <ietf@ietfa.amsl.com>; Fri, 31 Jul 2020 05:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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=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 msPvJiCF8sft for <ietf@ietfa.amsl.com>; Fri, 31 Jul 2020 05:23:54 -0700 (PDT)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 66C213A1453 for <ietf@ietf.org>; Fri, 31 Jul 2020 05:23:35 -0700 (PDT)
Received: by mail-ua1-x930.google.com with SMTP id y17so3536116uaq.6 for <ietf@ietf.org>; Fri, 31 Jul 2020 05:23:35 -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=Rf4wTf5K/QYDm4IoHaxDhPEiRmrn8G6UuB6vRfox9kc=; b=DqeYCD85vl11sWTkoXAK7jt0DYDpSbuGSStW763iLqocsA8xd4ebUejYamE5mCWdhO T1s2lEEPrIESWQSM+/j3vjKbOsjk6OL+ckRMQowSUdsF5dWOT0FrZDbvBwEx0e6C7e5G OtbGWpBojdR61B0OKpIPtgbhfIch5aZmkhLRI=
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=Rf4wTf5K/QYDm4IoHaxDhPEiRmrn8G6UuB6vRfox9kc=; b=WiornaqmLJqUQwoj/hS0RpZkst79mvKIMIEJ9v2jrRp+K3uT2ZE4Ffs2lbtdc9i0RQ 1q//iyBzo5mD9nkPbVdrzrThrS4aGpFZk6AyFduB4oNSjnGoPvgWgFdNSfMXnhanKDfV TkcfQxKy/Jrl/Sg5MAOU6KWtwPfn7AyvOCnoKDsjggpvg/ioEvJP/f1hA+jNfAaI0oPw tF7k7vD11mGNGE1P5/UYaOMMWI5K9mZBumZWWmip00HaUgYlxS4BJ5E0aJmA6f+Zyial N6AEU7VD3/0U+R2+iU5k3fvkvvpxoh4z+1QLol3zMydmolA5tMNjc9V3ZLEViXac3Gmm WmHg==
X-Gm-Message-State: AOAM531sSOuHZWjKW4qYSr4FlGkaexRlvJaRRZIn5PKOYEqSFYYb3XHn hE1I/l3Ii3uNriKYUec7Gz7aI1ZojdqvSqD73z14A7CrYE4=
X-Google-Smtp-Source: ABdhPJxktFlnL2yUNfNLgTzB7iCx6vUHJi43aUQzKIUkBtYr2wOsVsRIy03dly2oceftUsGZGckeRPFduXx0bog08Xo=
X-Received: by 2002:ab0:2eaa:: with SMTP id y10mr2244548uay.57.1596198214169; Fri, 31 Jul 2020 05:23:34 -0700 (PDT)
MIME-Version: 1.0
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> <CAJU8_nVWn7Kyh8omLiQVK9Q5DM1uBL7Qs45pi0y9U0tftt-uyw@mail.gmail.com> <4b8733f5-4356-2018-8e08-87e7596258ae@network-heretics.com>
In-Reply-To: <4b8733f5-4356-2018-8e08-87e7596258ae@network-heretics.com>
From: Kyle Rose <krose@krose.org>
Date: Fri, 31 Jul 2020 08:23:22 -0400
Message-ID: <CAJU8_nVWgcrPy9+0V5P9f=O5k=S6K5spJSso96yMU1MyzUNyzA@mail.gmail.com>
Subject: Re: USA dominion: Re: IESG Statement On Oppressive or Exclusionary Language
To: Keith Moore <moore@network-heretics.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008c25c205abbbdb77"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/S9uugVDG5ELkkrEwSe55TMaVA_k>
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: Fri, 31 Jul 2020 12:24:03 -0000

Congrats, Keith: you made me compose an email in vim.

To preface, I agree with what you're getting at, and will add my own
thoughts below. But first I would like to clarify that my earlier statement
obliquely referred to specific cases of people having withdrawn from IETF
participation because the technical problems they were trying to highlight
were not only not being taken seriously in official venues, but were
prompting ridicule and personal attacks from that vocal minority who could
not conceive of any legitimate position in opposition to IETF mantras. I'm
not going to get any more specific here because specific cases are not the
point of this thread, and there's already been too much drift.

Now, getting back to your reply:

The IETF classically expresses its values through its consensus process in
an emergent way: when a normative RFC is published in the IETF stream, it
(let's assume for the sake of argument) represents the consensus of the
participants at the time, and so whatever values are implied by the
normative language become part of the overall set of values that the IETF
expresses. The non-historic normative documents are effectively a codex
from which our shared values are drawn.

Position statements come at this from the other direction. They establish
an orthodox view within the IETF, effectively putting up a sign saying "If
you disagree, maybe you ought not come here." That is far more exclusionary
than any loaded technical jargon. By preemptively excluding those who
disagree with the prevailing orthodoxy, we create an echo chamber and
eventually come to assume that there are no reasonable divergent
viewpoints. For the IESG to arrogate to itself the power to set the bounds
of appropriate discourse on a non-technical matter on which many reasonable
people can and do disagree seems a dangerous precedent.

Fundamentally, what this comes down to is that the IETF is a bottom-up
organization. Not top-down. The IESG is there to serve the participants, as
a well of expertise and a means for shepherding consensus for a coherent
technical vision from a cacophony of voices, continuously changing and
often wildly out of tune with each other. The IETF is not simply a factory
for a vision chosen by the IESG.

Kyle

On Thu, Jul 30, 2020 at 10:47 PM Keith Moore <moore@network-heretics.com>
wrote:

> On 7/25/20 10:58 AM, Kyle Rose wrote:
>
> The IETF does have an inclusion problem, but I suspect it has very little
> to do with problematic technical jargon and a lot more to do with the
> all-too-frequent bullying, mocking, and dismissal that seem to be standard
> operating procedure for a small but vocal minority of the community.
>
> That statement could be credibly read in at least two ways:
>
> 1. the small but vocal minority of the community that claims the authority
> to bully people whom that small but vocal minority sees as being on the
> fringes
>
> 2. the small but vocal minority of the community that is on the fringes
> whom are seen as bullying others merely because they have different
> opinions (which they express even though they are different, and don't
> readily cave in to pressure from others)
>
> Even in this particular discussion, which to me looks like it has been
> relatively respectful, there are signs that it really bothers some people
> that other people have different opinions, as if everyone should somehow
> agree with a vocal minority of people *merely because that minority
> believes it has good intentions*.
>
> To me, part of what inclusion looks like is *respectful tolerance of
> differing views **even though some of those views make some people
> uncomfortable*.   I want to suggest that people being immediately
> comfortable isn't an appropriate goal, because it always makes some people
> uncomfortable that there are multiple valid perspectives on a subject.
> Instead, the community needs to cultivate a willingness to be uncomfortable
> when it is done in the service of accommodating different views and
> building rough consensus.
>
> Keith
>
>
>