idnits 2.17.1 draft-knodel-terminology-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Knodel 3 Internet-Draft ARTICLE 19 4 Intended status: Best Current Practice N. ten Oever 5 Expires: April 25, 2019 University of Amsterdam 6 October 22, 2018 8 Terminology, Power and Oppressive Language 9 draft-knodel-terminology-00 11 Abstract 13 This document argues for and describes alternatives that shift 14 specific language conventions used by RFC Authors and RFC Editors to 15 avoid oppressive terminology in the technical documentation of the 16 RFC series. Specifically, this document details two sets of terms 17 that are normalised on the technical level but oppressive on a 18 societal level. First, arguments are presented for why any 19 oppressive terms should be avoided by the IETF/IRTF. Second, problem 20 statements for both sets of terms are presented and alternatives are 21 proposed. There is a third section on additional considerations and 22 general action points to address the RFC series, past and future. 23 Lastly, a summary of recommendations is presented. 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology and power at the IETF . . . . . . . . . . . . . . 2 64 1.1. Master-slave . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1.1. Suggested alternatives . . . . . . . . . . . . . . . 5 66 1.2. Blacklist-whitelist . . . . . . . . . . . . . . . . . . . 6 67 1.2.1. Suggested alternatives . . . . . . . . . . . . . . . 6 68 1.3. Other considerations . . . . . . . . . . . . . . . . . . 7 69 2. Summary of recommendations . . . . . . . . . . . . . . . . . 7 70 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 5.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Terminology and power at the IETF 79 The primary function of the IETF is to publish documents that are 80 "readable, clear, consistent, and reasonably uniform" and one 81 function of the RFC Editor is to "[c]orrect larger content/clarity 82 issues; flag any unclear passages for author review" [RFC7322]. 83 Given the importance of communication at the IETF, it is worth 84 considering the effects of terminology that has been identified as 85 oppressive, racist and sexist. Furthermore, we argue that certain 86 obviously oppressive terms be avoided and suggest alternatives. 87 These sets of terms are "master-slave" and "white-blacklist" for 88 their racist and race-based meanings. Since the IETF is dedicated to 89 a "culture of open participation and diverse collaboration" 90 [RFC7704], terms that can create a hostile work environment should be 91 avoided. 93 According to the work of scholar Heather Brodie Graves from 1993, 94 "one goal of the application of rhetorical theory in the technical 95 communication classroom is to assess the appropriateness of 96 particular terms and to evaluate whether these terms will facilitate 97 or hinder the readers' understanding of the technical material" 98 [BrodieGravesGraves]. This implies that in order to effectively 99 communicate the content of RFCs to all readers, it is important for 100 Authors to consider the kinds of terms or language conventions that 101 may inadvertently get in the way of effective communication. She 102 continues, "complex and subtle configurations of sexist, racist, or 103 ethnocentric language use in technical documents can derail or 104 interfere with readers' ability and desire to comprehend and follow 105 important information." 107 Indeed, problems of language are problems of everyday speech. Racist 108 and sexist language is rampant and similarly counter-productive in 109 other sectors, notably social work [Burgest]. The terms "master- 110 slave," treated in detail below are present in other realms of 111 technology, notably "automotive clutch and brake systems, clocks, 112 flip-flop circuits, computer drives, and radio transmitters" 113 [Eglash]. And the ubiquitous word "robot" is the Czech word for 114 "slave" [Kurfess]. 116 However as noted in the research by Ron Eglash, this seemingly 117 entrenched technical terminology is relatively recent and can be 118 replaced with alternative metaphors that are more accurate, clearer, 119 less distracting, and that do not offend their readers. Language 120 matters and metaphors matter. Indeed, metaphors can be incredibly 121 useful devices to make more human the complex technical concepts 122 presented in RFCs. Metaphors should not be avoided but rather taken 123 seriously. Renowned linguist George Lakoff argued in 1980 that the 124 ubiquitous use of metaphors in our everyday speech indicates a 125 fundamental instinct to "structure our most basic understandings of 126 experience" [Lakoff]. Metaphors structure relationships, and they 127 frame possibilities and impossibilities [Wyatt]. 129 Like Graves, this document recognises the monumental challenge of 130 addressing linguistics and power and attempts to "promote awareness 131 that may lead to eventual wide-spread change" [BrodieGravesGraves]. 132 To that effect, below is a tersely written list of IETF-specific 133 arguments as to why the RFC Editor should be encouraged to correct 134 larger content and clarity issues with respect to oppressive 135 metaphors: 137 - The RFC series is intended to remain online in perpetuity. 138 Societal attitudes to oppressive language shift over time in the 139 direction of more empathy, not less. 141 - That oppressive terms in RFCs are largely hidden from the larger 142 public, or read only by engineers, is no excuse to ignore social- 143 level reactions to the terms. If the terms would be a poor choice 144 for user-facing application features, the terms should be avoided 145 in technical documentation and specifications, too. 147 - The digital technology community has a problem with monoculture. 148 And because the diversity of the technical community is already a 149 problem, a key strategy to breaking monoculture is to ensure that 150 technical documentation is addressed to a wide audience and 151 multiplicity of readers. 153 - And yet the technical community is not entirely comprised of only 154 white men. Eradicating the use of oppressive terminology in 155 official RFCs recognises the presence of and acknowledges the 156 requests from black and brown engineers and from women and gender- 157 non-conforming engineers to avoid the use of oppressive 158 terminology. 160 What follow are specific alternative suggestions to "master-slave" 161 and "white-blacklist" and the rationale for the use of the 162 alternatives. 164 1.1. Master-slave 166 Master-slave is an oppressive metaphor that will and should never 167 become fully detached from history. Aside from being unprofessional 168 and oppressive it stifles participation according to Eglash: "If the 169 master-slave metaphor affected these tough-minded engineers who had 170 the gumption to make it through a technical career back in the days 171 when they may have been the only black persons in their classes, what 172 impact might it have on black students who are debating whether or 173 not to enter science and technology careers at all?" [Eglash]. 175 Aside from the arguably most important reason outlined above, the 176 term set is becoming less used and therefore increasingly less 177 compatible as more communities move away from its use (eg [Python], 178 [Drupal], and [Django]. The usage of 'master' and 'slave' in 179 hardware and software has been halted by the Los Angeles County 180 Office of Affirmative Action, the Django community, the Python 181 community and several other programming languages. This was done 182 because the language is oppressive and hurts people in the community 183 [Django2]. It is also no longer in use at the IEEE. 185 In addition to being inappropriate and arcane, the master-slave 186 metaphor is both technically and historically inaccurate. For 187 instance, in DNS the 'slave' is able to refuse zone transfers on the 188 ground that it is malformed. The metaphor is incorrect historically 189 given the most recent centuries during which "the role of the master 190 was to abdicate and the role of the slave was to revolt" 191 [McClelland]. Yet in another sense slavery is also not 'just an 192 historic term', whereas freedom from slavery is a human-rights issue 193 [UDHR], it continues to exist in the present [Wikipedia]. 194 Furthermore, this term set wasn't revived until recently, after WWII, 195 and after many of the technologies that adopted it were already in 196 use with different terminology [Eglash]. 198 Lastly, we present not an additional rationale against their use, but 199 an indicator of actual racism in the community that has been surfaced 200 as a result of this larger debate among technologists, "I don't 201 believe in PC (political correctness), mostly because the minorities 202 constantly use it to get away with anything" [Jansens]. This 203 illustrates the need to, as Graves is cited above as saying, continue 204 to raise awareness within our community for eventual, lasting change 205 on the continued front of struggle against the racists amongst us. 207 1.1.1. Suggested alternatives 209 There are also many other relationships that can be used as 210 metaphors, Eglash's research calls into question the accuracy of the 211 master-slave metaphor. Fortunately, there are ample alternatives for 212 the master-slave relationship. Several options are suggested here 213 and should be chosen based on the pairing that is most clear in 214 context: 216 - Primary-secondary 218 - Leader-follower 220 - Active-standby 222 - Primary-replica 224 - Writer-reader 226 - Coordinator-worker 228 - Parent-helper 230 Since the use of master-slave is becoming less common in other 231 technical communities, it is best to simply duplicate the metaphor 232 being used by comparable or interoperable technologies. Likewise, 233 the IETF can show positive leadership in the technical community by 234 setting standards without using oppressive metaphors. 236 1.2. Blacklist-whitelist 238 Like master-slave, the metaphorical use of white-black to connote 239 good-evil is oppressive. While master-slave might seem like a more 240 egregious example of racism, white-black is arguably worse because it 241 is more pervasive and therefore more sinister. While recent 242 headlines have decried the technical community's use of master-slave, 243 there is far less discussion about white-black despite its 244 importance. There is even a name for this pervasive language 245 pitfall: the association of white with good and black with evil is 246 known as the "bad is black effect" [Grewal]. 248 Indeed, there is an entire book on the subject, written by renowned 249 authority on race, Franz Fanon. In his book "Black Skin, White 250 Masks," Fanon makes several persuasive arguments that standard 251 language encodes subconscious in-group, out-group preferences 252 [Fanon]. 254 In the case of blacklist-whitelist in the technical documentation of 255 the IETF/IRTF, it is entirely a term of art and an arbitrary 256 metaphorical construct with no technical merit. There are scientific 257 uses of black that are related to light- blackholes are black because 258 light cannot escape them; a spectrographic blackbox is used as a 259 metaphor for things that cannot be seen (e.g., blackbox is really a 260 riff on the metaphor for light as visibility). Blacklist-whitelist 261 is not a metaphor for lightness or darkness, it is a good-evil 262 metaphor and therefore entirely based in racism. This trope has 263 significant impact on how people are seen and treated. As we've seen 264 with metaphors, its use is pervasive and, though not necessarily 265 conscious, perceptions do get promulgated through culture and 266 repetition. 268 As with master-slave, we save our technical argument for last, 269 referencing and presenting first the reasons for the use of non- 270 oppressive, alternative terminology for the sake of our humanity. 271 Indeed, our technical argument is incredibly succinct: Why use a 272 metaphor when a direct description is both succinct and clear? There 273 can be absolutely no ambiguity if one uses the terms, as suggested 274 below, allow-block rather than white-black. 276 1.2.1. Suggested alternatives 278 There are alternatives to this terminology set that vastly improve 279 clarity because they are not even metaphors without adding a single 280 additional character. The alternatives proposed here say exactly 281 what they mean: 283 - Blocklist-allowlist 284 - Block-permit 286 1.3. Other considerations 288 As we have seen, the language used in technical documentation, like 289 all written text, creates and reinforces expectations and 290 stereotypes. We propose nothing more than additional care in the 291 choice of language just as care is taken in defining standards and 292 protocols themselves. The above two examples are not exhaustive, nor 293 are they mere examples. However, we use this section to broaden the 294 context of other oppressive terminologies to encompass additional 295 concerns. 297 There are many other metaphors present in technical documentation 298 that are "terms of art" but that have no technical basis whatsoever. 299 That some of these metaphors are oppressive leaves no excuses for 300 their continued use. A term like "man-in-the-middle" is not 301 technically useful. It is not a standard term, not as clear as its 302 alternative "on-path attacker", and should therefore be avoided. 303 When presented with the opportunity to employ the use of metaphors or 304 to parrot terms of art that connote gender or race, Authors should 305 simply find a better way to explain themselves. A fun read on the 306 politics of colloquial speech by George Orwell should dissuade any 307 clever Author from using tired explanatory metaphors [Orwell]. 309 Up until recently, strict English grammatists like Orwell decried the 310 use of the neuter pronoun "they". Without a neuter singular pronoun, 311 "he" is assumed as the default singular pronoun when the gender of 312 the person is unknown or ambiguous. However, that has changed, and 313 it is now widely accepted that "they" can be used as a neuter 314 singular pronoun. Since it is unlikely that all implementers and 315 infrastructure operators are of any particular gender, "he" should 316 never be used to refer to a person in IETF/IRTF documents. An Author 317 who uses male examples sets male-ness as a standard. 319 Militarised metaphors are also a pervasive problem in language, 320 perhaps even more so in technical communities because of the 321 historical and actual relationship between technology and war. We 322 welcome additional examples of terminology that might be avoided 323 through more awareness and thoughtfulness. 325 2. Summary of recommendations 327 To summarise this document, we have bulleted some very concrete 328 action points that can be taken by Editors, reviewers and Authors, 329 both present and future. 331 Authors SHOULD: 333 - Replace the oppressive term "master-slave" with more accurate 334 alternatives, for instance from the list of Section 1.1. 336 - Replace the oppressive term "blacklist-whitelist" with more 337 accurate alternative, for instance from the list of suggested 338 alternatives at Section 1.2. 340 - Reflect on their use of metaphors generally 342 - Use the neuter "they" as the singular pronoun and 344 - Consider to roll back technical hard coding of their code and 345 protocols with the documented knowledge available online 346 [socketwench]. 348 RFC Editor and Reviewers SHOULD: * Offer alternatives for oppressive 349 terminology as an important act of correcting larger editorial issues 350 and clarifying technical concepts and * Suggest to Authors that even 351 when referencing other specifications that have not replaced 352 oppressive terminology they could provide another term with a note 353 that the term is original and not being suggested by the Author. 355 3. Security Considerations 357 As this document concerns a research document, there are no security 358 considerations. 360 4. IANA Considerations 362 This document has no actions for IANA. 364 5. References 366 5.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, 370 DOI 10.17487/RFC2119, March 1997, 371 . 373 5.2. Informative References 375 [BrodieGravesGraves] 376 Heather Brodie Graves, . and . Roger Graves, "Masters, 377 slaves, and infant mortality: Language challenges for 378 technical editing", Technical Communication Quarterly, 379 7:4, 389-414 , 1998, 380 . 382 [Burgest] Burgest, David., ""Racism in Everyday Speech and Social 383 Work Jargon."", Social Work, vol. 18, no. 4, 1973, pp. 384 20-25 , 1973, . 386 [Django] fcurella, ., "#22667 replaced occurrences of master-slave 387 terminology with leader/follower #2692", 2014, 388 . 390 [Django2] lynncyrin, ., "comment on #22667 replaced occurrences of 391 master-slave terminology with leader/follower #2692", 392 2014, . 395 [Drupal] Xano, ., "Replace 'master-slave' terminology with 396 'primary/replica'", 2014, 397 . 399 [Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy 400 in Technical Literature.", Technology and Culture, vol. 48 401 no. 2, 2007, pp. 360-369. , 2007, . 404 [Fanon] Fanon, F., "Black skin, white masks", 1952. 406 [Grewal] Grewal, D., "The 'Bad Is Black' Effect", 2017, 407 . 410 [Jansens] Bart Jansens, ., "I don't believe in PC", 2008, 411 . 414 [Kurfess] Kurfess, Thomas., "Robotics and Automation Handbook", 415 2005. 417 [Lakoff] George Lakoff, . and . Mark Johnson, "Metaphors We Live 418 By", U of Chicago P, 1980. , n.d.. 420 [McClelland] 421 McClelland, J., "We need better metaphors", 2011, 422 . 425 [Orwell] George Orwell, ., "Politics and the English Language", 426 1946. 428 [Python] Daniel Oberhaus, ., "'master-slave' Terminology Was 429 Removed from Python Programming Language", 2018, 430 . 434 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 435 DOI 10.17487/RFC7322, September 2014, 436 . 438 [RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and 439 Professional Conduct", RFC 7704, DOI 10.17487/RFC7704, 440 November 2015, . 442 [socketwench] 443 socketwench, ., "Even in tech, words matter", 2018, 444 . 447 [UDHR] United Nations General Assembly, "The Universal 448 Declaration of Human Rights", 1948, 449 . 451 [Wikipedia] 452 Wikipedia, "Slavery in the 21st century", 2018, 453 . 456 [Wyatt] Sally Wyatt, ., "Danger! Metaphors at Work in Economics, 457 Geophysiology, and the Internet", Science, Technology, & 458 Human Values, Volume: 29 issue: 2, page(s): 242-261 , 459 2004. 461 Authors' Addresses 463 Mallory Knodel 464 ARTICLE 19 466 EMail: mallory@article19.org 468 Niels ten Oever 469 University of Amsterdam 471 EMail: mail@nielstenoever.net