Network Working Group M. Knodel
Internet-Draft Center for Democracy & Technology
Intended status: Best Current Practice N. ten Oever
Expires: January 9, 2021 Texas A&M University
July 08, 2020
Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs
draft-knodel-terminology-03
Abstract
This document argues for moving away from certain specific language
conventions sometimes used by RFC authors and the RFC Production
Centre in order to encourage the use of more inclusive terminology in
Internet-Drafts that are work in progress, and in new RFCs that may
be published in any of the RFC series. The document also provides
examples of inclusive terminology as precise alternatives for these
conventions.
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."
This Internet-Draft will expire on January 9, 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
Knodel & ten Oever Expires January 9, 2021 [Page 1]
Internet-Draft Terminology July 2020
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.
1. Introduction
According to [RFC7322], "The ultimate goal of the RFC publication
process is to produce documents that are readable, clear, consistent,
and reasonably uniform," and one function of the RFC Editor is to
"[c]orrect larger content/clarity issues; flag any unclear passages
for author review." Documents that are published as RFCs are first
worked on as Internet-Drafts.
Given the importance of communication between people developing RFCs,
Internet-Drafts (I-D's), and related documents, it is worth
considering the effects of terminology that has been identified as
exclusionary. This document argues that certain obviously
exclusionary terms should be avoided and replaced with alternatives.
We propose nothing more than additional care in the choice of
language just as care is taken in defining standards and protocols
themselves.
This document presents arguments for why exclusionary terms should be
avoided in Internet-Drafts and RFCs, describes the problems
introduced by some specific terms, and proposes alternative language.
The terms discussed in this document include "master-slave" and
"whitelist-blacklist". There is a final section on additional
considerations and general action points to address future RFCs and
I-D's. Lastly, a summary of recommendations is presented.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology and Power in Internet-Drafts and RFCs
According to the work of scholar Heather Brodie Graves from 1993,
"one goal of the application of rhetorical theory in the technical
communication classroom is to assess the appropriateness of
particular terms and to evaluate whether these terms will facilitate
or hinder the readers' understanding of the technical material"
[BrodieGravesGraves]. This implies that in order to effectively
communicate the content of I-Ds and RFCs to all readers, it is
important for Authors to consider the kinds of terms or language
Knodel & ten Oever Expires January 9, 2021 [Page 2]
Internet-Draft Terminology July 2020
conventions that may inadvertently get in the way of effective
communication. She continues, "complex and subtle configurations of
sexist, racist, or ethnocentric language use in technical documents
can derail or interfere with readers' ability and desire to
comprehend and follow important information."
Indeed, problems of language are problems of everyday speech. Racist
and sexist language is rampant and similarly counter-productive in
other sectors, notably social work [Burgest]. The terms "master-
slave," treated in detail below are present in other realms of
technology, notably "automotive clutch and brake systems, clocks,
flip-flop circuits, computer drives, and radio transmitters"
[Eglash].
However as noted in the research by Ron Eglash, this seemingly
entrenched technical terminology is relatively recent. It is not too
late for these terms to be replaced with alternative metaphors that
are more accurate, clearer, less distracting, and that do not offend
their readers. Language matters and metaphors matter. Indeed,
metaphors can be incredibly useful devices to make more human the
complex technical concepts presented in RFCs. Metaphors should not
be avoided, but rather taken seriously. Renowned linguist George
Lakoff argued in 1980 that the ubiquitous use of metaphors in our
everyday speech indicates a fundamental instinct to "structure our
most basic understandings of experience" [Lakoff]. Metaphors
structure relationships, and they frame possibilities and
impossibilities [Wyatt].
Like Graves, this document recognises the monumental challenge of
addressing linguistics and power, and attempts to "promote awareness
that may lead to eventual wide-spread change" [BrodieGravesGraves]
and suggests first steps for actions that may remedy the inadvertent
use of undesirable terms'. To that end, the list below is a tersely
written set of IETF-specific arguments as to why the RFC Editor
should be encouraged to correct other content and clarity issues with
respect to excluding language and metaphors:
o The RFC series is intended to remain online in perpetuity.
Societal attitudes to offensive and excluding language shift over
time in the direction of more empathy, not less.
o That excluding terms in RFCs are largely hidden from the larger
public, or read only by engineers, is no excuse to ignore social-
level reactions to the terms. If the terms would be a poor choice
for user-facing application features, the terms should be avoided
in technical documentation and specifications, too.
Knodel & ten Oever Expires January 9, 2021 [Page 3]
Internet-Draft Terminology July 2020
o At the time of this drafting, the digital technology community has
a problem with monoculture. And because the diversity of the
technical community is already a problem, a key strategy to
breaking monoculture is to ensure that technical documentation is
addressed to a wide audience and multiplicity of readers.
o And yet the technical community already includes members who take
offense to these terms. Eradicating the use of excluding
terminology in official RFCs recognises the presence of and
acknowledges the requests from black and brown engineers and from
women and gender-non-conforming engineers to avoid the use of
exclusive terminology.
This document does not try to prescribe terminology shifts for any
and all language that could be deemed exclusive. Instead what follow
are specific alternative suggestions to "master-slave" and "white-
blacklist" and the rationale for the use of the alternatives.
Additional considerations are presented in a subsequent section.
3.1. Master-Slave
Master-slave is an offensive and exclusive metaphor that will and
should never become fully detached from history. Aside from being
unprofessional and exclusive it stifled the participation of students
whom Eglash interviewed for his research. He asks: "If the master-
slave metaphor affected these tough-minded engineers who had the
gumption to make it through a technical career back in the days when
they may have been the only black persons in their classes, what
impact might it have on black students who are debating whether or
not to enter science and technology careers at all?" [Eglash]
Aside from the arguably most important reason outlined above, these
terms are becoming less used and therefore increasingly less
compatible as more communities move away from its use (eg [NIST],
[Python], [Drupal], [Github] and [Django]. The usage of 'master' and
'slave' in hardware and software has been halted by the Los Angeles
County Office of Affirmative Action, the Django community, the Python
community and several other programming languages. This was done
because the language is offensive and hurts people in the community
[Django2]. Root operator Internet Systems Consortium stopped using
the terms because they were asked to [ISC].
In addition to being inappropriate and arcane, the master-slave
metaphor is both technically and historically inaccurate. For
instance, in DNS the 'slave' is able to refuse zone transfers on the
ground that it is malformed. The metaphor is incorrect historically
given the most recent centuries during which "the role of the master
was to abdicate and the role of the slave was to revolt"
Knodel & ten Oever Expires January 9, 2021 [Page 4]
Internet-Draft Terminology July 2020
[McClelland]. Yet in another sense slavery is also not 'just an
historic term', whereas freedom from slavery is a human-rights issue
[UDHR], it continues to exist in the present [Wikipedia].
Furthermore, this term set wasn't revived until recently, after WWII,
and after many of the technologies that adopted it were already in
use with different terminology [Eglash].
Lastly, we present not an additional rationale against their use, but
an indicator of actual racism in the community that has been surfaced
as a result of this larger debate among technologists, "I don't
believe in PC (political correctness), mostly because the minorities
constantly use it to get away with anything" [Jansens]. This
illustrates the need to, as Graves is cited above as saying, continue
to raise awareness within our community for eventual, lasting change
on the continued front of struggle against the racists amongst us.
3.1.1. Suggested Alternatives
There are also many other relationships that can be used as
metaphors, Eglash's research calls into question the accuracy of the
master-slave metaphor. Fortunately, there are ample alternatives for
the master-slave relationship. Several options are suggested here
and should be chosen based on the pairing that is most clear in
context:
o Primary-secondary
o Primary-replica
o Active-standby
o Writer-reader
Since the use of master-slave is becoming less common in other
technical communities, it is best to simply duplicate the metaphor
being used by comparable or interoperable technologies. The IETF can
show positive leadership in the technical community by setting
standards without using offensive and exclusive metaphors.
For the DNS, RFC 8499 defines the current best practise for DNS
terminology and uses the term pair 'primary' and 'secondary'
[RFC8499].
3.2. Blacklist-Whitelist
The metaphorical use of white-black to connote good-evil is
exclusive. While master-slave might seem like a more egregious
example of racism, white-black is arguably worse because it is more
Knodel & ten Oever Expires January 9, 2021 [Page 5]
Internet-Draft Terminology July 2020
pervasive and therefore more insidious. While recent headlines have
decried the technical community's use of master-slave, there is far
less discussion about white-black despite its importance. There is
even a name for this pervasive language pitfall: the association of
white with good and black with evil is known as the "bad is black
effect" [Grewal].
Indeed, there is an entire book on the subject, written by renowned
authority on race, Frantz Fanon. In his book "Black Skin, White
Masks," Fanon makes several persuasive arguments that standard
language encodes subconscious in-group, out-group preferences
[Fanon].
In the case of blacklist-whitelist in the technical documentation of
I-Ds and RFCs, it is entirely a term of art and an arbitrary
metaphorical construct with no technical merit. There are scientific
uses of black that are related to light- black holes are black
because light cannot escape them. Blacklist-whitelist is not a
metaphor for lightness or darkness, it is a good-evil metaphor and
therefore this trope has significant impact on how people are seen
and treated. As we've seen with metaphors, its use is pervasive and,
though not necessarily conscious, perceptions do get promulgated
through culture and repetition.
As with master-slave, we save our technical argument for last,
referencing and presenting first the reasons for the use of non-
offensive, alternative terminology for the sake of our humanity.
Indeed, our technical argument is incredibly succinct: Why use a
metaphor when a direct description is both succinct and clear? There
can be absolutely no ambiguity if one uses the terms, as suggested
below, allow-block rather than white-black.
3.2.1. Suggested Alternatives
There are alternatives to this terminology set that vastly improve
clarity because they are not even metaphors without adding a single
additional character. The alternatives proposed here say exactly
what they mean. Examples of specifications that use these
alternative terms are also provided for illustration purposes.
o Accept-list and Drop-list (see for examle [RFC8612], [RFC8782],
and [RFC8783])
o Blocklist-allowlist
o Deny-allow
o Droplist-accesslist
Knodel & ten Oever Expires January 9, 2021 [Page 6]
Internet-Draft Terminology July 2020
o Drop-permit
o Block-permit
3.3. Other Considerations
As described in the preceding sections, the language used in
technical documentation, like all written text, creates and
reinforces expectations and stereotypes. We propose nothing more
than additional care in the choice of language just as care is taken
in defining standards and protocols themselves. The two examples
provided above are not the only cases of offensive language to be
avoided, and many more can be collected. However, these two examples
are particularly significant and require immediate action. We use
this section to broaden the context of other offensive and excludig
terminologies to encompass additional concerns.
There are many other metaphors present in technical documentation
that are "terms of art" but that have no technical basis whatsoever.
If any of these metaphors is offensive there is no excuse for its
continued use. A term like "man-in-the-middle" is not technically
useful. It is not a standard term, not as clear as its alternative
"on-path attacker", and should therefore be avoided. When presented
with the opportunity to employ the use of metaphors or to
unthinkingly repeat terms of art that connote gender or race, Authors
should simply find a better way to explain themselves. A fun read on
the politics of colloquial speech by George Orwell should dissuade
any clever Author from using tired explanatory metaphors [Orwell].
Up until recently, strict English grammatists like Orwell decried the
use of the neutral pronoun "they". Without a neutral singular
pronoun, "he" is assumed as the default singular pronoun when the
gender of the person is unknown or ambiguous. However, that has
changed, and it is now widely accepted that "they" can be used as a
neutral singular pronoun. Since it is unlikely that all implementers
and infrastructure operators are of any particular gender, "he"
should never be used to refer to a person in I-Ds and RFCs. An
Author who uses male examples sets male-ness as a standard.
Militarised metaphors are also a pervasive problem in language,
perhaps even more so in technical communities because of the
historical and actual relationship between technology and war. We
welcome additional examples of terminology that might be avoided
through more awareness and thoughtfulness.
Knodel & ten Oever Expires January 9, 2021 [Page 7]
Internet-Draft Terminology July 2020
4. Summary of Recommendations
To summarise, we have bulleted some very concrete action points that
can be taken by Editors, reviewers and Authors, both present and
future as they develop and publish Internet-Drafts and new RFCs.
Authors SHOULD: * Replace the excluding term "master-slave" with more
accurate alternatives, for instance from the list of Section 3.1. *
Replace the excluding term "blacklist-whitelist" with more accurate
alternative, for instance from the list of suggested alternatives at
Section 3.2. * Reflect on their use of metaphors generally * Use the
neutral "they" as the singular pronoun, and * Consider changing
existing exclusive language in current (reference) implementations
[socketwench] * Consult the style sheet maintained by the RFC editor.
RFC Editor MUST: * Offer alternatives for excluding terminology as an
important act of correcting larger editorial issues and clarifying
technical concepts and * Maintain a style sheet that collects all
terms that have been considered and indicate wheter they are deemed
acceptable, and if not what terms Authors should consider instead *
Suggest to Authors that even when referencing other specifications
that have not replaced offensive terminology, the Authors could use
another term in their document and include a note to say that they
have used the new term as a replacement for the term used in the
referenced document.
5. Further reading
''Anyone can edit', not everyone does: Wikipedia and the gender gap'
by Ford, Heather and Wajcman, Judy (2017) Social Studies of Science.
ISSN 0306-3127
Grant, Barbara M. "Master--slave dialogues in humanities
supervision...https://doi.org/10.1177/1474022207084880
Miller, Carolyn. "A Humanistic Rationale for Technical Writing"
6. Security Considerations
Security is dependent on a wide range of actors that are implementing
technical documentation. Therefore it is crucial that language is
clear, and understood by all that need to implement this
documentation. Correct and inclusive language is therefore conducive
for secure implementations of technical documentation.
Knodel & ten Oever Expires January 9, 2021 [Page 8]
Internet-Draft Terminology July 2020
7. IANA Considerations
This document has no actions for IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[BrodieGravesGraves]
Heather Brodie Graves, . and . Roger Graves, "Masters,
slaves, and infant mortality: Language challenges for
technical editing", Technical Communication Quarterly,
7:4, 389-414 , 1998,
<https://doi.org/10.1080/10572259809364639>.
[Burgest] Burgest, David., ""Racism in Everyday Speech and Social
Work Jargon."", Social Work, vol. 18, no. 4, 1973, pp.
20-25 , 1973, <www.jstor.org/stable/23711113.>.
[Django] fcurella, ., "#22667 replaced occurrences of master-slave
terminology with leader/follower #2692", 2014,
<https://github.com/django/django/pull/2692>.
[Django2] lynncyrin, ., "comment on #22667 replaced occurrences of
master-slave terminology with leader/follower #2692",
2014, <https://github.com/django/django/
pull/2692#issuecomment-44221563>.
[Drupal] Xano, ., "Replace 'master-slave' terminology with
'primary/replica'", 2014,
<https://www.drupal.org/project/drupal/issues/2275877>.
[Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy
in Technical Literature.", Technology and Culture, vol. 48
no. 2, 2007, pp. 360-369. , 2007,
<https://doi.org/10.1353/tech.2007.0066>.
Knodel & ten Oever Expires January 9, 2021 [Page 9]
Internet-Draft Terminology July 2020
[Fanon] Fanon, F., "Black skin, white masks", 1952.
[Github] Kevin Truong, . and VICE, "Github to Remove 'Master/Slave'
Terminology From its Platform", June 2020,
<https://www.vice.com/en_us/article/k7qbyv/github-to-
remove-masterslave-terminology-from-its-platform>.
[Grewal] Grewal, D., "The 'Bad Is Black' Effect", 2017,
<https://www.scientificamerican.com/article/the-bad-is-
black-effect/>.
[ISC] Internet Systems Consortium, ., "@ISCdotORG reply tweet",
2017,
<https://twitter.com/ISCdotORG/status/943152507211071489>.
[Jansens] Bart Jansens, ., "I don't believe in PC", 2008,
<https://www.drupal.org/project/project_issue_file_review/
issues/343414#comment-1164514>.
[Lakoff] George Lakoff, . and . Mark Johnson, "Metaphors We Live
By", U of Chicago P, 1980. , n.d..
[McClelland]
McClelland, J., "We need better metaphors", 2011,
<https://current.workingdirectory.net/posts/2011/master-
slave>.
[NIST] Eric Geller, . and Politico, "Agency to end use of
technology terms such as 'master' and 'slave' over racist
associations", June 2020,
<https://www.politico.com/news/2020/06/25/agency-ends-use-
technology-terms-racist-associations-339880>.
[Orwell] George Orwell, ., "Politics and the English Language",
1946.
[Python] Daniel Oberhaus, ., "'master-slave' Terminology Was
Removed from Python Programming Language", 2018,
<https://motherboard.vice.com/en_us/article/8x7akv/
masterslave-terminology-was-removed-from-python-
programming-language>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
DOI 10.17487/RFC7322, September 2014,
<https://www.rfc-editor.org/info/rfc7322>.
Knodel & ten Oever Expires January 9, 2021 [Page 10]
Internet-Draft Terminology July 2020
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[socketwench]
socketwench, ., "Even in tech, words matter", 2018,
<https://deninet.com/blog/2018/09/09/even-tech-words-
matter>.
[UDHR] United Nations General Assembly, "The Universal
Declaration of Human Rights", 1948,
<http://www.un.org/en/documents/udhr/>.
[Wikipedia]
Wikipedia, "Slavery in the 21st century", 2018,
<https://en.wikipedia.org/wiki/
Talk:Slavery_in_the_21st_century>.
[Wyatt] Sally Wyatt, ., "Danger! Metaphors at Work in Economics,
Geophysiology, and the Internet", Science, Technology, and
Human Values, Volume: 29 issue: 2, page(s): 242-261 ,
2004.
Authors' Addresses
Mallory Knodel
Center for Democracy & Technology
Email: mknodel@cdt.org
Knodel & ten Oever Expires January 9, 2021 [Page 11]
Internet-Draft Terminology July 2020
Niels ten Oever
Texas A&M University
Email: mail@nielstenoever.net
Knodel & ten Oever Expires January 9, 2021 [Page 12]