idnits 2.17.1 draft-knodel-terminology-04.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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 24, 2020) is 1335 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: 'Jansens' is defined on line 443, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 8782 (Obsoleted by RFC 9132) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: February 25, 2021 Texas A&M University 6 August 24, 2020 8 Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs 9 draft-knodel-terminology-04 11 Abstract 13 This document argues for more inclusive language conventions 14 sometimes used by RFC authors and the RFC Production Centre in 15 Internet-Drafts that are work in progress, and in new RFCs that may 16 be published in any of the RFC series, in order to foster greater 17 knowledge transfer and improve diversity of participation in the 18 IETF. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 25, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 According to [RFC7322], "The ultimate goal of the RFC publication 55 process is to produce documents that are readable, clear, consistent, 56 and reasonably uniform," and one function of the RFC Editor is to 57 "[c]orrect larger content/clarity issues; flag any unclear passages 58 for author review." Documents that are published as RFCs are first 59 worked on as Internet-Drafts. 61 Given the importance of communication between people developing RFCs, 62 Internet-Drafts (I-D's), and related documents, it is worth 63 considering the effects of terminology that has been identified as 64 exclusionary. This document argues that certain obviously 65 exclusionary terms should be avoided and replaced with alternatives. 66 We propose nothing more than additional care in the choice of 67 language just as care is taken in defining standards and protocols 68 themselves. 70 This document presents arguments for why exclusionary terms should be 71 avoided in Internet-Drafts and RFCs and as an exercise describes the 72 problems introduced by some specific terms and why their proposed 73 alternatives improve technical documentation. The example terms 74 discussed in this document include "master-slave" and "whitelist- 75 blacklist". There is a final section on additional considerations 76 and general action points to address future RFCs and I-D's. Lastly, 77 a summary of recommendations is presented. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in BCP 84 14 [RFC2119][RFC8174] when, and only when, they appear in all 85 capitals, as shown here. 87 3. Terminology and Power in Internet-Drafts and RFCs 89 According to the work of scholar Heather Brodie Graves from 1993, 90 "one goal of the application of rhetorical theory in the technical 91 communication classroom is to assess the appropriateness of 92 particular terms and to evaluate whether these terms will facilitate 93 or hinder the readers' understanding of the technical material" 94 [BrodieGravesGraves]. This implies that in order to effectively 95 communicate the content of I-Ds and RFCs to all readers, it is 96 important for Authors to consider the kinds of terms or language 97 conventions that may inadvertently get in the way of effective 98 communication. She continues, "complex and subtle configurations of 99 sexist, racist, or ethnocentric language use in technical documents 100 can derail or interfere with readers' ability and desire to 101 comprehend and follow important information." 103 Indeed, problems of language are problems of everyday speech. Racist 104 and sexist language is rampant and similarly counter-productive in 105 other sectors, notably social work [Burgest]. The terms "master- 106 slave," treated in detail below are present in other realms of 107 technology, notably "automotive clutch and brake systems, clocks, 108 flip-flop circuits, computer drives, and radio transmitters" 109 [Eglash]. 111 However as noted in the research by Ron Eglash, this seemingly 112 entrenched technical terminology is relatively recent. It is not too 113 late for these terms to be replaced with alternative metaphors that 114 are more accurate, clearer, less distracting, and that do not offend 115 their readers. Language matters and metaphors matter. Indeed, 116 metaphors can be incredibly useful devices to make more human the 117 complex technical concepts presented in RFCs. Metaphors should not 118 be avoided, but rather taken seriously. Renowned linguist George 119 Lakoff argued in 1980 that the ubiquitous use of metaphors in our 120 everyday speech indicates a fundamental instinct to "structure our 121 most basic understandings of experience" [Lakoff]. Metaphors 122 structure relationships, and they frame possibilities and 123 impossibilities [Wyatt]. 125 Like Graves, this document recognises the monumental challenge of 126 addressing linguistics and power, and attempts to "promote awareness 127 that may lead to eventual wide-spread change" [BrodieGravesGraves] 128 and suggests first steps for actions that may remedy the inadvertent 129 use of undesirable terms'. To that end, the list below is a tersely 130 written set of IETF-specific arguments as to why the RFC Editor 131 should be encouraged to correct other content and clarity issues with 132 respect to exclusionary language and metaphors: 134 1. The RFC series is intended to remain online in perpetuity. 135 Societal attitudes to offensive and exclusionary language shift 136 over time in the direction of more empathy, not less. 138 2. That exclusionary terms in RFCs are largely hidden from the 139 larger public, or read only by engineers, is no excuse to ignore 140 social-level reactions to the terms. If the terms would be a 141 poor choice for user-facing application features, the terms 142 should be avoided in technical documentation and specifications, 143 too. 145 3. At the time of this drafting, the digital technology community 146 has a problem with monoculture. And because the diversity of the 147 technical community is already a problem, a key strategy to 148 breaking monoculture is to ensure that technical documentation is 149 addressed to a wider audience and greater multiplicity of 150 readers. 152 4. And yet the technical community already includes members who take 153 offense to these terms. Eradicating the use of exclusionary 154 terminology in official RFCs recognises the presence of and 155 acknowledges the requests from black and brown engineers and from 156 women and gender-non-conforming engineers to avoid the use of 157 exclusionary terminology. 159 This document does not try to prescribe terminology shifts for any 160 and all language that could be deemed exclusionary. Instead what 161 follow are two examples of specific alternative suggestions to 162 "master-slave" and "white-blacklist" and the rationale for the use of 163 the alternatives. Suggested actions for handling additional 164 considerations are presented in a subsequent section. 166 3.1. Master-Slave 168 Master-slave is an offensive and exclusionary metaphor that will and 169 should never become fully detached from history. Aside from being 170 unprofessional and exclusionary it stifled the participation of 171 students whom Eglash interviewed for his research. He asks: "If the 172 master-slave metaphor affected these tough-minded engineers who had 173 the gumption to make it through a technical career back in the days 174 when they may have been the only black persons in their classes, what 175 impact might it have on black students who are debating whether or 176 not to enter science and technology careers at all?" [Eglash] 178 Aside from the arguably most important reason outlined above, these 179 terms are becoming less used and therefore increasingly less 180 compatible as more communities move away from its use (eg [NIST], 181 [Python], [Drupal], [Github] and [Django]. The usage of 'master' and 182 'slave' in hardware and software has been halted by the Los Angeles 183 County Office of Affirmative Action, the Django community, the Python 184 community and several other programming languages. This was done 185 because the language is offensive and hurts people in the community 186 [Django2]. Root operator Internet Systems Consortium stopped using 187 the terms because they were asked to [ISC]. 189 In addition to being inappropriate and arcane, the master-slave 190 metaphor is both technically and historically inaccurate. For 191 instance, in DNS the 'slave' is able to refuse zone transfers on the 192 ground that it is malformed. The metaphor is incorrect historically 193 given the most recent centuries during which "the role of the master 194 was to abdicate and the role of the slave was to revolt" 195 [McClelland]. Yet in another sense slavery is also not 'just an 196 historic term', whereas freedom from slavery is a human-rights issue 197 [UDHR], it continues to exist in the present [Wikipedia]. 198 Furthermore, this term set wasn't revived until recently, after WWII, 199 and after many of the technologies that adopted it were already in 200 use with different terminology [Eglash]. 202 Ultimately master-slave is a poor choice since it is 1) being used 203 less frequently already 2) in a variety of applications 3) to correct 204 perceived exclusionary effects 4) at the request of concerned members 205 of the technical community. 207 To find alternatives to master-slave, one can look to myriad existing 208 implementations. There are also many other relationships that can be 209 used as metaphors, Eglash's research calls into question the accuracy 210 of the master-slave metaphor. An alternative should be chosen based 211 on the pairing that is most clear in context: 213 o Primary-secondary based on authority. See for example [RFC8499]. 215 o Primary-replica based originality. 217 o Active-standby based on state. 219 o Writer-reader based on function. 221 3.2. Blacklist-Whitelist 223 The metaphorical use of white-black to connote good-evil is 224 exclusive. While master-slave might seem like a more egregious 225 example of racism, white-black is arguably worse because it is more 226 pervasive and therefore more insidious. While recent headlines have 227 decried the technical community's use of master-slave, there is far 228 less discussion about white-black despite its importance. There is 229 even a name for this pervasive language pitfall: the association of 230 white with good and black with evil is known as the "bad is black 231 effect" [Grewal]. 233 Indeed, there is an entire book on the subject, written by renowned 234 authority on race, Frantz Fanon. In his book "Black Skin, White 235 Masks," Fanon makes several persuasive arguments that standard 236 language encodes subconscious in-group, out-group preferences 237 [Fanon]. 239 In the case of blacklist-whitelist in the technical documentation of 240 I-Ds and RFCs, it is entirely a term of art and an arbitrary 241 metaphorical construct with no technical merit. There are scientific 242 uses of black that are related to light- black holes are black 243 because light cannot escape them. Blacklist-whitelist is not a 244 metaphor for lightness or darkness, it is a good-evil metaphor and 245 therefore this trope has significant impact on how people are seen 246 and treated. As we've seen with metaphors, its use is pervasive and, 247 though not necessarily conscious, perceptions do get promulgated 248 through culture and repetition. 250 As with master-slave, we save our technical argument for last, 251 referencing and presenting first the reasons for the use of non- 252 offensive, alternative terminology for the sake of our humanity. 253 Indeed, our technical argument is incredibly succinct: Why use a 254 metaphor when a direct description is both succinct and clear? There 255 can be absolutely no ambiguity if one uses the terms, as suggested 256 below, allow-block rather than white-black. 258 There are alternatives to this terminology set that vastly improve 259 clarity because they are not even metaphors, they're descriptions. 260 The alternatives proposed here say exactly what they mean. 262 o Accept-list and Drop-list for threat signaling. See for examle 263 [RFC8612], [RFC8782], and [RFC8783]). 265 o Blocklist-allowlist, deny-allow or block-permit for permissions. 267 3.3. Other Considerations 269 As described in the preceding sections, the language used in 270 technical documentation, like all written text, creates and 271 reinforces expectations and stereotypes. We propose nothing more 272 than additional care in the choice of language just as care is taken 273 in defining standards and protocols themselves. The two examples 274 provided above are not the only cases of exclusionary language to be 275 avoided, and many more can be collected. We use this section to 276 broaden the context of other offensive and exclusionary terminologies 277 to encompass additional concerns, why spotting and eradicating 278 problematic terminologies is a valid endeavour for authors and 279 editors of technical documentaion and how this might be systematised. 281 There are many other metaphors present in technical documentation 282 that are "terms of art" but that have no technical basis whatsoever. 283 If any of these metaphors is offensive there is no excuse for its 284 continued use. A term like "man-in-the-middle" is not technically 285 useful. It is not a standard term, not as clear as its alternative 286 "on-path attacker", and should therefore be avoided. When presented 287 with the opportunity to employ the use of metaphors or to 288 unthinkingly repeat terms of art that connote gender or race, Authors 289 should simply find a better way to explain themselves. A fun read on 290 the politics of colloquial speech by George Orwell should dissuade 291 any clever Author from using tired explanatory metaphors [Orwell]. 293 Gendered pronouns and sexism are common place but easy to spot and 294 replace. Up until recently, strict English grammatists like Orwell 295 decried the use of the neutral pronoun "they". Without a neutral 296 singular pronoun, "he" is assumed as the default singular pronoun 297 when the gender of the person is unknown or ambiguous. However, that 298 has changed, and it is now widely accepted that "they" can be used as 299 a neutral singular pronoun. Since it is unlikely that all 300 implementers and infrastructure operators are of any particular 301 gender, "he" should never be used to refer to a person in I-Ds and 302 RFCs. An Author who uses male examples sets male-ness as a standard. 304 Besides race and gender, our world is full of metaphors rooted in 305 oppression, ableism, and colonialism. Militarised metaphors are also 306 a pervasive problem in language, perhaps even more so in technical 307 communities because of the historical and actual relationship between 308 technology and war. 310 While it is not our intention to be exhaustive we hope to have made a 311 persuasive case for authors and editors to pay attention to the finer 312 details of metaphor, and the ways power is replicated in technical 313 documentation unless detailed attention is paid. The example terms 314 above "master-slave" and "blacklist-whitelist" are already less 315 common. If the IETF community has learned anything from the deabte 316 over the use of these terms, and this document, it is that language 317 matters to us deeply as members of society and as engineers. And 318 because language, and society, change over time, we must approach 319 future concerns with some degree of dispassion when the arguments 320 presented in the first section can be clearly applied. 322 There is harm in protracted discussion about the validity IETF 323 participants and their experiences with exclusionary terminology. 324 The racism in the community that has been surfaced as a result of 325 this larger debate among technologists pushed away participants and 326 observers. This illustrates the need to, as Graves is cited above as 327 saying, continue to raise awareness within our community for 328 eventual, lasting change on the continued front of struggle against 329 the racists amongst us. Yet we recommend a living stylesheet, rather 330 than repeated RFCs, be used as a mechanism for monitoring 331 exclusionary language in IETF documents [Terminology]. 333 It is there that we welcome additional examples of terminology that 334 might be avoided through more awareness and thoughtfulness. 336 4. Summary of Recommendations 338 To summarise, we have bulleted some very concrete action points that 339 can be taken by Editors, reviewers and Authors, both present and 340 future as they develop and publish Internet-Drafts and new RFCs. 342 Authors SHOULD: * Replace the exclusionary terms "master-slave" and 343 "blacklist-whitelist" with more accurate alternatives. * Read and 344 reflect upon the repository of exclusionary terminology Section 2. * 345 Reflect on their use of metaphors generally. * Consider changing 346 existing exclusionary language in current (reference) implementations 347 [socketwench]. * Consult the RFC style sheet maintained by the RFC 348 editor and the community. 350 RFC Editor MUST: * Offer alternatives for exclusionary terminology as 351 an important act of correcting larger editorial issues and clarifying 352 technical concepts and * Maintain the IETF repository that collects 353 all terms that have been considered and indicate wheter they are 354 deemed acceptable, and if not what terms Authors should consider 355 instead. * Suggest to Authors that even when referencing other 356 specifications that have not replaced offensive terminology, the 357 Authors could use another term in their document and include a note 358 to say that they have used the new term as a replacement for the term 359 used in the referenced document. 361 5. Further reading 363 ''Anyone can edit', not everyone does: Wikipedia and the gender gap' 364 by Ford, Heather and Wajcman, Judy (2017) Social Studies of Science. 365 ISSN 0306-3127 367 Grant, Barbara M. "Master--slave dialogues in humanities 368 supervision...https://doi.org/10.1177/1474022207084880 370 Miller, Carolyn. "A Humanistic Rationale for Technical Writing" 372 6. Security Considerations 374 Security is dependent on a wide range of actors that are implementing 375 technical documentation. Therefore it is crucial that language is 376 clear, and understood by all that need to implement this 377 documentation. Correct and inclusive language is therefore conducive 378 for secure implementations of technical documentation. 380 7. IANA Considerations 382 This document has no actions for IANA. 384 8. References 386 8.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, 390 DOI 10.17487/RFC2119, March 1997, 391 . 393 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 394 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 395 May 2017, . 397 8.2. Informative References 399 [BrodieGravesGraves] 400 Heather Brodie Graves, . and . Roger Graves, "Masters, 401 slaves, and infant mortality: Language challenges for 402 technical editing", Technical Communication Quarterly, 403 7:4, 389-414 , 1998, 404 . 406 [Burgest] Burgest, David., ""Racism in Everyday Speech and Social 407 Work Jargon."", Social Work, vol. 18, no. 4, 1973, pp. 408 20-25 , 1973, . 410 [Django] fcurella, ., "#22667 replaced occurrences of master-slave 411 terminology with leader/follower #2692", 2014, 412 . 414 [Django2] lynncyrin, ., "comment on #22667 replaced occurrences of 415 master-slave terminology with leader/follower #2692", 416 2014, . 419 [Drupal] Xano, ., "Replace 'master-slave' terminology with 420 'primary/replica'", 2014, 421 . 423 [Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy 424 in Technical Literature.", Technology and Culture, vol. 48 425 no. 2, 2007, pp. 360-369. , 2007, 426 . 428 [Fanon] Fanon, F., "Black skin, white masks", 1952. 430 [Github] Kevin Truong, . and VICE, "Github to Remove 'Master/Slave' 431 Terminology From its Platform", June 2020, 432 . 435 [Grewal] Grewal, D., "The 'Bad Is Black' Effect", 2017, 436 . 439 [ISC] Internet Systems Consortium, ., "@ISCdotORG reply tweet", 440 2017, 441 . 443 [Jansens] Bart Jansens, ., "I don't believe in PC", 2008, 444 . 447 [Lakoff] George Lakoff, . and . Mark Johnson, "Metaphors We Live 448 By", U of Chicago P, 1980. , n.d.. 450 [McClelland] 451 McClelland, J., "We need better metaphors", 2011, 452 . 455 [NIST] Eric Geller, . and Politico, "Agency to end use of 456 technology terms such as 'master' and 'slave' over racist 457 associations", June 2020, 458 . 461 [Orwell] George Orwell, ., "Politics and the English Language", 462 1946. 464 [Python] Daniel Oberhaus, ., "'master-slave' Terminology Was 465 Removed from Python Programming Language", 2018, 466 . 470 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 471 DOI 10.17487/RFC7322, September 2014, 472 . 474 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 475 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 476 January 2019, . 478 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 479 Threat Signaling (DOTS) Requirements", RFC 8612, 480 DOI 10.17487/RFC8612, May 2019, 481 . 483 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 484 Mortensen, A., and N. Teague, "Distributed Denial-of- 485 Service Open Threat Signaling (DOTS) Signal Channel 486 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 487 . 489 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 490 Denial-of-Service Open Threat Signaling (DOTS) Data 491 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 492 May 2020, . 494 [socketwench] 495 socketwench, ., "Even in tech, words matter", 2018, 496 . 499 [Terminology] 500 IETF, "Inclusive terminology in IETF Documents", August 501 2020, . 503 [UDHR] United Nations General Assembly, "The Universal 504 Declaration of Human Rights", 1948, 505 . 507 [Wikipedia] 508 Wikipedia, "Slavery in the 21st century", 2018, 509 . 512 [Wyatt] Sally Wyatt, ., "Danger! Metaphors at Work in Economics, 513 Geophysiology, and the Internet", Science, Technology, and 514 Human Values, Volume: 29 issue: 2, page(s): 242-261 , 515 2004. 517 Authors' Addresses 518 Mallory Knodel 519 Center for Democracy & Technology 521 Email: mknodel@cdt.org 523 Niels ten Oever 524 Texas A&M University 526 Email: mail@nielstenoever.net