idnits 2.17.1 draft-knodel-terminology-01.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 (March 11, 2019) is 1873 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) == Unused Reference: 'RFC7719' is defined on line 430, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: September 12, 2019 University of Amsterdam 6 March 11, 2019 8 Terminology, Power and Offensive Language 9 draft-knodel-terminology-01 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 offensive terminology in the technical documentation of the RFC 16 series. Specifically, this document details two sets of terms that 17 are normalised on the technical level but offensive on a societal 18 level. First, arguments are presented for why any offensive terms 19 should be avoided by the IETF/IRTF. Second, problem statements for 20 both sets of terms are presented and alternatives are referenced and 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 September 12, 2019. 46 Copyright Notice 48 Copyright (c) 2019 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 1. Terminology and power at the IETF 63 The primary function of the IETF is to publish documents that are 64 "readable, clear, consistent, and reasonably uniform" and one 65 function of the RFC Editor is to "[c]orrect larger content/clarity 66 issues; flag any unclear passages for author review [RFC7322]. Given 67 the importance of communication at the IETF, it is worth considering 68 the effects of terminology that has been identified as offensive, 69 racist and sexist. Furthermore, this document argues that certain 70 obviously offensive terms be avoided and replaced with alternatives. 71 These sets of terms are "master-slave" and "white-blacklist" for 72 their racist and race-based meanings. 74 According to the work of scholar Heather Brodie Graves from 1993, 75 "one goal of the application of rhetorical theory in the technical 76 communication classroom is to assess the appropriateness of 77 particular terms and to evaluate whether these terms will facilitate 78 or hinder the readers' understanding of the technical material" 79 [BrodieGravesGraves]. This implies that in order to effectively 80 communicate the content of RFCs to all readers, it is important for 81 Authors to consider the kinds of terms or language conventions that 82 may inadvertently get in the way of effective communication. She 83 continues, "complex and subtle configurations of sexist, racist, or 84 ethnocentric language use in technical documents can derail or 85 interfere with readers' ability and desire to comprehend and follow 86 important information." 88 Indeed, problems of language are problems of everyday speech. Racist 89 and sexist language is rampant and similarly counter-productive in 90 other sectors, notably social work [Burgest]. The terms "master- 91 slave," treated in detail below are present in other realms of 92 technology, notably "automotive clutch and brake systems, clocks, 93 flip-flop circuits, computer drives, and radio transmitters" 95 [Eglash]. And the ubiquitous word "robot" is the Czech word for 96 "slave" [Kurfess]. 98 However as noted in the research by Ron Eglash, this seemingly 99 entrenched technical terminology is relatively recent. It is not too 100 late for these terms to be replaced with alternative metaphors that 101 are more accurate, clearer, less distracting, and that do not offend 102 their readers. Language matters and metaphors matter. Indeed, 103 metaphors can be incredibly useful devices to make more human the 104 complex technical concepts presented in RFCs. Metaphors should not 105 be avoided but rather taken seriously. Renowned linguist George 106 Lakoff argued in 1980 that the ubiquitous use of metaphors in our 107 everyday speech indicates a fundamental instinct to "structure our 108 most basic understandings of experience" [Lakoff]. Metaphors 109 structure relationships, and they frame possibilities and 110 impossibilities [Wyatt]. 112 Like Graves, this document recognises the monumental challenge of 113 addressing linguistics and power and attempts to "promote awareness 114 that may lead to eventual wide-spread change" [BrodieGravesGraves]. 115 To that effect, below is a tersely written list of IETF-specific 116 arguments as to why the RFC Editor should be encouraged to correct 117 larger content and clarity issues with respect to offensive 118 metaphors: 120 o The RFC series is intended to remain online in perpetuity. 121 Societal attitudes to offensive language shift over time in the 122 direction of more empathy, not less. 124 o That offensive terms in RFCs are largely hidden from the larger 125 public, or read only by engineers, is no excuse to ignore social- 126 level reactions to the terms. If the terms would be a poor choice 127 for user-facing application features, the terms should be avoided 128 in technical documentation and specifications, too. 130 o At the time of this drafting, the digital technology community has 131 a problem with monoculture. And because the diversity of the 132 technical community is already a problem, a key strategy to 133 breaking monoculture is to ensure that technical documentation is 134 addressed to a wide audience and multiplicity of readers. 136 o And yet the technical community already includes members who take 137 offense to these terms. Eradicating the use of offensive 138 terminology in official RFCs recognises the presence of and 139 acknowledges the requests from black and brown engineers and from 140 women and gender-non-conforming engineers to avoid the use of 141 offensive terminology. 143 This document does not try to prescribe terminology shifts for any 144 and all language that could be deemed offensive. Instead what follow 145 are specific alternative suggestions to "master-slave" and "white- 146 blacklist" and the rationale for the use of the alternatives. 147 Additional considerations are presented in a subsequent section. 149 1.1. Master-slave 151 Master-slave is an offensive metaphor that will and should never 152 become fully detached from history. Aside from being unprofessional 153 and offensive it stifled the participation of students whom Eglash 154 interviewed for his research. He asks: "If the master-slave metaphor 155 affected these tough-minded engineers who had the gumption to make it 156 through a technical career back in the days when they may have been 157 the only black persons in their classes, what impact might it have on 158 black students who are debating whether or not to enter science and 159 technology careers at all?" [Eglash] 161 Aside from the arguably most important reason outlined above, the 162 term set is becoming less used and therefore increasingly less 163 compatible as more communities move away from its use (eg [Python], 164 [Drupal], and [Django]. The usage of 'master' and 'slave' in 165 hardware and software has been halted by the Los Angeles County 166 Office of Affirmative Action, the Django community, the Python 167 community and several other programming languages. This was done 168 because the language is offensive and hurts people in the community 169 [Django2]. It is also no longer in use at the IEEE. 171 In addition to being inappropriate and arcane, the master-slave 172 metaphor is both technically and historically inaccurate. For 173 instance, in DNS the 'slave' is able to refuse zone transfers on the 174 ground that it is malformed. The metaphor is incorrect historically 175 given the most recent centuries during which "the role of the master 176 was to abdicate and the role of the slave was to revolt" 177 [McClelland]. Yet in another sense slavery is also not 'just an 178 historic term', whereas freedom from slavery is a human-rights issue 179 [UDHR], it continues to exist in the present [Wikipedia]. 180 Furthermore, this term set wasn't revived until recently, after WWII, 181 and after many of the technologies that adopted it were already in 182 use with different terminology [Eglash]. 184 Lastly, we present not an additional rationale against their use, but 185 an indicator of actual racism in the community that has been surfaced 186 as a result of this larger debate among technologists, "I don't 187 believe in PC (political correctness), mostly because the minorities 188 constantly use it to get away with anything" [Jansens]. This 189 illustrates the need to, as Graves is cited above as saying, continue 190 to raise awareness within our community for eventual, lasting change 191 on the continued front of struggle against the racists amongst us. 193 1.1.1. Suggested alternatives 195 There are also many other relationships that can be used as 196 metaphors, Eglash's research calls into question the accuracy of the 197 master-slave metaphor. Fortunately, there are ample alternatives for 198 the master-slave relationship. Several options are suggested here 199 and should be chosen based on the pairing that is most clear in 200 context: 202 o Primary-secondary 204 o Leader-follower 206 o Active-standby 208 o Primary-replica 210 o Writer-reader 212 o Coordinator-worker 214 o Parent-helper 216 Since the use of master-slave is becoming less common in other 217 technical communities, it is best to simply duplicate the metaphor 218 being used by comparable or interoperable technologies. Likewise, 219 the IETF can show positive leadership in the technical community by 220 setting standards without using offensive metaphors. 222 For the DNS, RFC 7719 defines the current best practise for DNS 223 terminology and uses the term pair 'primary' and 'secondary'. 225 1.2. Blacklist-whitelist 227 The metaphorical use of white-black to connote good-evil is 228 offensive. While master-slave might seem like a more egregious 229 example of racism, white-black is arguably worse because it is more 230 pervasive and therefore more insidious. While recent headlines have 231 decried the technical community's use of master-slave, there is far 232 less discussion about white-black despite its importance. There is 233 even a name for this pervasive language pitfall: the association of 234 white with good and black with evil is known as the "bad is black 235 effect" [Grewal]. 237 Indeed, there is an entire book on the subject, written by renowned 238 authority on race, Frantz Fanon. In his book "Black Skin, White 239 Masks," Fanon makes several persuasive arguments that standard 240 language encodes subconscious in-group, out-group preferences 241 [Fanon]. 243 In the case of blacklist-whitelist in the technical documentation of 244 the IETF/IRTF, it is entirely a term of art and an arbitrary 245 metaphorical construct with no technical merit. There are scientific 246 uses of black that are related to light- blackholes are black because 247 light cannot escape them; a spectrographic blackbox is used as a 248 metaphor for things that cannot be seen (e.g., blackbox is really a 249 riff on the metaphor for light as visibility). Blacklist-whitelist 250 is not a metaphor for lightness or darkness, it is a good-evil 251 metaphor and therefore this trope has significant impact on how 252 people are seen and treated. As we've seen with metaphors, its use 253 is pervasive and, though not necessarily conscious, perceptions do 254 get promulgated through culture and repetition. 256 As with master-slave, we save our technical argument for last, 257 referencing and presenting first the reasons for the use of non- 258 offensive, alternative terminology for the sake of our humanity. 259 Indeed, our technical argument is incredibly succinct: Why use a 260 metaphor when a direct description is both succinct and clear? There 261 can be absolutely no ambiguity if one uses the terms, as suggested 262 below, allow-block rather than white-black. 264 1.2.1. Suggested alternatives 266 There are alternatives to this terminology set that vastly improve 267 clarity because they are not even metaphors without adding a single 268 additional character. The alternatives proposed here say exactly 269 what they mean: 271 o Blocklist-allowlist 273 o Block-permit 275 1.3. Other considerations 277 As we have seen, the language used in technical documentation, like 278 all written text, creates and reinforces expectations and 279 stereotypes. We propose nothing more than additional care in the 280 choice of language just as care is taken in defining standards and 281 protocols themselves. The above two examples are not exhaustive, nor 282 are they mere examples and require action. However, we use this 283 section to broaden the context of other offensive terminologies to 284 encompass additional concerns. 286 There are many other metaphors present in technical documentation 287 that are "terms of art" but that have no technical basis whatsoever. 288 That some of these metaphors are offensive leaves no excuses for 289 their continued use. A term like "man-in-the-middle" is not 290 technically useful. It is not a standard term, not as clear as its 291 alternative "on-path attacker", and should therefore be avoided. 292 When presented with the opportunity to employ the use of metaphors or 293 to parrot terms of art that connote gender or race, Authors should 294 simply find a better way to explain themselves. A fun read on the 295 politics of colloquial speech by George Orwell should dissuade any 296 clever Author from using tired explanatory metaphors [Orwell]. 298 Up until recently, strict English grammatists like Orwell decried the 299 use of the neutral pronoun "they". Without a neutral singular 300 pronoun, "he" is assumed as the default singular pronoun when the 301 gender of the person is unknown or ambiguous. However, that has 302 changed, and it is now widely accepted that "they" can be used as a 303 neutral singular pronoun. Since it is unlikely that all implementers 304 and infrastructure operators are of any particular gender, "he" 305 should never be used to refer to a person in IETF/IRTF documents. An 306 Author who uses male examples sets male-ness as a standard. 308 Militarised metaphors are also a pervasive problem in language, 309 perhaps even more so in technical communities because of the 310 historical and actual relationship between technology and war. We 311 welcome additional examples of terminology that might be avoided 312 through more awareness and thoughtfulness. 314 2. Summary of recommendations 316 To summarise this document, we have bulleted some very concrete 317 action points that can be taken by Editors, reviewers and Authors, 318 both present and future. 320 Authors SHOULD: * Replace the offensive term "master-slave" with more 321 accurate alternatives, for instance from the list of Section 1.1. * 322 Replace the offensive term "blacklist-whitelist" with more accurate 323 alternative, for instance from the list of suggested alternatives at 324 Section 1.2. * Reflect on their use of metaphors generally * Use the 325 neutral "they" as the singular pronoun and * Consider rolling back 326 technical hard coding of their standards implementations with the 327 documented knowledge available online [socketwench]. 329 RFC Editor and Reviewers SHOULD: * Offer alternatives for offensive 330 terminology as an important act of correcting larger editorial issues 331 and clarifying technical concepts and * Suggest to Authors that even 332 when referencing other specifications that have not replaced 333 offensive terminology they could provide another term with a note 334 that the term is original and not being suggested by the Author. 336 3. Additional references not cited above 338 ''Anyone can edit', not everyone does: Wikipedia and the gender gap' 339 by Ford, Heather and Wajcman, Judy (2017) Social Studies of Science. 340 ISSN 0306-3127 342 Grant, Barbara M. "Master--slave dialogues in humanities 343 supervision...https://doi.org/10.1177/1474022207084880 345 Miller, Carolyn. "A Humanistic Rationale for Technical Writing" 347 4. Security Considerations 349 As this document concerns a research document, there are no security 350 considerations. 352 5. IANA Considerations 354 This document has no actions for IANA. 356 6. References 358 6.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 6.2. Informative References 367 [BrodieGravesGraves] 368 Heather Brodie Graves, . and . Roger Graves, "Masters, 369 slaves, and infant mortality: Language challenges for 370 technical editing", Technical Communication Quarterly, 371 7:4, 389-414 , 1998, 372 . 374 [Burgest] Burgest, David., ""Racism in Everyday Speech and Social 375 Work Jargon."", Social Work, vol. 18, no. 4, 1973, pp. 376 20-25 , 1973, . 378 [Django] fcurella, ., "#22667 replaced occurrences of master-slave 379 terminology with leader/follower #2692", 2014, 380 . 382 [Django2] lynncyrin, ., "comment on #22667 replaced occurrences of 383 master-slave terminology with leader/follower #2692", 384 2014, . 387 [Drupal] Xano, ., "Replace 'master-slave' terminology with 388 'primary/replica'", 2014, 389 . 391 [Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy 392 in Technical Literature.", Technology and Culture, vol. 48 393 no. 2, 2007, pp. 360-369. , 2007, 394 . 396 [Fanon] Fanon, F., "Black skin, white masks", 1952. 398 [Grewal] Grewal, D., "The 'Bad Is Black' Effect", 2017, 399 . 402 [Jansens] Bart Jansens, ., "I don't believe in PC", 2008, 403 . 406 [Kurfess] Kurfess, Thomas., "Robotics and Automation Handbook", 407 2005. 409 [Lakoff] George Lakoff, . and . Mark Johnson, "Metaphors We Live 410 By", U of Chicago P, 1980. , n.d.. 412 [McClelland] 413 McClelland, J., "We need better metaphors", 2011, 414 . 417 [Orwell] George Orwell, ., "Politics and the English Language", 418 1946. 420 [Python] Daniel Oberhaus, ., "'master-slave' Terminology Was 421 Removed from Python Programming Language", 2018, 422 . 426 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 427 DOI 10.17487/RFC7322, September 2014, 428 . 430 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 431 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 432 2015, . 434 [socketwench] 435 socketwench, ., "Even in tech, words matter", 2018, 436 . 439 [UDHR] United Nations General Assembly, "The Universal 440 Declaration of Human Rights", 1948, 441 . 443 [Wikipedia] 444 Wikipedia, "Slavery in the 21st century", 2018, 445 . 448 [Wyatt] Sally Wyatt, ., "Danger! Metaphors at Work in Economics, 449 Geophysiology, and the Internet", Science, Technology, and 450 Human Values, Volume: 29 issue: 2, page(s): 242-261 , 451 2004. 453 Authors' Addresses 455 Mallory Knodel 456 ARTICLE 19 458 Email: mallory@article19.org 460 Niels ten Oever 461 University of Amsterdam 463 Email: mail@nielstenoever.net