idnits 2.17.1 draft-knodel-terminology-07.txt: -(447): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(552): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. 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 date (22 October 2021) is 918 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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 (~~), 2 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: Informational N. ten Oever 5 Expires: 25 April 2022 University of Amsterdam 6 22 October 2021 8 Terminology, Power, and Exclusionary Language in Internet-Drafts and 9 RFCs 10 draft-knodel-terminology-07 12 Abstract 14 This document argues for more inclusive language conventions 15 sometimes used by RFC authors and the RFC Production Centre in 16 Internet-Drafts that are work in progress, and in new RFCs that may 17 be published in any of the RFC series, in order to foster greater 18 knowledge transfer and improve diversity of participation in the 19 IETF. 21 This document represents the opinion of the authors and does not have 22 IETF consensus. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 25 April 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology and Power in Internet-Drafts and RFCs . . . . . . 3 59 2.1. Master-Slave . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Blacklist-Whitelist . . . . . . . . . . . . . . . . . . . 6 61 2.3. Other Considerations . . . . . . . . . . . . . . . . . . 7 62 3. Summary of Recommendations . . . . . . . . . . . . . . . . . 8 63 4. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Informative References . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 According to [RFC7322], "The ultimate goal of the RFC publication 72 process is to produce documents that are readable, clear, consistent, 73 and reasonably uniform," and one function of the RFC Editor is to 74 "[c]orrect larger content/clarity issues; flag any unclear passages 75 for author review." Documents that are published as RFCs are first 76 worked on as Internet-Drafts. 78 Given the importance of communication between people developing RFCs, 79 Internet-Drafts (I-D's), and related documents, it is worth 80 considering the effects of terminology that has been identified as 81 exclusionary. This document argues that certain obviously 82 exclusionary terms should be avoided and replaced with alternatives. 83 We propose nothing more than additional care in the choice of 84 language just as care is taken in defining standards and protocols 85 themselves. 87 This document presents arguments for why exclusionary terms should be 88 avoided in Internet-Drafts and RFCs and as an exercise describes the 89 problems introduced by some specific terms and why their proposed 90 alternatives improve technical documentation. The example terms 91 discussed in this document include "master-slave" and "whitelist- 92 blacklist". There is a final section on additional considerations 93 and general action points to address future RFCs and I-D's. Lastly, 94 a summary of recommendations is presented. 96 2. Terminology and Power in Internet-Drafts and RFCs 98 According to the work of scholar Heather Brodie Graves from 1993, 99 "one goal of the application of rhetorical theory in the technical 100 communication classroom is to assess the appropriateness of 101 particular terms and to evaluate whether these terms will facilitate 102 or hinder the readers' understanding of the technical material" 103 [BrodieGravesGraves]. This implies that in order to effectively 104 communicate the content of I-Ds and RFCs to all readers, it is 105 important for Authors to consider the kinds of terms or language 106 conventions that may inadvertently get in the way of effective 107 communication. She continues, "complex and subtle configurations of 108 sexist, racist, or ethnocentric language use in technical documents 109 can derail or interfere with readers' ability and desire to 110 comprehend and follow important information." 112 Indeed, problems of language are problems of everyday speech. Racist 113 and sexist language is rampant and similarly counter-productive in 114 other sectors, notably social work [Burgest]. The terms "master- 115 slave," treated in detail below are present in other realms of 116 technology, notably "automotive clutch and brake systems, clocks, 117 flip-flop circuits, computer drives, and radio transmitters" 118 [Eglash]. 120 However, as noted in the research by Ron Eglash, this seemingly 121 entrenched technical terminology is relatively recent. It is not too 122 late for these terms to be replaced with alternative metaphors that 123 are more accurate, clearer, less distracting, and that do not offend 124 their readers. Language matters and metaphors matter. Indeed, 125 metaphors can be incredibly useful devices to make more human the 126 complex technical concepts presented in RFCs. Metaphors should not 127 be avoided, but rather taken seriously. Renowned linguist George 128 Lakoff argued in 1980 that the ubiquitous use of metaphors in our 129 everyday speech indicates a fundamental instinct to "structure our 130 most basic understandings of experience" [Lakoff]. Metaphors 131 structure relationships, and they frame possibilities and 132 impossibilities [Wyatt]. 134 Like Graves, this document recognises the monumental challenge of 135 addressing linguistics and power, and attempts to "promote awareness 136 that may lead to eventual wide-spread change" [BrodieGravesGraves] 137 and suggests first steps for actions that may remedy the inadvertent 138 use of undesirable terms. To that end, the list below is a tersely 139 written set of IETF-specific arguments as to why the RFC Editor 140 should be encouraged to correct other content and clarity issues with 141 respect to exclusionary language and metaphors: 143 1. The RFC series is intended to remain online in perpetuity. 144 Societal attitudes to offensive and exclusionary language shift 145 over time in the direction of more empathy, not less. 147 2. That exclusionary terms in RFCs are largely hidden from the wider 148 public, or read only by engineers, is no excuse to ignore social- 149 level reactions to the terms. If the terms would be a poor 150 choice for user-facing application features, the terms should be 151 avoided in technical documentation and specifications, too. 153 3. At the time of writing, the digital technology community has a 154 problem with monoculture [RFC7704] [Cath]. And because the lack 155 of diversity of the technical community is a problem, a key 156 strategy to breaking monoculture is to ensure that technical 157 documentation is addressed to a wider audience and more readers. 159 4. The technical community already includes members who take offense 160 to these terms. Eradicating the use of exclusionary terminology 161 in RFCs and Internet-Drafts recognises the presence of and 162 acknowledges the requests from black and brown engineers and from 163 women and gender-non-conforming engineers to avoid the use of 164 exclusionary terminology [Wired] [Seele]. 166 This document does not try to prescribe terminology shifts for any 167 and all language that could be deemed exclusionary. Instead what 168 follow are two examples of specific alternative suggestions to 169 "master-slave" and "white-blacklist" and the rationale for the use of 170 the alternatives. Suggested actions for handling additional 171 considerations are presented in a subsequent section. 173 2.1. Master-Slave 175 Master-slave is an offensive and exclusionary metaphor that will and 176 should never become fully detached from history. Aside from being 177 unprofessional and exclusionary it stifled the participation of 178 students whom Eglash interviewed for his research. He asks: "If the 179 master-slave metaphor affected these tough-minded engineers who had 180 the gumption to make it through a technical career back in the days 181 when they may have been the only black persons in their classes, what 182 impact might it have on black students who are debating whether or 183 not to enter science and technology careers at all?" [Eglash] 185 Aside from the arguably most important reason outlined above, these 186 terms are becoming less used and therefore increasingly less 187 compatible as more communities move away from their use (e.g. 188 [NIST], [Python], [Drupal], [Github] and [Django] ). The usage of 189 'master' and 'slave' in hardware and software has been halted by the 190 Los Angeles County Office of Affirmative Action, the Django 191 community, the Python community and several other programming 192 languages. This was done because the language is offensive and hurts 193 people in the community [Django2]. Root operator The Internet 194 Systems Consortium recognised that the terms 'master' and 'slave' are 195 very value-laden and responded to multiple requests from users by 196 offering an inoffensive alternative [ISC]. 198 In addition to being inappropriate, the master-slave metaphor is both 199 technically and historically inaccurate. For instance, in DNS the 200 'slave' is able to refuse zone transfers on the ground that it is 201 malformed. The metaphor is incorrect historically given the most 202 recent centuries during which "the role of the master was to abdicate 203 and the role of the slave was to revolt" [McClelland]. Yet in 204 another sense slavery is also not 'just an historic term', whereas 205 freedom from slavery is a human-rights issue [UDHR], it continues to 206 exist in the present [Wikipedia]. Furthermore, this term set wasn't 207 revived until recently, after WWII, and after many of the 208 technologies that adopted it were already in use with different 209 terminology [Eglash]. 211 Ultimately master-slave is a poor choice since: 213 1. it is being used less frequently already in a variety of 214 applications, 216 2. it has perceived exclusionary effects, 218 3. oncerned members of the technical community have requested that 219 its use be ceased. 221 Eglash's research calls into question the accuracy of the master- 222 slave metaphor. To find alternatives to master-slave, one can look 223 to myriad existing implementations. There are also many other 224 relationships that can be used as metaphors. An alternative should 225 be chosen based on the pairing that is most clear in context: 227 * Primary-secondary based on authority. See for example [RFC8499]. 229 * Primary-replica based originality. 231 * Active-standby based on state. 233 * Writer-reader based on function. 235 2.2. Blacklist-Whitelist 237 The metaphorical use of white-black to connote good-evil is 238 exclusive. While master-slave might seem like a more egregious 239 example of racism, white-black is arguably worse because it is more 240 pervasive and therefore more insidious. While recent headlines have 241 decried the technical community's use of master-slave, there is far 242 less discussion about white-black despite its importance. There is 243 even a name for this pervasive language pitfall: the association of 244 white with good and black with evil is known as the "bad is black 245 effect" [Grewal]. 247 Indeed, there is an entire book on the subject, written by renowned 248 authority on race, Frantz Fanon. In his book "Black Skin, White 249 Masks," Fanon makes several persuasive arguments that standard 250 language encodes subconscious in-group, out-group preferences 251 [Fanon]. 253 In the case of blacklist-whitelist in the technical documentation of 254 I-Ds and RFCs, it is entirely a term of art and an arbitrary 255 metaphorical construct with no technical merit. There are scientific 256 uses of black that are related to light- black holes are black 257 because light cannot escape them. Blacklist-whitelist is not a 258 metaphor for lightness or darkness, it is a good-evil metaphor and 259 therefore this trope has significant impact on how people are seen 260 and treated. As we've seen with metaphors, its use is pervasive and, 261 though not necessarily conscious, perceptions do get promulgated 262 through culture and repetition. 264 As with master-slave, we save our technical argument for last, 265 referencing and presenting first the reasons for the use of non- 266 offensive, alternative terminology for the sake of our humanity. 267 Indeed, our technical argument is incredibly succinct: Why use a 268 metaphor when a direct description is both succinct and clear? There 269 can be absolutely no ambiguity if one uses the terms, as suggested 270 below, allow-block rather than white-black. 272 There are alternatives to this terminology set that vastly improve 273 clarity because they are not even metaphors, they're descriptions. 274 The alternatives proposed here say exactly what they mean. 276 * Accept-list and Drop-list for threat signaling. See for example 277 [RFC8612], [RFC8782], and [RFC8783]). 279 * Blocklist-allowlist, deny-allow, exempt-allowlist or block-permit 280 for permissions. 282 2.3. Other Considerations 284 As described in the preceding sections, the language used in 285 technical documentation, like all written text, creates and 286 reinforces expectations and stereotypes. We propose nothing more 287 than additional care in the choice of language just as care is taken 288 in defining standards and protocols themselves. The two examples 289 provided above are not the only cases of exclusionary language to be 290 avoided, and many more can be collected. We use this section to 291 broaden the context of other offensive and exclusionary terminologies 292 to encompass additional concerns, why spotting and eradicating 293 problematic terminologies is a valid endeavour for authors and 294 editors of technical documentation and how this might be 295 systematised. 297 There are many other metaphors present in technical documentation 298 that are "terms of art" but that have no technical basis whatsoever. 299 If any of these metaphors is offensive there is no excuse for its 300 continued use. A term like "man-in-the-middle" is not technically 301 useful. It is not a standard term, not as clear as its alternative 302 "on-path attacker", and should therefore be avoided. When presented 303 with the opportunity to employ the use of metaphors or to 304 unthinkingly repeat terms of art that connote gender or race, Authors 305 should simply find a better way to explain themselves. A fun read on 306 the politics of colloquial speech by George Orwell should dissuade 307 any clever Author from using tired explanatory metaphors [Orwell]. 309 Gendered pronouns and sexism are common place but easy to spot and 310 replace. Without a neutral singular pronoun, "he" is assumed as the 311 default singular pronoun when the gender of the person is unknown or 312 ambiguous. However, that has changed, and it is now widely accepted 313 that "they" can be used as a neutral singular pronoun. Since it is 314 unlikely that all implementers and infrastructure operators are of 315 any particular gender, "he" should never be used to refer to a person 316 in I-Ds and RFCs. An Author who uses male examples sets male-ness as 317 a standard. 319 Besides race and gender, our world is full of metaphors rooted in 320 oppression, ableism, and colonialism. Militarised metaphors are also 321 a pervasive problem in language, perhaps even more so in technical 322 communities because of the historical and actual relationship between 323 technology and war. 325 While it is not our intention to be exhaustive we hope to have made a 326 persuasive case for authors and editors to pay attention to the finer 327 details of metaphor, and the ways power is replicated in technical 328 documentation unless detailed attention is paid. The example terms 329 above "master-slave" and "blacklist-whitelist" are already less 330 common. If the IETF community has learned anything from the debate 331 over the use of these terms, and this document, it is that language 332 matters to us deeply as members of society and as engineers. And 333 because language, and society, change over time, we must approach 334 future concerns with some degree of dispassion when the arguments 335 presented in the first section can be clearly applied. 337 There is harm in protracted discussion about the validity IETF 338 participants and their experiences with exclusionary terminology. 339 Nevertheless, that harm is outweighed by inaction, therefore this 340 document seeks to continue that discussion and encourages further 341 debate on the issue. The racist behavior in the community that has 342 surfaced as a result of this larger debate among technologists (see 343 for example https://datatracker.ietf.org/doc/html/draft-les-white- 344 intersectional-dots-00 and https://datatracker.ietf.org/doc/html/ 345 draft-les-white-tls-preferred-pronouns-00 ) reportedly pushed away 346 participants and observers [Conger]. This illustrates the need to, 347 as Graves is cited above as saying, continue to raise awareness 348 within our community for eventual, lasting change on the continued 349 front of struggle against the racist behavior. Yet we recommend a 350 living stylesheet, rather than repeated RFCs, be used as a mechanism 351 for monitoring exclusionary language in IETF documents 352 [inclusiveterminology]. 354 It is there that we welcome additional examples of terminology that 355 might be avoided through more awareness and thoughtfulness. 357 3. Summary of Recommendations 359 To summarise, we have listed some very concrete action points that 360 can be taken by Editors, reviewers and Authors, both present and 361 future as they develop and publish Internet-Drafts and new RFCs. 363 The authors think that document authors should: 365 * Replace the exclusionary terms "master-slave" and "blacklist- 366 whitelist" with more accurate alternatives. 368 * Read and reflect upon the repository of exclusionary terminology 369 maintained by the community [inclusiveterminology]. 371 * Reflect on their use of metaphors generally. 373 * Consider changing existing exclusionary language in current 374 (reference) implementations [socketwench]. 376 * Consult the RFC style sheet maintained by the RFC editor 377 The authors think that the RFC editor should: * Offer alternatives 378 for exclusionary terminology as an important act of correcting larger 379 editorial issues and clarifying technical concepts and * Consult the 380 IETF community and other sources to build a style sheet giving 381 guidance to authors on the use of terminology, that collects all 382 terms that have been considered and indicate whether they are deemed 383 acceptable, and if not what terms Authors should consider instead. * 384 Suggest to Authors that even when referencing other specifications 385 that have not replaced offensive terminology, the Authors could use 386 another term in their document and include a note to say that they 387 have used the new term as a replacement for the term used in the 388 referenced document. 390 4. Further Reading 392 For more information on this topic we suggest reading: 394 Ford, Heather., Wajcman, Judy. 2017. "'Anyone can edit', not 395 everyone does: Wikipedia and the gender gap" Social Studies of 396 Science. ISSN 0306-3127 398 Grant, Barbara M. 2008. "Master--slave dialogues in humanities 399 supervision" Arts and Humanities in Higher Education, Volume: 7 400 issue: 1, page(s): 9-27 https://doi.org/10.1177/1474022207084880 402 Miller, Carolyn, R. 1979. "A Humanistic Rationale for Technical 403 Writing" College English, Vol. 40, No. 6, pp. 610-617 405 5. Security Considerations 407 Security is dependent on a wide range of actors that are implementing 408 technical documentation. Therefore it is crucial that language is 409 clear, and understood by all that need to implement this 410 documentation. Correct and inclusive language is therefore conducive 411 for secure implementations of technical documentation. 413 6. IANA Considerations 415 This document has no actions for IANA. 417 7. Informative References 419 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 420 DOI 10.17487/RFC7322, September 2014, 421 . 423 [RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and 424 Professional Conduct", RFC 7704, DOI 10.17487/RFC7704, 425 November 2015, . 427 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 428 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 429 January 2019, . 431 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 432 Mortensen, A., and N. Teague, "Distributed Denial-of- 433 Service Open Threat Signaling (DOTS) Signal Channel 434 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 435 . 437 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 438 Denial-of-Service Open Threat Signaling (DOTS) Data 439 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 440 May 2020, . 442 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 443 Threat Signaling (DOTS) Requirements", RFC 8612, 444 DOI 10.17487/RFC8612, May 2019, 445 . 447 [Burgest] Burgest, David R., "“Racism in Everyday Speech and Social 448 Work Jargon.”", Social Work, vol. 18, no. 4, 1973, pp. 449 20-25 , 1973, . 451 [Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy 452 in Technical Literature.", Technology and Culture, vol. 48 453 no. 2, 2007, pp. 360-369. , 2007, 454 . 456 [BrodieGravesGraves] 457 Heather Brodie Graves, . and . Roger Graves, "Masters, 458 slaves, and infant mortality: Language challenges for 459 technical editing", Technical Communication Quarterly, 460 7:4, 389-414 , 1998, 461 . 463 [Wyatt] Sally Wyatt, ., "Danger! Metaphors at Work in Economics, 464 Geophysiology, and the Internet", Science, Technology, and 465 Human Values, Volume: 29 issue: 2, page(s): 242-261 , 466 2004. 468 [Lakoff] George Lakoff, . and . Mark Johnson, "Metaphors We Live 469 By", U of Chicago P, 1980. , n.d.. 471 [Orwell] George Orwell, ., "Politics and the English Language", 472 1946. 474 [McClelland] 475 McClelland, J., "We need better metaphors", 2011, 476 . 479 [UDHR] United Nations General Assembly, "The Universal 480 Declaration of Human Rights", 1948, 481 . 483 [Fanon] Fanon, F., "Black skin, white masks", 1952. 485 [Python] Daniel Oberhaus, ., "'master-slave' Terminology Was 486 Removed from Python Programming Language", 2018, 487 . 491 [Django] fcurella, ., "#22667 replaced occurrences of master-slave 492 terminology with leader/follower #2692", 2014, 493 . 495 [Django2] lynncyrin, ., "comment on #22667 replaced occurrences of 496 master-slave terminology with leader/follower #2692", 497 2014, . 500 [Wikipedia] 501 Wikipedia, "Slavery in the 21st century", 2018, 502 . 505 [Drupal] Xano, ., "Replace 'master-slave' terminology with 506 'primary/replica'", 2014, 507 . 509 [Grewal] Grewal, D., "The 'Bad Is Black' Effect", 2017, 510 . 513 [socketwench] 514 socketwench, ., "Even in tech, words matter", 2018, 515 . 518 [ISC] Internet Systems Consortium, ., "@ISCdotORG reply tweet", 519 2017, 520 . 522 [Github] Kevin Truong, . and VICE, "Github to Remove 'Master/Slave' 523 Terminology From its Platform", June 2020, 524 . 527 [NIST] Eric Geller, . and Politico, "Agency to end use of 528 technology terms such as 'master' and 'slave' over racist 529 associations", June 2020, 530 . 533 [inclusiveterminology] 534 IETF, "Inclusive terminology in IETF Documents", August 535 2020, . 537 [Cath] Corinne Cath, ., "The Technology We Choose to Create: 538 Human Rights Advocacy in the Internet Engineering Task 539 Force", Telecommunications Policy 45, no. 6 (July 1, 540 2021): 102144. , 2021, 541 . 543 [Wired] Elizabeth Landau, . and Wired, "Tech Confronts Its Use of 544 the Labels ‘Master’ and ‘Slave’", 2020, 545 . 548 [Seele] Mike Seele, ., "Striking Out Racist Terminology in 549 Engineering", 2020, . 552 [Conger] Kate Conger, . and New York Times, "‘Master,’ ‘Slave’ and 553 the Fight Over Offensive Terms in Computing", 2021, 554 . 557 Authors' Addresses 559 Mallory Knodel 560 Center for Democracy & Technology 562 Email: mknodel@cdt.org 563 Niels ten Oever 564 University of Amsterdam 566 Email: mail@nielstenoever.net