Terminology, Power and Inclusive Language
Center for Democracy & Technology
mknodel@cdt.org
Texas A&M University and University of Amsterdam
mail@nielstenoever.net
IETF
Internet-Draft
This document argues for moving away from specific language conventions used by RFC authors and RFC Editors in order to encourage inclusive terminology in the ongoing RFC series. The document also provides examples of inclusive terminology as precise alternatives for these conventions.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in .
The primary function of the IETF is to publish 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 . Given the importance of communication at the IETF, 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.
First, arguments are presented for why exclusionary terms should be avoided by the IETF/IRTF in general. Second, problem statements for two sets of terms are presented and alternatives are referenced and proposed. There is a third section on additional considerations and general action points to address the RFC series, past and future. Lastly, a summary of recommendations is presented.
The sets of terms discussed in this document are “master-slave” and “whitelist-blacklist”.
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” . This implies that in order to effectively communicate the content of RFCs to all readers, it is important for Authors to consider the kinds of terms or language 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 . 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” . And the ubiquitous word “robot” is the Czech word for “slave” .
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” . Metaphors structure relationships, and they frame possibilities and impossibilities .
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” . To that effect, below is a tersely written list of IETF-specific arguments as to why the RFC Editor should be encouraged to correct larger content and clarity issues with respect to offensive metaphors:
The RFC series is intended to remain online in perpetuity. Societal attitudes to offensive language shift over time in the direction of more empathy, not less.
That offensive 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.
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.
And yet the technical community already includes members who take offense to these terms. Eradicating the use of offensive 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 offensive terminology.
This document does not try to prescribe terminology shifts for any and all language that could be deemed offensive. 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.
Master-slave is an offensive metaphor that will and should never become fully detached from history. Aside from being unprofessional and offensive 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?”
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 , , and . 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 . Root operator Internet Systems Consortium stopped using the terms because they were asked to .
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” . Yet in another sense slavery is also not ‘just an historic term’, whereas freedom from slavery is a human-rights issue , it continues to exist in the present . 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 .
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” . 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.
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:
Primary-secondary
Primary-replica
Leader-follower
Active-standby
Writer-reader
Coordinator-worker
Parent-helper
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. Likewise, the IETF can show positive leadership in the technical community by setting standards without using offensive metaphors.
For the DNS, RFC 8499 defines the current best practise for DNS terminology and uses the term pair ‘primary’ and ‘secondary’ .
The metaphorical use of white-black to connote good-evil is offensive. While master-slave might seem like a more egregious example of racism, white-black is arguably worse because it is more 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” .
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 .
In the case of blacklist-whitelist in the technical documentation of the IETF/IRTF, 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– blackholes are black because light cannot escape them; a spectrographic blackbox is used as a metaphor for things that cannot be seen (e.g., blackbox is really a riff on the metaphor for light as visibility). 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.
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:
Blocklist-allowlist
Deny-allow
Droplist-accesslist
Drop-permit
Block-permit
As we have seen, 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 above two examples are not exhaustive, nor are they mere examples and require action. However, we use this section to broaden the context of other offensive 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. That some of these metaphors are offensive leaves no excuses for their 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 parrot 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 .
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 IETF/IRTF documents. 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.
To summarise this document, we have bulleted some very concrete action points that can be taken by Editors, reviewers and Authors, both present and future.
Authors SHOULD:
* Replace the offensive term “master-slave” with more accurate alternatives, for instance from the list of .
* Replace the offensive term “blacklist-whitelist” with more accurate alternative, for instance from the list of suggested alternatives at .
* Reflect on their use of metaphors generally
* Use the neutral “they” as the singular pronoun and
* Consider rolling back technical hard coding of their standards implementations with the documented knowledge available online .
RFC Editor and Reviewers MUST:
* Offer alternatives for offensive terminology as an important act of correcting larger editorial issues and clarifying technical concepts and
* Suggest to Authors that even when referencing other specifications that have not replaced offensive terminology they could provide another term with a note that the term is original and not being
suggested by the Author.
‘‘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”
As this document concerns a research document, there are no security considerations.
This document has no actions for IANA.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC Style Guide
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".
DNS Terminology
The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.This document obsoletes RFC 7719 and updates RFC 2308.
“Racism in Everyday Speech and Social Work Jargon.”
Broken Metaphor: The Master-Slave Analogy in Technical Literature.
Robotics and Automation Handbook
Masters, slaves, and infant mortality: Language challenges for technical editing
Danger! Metaphors at Work in Economics, Geophysiology, and the Internet
Metaphors We Live By
Politics and the English Language
We need better metaphors
The Universal Declaration of Human Rights
United Nations General Assembly
Black skin, white masks
I don't believe in PC
'master-slave' Terminology Was Removed from Python Programming Language
#22667 replaced occurrences of master-slave terminology with leader/follower #2692
comment on #22667 replaced occurrences of master-slave terminology with leader/follower #2692
Slavery in the 21st century
Wikipedia
Replace 'master-slave' terminology with 'primary/replica'
The 'Bad Is Black' Effect
Even in tech, words matter
@ISCdotORG reply tweet
Github to Remove 'Master/Slave' Terminology From its Platform
VICE