idnits 2.17.1 draft-gont-diversity-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (27 January 2022) is 813 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 220, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-shmoo-remote-fee-02 == Outdated reference: A later version (-14) exists of draft-knodel-terminology-08 -- Obsolete informational reference (is this intentional?): RFC 8989 (Obsoleted by RFC 9389) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 gendispatch F. Gont 3 Internet-Draft EdgeUno 4 Intended status: Informational K. Moore 5 Expires: 31 July 2022 Network Heretics 6 27 January 2022 8 Diversity and Inclusiveness in the IETF 9 draft-gont-diversity-analysis-01 11 Abstract 13 This document discusses a number of structural issues that currently 14 hinders diversity and inclusiveness in the IETF. The issues 15 discussed in this document are non-exhaustive, but still provide a 16 good starting point for the IETF to establish a more comprehensive 17 agenda to foster diversity and inclusiveness. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 31 July 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Perceived Return of Investment (ROI) . . . . . . . . . . . . 4 56 4.1. Operators . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Academia . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Effects of Current Participation . . . . . . . . . . . . . . 5 59 6. Diversity in IETF groups and leadership roles . . . . . . . . 6 60 6.1. IESG . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.2. WG Chairs . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6.3. NOMCOM . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. Difficulty in Joining the IETF . . . . . . . . . . . . . . . 8 65 8.1. Finding interesting Working Groups and Areas . . . . . . 8 66 8.2. Difficulty in Authoring and Submitting Internet-Drafts . 9 67 8.3. Contributing to Working Groups . . . . . . . . . . . . . 10 68 8.4. Support from Experienced Members . . . . . . . . . . . . 10 69 9. Economic Constraints . . . . . . . . . . . . . . . . . . . . 10 70 10. Educational Constraints . . . . . . . . . . . . . . . . . . . 11 71 11. Cultural Issues . . . . . . . . . . . . . . . . . . . . . . . 11 72 11.1. Language . . . . . . . . . . . . . . . . . . . . . . . . 11 73 11.2. Using email effectively . . . . . . . . . . . . . . . . 12 74 11.3. Comfort zone . . . . . . . . . . . . . . . . . . . . . . 12 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 78 15. Informative References . . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. DISCLAIMER 83 For the most part, many of the topics discussed in this document are 84 the result of on-list and off-list conversations with a number of 85 IETF participants, and are based personal experiences of said group 86 of colleagues, and what such group believes are some of the 87 structural problems hindering diversity in the IETF. 89 As such, it is very likely (and possibly guaranteed!) that there are 90 aspects that are partially (or even totally!) overlooked. If you 91 feel that is the case, please do contact the authors, and feel free 92 to educate us on what we may have missed. The authors will be happy 93 to incorporate co-authors where needed, include ideas from others 94 while giving due credit, or even include ideas while anonymizing the 95 source or author of the proposal. 97 Please refer to Section 3 regarding the terminology employed 98 throughout this document. 100 2. Introduction 102 This document tries to raise a number of structural issues that 103 currently hinders diversity and inclusiveness in the IETF. The 104 issues discussed in this document are non-exhaustive, but still 105 provide a good starting point for the IETF to establish a more 106 comprehensive agenda for the IETF to address the issue of diversity 107 and inclusiveness. 109 We have grouped structural issues in these categories: 111 * Perceived Return of Investment (ROI) (see Section 4) 113 * Effects of Current Participation (see Section 5) 115 * Diversity in IETF groups and leadership roles (see Section 6) 117 * Processes (see Section 7) 119 * Difficulty in Joining the IETF (see Section 8) 121 * Economic Constraints (see Section 9) 123 * Educational Constraints (see Section 10) 125 * Cultural Issues (see Section 11) 127 3. Terminology 129 Throughout this document, whenever we refer to "diversity" or 130 "inclusiveness" we imply including or involving people of: 132 * a range of different social and ethnic backgrounds 134 * different genders 136 * different sexual orientations 138 * different countries and regions 140 * different types of organizations (companies, non-profits, etc.) 142 * people who are not sponsored by or representing any organization 143 The above list is non-exhaustive, but should make it evident that 144 "diversity" has multiple axes, and this document does not limit its 145 discussion of diversity to any particular sub-set of them. 147 4. Perceived Return of Investment (ROI) 149 While many IETF participants engage in the IETF for the sake of 150 improving the Internet or as a personal hobby, IETF participation 151 involves an investment, whether participation is done independently, 152 or supported by an organization (e.g., company). 154 As with any investment, the question of what is the return of 155 investment (ROI) is often asked both by participants and their 156 supporting companies (if any). 158 In the case of companies, the possible ROI will typically depend on 159 the specific sector, but might include: 161 * Benefiting from Intellectual Property Rights (IPRs). 163 * Benefiting from leading technologies, with e.g. improved "time to 164 market". 166 In the case of independent participants, ROI could be in the form of: 168 * Being able to make a difference in improving Internet 169 technologies. 171 * Better career opportunities. 173 However, these benefits can only be realized by a small subset of 174 companies and participants. For example, in order for companies to 175 benefit from IPRs and improved time-to-market of products, they need 176 to be in the business of manufacturing such specific products. In 177 order cases, companies might deem the ROI of IETF participation as 178 negligible. 180 In the case of independent participants, the ability to realize 181 better career opportunities generally depends on the availability of 182 companies that might benefit from the IETF in the same country or 183 region. In other words, lacking local companies or organizations 184 that benefit from IETF participation essentially means that IETF 185 participation and the associated skills will result in a negligible 186 ROI for independent participants. And, when processes are biased 187 towards a specific community, even the possibility of improving the 188 Internet "for the common good" might seem unfeasible. 190 As a result of this, there is a whole range of individuals and 191 organizations for which IETF participation might not result 192 attractive or feasible: 194 * Individuals from developing countries 196 * Service- and consulting-oriented companies 198 * Unaffiliated open source developers 200 * Operators 202 * Academia 204 That said, there is always the case of individuals and/or companies 205 that might still try engage in the IETF. However, other issues, such 206 as those discussed in Section 5, Section 6 and Section 9 typically 207 discourage such participation. 209 The following subsections discuss the specific realities of some of 210 these communities. 212 4.1. Operators 214 Operators participation in the IETF has been studied in some detail 215 in [I-D.opsawg-operators-ietf], and some criticism regarding the 216 reduced operator participation has been discussed in [Bush]. 218 4.2. Academia 220 [TBD] 222 5. Effects of Current Participation 224 The IETF is far from achieving diversity in many (if not most) axes. 225 For example, the IETF is far from having gender parity in the number 226 of participants, or in having a truly diverse geographical 227 participation. 229 The lack of diversity in current IETF participation essentially means 230 that decisions and the perception of structural problems is biased 231 towards the realities of current participants, and hinders the 232 participation of those not "in the club" of large Internet tech 233 companies. 235 For example, face-to-face (f2f) meetings are held in regions 236 reflecting current participation levels. But this in turn 237 facilitates participation from those regions, and makes participation 238 from other regions less accessible. 240 Similarly, the lack of diversity in current participants is in turn 241 reflected in the lack of diversity in IETF groups and leadership 242 roles (discussed in Section 6) which, again, tends to bias processes 243 in favor of the current participants. 245 Finally, how new work is considered by the IETF is also generally 246 biased in favor of those "in the loop" -- that is, participants that 247 are already engaged in the IETF and that generally belong to the 248 reduced groups for which a ROI from IETF participation is feasible 249 (see Section 4). At times, participants may perceive discrimination 250 on the basis of e.g. their employers (or who their employers are 251 not), the way they use the English language (see Section 11.1, their 252 cultural conventions and how well those conventions mesh with 253 expectations of the majority of IETF participants, and their 254 technical backgrounds. 256 6. Diversity in IETF groups and leadership roles 258 Lack of diversity in IETF groups and leadership roles has a direct 259 effect on IETF participation, as a result of: 261 * Process fairness by having a very small number of interests 262 judging WG consensus, community consensus, and appeals. 264 * Leadership selection fairness by having a limited number of 265 interests participating in the NOMCOM and IAB. 267 * Arbitrary decisions produced and enforces by such groups, without 268 getting community consensus on them (see e.g., 269 [I-D.carpenter-nomcom2020-letter]). 271 6.1. IESG 273 While one might expect greater diversity in IESG members, there are 274 at least two possible causes for that: 276 * There is reduced diversity in many axes of IETF participation. 278 * There is (allegedly) a reduced number of possible candidates with 279 the necessary skills. 281 As noted in Section 5, it is probably obvious that IETF participation 282 is not as diverse as one would expect -- and this certainly 283 constrains diversity in IETF leadership roles in general. 285 It is also commonly suggested that there is a limited number of 286 candidates with the appropriate skills set for IESG positions, and 287 that one of the common missing skills is IETF management experience. 288 However, there does not seem to be a concrete effort to produce an 289 increase in the number of participants with appropriate skills to 290 volunteer for such roles. For example, fostering diversity in WG 291 chair positions would be an obvious choice for increasing the pool of 292 potential candidates for IESG positions, as discussed in Section 6.2. 294 6.2. WG Chairs 296 Most WGs have permanent WG chairs which only become rotated when: 298 * A WG chair takes a higher responsibility within the IETF (e.g. WG 299 Chair becomes an Area Director). 301 * There are personal issues affecting the WG chair (e.g., WG chair 302 retires, changes jobs, etc.). 304 * There is evident malfunction of a WG which leads to an WG chair 305 being replaced. 307 However, if the IETF adopted the convention that chairs are rotated 308 in all cases, this would certainly: 310 * Increase diversity in WG chairs positions. 312 * Increase the pool of IETF participants with IETF leadership 313 experience, which could in turn help increase diversity in other 314 leadership roles, such as the IESG. 316 * Makes WG chair changes less stressful and controversial, since WG 317 chairs are rotated *by default*. 319 NOTE: One could envision a policy where each WG has three co- 320 chairs, with different experience levels, and where one of the co- 321 chairs has no previous WG chair experience. Every two (or so) 322 years the most experienced WG chair leaves his role, which is 323 occupied by the second-most experienced WG chair from the group. 324 And a new un-experienced WG chair is incorporated by the WG. 326 6.3. NOMCOM 328 The current NOMCOM member selection rules try to be fair, but are 329 still biased in favor of the specific groups discussed in Section 4 330 and Section 5. 332 For example, 334 * The requirement to have attended X out of Y of the last f2f 335 meetings is clearly biased in favor of IETF participants who have 336 enough funding to travel to most meetings. 338 * Big tech companies are more likely to be willing to let their 339 employees do that because they're more likely to get IESG and IAB 340 members who favor their interests. 342 * There is the expectation that NOMCOM members attend f2f meetings 343 to carry their NOMCOM duties -- which, again, favors the same 344 group of participants (those with funding, which generally work 345 for big tech companies). 347 * If the NOMCOM has f2f interviews, the process also favors those 348 candidates that are able to attend f2f meetings, who can be 349 interviewed in-person. 351 NOTE: There are a few obvious things that could be done to improve 352 these issues. [RFC8989] is certainly a step in the right 353 direction. Having the NOMCOM perform its duties only online would 354 be another. 356 7. Processes 358 Some aspects of WG operation are loosely described. While this may 359 be beneficial in some cases, other times the rules or expectations 360 regarding how WGs are meant to operate can be problematic for 361 participants, and even more so to newcomers. 363 NOTE: [I-D.carpenter-gendispatch-rfc7221bis] is a good attempt at 364 clarifying some specific aspects of WG operation. 366 8. Difficulty in Joining the IETF 368 8.1. Finding interesting Working Groups and Areas 370 It is usually hard for newcomers (and sometimes experienced people) 371 to see how to contribute effectively or even to find which working 372 groups (if any) whose work they would be interested in. 374 Similarly there are now so many different groups, committees, 375 supporting organizations, etc. involved in running IETF that it is 376 hard to understand the big picture, and know which group does what, 377 or which people to talk to about any given concern. [IETF-Tao] can 378 ameliorate this issue, but not eliminate it. 380 In some cases, working groups may (intentionally) have a narrow 381 charter, in which case re-chartering the working group, or getting 382 support for a Birds of a Feather (BoF) session may be non-trivial. 384 It is also hard for newer people to get "up to speed" on an existing 385 working group or topic area. Reading the WG's mailing list archive 386 can be very time consuming and not always very illuminating. The 387 Datatracker and Tools effort have been (and still are) of a lot of 388 help here. But having materials that e.g. provide a summary of what 389 the ongoing work of a WG is, and that summaries what recent 390 discussions have been about, and what the different views are/have 391 been, would certainly help in this area. 393 8.2. Difficulty in Authoring and Submitting Internet-Drafts 395 There are so many formatting rules that an Internet-Draft (and 396 eventually an RFC) needs to comply to, that in practice the only 397 reasonable way create and submit an Internet-Draft is via the set of 398 tools available at: https://tools.ietf.org/ . Tools such as xml2rfc 399 are of a lot of help to produce documents that comply with the 400 Internet-Draft formatting rules -- but its error messages might 401 result cryptic to the unexperienced user. 403 The number of tools has expanded so much that they probably deserve 404 their own guidelines. And existing guidelines such as 405 [ID-Guidelines] should probably be updated with the assumption that 406 Internet-Drafts will be produced with the set of available tools. 408 This means that e.g. it becomes less important to the Internet- 409 Draft author what formatting rules a document needs to comply to, 410 since the existing tools will guarantee such compliance. On the 411 other hand, an author may benefit from guidelines on how to use 412 the set of available tools. 414 Document authors generally have freedom to select the tools they 415 employ to author Internet-Drafts. However, this may represent a 416 challenge to working groups if/when the authors of a working group 417 become unresponsive and one or more editors need to take control of 418 the document -- but the new editors are not familiar with the tools 419 or document source format employed by the original authors of the 420 document. 422 8.3. Contributing to Working Groups 424 Traditionally, aside from f2f meetings, most working group 425 discussions have taken place on mailing-lists. 427 Use of mailing-lists have has been considered rather ineffective or 428 inconvenient by some, and some working groups have started to rely 429 more on GitHub both for suggesting changes to e.g. Internet-Drafts 430 and to discuss the associated changes. While some have found this 431 move convenient, some perceive the reliance on 'git' as an obstacle 432 to participation. The choice of tools is, indeed, a trade-off. 434 8.4. Support from Experienced Members 436 In some cases newcomers would benefit from a mentor that could guide 437 the newcomer through the process of writing, publishing, and 438 socializing an Internet-Draft. In cases where a proposal would 439 nicely fit into one of the existing working groups, the corresponding 440 working group chairs might be able to provide guidance (assuming the 441 newcomer is able to spot the appropriate working group and chairs). 442 If there is no obvious target working group, obtaining such guidance 443 might result more difficult. 445 This challenge could be mitigated by having a group of volunteers 446 that would be willing to guide newcomers in finding an appropriate 447 working group and submitting a proposal to that working group, or 448 finding alternatives for pursuing said proposal. 450 On the other hand, it has also been suggested that when trying to 451 pursue work in specific areas or working groups, backing by 452 experienced members is implicitly required in order for a proposal to 453 have any chances of making progress -- particularly when come from 454 newcomers. 456 9. Economic Constraints 458 The current IETF processes favor participants who have enough money 459 to travel to several meetings a year, and/or participants who work 460 for companies who can afford such expense and are willing to spend 461 that money (which tends to be a specific subset of companies, as 462 discussed in Section 4). 464 [RFC4144] (an individual submission) argues that "eighty percent 465 of success is showing up". 467 Clearly, work such as [I-D.ietf-shmoo-remote-fee] is a step in the 468 right direction. Other things to evaluate and consider are: 469 incorporating fee waivers for f2f meetings and/or adjusting the IETF 470 meeting fee to the local realities (i.e., move away from a flat fee), 471 and reducing the number of f2f meetings. 473 10. Educational Constraints 475 You have to know a lot of technical material to participate usefully 476 and effectively in IETF. How IPv4 and IPv6 work, something about 477 routing (at least the need for advertisements and aggregation), 478 something about addressing, something about transport protocols 479 (probably TCP and UDP, at least), something about congestion control 480 (at least that it's needed), something about DNS, something about 481 protocol layering, something about applications, something about 482 security (at least basics of authentication and encryption), etc.For 483 someone with little exposure there can be a very steep learning 484 curve. 486 Additionally, improving internet protocols requires skills to assess 487 protocols in a critical way. While there are multiple courses and 488 certifications that provide general knowledge about Internet 489 protocols and the skills for e.g. configuring internet routers, there 490 are fewer materials that try to analyze protocols in a critical way 491 (e.g. [Perlman] and [Day]). And this represents a barrier to 492 newcomers. 494 While this is not a problem that the IETF could (or should) solve, 495 there has been work that has helped in this area, and possibly more 496 could be done. e.g., some IETF tutorials have been very educational 497 and useful not only to introduce newcomers to IETF work, but also to 498 provide context for such work, and occasionally also discuss 499 shortcomings. There is certainly room for the IETF to expand on 500 these activities. 502 11. Cultural Issues 504 There are a number of cultural issues that also hinder diversity and 505 inclusiveness in the IETF. The following sub-sections discuss some 506 of these. 508 11.1. Language 510 Language can be exclusionary in many different ways. 512 For example, IETF participation requires and implies use of English 513 language. While English language has become the de facto 514 international language (with attempts such as Esperanto failing 515 miserably), communication in (any) non-native language can be 516 challenging for a number of reasons. This tends to be more 517 challenging when oral communication (as opposed to written) is 518 involved when expressions or phrasals that are unfamiliar to non- 519 native speakers of the language are involved. 521 Consider expressions such as "red herring", "knee jerk", and 522 others. 524 Use of terms that may have a political or social connotation may 525 result offensive to at least part of the community (see e.g. 526 [I-D.knodel-terminology] or [I-D.gondwana-effective-terminology]). 527 On the other hand, some participants (particularly those that do not 528 speak English as a native language) may be unaware of the connotation 529 or historical background of such words, and may in turn be judged for 530 their inadvertent usage. 532 11.2. Using email effectively 534 Email is still the best way for IETFer's to communicate at a 535 distance, it's vendor-independent and avoids vendor lock-in, it's 536 universally available, there are many providers and email user agents 537 to choose from, it lends itself to searching and archiving, etc. 538 It's the medium of choice partially because it doesn't impose many 539 barriers to IETF participants using it. But there's a bit of an art 540 to using it effectively. 542 11.3. Comfort zone 544 Willingness to leave one's comfort zone is usually a necessary 545 condition to participating effectively in IETF. 547 Anyone who participates significantly is going to run into other 548 people who disagree, who think about the problem differently, who 549 have completely different contexts. This might be because they're 550 from a different technical background, different kind of company, 551 different culture, or all of the above. This is normal and even 552 necessary. Trying to sort out differences between people with 553 different points-of-view is often uncomfortable precisely because it 554 often forces us to question our own assumptions. It follows that a 555 desire or demand to be "comfortable" at all times is 556 counterproductive. 558 And sometimes one runs into overt personal prejudice on the part of 559 others, and we have to deal with that too. It's part of the 560 landscape. Often people aren't aware of their prejudices or accept 561 them as natural or correct, and don't know how to turn them off even 562 if they wanted to. With increasing familiarity and a willingness to 563 respect fellow participants, it can diminish over time. But it takes 564 work, and that work is also often uncomfortable work. 566 12. IANA Considerations 568 This document has no IANA actions. 570 13. Security Considerations 572 There are no security implications arising from this document. 574 14. Acknowledgements 576 The authors would like to thank (in alphabetical order) Carsten 577 Bormann, Brian Carpenter, Lars Eggert, Theresa Enghardt, Simone 578 Ferlin-Reiter, Juliana Guerra, Bron Gondwana, Joel M. Halpern, 579 Dominique Lazanski, Eliot Lear, for providing valuable comments on 580 earlier versions of this document. 582 This document has been motivated by discussions with a number of 583 individuals, both on- and off-list. 585 15. Informative References 587 [Bush] Bush, R., "Into the Future with the Internet Vendor Task 588 Force: A Very Curmudgeonly View - or - Testing Spaghetti 589 -- A Wall's Point of View", ACM SIGCOMM Computer 590 Communication Review, Volume 35, Number 5, October 2005, 591 . 593 [Day] Day, J., "Patterns in Network Architecture: A Return to 594 Fundamentals", 1st edition, Prentice-Hall, 1999. 596 [I-D.carpenter-gendispatch-rfc7221bis] 597 Farrel, A., Crocker, D., Carpenter, B. E., Gont, F., and 598 M. Richardson, "Handling and Adoption of Internet-Drafts 599 by IETF Working Groups", Work in Progress, Internet-Draft, 600 draft-carpenter-gendispatch-rfc7221bis-01, 29 October 601 2020, . 604 [I-D.carpenter-nomcom2020-letter] 605 Carpenter, B. E., "Open Letter to the 2020-21 IETF 606 Nominating Committee", Work in Progress, Internet-Draft, 607 draft-carpenter-nomcom2020-letter-00, 11 September 2020, 608 . 611 [I-D.gondwana-effective-terminology] 612 Gondwana, B., "Effective Terminology in IETF drafts", Work 613 in Progress, Internet-Draft, draft-gondwana-effective- 614 terminology-01, 25 August 2020, 615 . 618 [I-D.ietf-shmoo-remote-fee] 619 Kuehlewind, M., Reed, J., and R. Salz, "Open Participation 620 Principle regarding Remote Registration Fee", Work in 621 Progress, Internet-Draft, draft-ietf-shmoo-remote-fee-02, 622 25 October 2021, . 625 [I-D.knodel-terminology] 626 Knodel, M. and N. T. Oever, "Terminology, Power, and 627 Exclusionary Language in Internet-Drafts and RFCs", Work 628 in Progress, Internet-Draft, draft-knodel-terminology-08, 629 12 January 2022, . 632 [I-D.opsawg-operators-ietf] 633 Grundemann, C. and J. Zorz, "Operators and the IETF", Work 634 in Progress, Internet-Draft, draft-opsawg-operators-ietf- 635 00, 27 October 2014, . 638 [ID-Guidelines] 639 Housley, R., "Guidelines to Authors of Internet-Drafts", 640 2010, . 642 [IETF-Tao] ten Oever, N. and K. Moriarty, "The Tao of IETF: A 643 Novice's Guide to the Internet Engineering Task Force", 644 2019, . 646 [Perlman] Perlman, R., "Interconnections: Bridges, Routers, 647 Switches, and Internetworking Protocols", 2nd edition, 648 Addison-Wesley Professional, 1999. 650 [RFC4144] Eastlake 3rd, D., "How to Gain Prominence and Influence in 651 Standards Organizations", RFC 4144, DOI 10.17487/RFC4144, 652 September 2005, . 654 [RFC8989] Carpenter, B. and S. Farrell, "Additional Criteria for 655 Nominating Committee Eligibility", RFC 8989, 656 DOI 10.17487/RFC8989, February 2021, 657 . 659 Authors' Addresses 661 Fernando Gont 662 EdgeUno 663 Segurola y Habana 4310, 7mo Piso 664 Villa Devoto 665 Ciudad Autonoma de Buenos Aires 666 Argentina 668 Email: fernando.gont@edgeuno.com 669 URI: https://www.edgeuno.com 671 Keith Moore 672 Network Heretics 674 Email: moore@network-heretics.com