RE: IESG Statement On Oppressive or Exclusionary Language

"STARK, BARBARA H" <bs7652@att.com> Wed, 29 July 2020 19:35 UTC

Return-Path: <bs7652@att.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 CC9D63A0E5B for <ietf@ietfa.amsl.com>; Wed, 29 Jul 2020 12:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Level:
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 fD3H3pPuP0hq for <ietf@ietfa.amsl.com>; Wed, 29 Jul 2020 12:35:23 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC303A0E57 for <ietf@ietf.org>; Wed, 29 Jul 2020 12:35:22 -0700 (PDT)
Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 06TJVDN9017920; Wed, 29 Jul 2020 15:35:22 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 32kc49v9qr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jul 2020 15:35:21 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 06TJZKg3007921; Wed, 29 Jul 2020 15:35:20 -0400
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 06TJZHha007864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Jul 2020 15:35:17 -0400
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 4C8AC400B57A; Wed, 29 Jul 2020 19:35:17 +0000 (GMT)
Received: from GAALPA1MSGEX1CA.ITServices.sbc.com (unknown [135.50.89.108]) by zlp30485.vci.att.com (Service) with ESMTPS id 076C7400B578; Wed, 29 Jul 2020 19:35:17 +0000 (GMT)
Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CA.ITServices.sbc.com (135.50.89.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 29 Jul 2020 15:35:16 -0400
Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.004; Wed, 29 Jul 2020 15:35:16 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Victor Kuarsingh' <victor@jvknet.com>
CC: "'ietf@ietf.org'" <ietf@ietf.org>
Subject: RE: IESG Statement On Oppressive or Exclusionary Language
Thread-Topic: IESG Statement On Oppressive or Exclusionary Language
Thread-Index: AQHWYQ92QkPuo+zmf0yn1kbamJZaxakWgT+AgAACbQCAAAvnAIAAIKOAgAAFl4CABtmoAIABFsKAgAAUdQCAAB+JAIAAEgMA///BwFCAAFixAP//0W6A
Date: Wed, 29 Jul 2020 19:35:16 +0000
Message-ID: <028eaeaf25c24469bd1add1b5cbc4554@att.com>
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> <CAJc3aaN0ia=DzYGMmppB_VnxcnvEmazOb0uNgycSA0zuPmA+mg@mail.gmail.com>
In-Reply-To: <CAJc3aaN0ia=DzYGMmppB_VnxcnvEmazOb0uNgycSA0zuPmA+mg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.90.7]
x-tm-snts-smtp: DA0C805DAD8C7DDD1EC6EC8F1E663066620B1F2B5520958F2B9C11D3E5A2AB352
Content-Type: multipart/alternative; boundary="_000_028eaeaf25c24469bd1add1b5cbc4554attcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_13:2020-07-29, 2020-07-29 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1015 impostorscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 adultscore=0 spamscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007290131
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DFstwzLlxCwt5aODAJdDpoQMY0s>
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 19:35:26 -0000

Hi Victor,
I think I may not have described what I was suggesting clearly enough. I wasn’t proposing any fixed (i.e., MANDATORY or MUST) rules. I was trying to avoid problems caused by the perception that people inside IETF would be identifying what words were problematic (using their own subjective criteria, and where the decision makers are not members of the demographics perceived to be slighted by the words), and that use of these words would be strictly prohibited.

Let me make my suggestion more concretely:

There exists a list (not an IANA list, but maybe on tools or datatracker).
This list has 2 columns:
Word or Phrase  |  Reference(s)

The Reference(s) column has references to websites where entities IETF considers important are asking for the word or phrase not to be used in documentation or publications that they have some element of control over. It can be delimited (comma or semi-colon) so a word that is referenced by multiple entities can have multiple references.

The Word column could have a tool (like idnits) developed against it such that authors, shepherds, or anyone else can directly run the check and there is no need for WG chairs or GenArt reviewers to be held responsible for knowing all the words on the list or running the tool.

It is only RECOMMENDED that these words not be used. The authors are being asked to make a *conscious* decision to use the words, knowing some people somewhere may have issues in certain contexts. The authors are also provided references so they can know who it is who has issues and in what context. But it can also happen that a reviewer or RFC editor decides to run the check and asks the authors if use of the words was intentional. The authors can say “Yes”, and that’s the end of it (until the next person asks and they say “Yes” again). “Yes, use of these words is intentional” is valid; which means publication of a RFC isn’t denied just because it contains those words.

But lists like this don’t just magically spawn. There needs to be a process for creating/updating the list. I think anyone should be able to suggest adding a word or phrase. But they have to provide a reference where an entity describes how that entity deals with occurrences of that word or phrase. The suggester can also provide additional references for existing entries. Some people do need to look at the suggestion and make a decision as to whether the referenced website is sufficiently relevant to IETF and belongs on the list.

I think this is manageable with relatively low overhead, and it doesn’t censor use of the words. It merely asks people to make an informed and conscious decision to use the words. And the list of words to be careful about is explicit and known.
Barbara

From: Victor Kuarsingh <victor@jvknet.com>
Sent: Wednesday, July 29, 2020 11:11 AM
To: STARK, BARBARA H <bs7652@att.com>
Cc: ietf@ietf.org
Subject: Re: IESG Statement On Oppressive or Exclusionary Language

Barbara,



On Wed, Jul 29, 2020 at 11:34 AM STARK, BARBARA H <bs7652@att.com<mailto: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<https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_news_-3Fid-3D1o9zxsxl&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=KGQ1RQlq8czTXz492w-8fak_ka8kxLlHRSTeBzQXbLU&s=Eh4QhnAGng9GaqjLRoNUv_dscuCVaUSBQ2PvbDw3akM&e=>

Specifically, for "master/slave" or "blacklist/whitelist", look at
https://help.apple.com/applestyleguide/#/apsg72b28652<https://urldefense.proofpoint.com/v2/url?u=https-3A__help.apple.com_applestyleguide_-23_apsg72b28652&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=KGQ1RQlq8czTXz492w-8fak_ka8kxLlHRSTeBzQXbLU&s=N3_-r7Tw9dSLr5jiyEQXbLKL8arC4XWS7EMeGEiKNQM&e=> 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