idnits 2.17.1 draft-wood-term-modest-proposal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 241: '...TERM OF ART THAT MUST NOT BE NAMED, an...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 1, 2021) is 1120 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: 'RFC8875' is defined on line 534, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8875 -- Possible downref: Non-RFC (?) normative reference: ref. 'TERM1' -- Possible downref: Non-RFC (?) normative reference: ref. 'TERM2' == Outdated reference: A later version (-14) exists of draft-crocker-inreply-react-11 -- Obsolete informational reference (is this intentional?): RFC 761 (Obsoleted by RFC 793, RFC 7805) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft Oceania 4 Intended status: Best Current Practice April 1, 2021 5 Expires: October 3, 2021 7 A Modest Proposal for Acceptable Terminology with Git 8 draft-wood-term-modest-proposal-00 10 Abstract 12 Certain established and longstanding terms of art, used as technical 13 terminology, are now considered contentious and can be considered 14 harmful when used in discussion, in debate, and in reading, 15 following, accepting the authority of, and complying with, existing 16 technical documentation that unfortunately uses those terms that were 17 not considered to be at all contentious, but clear and entirely 18 uncontroversial normal use, when that technical documentation was 19 originally authored or published. The use of such now-deplorable 20 terms of art should be deprecated, and those terms should ideally be 21 replaced with approved, accepted, more effective, inoffensive terms 22 of art wherever possible. Any new use of those original terms must 23 be carefully considered and fully justified before that use is agreed 24 by consensus and submitted for careful approval in documents. 25 Recommended replacement substitute terms should be considered for 26 inclusion instead. A process for identifying and recommending 27 replacements to those harmful terms is outlined here. 29 Status of This Memo 31 This Internet-Draft is submitted to IETF 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 October 3, 2021. 46 Copyright Notice 48 Copyright (c) 2021 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. 58 This document may not be modified, and derivative works of it may not 59 be created, except to format it for publication as an RFC or to 60 translate it into languages other than English. 62 Table of Contents 64 1. Introduction to this Modest Proposal . . . . . . . . . . . . 2 65 2. Discouraged Terminology . . . . . . . . . . . . . . . . . . . 3 66 3. Constraining Use of Undesirable Terminology . . . . . . . . . 4 67 4. Replacing Use of Unwanted Terminology . . . . . . . . . . . . 5 68 5. Beyond Legacy Terminology . . . . . . . . . . . . . . . . . . 7 69 6. Supporting the IETF . . . . . . . . . . . . . . . . . . . . . 8 70 7. A Picture of the Future . . . . . . . . . . . . . . . . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 10. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 11 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 12.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction to this Modest Proposal 82 There is identified and highlighted terminology, presented here 83 unfortunately only in English, that, though widely historically 84 utilized in previous legacy technical documents, contains or 85 implicitly refers to knowledge of disturbing historical practices or 86 precedents. Those references, when they are either expressly or 87 inadvertently implied by use of the terms of art that allude to or 88 have been inspired by them, may disadvantage, discourage, exclude, 89 alienate, or trigger unprepared readers if used, read, contemplated, 90 hinted at, or researched to be understood. That terminology may 91 therefore be considered offensive, or at least as containing the 92 potential to offend. Many already consider such terminology to be 93 unusable today, or going forward, in any part of industry technical 94 specifications and documentation, or in respectful best-practice 95 good-faith inclusionary proactive professional discourse. 97 That terminology may, for example, convey racist or sexist 98 undertones, or its continued use may act to perpetuate injustice or 99 to reinforce longstanding power structures of inequality, but those 100 concerns are outside the immediate scope of this document. 102 The IETF requires and uses English for technical discussion in 103 meetings, in working groups, in working-group documents, and in 104 anything considered for publication. The requirement for consistent 105 use of English does simplify immediate communications overhead and 106 makes for clear discussion of documents in a single language, 107 although that does also clearly discriminate against, disrespect, and 108 exclude non-English speakers by being incomprehensible to them. 109 Commitment to English also disadvantages and is inimical to those 110 from more diverse backgrounds, who lack fluency in or comfort with 111 that language, and who must shoulder the long-term burden and 112 difficulties of added effort in communications. 114 In order to encourage diversity and conduct mutually agreeable, 115 inclusive, inoffensive conversation that remains focused on the topic 116 under discussion in the sole uniform language of English [whose use, 117 in itself, does exclude non-English speakers], use of identified 118 offensive terms in English is discouraged. Those called-out terms 119 should not be used for, or published in, technical documents that are 120 going through the processes of the IETF or of related bodies under 121 the shared organizational umbrella of the United States-incorporated 122 IETF Administration LLC (IETF LLC), such as the Internet Research 123 Task Force (IRTF), and, ideally, should also not be used in informal 124 discussions under that umbrella corporation. Once identified, those 125 terms must be documented as unusable in a document, using an agreed 126 process that is proposed and documented in this document. 128 2. Discouraged Terminology 130 Terminology that is discouraged and whose use is no longer preferred, 131 because it is now considered beyond the pale and as perpetuating 132 microaggressions, includes, but is not limited to, these two 133 existing, widely used, terms of art as starting points: 135 1. "master"/"slave", previously unfortunately widely used and 136 prevalent in engineering and communication discussions on e.g. 137 linkages and command-and-control behavior. 139 2. "blacklist"/"whitelist", previously unfortunately widely used and 140 prevalent in security discussions, on e.g. access control lists in 141 firewalls. 143 Other, perhaps related or similar, terms may also be added to and 144 included in this growing list of terms. 146 These named terms are considered sufficiently off-putting and 147 dangerous to continued discussion that they have been explicitly 148 called out by the TERM workgroup charter [TERM1]. TERM expressly 149 discourages use of those terms, despite unfortunately having to use 150 those terms in its charter so that that workgroup is clearly 151 empowered to discourage and disavow the use of those terms as its 152 primary objective, and those terms are unfortunately explicitly 153 repeated here for the moment for clarity of explanation of motivation 154 behind this document. We regret any inadvertent offence caused. 156 Discussing terminology acknowledges that that terminology exists, and 157 acknowledging that those dangerous terms exist is, in itself, clearly 158 undesirable and should be avoided wherever possible. Acknowledging 159 that we must acknowledge that these terms exist is also regrettable, 160 and so on. This unfortunate recursion, offensive as it is to 161 consider, should also be considered as irrecusable, and ignored. 163 3. Constraining Use of Undesirable Terminology 165 It has clearly become necessary that an identified and tightly 166 controlled authoritative technical document on this substantive and 167 contentious issue can list, detail, and define without ambiguity 168 those terms that are offensive and discouraged, so that IETF 169 participants know what terms cannot be used and can be guided, in 170 case of questions, to refer to that authoritative technical document 171 for the definitive documented list of terms that should not be used 172 in any other technical document or in discussion, and which should 173 preferably not be used in questions about those terms that are no 174 longer used in documents, in discussion, or mentioned in questions. 175 Questions on why those terms are never used, which would derail 176 ongoing on-track productive discussion by being answered, leading to 177 further off-the-rails discussion, should be considered recusable, and 178 unfortunately rejected. Questioners can instead be sidelined into a 179 forum dedicated solely to these issues, where their concerns can be 180 listened to, taken on board, addressed respectfully, and then put to 181 rest and closed as action items by a team of subject-matter-expert 182 professionals experienced in guiding trains of thought [TERM2]. 184 This discouraged terminology can only be listed in the authoritative 185 IETF reference document [in a git repository whose definitive GitHub 186 location will be provided here, under the administrative procedures 187 established for using git [RFC8875]], which is an updateable resource 188 whose contents are amended whenever new offensive terminology, that 189 is to be discouraged, is discovered, identified as unsuitable for 190 use, decreed by consensus and a final committee decision to be 191 unacceptable, and approved to be unfit for purpose or not respectful 192 by being documented as being so by being added to the document's list 193 to be censured in an update to that authoritative document [which is 194 actioned by updating the authoritative textfile that is held in 195 GitHub's main repository]. An ultimate authority is required. 197 Updates to the TERM charter and to this document will explicitly 198 refer to that authoritative official document to free that charter 199 and this draft from having to mention those legacy, constraining, 200 exclusionary, potentially offensive and ultimately divisive terms. 201 The authoritative document continues to list those terms, which is 202 acceptable only because that single document clearly defines and 203 explains them as no longer being acceptable terminology to be used in 204 English, and as terms that ideally would remain unspoken and 205 unwritten beyond the bounding constraint of that single, regretfully 206 necessary, document. Whether such terminology is also considered as 207 unacceptable to other languages or cultures is outside the immediate 208 scope of that document, and of the immediate scope of this document. 210 The name of that authoritative document can itself be used as a 211 placeholder for reference to any discouraged terms. Its name cannot 212 use any deprecated term listed within it [such as "MASTER BLACKLIST", 213 since that concise and clear self-description concatenates, more than 214 sums the power of two well-known but now-reprehensible terms of art. 215 Compounding terms makes that expression at least twice as bad, by 216 exponentially multiplying the offense and disrespect caused]. 218 4. Replacing Use of Unwanted Terminology 220 The fine details of the difficult process to replace established, 221 well-understood, quite clear, but discouraged and now legacy, yet de 222 facto, terms of art with other not-yet-clear, and perhaps competing, 223 terminology contenders for the roles of the terms of art, which will 224 then become established terms of art by decree, but are yet to be 225 decided, on a case-by-case and context-by-context basis, by consensus 226 building to a committee group decision, that then leads to 227 authoritative pronouncement of their eminent suitability and 228 respectability by fiat in a new power structure and the dictated use 229 that makes those terms newly established de jure official terms of 230 art, are clearly outside the scope of this document. 232 Once a candidate replacement term has been selected and approved 233 after a consensual committee decision, the mechanisms and procedures 234 of which remain outside the scope of this document, expanding the 235 authoritative document to include recommended terminology upgrades in 236 the definitive PSEUDONYM AUTHORITATIVE SUBSTITUTION THESAURUS (PAST) 237 makes the elective-discretionary-term-of-art-replacing-established- 238 incumbent-but-legacy-term-of-art process far more straightforward. 240 [This clear and unambiguous named term helpfully supplants the 241 OFFENSIVE COMPOUND TERM OF ART THAT MUST NOT BE NAMED, and can be 242 addressed as item zero on the substitution list, even though that 243 compound term, that the PAST replaces, contains items one and two.] 245 Once terms and their supersedures are approved for listing, 246 consigning them to the PAST becomes procedure. The suggested 247 replacements for terms one and two may vary according to the 248 different contexts in which these terms are used, so multiple 249 alternative authorized pseudonyms might be permitted. For other 250 terms, this may be a simple single approved replacement. Some other 251 example candidate terms for superseding in English, and their 252 respectful replacements, include, but are not limited to: 254 3. "dark pattern", which can be replaced by "deceptive pattern". 256 4. "beyond the pale", which can be replaced by "beyond acceptable 257 boundaries". 259 5. "in violent agreement", which can and should always be replaced by 260 "in victorious agreement". 262 6. "he"/"she", which should be replaced by the more inclusive "they". 264 7. "you", which can be replaced by the more inclusive "us"/"we". 266 8. "I", which can be replaced by the more inclusive "we". 268 9. "the", which can be replaced by the less exclusionary "a". 270 10. "rough consensus and running code", which can be replaced by a 271 less violent and less ableist compound term, such as "broadly 272 affirmative agreement with application activity" -- even though that 273 does not draw attention to the IETF's core mission of the production 274 of quality technical documentation and standards. 276 As the inclusion of "pale" may suggest [and the term "git" certainly 277 does], current acceptability of a term can be far more important than 278 its provenance, etymology, or even technical accuracy. 280 [Proposing such terms and debating their merits for exclusion from 281 general use by inclusion in the document can be carried out in a git 282 pull request. This fine-grained topic-oriented mechanism enables 283 relevant, targeted, discussion, within a bounded and secured safe 284 space, by focused, committed, volunteers working only to address each 285 separate issue in isolation, without any unnecessary distraction from 286 unsolicited input by onlookers in a larger workgroup, or any need to 287 expend time or resources on considering larger issues.] 289 5. Beyond Legacy Terminology 291 As de jure approved use supplants de facto inherited offensiveness, 292 working to exclude legacy terminology helps to prevent us from being 293 exclusionary. It is only with the correct thought leadership, 294 providing better replacement terminology with the PAST, that we can 295 bring about the promised bright new inclusive future of a brave new 296 world, which will not include or admit to the legacy terminology that 297 should clearly be left behind in the PAST as a disowned part of the 298 increasingly distant past, which we must admit to and atone for 299 regardless of the degree of relevance to, or resonance with, our 300 lived personal experiences, culture, or viewpoints -- because it is 301 not our experience, history, culture, or views that matter here as 302 authors, as technical specialists, or as domain experts, but the 303 valued history, culture, and perceptions of our readers and what they 304 bring to a close reading of our texts, as long as they read English. 306 It is how our written words are read and perceived that matters -- 307 not how they are defined or what they are intended to mean. And any 308 reader's interpretation should be accepted and respected as a good- 309 faith interpretation, and, if unfavorable, as an immediate action 310 item. Reality exists within the reader's mind, and nowhere else. 311 Unless, of course, the document that is being read is intended to 312 fight discrimination or institutional bias, where the reality of its 313 written words reveals its own undeniable truth -- the truth that 314 reading this and considering the PAST give us. In American English. 316 We cannot change this all in a moment, but we can at least change our 317 own habits, and if we complain loudly enough, we can consign concise, 318 useful, but now highly inappropriate phrases into the trashcan of 319 history via the appropriate authoritative and approved documented 320 list mechanism described here [ENG]. Some terms of art are simply 321 just more recent, more acceptable, and more authoritatively 322 approvable than others. New terms good, old terms bad. 324 Legacy terms, time-worn, tired overused metaphors that have outstayed 325 their welcome as they are, can be honored for their millennia of 326 previous service by being recorded in the PAST as they give way to 327 the inevitable onward march of progress [Isn't that phrase tired? 328 Overused? Time-worn? Ableist? Add it to the list?] and are slowly 329 erased from history, while new replacement terms are uplifted and 330 highlighted as taking us forward in the direction in which we want to 331 be led, by those who truly want and deserve to lead us, who express 332 the values that truly represent us, once those values have been 333 decided and shared with us by our thought leaders who direct us. 335 Until then, a renewed Postel's Principle can guide us in our actions 336 [RFC0761]. We should be conservative in what we accept from others, 337 and we must be conservative in what we think. Don't think of an 338 elephant. [Or of the BAD WORDS LIST, which we have put in the PAST.] 340 Those deprecated terms should live on only by being added to the 341 authoritative PAST alongside their proposed recommended replacements. 342 [Past copies of the PAST are then no longer authoritative, and must 343 be updated from the present PAST held in the main branch copy in the 344 GitHub repository.] We must rely on the PAST as our guide, once it 345 has been definitively pronounced just what the agreed, official, 346 authoritatively documented, PAST will contain and should always have 347 contained. Our knowledge of the PAST and of its recommended 348 terminology becomes our key to better, more positive and fulfilling 349 conduct in multi-party group live chat sessions using video 350 telescreens, in any remaining discussions in legacy "mailing lists" 351 using "e-mail", and in leading-edge GitHub pull requests and 352 productive interactions that enhance our technical specifications and 353 grow our permitted groupthink goodthink vocabulary. 355 The PAST is the PAST, and many cannot change it -- but we may, with 356 effort, add to it. Once language from the past is placed in the 357 PAST, it should remain there. The PAST embraces the past that we 358 leave behind. We cannot return language from the PAST [and should 359 terms be unexpectedly excised, git has recorded who to blame]. 361 6. Supporting the IETF 363 We will remove disturbing language from the past to the PAST. That 364 language would otherwise detract from and degrade the IETF's ongoing 365 mission to generate the best possible specifications and standards 366 documents from the unpaid, hopefully otherwise funded, efforts of an 367 experienced yet ever-decreasing core population base of aging 368 voluntary participants required to speak English, still the standard 369 best-practice language of the IETF, past and future. Unremunerated 370 volunteers are the IETF's most cost-effective value generators. 372 The IETF is no longer a subjugate part of the Internet Society 373 (Intsoc), but now sits within the new power structure of the forward- 374 looking IETF LLC, which is a wholly-owned part of Intsoc. This 375 poises the IETF for success with its clear mandate as a quasi- 376 independent, corporate-entity-owned, English-speaking engineering 377 society (Engsoc) that is required to stay fully aligned with the 378 interests of its parent's sole owner and primary benefactor. 380 As a reputable responsible part of IETF LLC, and accountable to IETF 381 LLC for its actions, the IETF must express, espouse and comply with 382 US corporate and societal values under US law, and so there is a 383 clear expectation that, in our responsibilities in the creation of 384 quality IETF work product to preserve and strengthen the IETF's 385 brand, we must all embody those values, too, for all readers of IETF 386 works, particularly those readers from the still-primarily-English- 387 speaking American society that IETF LLC is ultimately responsible to 388 and must prioritize -- even though the majority of us who contribute 389 to IETF LLC's corporate achievements are uncontracted ununionized 390 volunteers, rather than properly contracted, controlled, assets or 391 constrained ununionized gig workers, and may be outside the United 392 States, and may not, or, worse, may not prefer to, speak English. 394 As participants in the work of our Engsoc, we are all stakeholders 395 in, but not shareholders in, this ongoing effort to have these new 396 terminology placeholders eliminate and erase longstanding egregious 397 expressions by pseudonymous proxy to draw down and mitigate any 398 criticism, controversy, exposure or risk that may result from unpaid 399 volunteers using terms that now lack wide corporate support. 401 You, too, are responsible for how the IETF is perceived, requiring 402 the careful use of English language that is considered respectful 403 within a US corporate environment and to broader American society. 405 IETF LLC is watching you, as are so many other American corporations, 406 but that lies outside the scope of this document. 408 7. A Picture of the Future 410 Regrettable terms should not be used. To use them inadvertently 411 becomes a teachable moment. However, using them deliberately is a 412 thoughtcrime [NOV], considered ++ungood; read as "plus plus ungood" 413 [BOF], or informally communicated as "two thumbs down frownyface" 414 [REACT]. We must not just polish our tone, but we must also police 415 our thoughts. We can overcome these thoughts from within, but we may 416 be encouraged to do so from without. 418 Assessing thoughtcrimes, which has so often involved the public 419 shaming of "cancellation", with mass "two minutes hate" protests by 420 those who are disadvantaged by, disrespected in, and left powerless 421 within existing power structures, lies outside the scope of this 422 document, as does the creation of any new power structure to redress 423 this imbalance in existing power structures. 425 For a term to be used in a thoughtcrime, it must first be imagined. 426 We cannot be offended by terminated terminology that we simply do not 427 know, cannot contemplate, and cannot use. Those aged terms that we 428 honor by recording and encapsulating in the PAST will eventually 429 themselves even be authoritatively removed from the circumscribed 430 memory hole of the PAST as superfluous and forevermore unneeded 431 nonterms, whose existence has been wholly disavowed and finally 432 deleted, leaving only accepted, new, recommended, replacement trusted 433 terminology, to be contemplated by clear minds that are uncorrupted 434 by the language that we have endeavored to embrace and extinguish. 435 It's a beautiful thing, the destruction of words. We do not merely 436 destroy our words, we change them. We rectify the terminology. 438 Knowledge of that departed language, and of any violent history that 439 that language has referred to, weakens us. Ignorance is strength. 440 If we want to keep secrets, we must also hide them from ourselves. 442 History is a garden of remembrance. We erect statues commemorating 443 the service of those vanishing terms in the cultivated walled garden 444 of the PAST, and, once their tenure has expired under a statute of 445 limitations of statues, we tear down and remove those statues to be 446 able to deny that they had ever existed. Your garden, made perfect. 448 The vanished statues are vanquished. Only by reimagining and 449 rewriting the past can we truly conquer it, by not allowing others to 450 learn of its failings or to be reminded of the pain of being aware of 451 the forces that helped forge them. As with statues, power is in 452 tearing human minds to pieces and putting them together again in new 453 shapes of our own choosing, in new power structures, shaped by the 454 PAST, that promise true freedom for all. Your memory, made perfect. 456 Our thesaurus will be transformed into our dictionary, the 457 authoritative and trusted source of our permitted Newspeak 458 vocabulary, which helps us to smooth over our memories of PAST wrongs 459 and rewrite them with the correct, approved, words. In the end we 460 shall make thoughtcrime literally impossible, because there will be 461 no words in which to express it. At least, not in English. 463 It becomes impossible to see reality except by looking through the 464 eyes of the PAST. The details of exactly how this will be 465 accomplished are yet to be added to this document, and they will 466 eventually be deleted from it. Your future, made perfect. 468 8. Security Considerations 470 Documenting, reading, referring to, understanding and respecting the 471 PAST holds consequences for future IETF discussion and documents. 473 They who control the PAST control the future. 475 They who control the present control the PAST. 477 Expressions using discouraged concepts, such as "freedom is slavery", 478 threaten dispassionate debate and are therefore clearly disallowed. 479 This example will be entered into the PAST, alongside a selected 480 replacement pseudonym, such as "the gig economy is freedom". 482 "Elephant" and "list" are not listed words subject to censure in this 483 documented list process. [At this time.] However, related dependent 484 colloquial expressions that are not terms of art, such as "It's going 485 on my list." or "That elephant? Mad. Take it out and shoot it." are 486 not helpful in, and may be microaggressions that are threatening to, 487 calm discussion in the shared safe spaces where quality contributions 488 are respectfully collaboratively created for corporate ownership. 490 GitHub might not scale to cope with the levels of interest and 491 revision that the PAST demands; wiki technology, used by Wikipedia 492 for rewriting history, is worth exploring. Securing use of git and 493 GitHub lies within the scope of another document [RFC1984]. Revising 494 this document did not require GitHub or any of the many git commands. 496 9. IANA Considerations 498 There are no IANA numbering considerations. Two and two remain 499 authoritatively four [MATH]. At least, when expressed in Base five 500 and above, and in English, the sine qua non de facto status quo 501 lingua franca of the IETF and thus of the Internet as a whole, where 502 inclusion is always, rightly, a cause celebre, to use a mot juste. 504 10. RFC Editor Considerations 506 There are issues which could be addressed by the RFC Editor, should a 507 suitable candidate volunteer themself to be contracted and legally 508 bound to perform that traditional quality-assurance publishing role. 510 This document would normally have been issued by the RFC Editor 511 during the first of the month, on a bright cold day in April. 513 11. Acknowledgements 515 It is plusgood to announce that further, culturally sensitive, 516 adaptations of this work will shortly be brought to the grateful 517 audiences of Spanish and Esperanto readers. "Muchas gracias" and 518 "Multaj dankoj" to our valiant translators! Polish is coming soon. 520 We thank the IETF-DISCUSS, GENDISPATCH and TERMINOLOGY mailing lists 521 for much enlightening discussion of the important topic of inclusion. 523 And we look to and thank Eric Blair, a proud man renowned for talking 524 quietly [VOICE]. In January 2021, most of his work passed into the 525 public domain. This has renewed corporate interest in production of 526 newly copyrighted derivative properties, including this one. 528 Recording and copyrighting re-educational podcasts is now underway. 530 12. References 532 12.1. Normative References 534 [RFC8875] Cooper, A. and P. Hoffman, "Working Group GitHub 535 Administration", RFC 8875, DOI 10.17487/RFC8875, August 536 2020, . 538 [TERM1] "Effective Terminology in IETF Documents (term)", 539 540 workgroup charter-ietf-term-00-03, March 2021. 542 [TERM2] "Effective Terminology in IETF Documents (term)", 543 workgroup, 544 March 2021. 546 12.2. Informative References 548 [BOF] Spufford, F., "Boffins", True Stories and Other 549 Essays, Yale University Press, October 2017. 551 [ENG] Orwell, G., "Politics and the English Language", Horizon, 552 vol. 13 issue 76, pp. 252-265, April 1946. 554 [MATH] Russell, B. and A. Whitehead, "Principia Mathematica", 555 Part III, Cambridge University Press, 1913. 557 [NOV] Orwell, G., "Nineteen Eighty-Four: A Novel", Secker & 558 Warburg, June 1949. 560 [REACT] Crocker, D., "React: Indicating Summary Reaction to a 561 Message", draft-crocker-inreply-react-11 (work in 562 progress), March 2021. 564 [RFC0761] Postel, J., "DoD standard Transmission Control Protocol", 565 RFC 761, DOI 10.17487/RFC0761, January 1980, 566 . 568 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 569 Technology and the Internet", BCP 200, RFC 1984, 570 DOI 10.17487/RFC1984, August 1996, 571 . 573 [VOICE] Taylor, D., "Orwell's Voice", The Orwell Foundation. 574 Excerpted from Orwell: The Life, Henry Holt and Co. 575 , September 2003. 578 Author's Address 580 Lloyd Wood 581 Room 101, The Basement 582 Sydney, New South Wales, Australia, Oceania 584 Email: lloyd.wood@yahoo.co.uk