Skip to main content

Terminology, Power and Oppressive Language

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Mallory Knodel , Niels ten Oever
Last updated 2018-10-22
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                                          M. Knodel
Internet-Draft                                                ARTICLE 19
Intended status: Best Current Practice                      N. ten Oever
Expires: April 25, 2019                          University of Amsterdam
                                                        October 22, 2018

               Terminology, Power and Oppressive Language


   This document argues for and describes alternatives that shift
   specific language conventions used by RFC Authors and RFC Editors to
   avoid oppressive terminology in the technical documentation of the
   RFC series.  Specifically, this document details two sets of terms
   that are normalised on the technical level but oppressive on a
   societal level.  First, arguments are presented for why any
   oppressive terms should be avoided by the IETF/IRTF.  Second, problem
   statements for both sets of terms are presented and alternatives are
   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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

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

   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 April 25, 2019.

Knodel & ten Oever       Expires April 25, 2019                 [Page 1]
Internet-Draft                 Terminology                  October 2018

Copyright Notice

   Copyright (c) 2018 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
   ( 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.  Terminology and power at the IETF . . . . . . . . . . . . . .   2
     1.1.  Master-slave  . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  Suggested alternatives  . . . . . . . . . . . . . . .   5
     1.2.  Blacklist-whitelist . . . . . . . . . . . . . . . . . . .   6
       1.2.1.  Suggested alternatives  . . . . . . . . . . . . . . .   6
     1.3.  Other considerations  . . . . . . . . . . . . . . . . . .   7
   2.  Summary of recommendations  . . . . . . . . . . . . . . . . .   7
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Terminology and power at the IETF

   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" [RFC7322].
   Given the importance of communication at the IETF, it is worth
   considering the effects of terminology that has been identified as
   oppressive, racist and sexist.  Furthermore, we argue that certain
   obviously oppressive terms be avoided and suggest alternatives.
   These sets of terms are "master-slave" and "white-blacklist" for
   their racist and race-based meanings.  Since the IETF is dedicated to
   a "culture of open participation and diverse collaboration"
   [RFC7704], terms that can create a hostile work environment should be

Knodel & ten Oever       Expires April 25, 2019                 [Page 2]
Internet-Draft                 Terminology                  October 2018

   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 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 [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].  And the ubiquitous word "robot" is the Czech word for
   "slave" [Kurfess].

   However as noted in the research by Ron Eglash, this seemingly
   entrenched technical terminology is relatively recent and can 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].
   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 oppressive

   -  The RFC series is intended to remain online in perpetuity.
      Societal attitudes to oppressive language shift over time in the
      direction of more empathy, not less.

Knodel & ten Oever       Expires April 25, 2019                 [Page 3]
Internet-Draft                 Terminology                  October 2018

   -  That oppressive 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.

   -  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 is not entirely comprised of only
      white men.  Eradicating the use of oppressive 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 oppressive

   What follow are specific alternative suggestions to "master-slave"
   and "white-blacklist" and the rationale for the use of the

1.1.  Master-slave

   Master-slave is an oppressive metaphor that will and should never
   become fully detached from history.  Aside from being unprofessional
   and oppressive it stifles participation according to Eglash: "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, the
   term set is becoming less used and therefore increasingly less
   compatible as more communities move away from its use (eg [Python],
   [Drupal], 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 oppressive and hurts people in the community
   [Django2].  It is also no longer in use at the IEEE.

   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

Knodel & ten Oever       Expires April 25, 2019                 [Page 4]
Internet-Draft                 Terminology                  October 2018

   given the most recent centuries during which "the role of the master
   was to abdicate and the role of the slave was to revolt"
   [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.

1.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

   -  Primary-secondary

   -  Leader-follower

   -  Active-standby

   -  Primary-replica

   -  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 oppressive metaphors.

Knodel & ten Oever       Expires April 25, 2019                 [Page 5]
Internet-Draft                 Terminology                  October 2018

1.2.  Blacklist-whitelist

   Like master-slave, the metaphorical use of white-black to connote
   good-evil is oppressive.  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 sinister.  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, Franz 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 entirely based in racism.  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

   As with master-slave, we save our technical argument for last,
   referencing and presenting first the reasons for the use of non-
   oppressive, 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.

1.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:

   -  Blocklist-allowlist

Knodel & ten Oever       Expires April 25, 2019                 [Page 6]
Internet-Draft                 Terminology                  October 2018

   -  Block-permit

1.3.  Other considerations

   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.  However, we use this section to broaden the
   context of other oppressive terminologies to encompass additional

   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 oppressive 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 [Orwell].

   Up until recently, strict English grammatists like Orwell decried the
   use of the neuter pronoun "they".  Without a neuter 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 neuter
   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.

2.  Summary of recommendations

   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:

Knodel & ten Oever       Expires April 25, 2019                 [Page 7]
Internet-Draft                 Terminology                  October 2018

   -  Replace the oppressive term "master-slave" with more accurate
      alternatives, for instance from the list of Section 1.1.

   -  Replace the oppressive term "blacklist-whitelist" with more
      accurate alternative, for instance from the list of suggested
      alternatives at Section 1.2.

   -  Reflect on their use of metaphors generally

   -  Use the neuter "they" as the singular pronoun and

   -  Consider to roll back technical hard coding of their code and
      protocols with the documented knowledge available online

   RFC Editor and Reviewers SHOULD: * Offer alternatives for oppressive
   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
   oppressive terminology they could provide another term with a note
   that the term is original and not being suggested by the Author.

3.  Security Considerations

   As this document concerns a research document, there are no security

4.  IANA Considerations

   This document has no actions for IANA.

5.  References

5.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,

5.2.  Informative References

              Heather Brodie Graves, . and . Roger Graves, "Masters,
              slaves, and infant mortality: Language challenges for
              technical editing", Technical Communication Quarterly,
              7:4, 389-414 , 1998,

Knodel & ten Oever       Expires April 25, 2019                 [Page 8]
Internet-Draft                 Terminology                  October 2018

   [Burgest]  Burgest, David., ""Racism in Everyday Speech and Social
              Work Jargon."", Social Work, vol. 18, no. 4, 1973, pp.
              20-25 , 1973, <>.

   [Django]   fcurella, ., "#22667 replaced occurrences of master-slave
              terminology with leader/follower #2692", 2014,

   [Django2]  lynncyrin, ., "comment on #22667 replaced occurrences of
              master-slave terminology with leader/follower #2692",
              2014, <

   [Drupal]   Xano, ., "Replace 'master-slave' terminology with
              'primary/replica'", 2014,

   [Eglash]   Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy
              in Technical Literature.", Technology and Culture, vol. 48
              no. 2, 2007, pp. 360-369. , 2007, <doi:10.1353/

   [Fanon]    Fanon, F., "Black skin, white masks", 1952.

   [Grewal]   Grewal, D., "The 'Bad Is Black' Effect", 2017,

   [Jansens]  Bart Jansens, ., "I don't believe in PC", 2008,

   [Kurfess]  Kurfess, Thomas., "Robotics and Automation Handbook",

   [Lakoff]   George Lakoff, . and . Mark Johnson, "Metaphors We Live
              By", U of Chicago P, 1980. , n.d..

              McClelland, J., "We need better metaphors", 2011,

   [Orwell]   George Orwell, ., "Politics and the English Language",

Knodel & ten Oever       Expires April 25, 2019                 [Page 9]
Internet-Draft                 Terminology                  October 2018

   [Python]   Daniel Oberhaus, ., "'master-slave' Terminology Was
              Removed from Python Programming Language", 2018,

   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
              DOI 10.17487/RFC7322, September 2014,

   [RFC7704]  Crocker, D. and N. Clark, "An IETF with Much Diversity and
              Professional Conduct", RFC 7704, DOI 10.17487/RFC7704,
              November 2015, <>.

              socketwench, ., "Even in tech, words matter", 2018,

   [UDHR]     United Nations General Assembly, "The Universal
              Declaration of Human Rights", 1948,

              Wikipedia, "Slavery in the 21st century", 2018,

   [Wyatt]    Sally Wyatt, ., "Danger! Metaphors at Work in Economics,
              Geophysiology, and the Internet", Science, Technology, &
              Human Values, Volume: 29 issue: 2, page(s): 242-261 ,

Authors' Addresses

   Mallory Knodel


   Niels ten Oever
   University of Amsterdam


Knodel & ten Oever       Expires April 25, 2019                [Page 10]