Re: IESG Statement On Oppressive or Exclusionary Language

Victor Kuarsingh <victor@jvknet.com> Wed, 29 July 2020 16:11 UTC

Return-Path: <victor@jvknet.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 4B2123A0BD8 for <ietf@ietfa.amsl.com>; Wed, 29 Jul 2020 09:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com
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 wsdUb9Ll2geO for <ietf@ietfa.amsl.com>; Wed, 29 Jul 2020 09:11:41 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 8693D3A0C21 for <ietf@ietf.org>; Wed, 29 Jul 2020 09:11:18 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id a5so12216769wrm.6 for <ietf@ietf.org>; Wed, 29 Jul 2020 09:11:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kRBX4RL2VEolPDXlDGbkZj4q5NhZrIoqQ8E/R8hQeQA=; b=CS1b4MNeWWNGBggKvZlB/YGfSS7ElbckEBKqkzpY7ZtVd+AB7AM1jIvDoPjvLt/KIV MbbHTm8tyOcj9xG7xBEHTndfB87GaxMZUIyle1DNJvUit/1ZsPWi1EM4C3q0nOKCMfkJ HwtZzDtUaRfPP4LCBHmpXw5EV2tBeU80cigmkiCtZ+XXsgs5GNzHEa+H0PLi3SacwNNv mRlNsZOgZdee9RFc45xnp21XydCOqCnvcFwmVHJNE81pRA6SZPtMD/YeXZJ4ukL52j7t uFZI04TTVEm0cYxIbyUz6YSEEho/AF/IopCeB5SCOz+EPa74AWrbrzYqP0OksRYjnZ70 oVhA==
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=kRBX4RL2VEolPDXlDGbkZj4q5NhZrIoqQ8E/R8hQeQA=; b=OtQ7jtlwUIuoCL4t51zCQdjz6nytcyPFhhKWrTRcpMeui0HvzTMp9NWCPPuduw77N6 Tt4nLuWCWVjUmdU72P1Tyh3nSg3fazWepjzGx0dPt0d9pQjiIi+z08QbLz7OC3SEe99h nqUudo6QreFPhxQYLpRr1FU88UiVPDWWmdqxxW2R92EQopp9+cExgbMo1H1wb40Wu9R+ zcOFbx0GGCJDzIX3HBHvUAU+4kdXaGdPTzNcEgNjpLLwDpD/UQWZ4R0FVHHxL7sO8QGy eQu2m53g53jGqr04k3LS4bfXRG8KFL9t0m4b3pQgopfjBirxj/SNC3gdTvGM5j2H4tRL nOJw==
X-Gm-Message-State: AOAM532sd815U0ItMLeQA50nHl+BC0zF1FsFz4daFl/N+UIH98cGQzKk mdWLoIjlRychwLDS5N/SGKup87YIFz4ah5XyI+RCfxak5S5lhQ==
X-Google-Smtp-Source: ABdhPJxq2pJEJiMhe9aB1qMyfRSBWOqKHUiOoqLnOoCH9Jz1GjEXRE9tiosSuQ7H/38uZDCbSA1BLltjzSb2ru1nTHk=
X-Received: by 2002:a5d:4bd2:: with SMTP id l18mr29093008wrt.119.1596039076874; Wed, 29 Jul 2020 09:11:16 -0700 (PDT)
MIME-Version: 1.0
References: <933ce8b4-78a5-76bf-55c3-7c5694faffbb@necom830.hpcl.titech.ac.jp> <267BCA35-3A3F-440B-9F5F-2C818D5AE71A@icloud.com> <e7956fd8-2639-3df6-9539-0dd483cafa25@necom830.hpcl.titech.ac.jp> <34CF64D6-10F3-4F45-B592-FA14C911DB0B@chopps.org> <c18fc227-7da0-1487-a2ae-74de1ac73759@necom830.hpcl.titech.ac.jp> <CALaySJ+UbSP5nJungBae053q7W_VQ-8yx2pr+KP6S+G81_1_VA@mail.gmail.com> <29896C76-F631-4E5A-9F42-CB9CEA08ABF8@gmail.com> <0A4009EF-5FF7-4BDD-9D45-33DEBC140CFD@akamai.com> <f60386ad-2dbe-4364-aa14-c8b8ceac46b3@www.fastmail.com> <d6ded405-d91a-5235-3f8d-5afacb490a11@mnt.se> <eb0feb43f71d4a8b8f9f1e7eec264b17@att.com>
In-Reply-To: <eb0feb43f71d4a8b8f9f1e7eec264b17@att.com>
From: Victor Kuarsingh <victor@jvknet.com>
Date: Wed, 29 Jul 2020 12:11:06 -0400
Message-ID: <CAJc3aaN0ia=DzYGMmppB_VnxcnvEmazOb0uNgycSA0zuPmA+mg@mail.gmail.com>
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
To: "STARK, BARBARA H" <bs7652@att.com>
Cc: "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000039b4ac05ab96ce64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/k3uct1hoEr3lVIroq4qX5je6Ok4>
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: Wed, 29 Jul 2020 16:11:45 -0000

Barbara,



On Wed, Jul 29, 2020 at 11:34 AM STARK, BARBARA H <bs7652@att.com> wrote:

> Not replying to any particular email, but to the general discussion...
>
> It seems to me that IETF isn't in a good position to natively determine
> what words are "problematic". So what I think would be good would be to
> have a list of words and phrases that external communities (e.g.,
> governments, universities, corporations) are either forbidding or
> recommending against. Include a reference to the external community's web
> page where they discuss this. RECOMMEND not using words in this list. Allow
> anyone to suggest having something added to the list; suggestion must
> include the reference. Have a small team that vets the request (makes sure
> the reference works and judges whether the referenced community reflects a
> community that IETF should consider reflecting -- which is still a judgment
> call, but I think identifying whether a community is (or should be)
> important to IETF members is easier than judging whether someone who
> doesn't share your experiences might be offended by a word or phrase) and
> decides whether or not to add it to the list. An existing team, like the
> Ombudsteam, might be tasked with this.
>
> The RFC Editor doesn't need to police the use of these words. Allow for
> IETF community self-policing to decide whether a WG or independent stream
> author really want to use a word or phrase, given its presence on this list.
>
> For example, consider Apple as a reasonable reference.
> https://developer.apple.com/news/?id=1o9zxsxl
>
> Specifically, for "master/slave" or "blacklist/whitelist", look at
> https://help.apple.com/applestyleguide/#/apsg72b28652 and go to
> master/slave or blacklist/whitelist in the alphabetical list
>

Since this is such a problematic topic, I was wondering if there is a more
subtle way to slowly address this with as little pain as possible.  People
may get upset that I am making this suggestion, however here it is.

1. WG Chairs (since we read the docs anyway), flag a doc for GenART review
if words are in it that may need to be scrutinized  (AD can also ask for
that review)
2. As part of that directorate  review (or we create a new directorate for
this? ) we flag / make recommendations on alterative words/phrases if needed

Seems like this would work without the need to pre-agree.  That team can
then look to key external references as input.  Over time, with some
experience behind us (from actual reviews and updates), we can then apply
our knowledge and experience to the problem to see if it makes sense to
create more fixed rules on this.  Perhaps this is too late in the process
to do such changes.  it would also incentive authors and WG chairs to
pre-vet for this in as part of normal document creation.  We have lots of
time to make this part of normal WG review anyway.

regards,

Victor K



>
> Apple participates actively in IETF and does good work here -- so it is
> important to IETF.
>
> References don't have to all point to US entities -- any term/reference
> can be proposed to be added to the list from any geography/country.
>
> If there is a good reference for RECOMMENDING against the use of "folks"
> or "people" in RFCs, propose adding those words it and point to the
> reference.
> Barbara
>
>
>
>
>