Re: IESG Statement On Oppressive or Exclusionary Language

John C Klensin <john-ietf@jck.com> Sun, 09 August 2020 03:48 UTC

Return-Path: <john-ietf@jck.com>
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 4F9183A0803 for <ietf@ietfa.amsl.com>; Sat, 8 Aug 2020 20:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 k1jual-G8nXj for <ietf@ietfa.amsl.com>; Sat, 8 Aug 2020 20:48:35 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A02A3A07B8 for <ietf@ietf.org>; Sat, 8 Aug 2020 20:48:35 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1k4cK1-000AXM-OF; Sat, 08 Aug 2020 23:48:33 -0400
Date: Sat, 08 Aug 2020 23:48:27 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, ietf@ietf.org
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
Message-ID: <60160A936BE682CEDE0704E1@PSB>
In-Reply-To: <56fd2677-df6a-8ff2-6093-6e8d42442973@joelhalpern.com>
References: <5692e18e-afbb-9294-1074-3b81dafe8803@network-heretics.com> <59C4CA26-A1EB-4CF4-B973-BC2BBF53A094@gmail.com> <CAL02cgTZt-9+QWPT1aWXcOgpEwuNV2uHnVi5dGm7V5y_8_U1SQ@mail.gmail.com> <0cceb0f2-b5fe-a194-7ce8-68cc537f9cd1@lounge.org> <CAL02cgTV-cfTPO2wrKz0H2E=FLhagu-qs7fwx6jXeJDH-2cSHA@mail.gmail.com> <20200807171546.GP40202@straasha.imrryr.org> <737B9515-C538-4EEB-8A5D-672987A0FE86@akamai.com> <20200807190716.GQ40202@straasha.imrryr.org> <845bd95e-0d95-a164-40f9-e9c45feed6dc@gmail.com> <6D464C5C-D9CB-47A1-A8BB-CD8CAD21B779@cooperw.in> <B5969C0B-EF25-40CF-BFB4-8E062C90CA24@gmail.com> <90fd8bff-c81c-5518-65c6-b929132a4bdd@comcast.net> <44B55324558FD335BADB4165@PSB> <56fd2677-df6a-8ff2-6093-6e8d42442973@joelhalpern.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/8E7voeut2Cy5thx1mHf5iiNve8o>
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: Sun, 09 Aug 2020 03:48:37 -0000


--On Saturday, August 8, 2020 22:42 -0400 "Joel M. Halpern"
<jmh@joelhalpern.com> wrote:

> While full coordiantion probably needs something akin to RSE
> involvement, it seems to me that it would be a useful step if
> the IETF could at least figure out how to create a working
> list along the lines of what Joe Touch posted.  (Here are some
> words.  Here are some other words that you could / should /
> might / ... consider using in place of them.)
> 
> Having such a list with some resemblance of IETF rough
> consensus that following it is a good idea would help us move
> forward without getting bogged down in either "whose job is a
> formal decision?" or "when will there be an RSE?".
> 
> Such a list would, it seems to me, help genart reviewers at
> least keep the question in mind.

Yes, but that takes me/us back to suggestions made weeks ago,
i.e.,

(i) We treat this IESG statement and the underlying I-D as
having done a great job of increasing the community's
sensitivity to the issues of choices of language, largely
independent or how those issues are defined.

(ii) We conclude that we really don't need to get to an official
vocabulary, especially an official negative or discouraged
vocabulary/ work list.

(iii) With the community's new-found sensitivity, we encourage
document reviewers, especially within WGs in addition to IETF LC
(or any particular review team) to spot unfortunate language as
they read through documents.  When should language is spotted
(again, preferably early in the document life cycle) it should
lead to discussions with authors about whether the language is
appropriate and possible alternative.  Reviews during IETF Last
Call (or later) and public comments on the language should be
viewed as a last resort although possibly a necessary one.

    john