Internet DRAFT - draft-moore-exclusionary-language
draft-moore-exclusionary-language
GENDISPATCH K. Moore
Internet-Draft Network Heretics
Intended status: Standards Track 26 August 2020
Expires: 27 February 2021
Avoiding Exclusionary Language in RFCs
draft-moore-exclusionary-language-00
Abstract
It has been asserted that some language in IETF documents is
"exclusionary" - that it offends some readers or groups of people,
and/or discourages participation in IETF by doing so. While there is
some debate about exactly which language is exclusionary, at least
some cited examples of such language can credibly have such effects.
It is believed that most instances of such language are accidental,
and that most document authors and editors wish to avoid use of
language that may be offensive. This memo therefore attempts to
establish procedures that warn document authors and editors about
language that may credibly having such effects, and thereby, to
reduce both accidental and deliberate use of such language.
At the same time, it is recognized that in some cases there an be
strong and conflicting opinions about whether or not particular
language is desirable or appropriate. IETF's primary function is
providing technical direction for the benefit of the Internet
community, rather than social engineering. If a document can be
blocked or substantially delayed over disputes about the proprietary
of language in that document, this can be disruptive to IETF's
primary function. This memo therefore makes recommendations to
prevent such disputes from blocking progress on technical documents.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Moore Expires 27 February 2021 [Page 1]
Internet-Draft Avoiding Exclusionary Language in RFCs August 2020
This Internet-Draft will expire on 27 February 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Language That Offends or Distracts is Counterproductive to
IETF's Goals. . . . . . . . . . . . . . . . . . . . . . . 3
3. Reasons for Caution . . . . . . . . . . . . . . . . . . . . . 3
3.1. Potential Harm to Accessibility of IETF Documents . . . . 3
3.2. Small Benefit, Potentially Large Cost . . . . . . . . . . 4
3.3. Potential For Unproductive Distraction . . . . . . . . . 4
3.4. Late Substitution of Words Considered Harmful . . . . . . 5
3.5. No Sweet Spot For Non-Technical Discussions . . . . . . . 6
3.6. Need to Minimize Disruption . . . . . . . . . . . . . . . 6
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RFC Editor Requested To Advise Community About Potentially
Exclusionary Language . . . . . . . . . . . . . . . . . 6
4.2. Complaints Preferred From Aggrieved Parties . . . . . . . 7
4.3. Authors/Editors Entrusted To Avoid Exclusionary
Language . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Embellishment of Internet-Drafts Tools . . . . . . . . . 7
4.5. Working Group Chairs May Limit Discussion of Language . . 8
4.6. IESG Should Defer To Working Group Consensus On
Language . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Blocking Based On Language Must be Based On IETF
Consensus . . . . . . . . . . . . . . . . . . . . . . . 8
4.8. No Automatic Substitution Of Identified Words . . . . . . 8
4.9. No Requirement To Revise Existing RFCs . . . . . . . . . 8
4.10. Evaluation Of These Recommendations . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
Moore Expires 27 February 2021 [Page 2]
Internet-Draft Avoiding Exclusionary Language in RFCs August 2020
1. Introduction
Various parties have raised concerns that language in some IETF
documents is offensive to some readers or groups, that such language
may have the effect of discouraging use of IETF documents and/or
discouraging participation in IETF. This memo therefore considers
both potential positive and potential negative effects of regulating
use of certain words and kinds of language that are asserted to cause
such harm.
2. Language That Offends or Distracts is Counterproductive to IETF's
Goals.
The community of IETF participants wishes for its standards and other
documents to be as widely usable as possible. Broadly speaking,
language that offends some set of readers of a document is
counterproductive, because it may discourage use of the document and/
or distract from the technical content of the document. More
broadly, such language in one RFC may discourage use of other RFCs if
the IETF organization is seen as unfairly biased. Finally, such
language may discourage participation in IETF by the aggrieved
parties.
Most such offenses in existing RFCs are believed to be accidental,
especially when using terms that have become well-established in
technical vocabulary, or in the English language itself, long before
today's emerging realization that such terms can be offensive or
distracting. Also, many assertions of harm caused by particular
words are believed to be uncontroversial, such that document authors
and editors will willingly avoid use of such language if made aware
of the potential harm.
3. Reasons for Caution
3.1. Potential Harm to Accessibility of IETF Documents
Any efforts to prohibit use of certain words should, in general, be
regarded with caution because of the harm that censorship can do to
expression. However, because IETF's work is almost entirely
technical in nature, this may be less of a concern for IETF than for
language in general. While there may be disagreement about some
terms that have multiple meanings, it is difficult to imagine that
IETF has a need to use terms that are generally seen as derogatory or
pejorative to any group of people.
Moore Expires 27 February 2021 [Page 3]
Internet-Draft Avoiding Exclusionary Language in RFCs August 2020
3.2. Small Benefit, Potentially Large Cost
Broadly speaking, it seems worthwhile to attempt to evolve the
technical language we use to make it less likely to offend or
distract. However, it should be realized that actual benefit from
doing so is likely to be small, while the energy drain to IETF from
doing so is potentially quite large. No matter how well intended,
IETF changes to its language cannot significantly address great
injustices done in the past or present. Such changes may have the
effect of making IETF documents more accessible, or they may have the
effect of making it appear that IETF is sweeping those injustices
under a rug. Different people may reasonably have different opinions
about these matters.
What this suggests is that IETF should consider and carry out such
changes with humility, and with as little disruption to its ordinary
work as possible, and that IETF should not inflate these actions with
a sense of great purpose. (This may also make it easier to reach
broad agreement on such actions.)
3.3. Potential For Unproductive Distraction
Long debates about offensive or distracting language can potentially
be significant and unproductive diversions away from IETF's work.
This is for several reasons:
* Getting an RFC approved for publication can require many months or
even years of effort, including working group discussion and
multiple revisions, multiple working group last calls and
additional revisions, followed by potentially multiple IESG last
calls, and subsequent processing by the RFC Editor. Any effort
that even implicitly threatens to block or significantly delay
publication of documents, especially for non-technical reasons,
may have a broad chilling effect on IETF work. It is therefore
unsurprising if some efforts to restrict language invite
significant community opposition.
* For some words there is no consensus about whether use of that
particular word actually causes harm or what appropriate
substitutions might be. Arguments that the word causes (or does
not cause) harm may be contentious even if (especially if) lacking
in substance or robust supporting evidence.
* Different people, even among the groups supposedly aggrieved by
use of certain words, may reasonably have different ideas about
the amount of harm or distraction caused by certain words.
Debates over the propriety of some words and some kinds of
language may never terminate.
Moore Expires 27 February 2021 [Page 4]
Internet-Draft Avoiding Exclusionary Language in RFCs August 2020
* Views about the propriety of certain words can be expected to
change over time, which might potentially compel some documents to
be revised multiple times in order to track then-current usage.
* Experience suggests that there is a tendency to exaggerate the
importance of rules governing the use of specific words. For
example, RFC 2119 specifies words that have special meanings when
written entirely in upper-case letters, in documents that
explicitly invoke RFC 2119. This has often been mis-interpreted
in various ways, including that words "should", "must" etc. must
be written in upper-case letters when used in RFCs.
3.4. Late Substitution of Words Considered Harmful
Late substitution of offensive (or supposedly-offensive) words in
documents, with other words, may harm the clarity and readability of
such documents.
Technical language borrows terms from ordinary language (or
sometimes, other subject domains) in order to utilize readers'
familiarity with other meanings of those terms. This often helps
readers understand the technical meanings of those terms without
their needing to learn entirely new words. This tactic generally
improves the accessibility of the technical language.
Generally the author(s) or editor(s) of a document will have
carefully selected the technical terms in the document to optimize
readability and accessibility of the document. Other language in the
document will have been crafted around use of those selected terms.
Late substitution of alternate terms may impair readability if the
new terms are not as readable or accessible, and may require
significant document revision in order to try to restore clarity to
the document, precisely because the newly-chosen words may be
semantically somewhat different than the original ones. Ideally the
best terms to use, taking all known factors into account, are chosen
early in the process of writing a document. In some cases, clarity
of a new document may be enhanced when its terminology is aligned
with other documents (whether or not produced by IETF) needed to
understand the new document or implement the specified protocol. In
general the author(s), editor(s), and perhaps the working group, are
likely in a better position to decide what terms to use, than any
subsequent party.
Moore Expires 27 February 2021 [Page 5]
Internet-Draft Avoiding Exclusionary Language in RFCs August 2020
It is possible that substitution of new terms in place of well-
established or more descriptive terms may create confusion among
readers, and thus make the technical content less accessible than
otherwise. Thus there is a balance of interests that must be
considered if the overall goal is to maximize the benefit of IETF-
produced documents to Internet users. (To be fair, there may also be
cases where substitution of new terms improves clarity.)
3.5. No Sweet Spot For Non-Technical Discussions
When making technical decisions there is often a "sweet spot" which
appears to maximize technical benefit even when viewed from various
points of view. It is less clear that such a "sweet spot" generally
exists for "social" decisions such as the choice of language.
3.6. Need to Minimize Disruption
For the above reasons it is believed that measures taken by IETF to
reduce use of offensive and distracting language should be mostly-
voluntary on the part of authors and document editors, should
leverage existing mechanisms and processes when possible in
preference to creating new mechanisms or processes, and in general
should be chosen to minimize disruption to IETF technical work.
4. Recommendations
The following recommendations are made in light of the above
concerns.
4.1. RFC Editor Requested To Advise Community About Potentially
Exclusionary Language
The RFC Editor is requested to maintain, perhaps as part of its style
guide, advice about language that may be offensive or distracting.
Such advice should generally be stated in broad terms rather than
specific words, but specific words may be cited as examples of
language that is potentially offensive or distracting. The RFC
Editor MAY also publish a list of specific words that are seen as
potentially offensive or distracting, for the purpose of alerting
document authors and editors to such potential.
If the RFC Editor is unwilling to provide such services, or funding
for such services cannot be arranged, an alternate neutral party
chosen by IETF Consensus may instead provide such services.
Moore Expires 27 February 2021 [Page 6]
Internet-Draft Avoiding Exclusionary Language in RFCs August 2020
4.2. Complaints Preferred From Aggrieved Parties
Any requests that RFCs avoid language that offends a certain group or
individual SHOULD ideally come from the aggrieved parties - i.e. from
aggrieved individuals or credible representatives of an aggrieved
group or individual, rather than by other individuals or groups
purporting to speak on behalf of the aggrieved parties.
Requests credibly originating from aggrieved parties should be
treated as sincere expressions from those parties. Requests
originating from third parties should be viewed with skepticism,
unless perhaps accompanied by documentation of peer-reviewed
controlled research with clearly described, robust and repeatable
methods, ample sample sizes, and publicly-accessible detailed
results.
4.3. Authors/Editors Entrusted To Avoid Exclusionary Language
In order to minimize disruption and delay in publishing documents,
and also to distribute the workload associated with avoiding such
language, the principal effort to avoid offensive or distracting
language SHOULD be a voluntary one among document authors and
editors. Authors and editors MAY of course consult with their
Working Groups, Area Directors, or other advisors
4.4. Embellishment of Internet-Drafts Tools
To assist authors and editors in identifying potentially offensive or
distracting language, Internet-Draft processing tools MAY be modified
to indicate which words in a document have been identified as
potentially offensive or distracting language, with messages
containing references to the RFC Editor's advice about such language.
However, the presence of such words MUST NOT be considered errors
(since context is often very important), and MUST NOT block
publication of the Internet-Draft. (but see below) Any messages
issued by such tools about such words should be clearly described as
advisory in nature.
Separate from the above, if there is IETF Consensus that specific
words must be forbidden in Internet-Drafts, the Internet-Draft
processing tools SHOULD treat presence of such words as errors and
refuse to publish documents containing them.
Moore Expires 27 February 2021 [Page 7]
Internet-Draft Avoiding Exclusionary Language in RFCs August 2020
4.5. Working Group Chairs May Limit Discussion of Language
While complaints about the use of language in a working group draft
may be submitted to the working group at any time, working group
Chairs MAY defer discussion of potentially offensive or distracting
words until the first Working Group Last Call for a document in which
such language appears. Working Group chairs MAY also limit debate
about language in real-time meetings and/or on the mailing list. The
intent is to avoid constant and endless discussion of such words
which can distract from discussion of technical issues and delay
progress in resolving such issues. It is also hoped that deferring
group discussion of such language may provide an incentive for
opposing parties to work out their differences in private email.
4.6. IESG Should Defer To Working Group Consensus On Language
When considering use of language in working group documents, and in
the absence of established IETF Consensus on the topic, IESG SHOULD
defer to the working group's consensus about whether use of contested
language is appropriate (given that the working group are subject
matter experts).
4.7. Blocking Based On Language Must be Based On IETF Consensus
Any policies that prohibit use of certain words or language, or
impose additional process that may block or significantly delay
documents containing certain words or language, MUST be described in
IETF Consensus documents.
4.8. No Automatic Substitution Of Identified Words
Since an effective choice of alternative language may depend on the
specific requirements of a particular specification, there MUST NOT
be any automatic substitution of prohibited or otherwise identified
words.
4.9. No Requirement To Revise Existing RFCs
Existing RFCs SHOULD NOT be revised merely because of the use of
language that is now considered inappropriate. Revising published
RFCs for any reason can be difficult and draining on IETF resources
that could be better applied to addressing technical issues,
especially as such revision provides an opportunity to revisit many
old issues. Revising published RFCs also increases the burden on the
users and implementers of such RFCs who must then attempt to
reconcile the (potentially conflicting) different versions with their
implementations.
Moore Expires 27 February 2021 [Page 8]
Internet-Draft Avoiding Exclusionary Language in RFCs August 2020
As an alternative to revising old RFCs, a brief list of changes in an
existing RFC's language MAY be published as Informational or BCP
documents.
4.10. Evaluation Of These Recommendations
The desirability of these recommendations should be judged by their
effect on RFCs published, as evaluated after some time, rather than
by the strictness of the measures taken.
5. Security Considerations
It is recognized that debates about proprietary of language may in
some cases not be easily resolved, and that in some cases such debate
may be deliberately used as a way to disrupt the normal operation of
IETF. This document recommends some measures to limit debate whether
or not it is a deliberate attempt to disrupt IETF.
Author's Address
Keith Moore
Network Heretics
Email: moore@network-heretics.com
Moore Expires 27 February 2021 [Page 9]
