idnits 2.17.1 draft-knodel-terminology-02.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 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 (June 16, 2020) is 1410 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) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 2 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 Center for Democracy & Technology 4 Intended status: Best Current Practice N. ten Oever 5 Expires: December 18, 2020Texas A&M University and University of Amsterd 6 June 16, 2020 8 Terminology, Power and Inclusive Language 9 draft-knodel-terminology-02 11 Abstract 13 This document argues for moving away from specific language 14 conventions used by RFC authors and RFC Editors in order to encourage 15 inclusive terminology in the ongoing RFC series. The document also 16 provides examples of inclusive terminology as precise alternatives 17 for these conventions. 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 18, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 The primary function of the IETF is to publish documents that are 58 "readable, clear, consistent, and reasonably uniform" and one 59 function of the RFC Editor is to "[c]orrect larger content/clarity 60 issues; flag any unclear passages for author review [RFC7322]. Given 61 the importance of communication at the IETF, it is worth considering 62 the effects of terminology that has been identified as exclusionary. 63 This document argues that certain obviously exclusionary terms should 64 be avoided and replaced with alternatives. 66 First, arguments are presented for why exclusionary terms should be 67 avoided by the IETF/IRTF in general. Second, problem statements for 68 two sets of terms are presented and alternatives are referenced and 69 proposed. There is a third section on additional considerations and 70 general action points to address the RFC series, past and future. 71 Lastly, a summary of recommendations is presented. 73 The sets of terms discussed in this document are "master-slave" and 74 "whitelist-blacklist". 76 2. Terminology and power at the IETF 78 According to the work of scholar Heather Brodie Graves from 1993, 79 "one goal of the application of rhetorical theory in the technical 80 communication classroom is to assess the appropriateness of 81 particular terms and to evaluate whether these terms will facilitate 82 or hinder the readers' understanding of the technical material" 83 [BrodieGravesGraves]. This implies that in order to effectively 84 communicate the content of RFCs to all readers, it is important for 85 Authors to consider the kinds of terms or language conventions that 86 may inadvertently get in the way of effective communication. She 87 continues, "complex and subtle configurations of sexist, racist, or 88 ethnocentric language use in technical documents can derail or 89 interfere with readers' ability and desire to comprehend and follow 90 important information." 92 Indeed, problems of language are problems of everyday speech. Racist 93 and sexist language is rampant and similarly counter-productive in 94 other sectors, notably social work [Burgest]. The terms "master- 95 slave," treated in detail below are present in other realms of 96 technology, notably "automotive clutch and brake systems, clocks, 97 flip-flop circuits, computer drives, and radio transmitters" 98 [Eglash]. And the ubiquitous word "robot" is the Czech word for 99 "slave" [Kurfess]. 101 However as noted in the research by Ron Eglash, this seemingly 102 entrenched technical terminology is relatively recent. It is not too 103 late for these terms to be replaced with alternative metaphors that 104 are more accurate, clearer, less distracting, and that do not offend 105 their readers. Language matters and metaphors matter. Indeed, 106 metaphors can be incredibly useful devices to make more human the 107 complex technical concepts presented in RFCs. Metaphors should not 108 be avoided but rather taken seriously. Renowned linguist George 109 Lakoff argued in 1980 that the ubiquitous use of metaphors in our 110 everyday speech indicates a fundamental instinct to "structure our 111 most basic understandings of experience" [Lakoff]. Metaphors 112 structure relationships, and they frame possibilities and 113 impossibilities [Wyatt]. 115 Like Graves, this document recognises the monumental challenge of 116 addressing linguistics and power and attempts to "promote awareness 117 that may lead to eventual wide-spread change" [BrodieGravesGraves]. 118 To that effect, below is a tersely written list of IETF-specific 119 arguments as to why the RFC Editor should be encouraged to correct 120 larger content and clarity issues with respect to offensive 121 metaphors: 123 o The RFC series is intended to remain online in perpetuity. 124 Societal attitudes to offensive language shift over time in the 125 direction of more empathy, not less. 127 o That offensive terms in RFCs are largely hidden from the larger 128 public, or read only by engineers, is no excuse to ignore social- 129 level reactions to the terms. If the terms would be a poor choice 130 for user-facing application features, the terms should be avoided 131 in technical documentation and specifications, too. 133 o At the time of this drafting, the digital technology community has 134 a problem with monoculture. And because the diversity of the 135 technical community is already a problem, a key strategy to 136 breaking monoculture is to ensure that technical documentation is 137 addressed to a wide audience and multiplicity of readers. 139 o And yet the technical community already includes members who take 140 offense to these terms. Eradicating the use of offensive 141 terminology in official RFCs recognises the presence of and 142 acknowledges the requests from black and brown engineers and from 143 women and gender-non-conforming engineers to avoid the use of 144 offensive terminology. 146 This document does not try to prescribe terminology shifts for any 147 and all language that could be deemed offensive. Instead what follow 148 are specific alternative suggestions to "master-slave" and "white- 149 blacklist" and the rationale for the use of the alternatives. 150 Additional considerations are presented in a subsequent section. 152 2.1. Master-slave 154 Master-slave is an offensive metaphor that will and should never 155 become fully detached from history. Aside from being unprofessional 156 and offensive it stifled the participation of students whom Eglash 157 interviewed for his research. He asks: "If the master-slave metaphor 158 affected these tough-minded engineers who had the gumption to make it 159 through a technical career back in the days when they may have been 160 the only black persons in their classes, what impact might it have on 161 black students who are debating whether or not to enter science and 162 technology careers at all?" [Eglash] 164 Aside from the arguably most important reason outlined above, these 165 terms are becoming less used and therefore increasingly less 166 compatible as more communities move away from its use (eg [Python], 167 [Drupal], [Github] and [Django]. The usage of 'master' and 'slave' 168 in hardware and software has been halted by the Los Angeles County 169 Office of Affirmative Action, the Django community, the Python 170 community and several other programming languages. This was done 171 because the language is offensive and hurts people in the community 172 [Django2]. Root operator Internet Systems Consortium stopped using 173 the terms because they were asked to [ISC]. 175 In addition to being inappropriate and arcane, the master-slave 176 metaphor is both technically and historically inaccurate. For 177 instance, in DNS the 'slave' is able to refuse zone transfers on the 178 ground that it is malformed. The metaphor is incorrect historically 179 given the most recent centuries during which "the role of the master 180 was to abdicate and the role of the slave was to revolt" 181 [McClelland]. Yet in another sense slavery is also not 'just an 182 historic term', whereas freedom from slavery is a human-rights issue 183 [UDHR], it continues to exist in the present [Wikipedia]. 184 Furthermore, this term set wasn't revived until recently, after WWII, 185 and after many of the technologies that adopted it were already in 186 use with different terminology [Eglash]. 188 Lastly, we present not an additional rationale against their use, but 189 an indicator of actual racism in the community that has been surfaced 190 as a result of this larger debate among technologists, "I don't 191 believe in PC (political correctness), mostly because the minorities 192 constantly use it to get away with anything" [Jansens]. This 193 illustrates the need to, as Graves is cited above as saying, continue 194 to raise awareness within our community for eventual, lasting change 195 on the continued front of struggle against the racists amongst us. 197 2.1.1. Suggested alternatives 199 There are also many other relationships that can be used as 200 metaphors, Eglash's research calls into question the accuracy of the 201 master-slave metaphor. Fortunately, there are ample alternatives for 202 the master-slave relationship. Several options are suggested here 203 and should be chosen based on the pairing that is most clear in 204 context: 206 o Primary-secondary 208 o Primary-replica 210 o Leader-follower 212 o Active-standby 214 o Writer-reader 216 o Coordinator-worker 218 o Parent-helper 220 Since the use of master-slave is becoming less common in other 221 technical communities, it is best to simply duplicate the metaphor 222 being used by comparable or interoperable technologies. Likewise, 223 the IETF can show positive leadership in the technical community by 224 setting standards without using offensive metaphors. 226 For the DNS, RFC 8499 defines the current best practise for DNS 227 terminology and uses the term pair 'primary' and 'secondary' 228 [RFC8499]. 230 2.2. Blacklist-whitelist 232 The metaphorical use of white-black to connote good-evil is 233 offensive. While master-slave might seem like a more egregious 234 example of racism, white-black is arguably worse because it is more 235 pervasive and therefore more insidious. While recent headlines have 236 decried the technical community's use of master-slave, there is far 237 less discussion about white-black despite its importance. There is 238 even a name for this pervasive language pitfall: the association of 239 white with good and black with evil is known as the "bad is black 240 effect" [Grewal]. 242 Indeed, there is an entire book on the subject, written by renowned 243 authority on race, Frantz Fanon. In his book "Black Skin, White 244 Masks," Fanon makes several persuasive arguments that standard 245 language encodes subconscious in-group, out-group preferences 246 [Fanon]. 248 In the case of blacklist-whitelist in the technical documentation of 249 the IETF/IRTF, it is entirely a term of art and an arbitrary 250 metaphorical construct with no technical merit. There are scientific 251 uses of black that are related to light- blackholes are black because 252 light cannot escape them; a spectrographic blackbox is used as a 253 metaphor for things that cannot be seen (e.g., blackbox is really a 254 riff on the metaphor for light as visibility). Blacklist-whitelist 255 is not a metaphor for lightness or darkness, it is a good-evil 256 metaphor and therefore this trope has significant impact on how 257 people are seen and treated. As we've seen with metaphors, its use 258 is pervasive and, though not necessarily conscious, perceptions do 259 get promulgated through culture and repetition. 261 As with master-slave, we save our technical argument for last, 262 referencing and presenting first the reasons for the use of non- 263 offensive, alternative terminology for the sake of our humanity. 264 Indeed, our technical argument is incredibly succinct: Why use a 265 metaphor when a direct description is both succinct and clear? There 266 can be absolutely no ambiguity if one uses the terms, as suggested 267 below, allow-block rather than white-black. 269 2.2.1. Suggested alternatives 271 There are alternatives to this terminology set that vastly improve 272 clarity because they are not even metaphors without adding a single 273 additional character. The alternatives proposed here say exactly 274 what they mean: 276 o Blocklist-allowlist 278 o Deny-allow 280 o Droplist-accesslist 282 o Drop-permit 284 o Block-permit 286 2.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 and require action. However, we use this 294 section to broaden the context of other offensive terminologies to 295 encompass additional 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 offensive 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 neutral pronoun "they". Without a neutral singular 311 pronoun, "he" is assumed as the default singular pronoun when the 312 gender of the person is unknown or ambiguous. However, that has 313 changed, and it is now widely accepted that "they" can be used as a 314 neutral singular pronoun. Since it is unlikely that all implementers 315 and infrastructure operators are of any particular gender, "he" 316 should never be used to refer to a person in IETF/IRTF documents. An 317 Author 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 3. 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: * Replace the offensive term "master-slave" with more 332 accurate alternatives, for instance from the list of Section 2.1. * 333 Replace the offensive term "blacklist-whitelist" with more accurate 334 alternative, for instance from the list of suggested alternatives at 335 Section 2.2. * Reflect on their use of metaphors generally * Use the 336 neutral "they" as the singular pronoun and * Consider rolling back 337 technical hard coding of their standards implementations with the 338 documented knowledge available online [socketwench]. 340 RFC Editor and Reviewers MUST: * Offer alternatives for offensive 341 terminology as an important act of correcting larger editorial issues 342 and clarifying technical concepts and * Suggest to Authors that even 343 when referencing other specifications that have not replaced 344 offensive terminology they could provide another term with a note 345 that the term is original and not being suggested by the Author. 347 4. Additional references not cited above 349 ''Anyone can edit', not everyone does: Wikipedia and the gender gap' 350 by Ford, Heather and Wajcman, Judy (2017) Social Studies of Science. 351 ISSN 0306-3127 353 Grant, Barbara M. "Master--slave dialogues in humanities 354 supervision...https://doi.org/10.1177/1474022207084880 356 Miller, Carolyn. "A Humanistic Rationale for Technical Writing" 358 5. Security Considerations 360 As this document concerns a research document, there are no security 361 considerations. 363 6. IANA Considerations 365 This document has no actions for IANA. 367 7. References 369 7.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, 373 DOI 10.17487/RFC2119, March 1997, 374 . 376 7.2. Informative References 378 [BrodieGravesGraves] 379 Heather Brodie Graves, . and . Roger Graves, "Masters, 380 slaves, and infant mortality: Language challenges for 381 technical editing", Technical Communication Quarterly, 382 7:4, 389-414 , 1998, 383 . 385 [Burgest] Burgest, David., ""Racism in Everyday Speech and Social 386 Work Jargon."", Social Work, vol. 18, no. 4, 1973, pp. 387 20-25 , 1973, . 389 [Django] fcurella, ., "#22667 replaced occurrences of master-slave 390 terminology with leader/follower #2692", 2014, 391 . 393 [Django2] lynncyrin, ., "comment on #22667 replaced occurrences of 394 master-slave terminology with leader/follower #2692", 395 2014, . 398 [Drupal] Xano, ., "Replace 'master-slave' terminology with 399 'primary/replica'", 2014, 400 . 402 [Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy 403 in Technical Literature.", Technology and Culture, vol. 48 404 no. 2, 2007, pp. 360-369. , 2007, 405 . 407 [Fanon] Fanon, F., "Black skin, white masks", 1952. 409 [Github] Kevin Truong, . and VICE, "Github to Remove 'Master/Slave' 410 Terminology From its Platform", June 2020, 411 . 414 [Grewal] Grewal, D., "The 'Bad Is Black' Effect", 2017, 415 . 418 [ISC] Internet Systems Consortium, ., "@ISCdotORG reply tweet", 419 2017, 420 . 422 [Jansens] Bart Jansens, ., "I don't believe in PC", 2008, 423 . 426 [Kurfess] Kurfess, Thomas., "Robotics and Automation Handbook", 427 2005. 429 [Lakoff] George Lakoff, . and . Mark Johnson, "Metaphors We Live 430 By", U of Chicago P, 1980. , n.d.. 432 [McClelland] 433 McClelland, J., "We need better metaphors", 2011, 434 . 437 [Orwell] George Orwell, ., "Politics and the English Language", 438 1946. 440 [Python] Daniel Oberhaus, ., "'master-slave' Terminology Was 441 Removed from Python Programming Language", 2018, 442 . 446 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 447 DOI 10.17487/RFC7322, September 2014, 448 . 450 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 451 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 452 January 2019, . 454 [socketwench] 455 socketwench, ., "Even in tech, words matter", 2018, 456 . 459 [UDHR] United Nations General Assembly, "The Universal 460 Declaration of Human Rights", 1948, 461 . 463 [Wikipedia] 464 Wikipedia, "Slavery in the 21st century", 2018, 465 . 468 [Wyatt] Sally Wyatt, ., "Danger! Metaphors at Work in Economics, 469 Geophysiology, and the Internet", Science, Technology, and 470 Human Values, Volume: 29 issue: 2, page(s): 242-261 , 471 2004. 473 Authors' Addresses 475 Mallory Knodel 476 Center for Democracy & Technology 478 Email: mknodel@cdt.org 480 Niels ten Oever 481 Texas A&M University and University of Amsterdam 483 Email: mail@nielstenoever.net