Internet-Draft Diversity & Inclusiveness January 2022
Gont & Moore Expires 31 July 2022 [Page]
Workgroup:
gendispatch
Internet-Draft:
draft-gont-diversity-analysis-01
Published:
Intended Status:
Informational
Expires:
Authors:
F. Gont
EdgeUno
K. Moore
Network Heretics

Diversity and Inclusiveness in the IETF

Abstract

This document discusses a number of structural issues that currently hinders diversity and inclusiveness in the IETF. The issues discussed in this document are non-exhaustive, but still provide a good starting point for the IETF to establish a more comprehensive agenda to foster diversity and inclusiveness.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 31 July 2022.

1. DISCLAIMER

For the most part, many of the topics discussed in this document are the result of on-list and off-list conversations with a number of IETF participants, and are based personal experiences of said group of colleagues, and what such group believes are some of the structural problems hindering diversity in the IETF.

As such, it is very likely (and possibly guaranteed!) that there are aspects that are partially (or even totally!) overlooked. If you feel that is the case, please do contact the authors, and feel free to educate us on what we may have missed. The authors will be happy to incorporate co-authors where needed, include ideas from others while giving due credit, or even include ideas while anonymizing the source or author of the proposal.

Please refer to Section 3 regarding the terminology employed throughout this document.

2. Introduction

This document tries to raise a number of structural issues that currently hinders diversity and inclusiveness in the IETF. The issues discussed in this document are non-exhaustive, but still provide a good starting point for the IETF to establish a more comprehensive agenda for the IETF to address the issue of diversity and inclusiveness.

We have grouped structural issues in these categories:

3. Terminology

Throughout this document, whenever we refer to "diversity" or "inclusiveness" we imply including or involving people of:

  • a range of different social and ethnic backgrounds
  • different genders
  • different sexual orientations
  • different countries and regions
  • different types of organizations (companies, non-profits, etc.)
  • people who are not sponsored by or representing any organization

The above list is non-exhaustive, but should make it evident that "diversity" has multiple axes, and this document does not limit its discussion of diversity to any particular sub-set of them.

4. Perceived Return of Investment (ROI)

While many IETF participants engage in the IETF for the sake of improving the Internet or as a personal hobby, IETF participation involves an investment, whether participation is done independently, or supported by an organization (e.g., company).

As with any investment, the question of what is the return of investment (ROI) is often asked both by participants and their supporting companies (if any).

In the case of companies, the possible ROI will typically depend on the specific sector, but might include:

  • Benefiting from Intellectual Property Rights (IPRs).
  • Benefiting from leading technologies, with e.g. improved "time to market".

In the case of independent participants, ROI could be in the form of:

  • Being able to make a difference in improving Internet technologies.
  • Better career opportunities.

However, these benefits can only be realized by a small subset of companies and participants. For example, in order for companies to benefit from IPRs and improved time-to-market of products, they need to be in the business of manufacturing such specific products. In order cases, companies might deem the ROI of IETF participation as negligible.

In the case of independent participants, the ability to realize better career opportunities generally depends on the availability of companies that might benefit from the IETF in the same country or region. In other words, lacking local companies or organizations that benefit from IETF participation essentially means that IETF participation and the associated skills will result in a negligible ROI for independent participants. And, when processes are biased towards a specific community, even the possibility of improving the Internet "for the common good" might seem unfeasible.

As a result of this, there is a whole range of individuals and organizations for which IETF participation might not result attractive or feasible:

  • Individuals from developing countries
  • Service- and consulting-oriented companies
  • Unaffiliated open source developers
  • Operators
  • Academia

That said, there is always the case of individuals and/or companies that might still try engage in the IETF. However, other issues, such as those discussed in Section 5, Section 6 and Section 9 typically discourage such participation.

The following subsections discuss the specific realities of some of these communities.

4.1. Operators

Operators participation in the IETF has been studied in some detail in [I-D.opsawg-operators-ietf], and some criticism regarding the reduced operator participation has been discussed in [Bush].

5. Effects of Current Participation

The IETF is far from achieving diversity in many (if not most) axes. For example, the IETF is far from having gender parity in the number of participants, or in having a truly diverse geographical participation.

The lack of diversity in current IETF participation essentially means that decisions and the perception of structural problems is biased towards the realities of current participants, and hinders the participation of those not "in the club" of large Internet tech companies.

For example, face-to-face (f2f) meetings are held in regions reflecting current participation levels. But this in turn facilitates participation from those regions, and makes participation from other regions less accessible.

Similarly, the lack of diversity in current participants is in turn reflected in the lack of diversity in IETF groups and leadership roles (discussed in Section 6) which, again, tends to bias processes in favor of the current participants.

Finally, how new work is considered by the IETF is also generally biased in favor of those "in the loop" -- that is, participants that are already engaged in the IETF and that generally belong to the reduced groups for which a ROI from IETF participation is feasible (see Section 4). At times, participants may perceive discrimination on the basis of e.g. their employers (or who their employers are not), the way they use the English language (see Section 11.1, their cultural conventions and how well those conventions mesh with expectations of the majority of IETF participants, and their technical backgrounds.

6. Diversity in IETF groups and leadership roles

Lack of diversity in IETF groups and leadership roles has a direct effect on IETF participation, as a result of:

  • Process fairness by having a very small number of interests judging WG consensus, community consensus, and appeals.
  • Leadership selection fairness by having a limited number of interests participating in the NOMCOM and IAB.
  • Arbitrary decisions produced and enforces by such groups, without getting community consensus on them (see e.g., [I-D.carpenter-nomcom2020-letter]).

6.1. IESG

While one might expect greater diversity in IESG members, there are at least two possible causes for that:

  • There is reduced diversity in many axes of IETF participation.
  • There is (allegedly) a reduced number of possible candidates with the necessary skills.

As noted in Section 5, it is probably obvious that IETF participation is not as diverse as one would expect -- and this certainly constrains diversity in IETF leadership roles in general.

It is also commonly suggested that there is a limited number of candidates with the appropriate skills set for IESG positions, and that one of the common missing skills is IETF management experience. However, there does not seem to be a concrete effort to produce an increase in the number of participants with appropriate skills to volunteer for such roles. For example, fostering diversity in WG chair positions would be an obvious choice for increasing the pool of potential candidates for IESG positions, as discussed in Section 6.2.

6.2. WG Chairs

Most WGs have permanent WG chairs which only become rotated when:

  • A WG chair takes a higher responsibility within the IETF (e.g. WG Chair becomes an Area Director).
  • There are personal issues affecting the WG chair (e.g., WG chair retires, changes jobs, etc.).
  • There is evident malfunction of a WG which leads to an WG chair being replaced.

However, if the IETF adopted the convention that chairs are rotated in all cases, this would certainly:

  • Increase diversity in WG chairs positions.
  • Increase the pool of IETF participants with IETF leadership experience, which could in turn help increase diversity in other leadership roles, such as the IESG.
  • Makes WG chair changes less stressful and controversial, since WG chairs are rotated *by default*.
NOTE: One could envision a policy where each WG has three co-chairs, with different experience levels, and where one of the co-chairs has no previous WG chair experience. Every two (or so) years the most experienced WG chair leaves his role, which is occupied by the second-most experienced WG chair from the group. And a new un-experienced WG chair is incorporated by the WG.

6.3. NOMCOM

The current NOMCOM member selection rules try to be fair, but are still biased in favor of the specific groups discussed in Section 4 and Section 5.

For example,

  • The requirement to have attended X out of Y of the last f2f meetings is clearly biased in favor of IETF participants who have enough funding to travel to most meetings.
  • Big tech companies are more likely to be willing to let their employees do that because they're more likely to get IESG and IAB members who favor their interests.
  • There is the expectation that NOMCOM members attend f2f meetings to carry their NOMCOM duties -- which, again, favors the same group of participants (those with funding, which generally work for big tech companies).
  • If the NOMCOM has f2f interviews, the process also favors those candidates that are able to attend f2f meetings, who can be interviewed in-person.
NOTE: There are a few obvious things that could be done to improve these issues. [RFC8989] is certainly a step in the right direction. Having the NOMCOM perform its duties only online would be another.

7. Processes

Some aspects of WG operation are loosely described. While this may be beneficial in some cases, other times the rules or expectations regarding how WGs are meant to operate can be problematic for participants, and even more so to newcomers.

NOTE: [I-D.carpenter-gendispatch-rfc7221bis] is a good attempt at clarifying some specific aspects of WG operation.

8. Difficulty in Joining the IETF

8.1. Finding interesting Working Groups and Areas

It is usually hard for newcomers (and sometimes experienced people) to see how to contribute effectively or even to find which working groups (if any) whose work they would be interested in.

Similarly there are now so many different groups, committees, supporting organizations, etc. involved in running IETF that it is hard to understand the big picture, and know which group does what, or which people to talk to about any given concern. [IETF-Tao] can ameliorate this issue, but not eliminate it.

In some cases, working groups may (intentionally) have a narrow charter, in which case re-chartering the working group, or getting support for a Birds of a Feather (BoF) session may be non-trivial.

It is also hard for newer people to get "up to speed" on an existing working group or topic area. Reading the WG's mailing list archive can be very time consuming and not always very illuminating. The Datatracker and Tools effort have been (and still are) of a lot of help here. But having materials that e.g. provide a summary of what the ongoing work of a WG is, and that summaries what recent discussions have been about, and what the different views are/have been, would certainly help in this area.

8.2. Difficulty in Authoring and Submitting Internet-Drafts

There are so many formatting rules that an Internet-Draft (and eventually an RFC) needs to comply to, that in practice the only reasonable way create and submit an Internet-Draft is via the set of tools available at: https://tools.ietf.org/ . Tools such as xml2rfc are of a lot of help to produce documents that comply with the Internet-Draft formatting rules -- but its error messages might result cryptic to the unexperienced user.

The number of tools has expanded so much that they probably deserve their own guidelines. And existing guidelines such as [ID-Guidelines] should probably be updated with the assumption that Internet-Drafts will be produced with the set of available tools.

This means that e.g. it becomes less important to the Internet-Draft author what formatting rules a document needs to comply to, since the existing tools will guarantee such compliance. On the other hand, an author may benefit from guidelines on how to use the set of available tools.

Document authors generally have freedom to select the tools they employ to author Internet-Drafts. However, this may represent a challenge to working groups if/when the authors of a working group become unresponsive and one or more editors need to take control of the document -- but the new editors are not familiar with the tools or document source format employed by the original authors of the document.

8.3. Contributing to Working Groups

Traditionally, aside from f2f meetings, most working group discussions have taken place on mailing-lists.

Use of mailing-lists have has been considered rather ineffective or inconvenient by some, and some working groups have started to rely more on GitHub both for suggesting changes to e.g. Internet-Drafts and to discuss the associated changes. While some have found this move convenient, some perceive the reliance on 'git' as an obstacle to participation. The choice of tools is, indeed, a trade-off.

8.4. Support from Experienced Members

In some cases newcomers would benefit from a mentor that could guide the newcomer through the process of writing, publishing, and socializing an Internet-Draft. In cases where a proposal would nicely fit into one of the existing working groups, the corresponding working group chairs might be able to provide guidance (assuming the newcomer is able to spot the appropriate working group and chairs). If there is no obvious target working group, obtaining such guidance might result more difficult.

This challenge could be mitigated by having a group of volunteers that would be willing to guide newcomers in finding an appropriate working group and submitting a proposal to that working group, or finding alternatives for pursuing said proposal.

On the other hand, it has also been suggested that when trying to pursue work in specific areas or working groups, backing by experienced members is implicitly required in order for a proposal to have any chances of making progress -- particularly when come from newcomers.

9. Economic Constraints

The current IETF processes favor participants who have enough money to travel to several meetings a year, and/or participants who work for companies who can afford such expense and are willing to spend that money (which tends to be a specific subset of companies, as discussed in Section 4).

[RFC4144] (an individual submission) argues that "eighty percent of success is showing up".

Clearly, work such as [I-D.ietf-shmoo-remote-fee] is a step in the right direction. Other things to evaluate and consider are: incorporating fee waivers for f2f meetings and/or adjusting the IETF meeting fee to the local realities (i.e., move away from a flat fee), and reducing the number of f2f meetings.

10. Educational Constraints

You have to know a lot of technical material to participate usefully and effectively in IETF. How IPv4 and IPv6 work, something about routing (at least the need for advertisements and aggregation), something about addressing, something about transport protocols (probably TCP and UDP, at least), something about congestion control (at least that it's needed), something about DNS, something about protocol layering, something about applications, something about security (at least basics of authentication and encryption), etc.For someone with little exposure there can be a very steep learning curve.

Additionally, improving internet protocols requires skills to assess protocols in a critical way. While there are multiple courses and certifications that provide general knowledge about Internet protocols and the skills for e.g. configuring internet routers, there are fewer materials that try to analyze protocols in a critical way (e.g. [Perlman] and [Day]). And this represents a barrier to newcomers.

While this is not a problem that the IETF could (or should) solve, there has been work that has helped in this area, and possibly more could be done. e.g., some IETF tutorials have been very educational and useful not only to introduce newcomers to IETF work, but also to provide context for such work, and occasionally also discuss shortcomings. There is certainly room for the IETF to expand on these activities.

11. Cultural Issues

There are a number of cultural issues that also hinder diversity and inclusiveness in the IETF. The following sub-sections discuss some of these.

11.1. Language

Language can be exclusionary in many different ways.

For example, IETF participation requires and implies use of English language. While English language has become the de facto international language (with attempts such as Esperanto failing miserably), communication in (any) non-native language can be challenging for a number of reasons. This tends to be more challenging when oral communication (as opposed to written) is involved when expressions or phrasals that are unfamiliar to non-native speakers of the language are involved.

Consider expressions such as "red herring", "knee jerk", and others.

Use of terms that may have a political or social connotation may result offensive to at least part of the community (see e.g. [I-D.knodel-terminology] or [I-D.gondwana-effective-terminology]). On the other hand, some participants (particularly those that do not speak English as a native language) may be unaware of the connotation or historical background of such words, and may in turn be judged for their inadvertent usage.

11.2. Using email effectively

Email is still the best way for IETFer's to communicate at a distance, it's vendor-independent and avoids vendor lock-in, it's universally available, there are many providers and email user agents to choose from, it lends itself to searching and archiving, etc. It's the medium of choice partially because it doesn't impose many barriers to IETF participants using it. But there's a bit of an art to using it effectively.

11.3. Comfort zone

Willingness to leave one's comfort zone is usually a necessary condition to participating effectively in IETF.

Anyone who participates significantly is going to run into other people who disagree, who think about the problem differently, who have completely different contexts. This might be because they're from a different technical background, different kind of company, different culture, or all of the above. This is normal and even necessary. Trying to sort out differences between people with different points-of-view is often uncomfortable precisely because it often forces us to question our own assumptions. It follows that a desire or demand to be "comfortable" at all times is counterproductive.

And sometimes one runs into overt personal prejudice on the part of others, and we have to deal with that too. It's part of the landscape. Often people aren't aware of their prejudices or accept them as natural or correct, and don't know how to turn them off even if they wanted to. With increasing familiarity and a willingness to respect fellow participants, it can diminish over time. But it takes work, and that work is also often uncomfortable work.

12. IANA Considerations

This document has no IANA actions.

13. Security Considerations

There are no security implications arising from this document.

14. Acknowledgements

The authors would like to thank (in alphabetical order) Carsten Bormann, Brian Carpenter, Lars Eggert, Theresa Enghardt, Simone Ferlin-Reiter, Juliana Guerra, Bron Gondwana, Joel M. Halpern, Dominique Lazanski, Eliot Lear, for providing valuable comments on earlier versions of this document.

This document has been motivated by discussions with a number of individuals, both on- and off-list.

15. Informative References

[Bush]
Bush, R., "Into the Future with the Internet Vendor Task Force: A Very Curmudgeonly View - or - Testing Spaghetti -- A Wall's Point of View", ACM SIGCOMM Computer Communication Review, Volume 35, Number 5, , <https://archive.psg.com/051000.sigcomm-ivtf.pdf>.
[Day]
Day, J., "Patterns in Network Architecture: A Return to Fundamentals", 1st edition, Prentice-Hall, .
[I-D.carpenter-gendispatch-rfc7221bis]
Farrel, A., Crocker, D., Carpenter, B. E., Gont, F., and M. Richardson, "Handling and Adoption of Internet-Drafts by IETF Working Groups", Work in Progress, Internet-Draft, draft-carpenter-gendispatch-rfc7221bis-01, , <https://www.ietf.org/archive/id/draft-carpenter-gendispatch-rfc7221bis-01.txt>.
[I-D.carpenter-nomcom2020-letter]
Carpenter, B. E., "Open Letter to the 2020-21 IETF Nominating Committee", Work in Progress, Internet-Draft, draft-carpenter-nomcom2020-letter-00, , <https://www.ietf.org/archive/id/draft-carpenter-nomcom2020-letter-00.txt>.
[I-D.gondwana-effective-terminology]
Gondwana, B., "Effective Terminology in IETF drafts", Work in Progress, Internet-Draft, draft-gondwana-effective-terminology-01, , <https://www.ietf.org/archive/id/draft-gondwana-effective-terminology-01.txt>.
[I-D.ietf-shmoo-remote-fee]
Kuehlewind, M., Reed, J., and R. Salz, "Open Participation Principle regarding Remote Registration Fee", Work in Progress, Internet-Draft, draft-ietf-shmoo-remote-fee-02, , <https://www.ietf.org/archive/id/draft-ietf-shmoo-remote-fee-02.txt>.
[I-D.knodel-terminology]
Knodel, M. and N. T. Oever, "Terminology, Power, and Exclusionary Language in Internet-Drafts and RFCs", Work in Progress, Internet-Draft, draft-knodel-terminology-08, , <https://www.ietf.org/archive/id/draft-knodel-terminology-08.txt>.
[I-D.opsawg-operators-ietf]
Grundemann, C. and J. Zorz, "Operators and the IETF", Work in Progress, Internet-Draft, draft-opsawg-operators-ietf-00, , <https://www.ietf.org/archive/id/draft-opsawg-operators-ietf-00.txt>.
[ID-Guidelines]
Housley, R., "Guidelines to Authors of Internet-Drafts", , <https://www.ietf.org/standards/ids/guidelines/>.
[IETF-Tao]
ten Oever, N. and K. Moriarty, "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", , <https://www.ietf.org/about/participate/tao/>.
[Perlman]
Perlman, R., "Interconnections: Bridges, Routers, Switches, and Internetworking Protocols", 2nd edition, Addison-Wesley Professional, .
[RFC4144]
Eastlake 3rd, D., "How to Gain Prominence and Influence in Standards Organizations", RFC 4144, DOI 10.17487/RFC4144, , <https://www.rfc-editor.org/info/rfc4144>.
[RFC8989]
Carpenter, B. and S. Farrell, "Additional Criteria for Nominating Committee Eligibility", RFC 8989, DOI 10.17487/RFC8989, , <https://www.rfc-editor.org/info/rfc8989>.

Authors' Addresses

Fernando Gont
EdgeUno
Segurola y Habana 4310, 7mo Piso
Villa Devoto
Ciudad Autonoma de Buenos Aires
Argentina
URI: https://www.edgeuno.com
Keith Moore
Network Heretics