| Internet-Draft | Inclusive IETF Participation | October 2026 |
| ATTOUMANI MOHAMED | Expires 1 May 2027 | [Page] |
Participation in the IETF remains very unevenly distributed across regions, and Africa is among the least represented. This document argues that closing this gap is a shared responsibility and proposes a two-track approach. Outside the IETF, universities, technical communities, Internet governance forums, and regional institutions in underrepresented regions need to demystify the IETF and bring academics, students, and young engineers toward its work. Within the IETF, barriers to entry can be lowered further, and holding an IETF meeting in Africa would send a strong signal and act as a catalyst, meeting a local community prepared by the first track. The document proposes concrete actions, indicative metrics, and next steps for both tracks.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft is available on the IETF Datatracker at https://datatracker.ietf.org/doc/draft-attoumani-ietf-inclusion/. Source and revision history are maintained at https://github.com/karimattoumanimohamed/draft-attoumani-ietf-inclusion, where comments can be submitted as issues. Discussion is welcome on the gendispatch@ietf.org mailing list.¶
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 1 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The IETF is open: anyone can join a mailing list, comment on an Internet-Draft, or attend a meeting. Openness of process, however, does not by itself produce breadth of participation. Contributors from Africa and other underrepresented regions remain rare among participants, authors, and leaders, even though much of the future growth of the Internet is expected in these regions (Section 2).¶
Discussions of this gap often focus on what the IETF should change. This document takes a different position: the gap is a shared responsibility. Many potential contributors do not participate because they have never heard of the IETF, do not understand how it works, or see no recognition for such work in their institutions. These are problems that communities in underrepresented regions are best placed to address themselves. At the same time, the IETF can lower the remaining barriers and send clear signals that newcomers from these regions are expected and welcome.¶
This document therefore proposes a two-track approach (Section 3):¶
An IETF meeting in Africa is not proposed as a reward for, nor as a precondition of, the first track. The two reinforce each other: local mobilization creates a community ready to make the most of such a meeting, and the meeting gives that mobilization visibility and momentum.¶
This document focuses on Africa, where the gap is among the largest and where the author's experience lies, but most proposals apply to other underrepresented regions. It does not propose any change to the IETF standards process, and it does not seek institutional representation in the IETF, whose work is carried out by individuals and decided by rough consensus [RFC3935] [RFC2026]. It builds on existing work on diversity and meeting policy [RFC7704] [RFC8718] [RFC8719] [RFC9712].¶
The publicly available indicators, although partial, point in the same direction:¶
Other indicators that matter for inclusion, such as visa refusals among registered participants, are not published. Agreeing on definitions and publishing baselines is one of the proposals of this document (Section 5.3).¶
The barriers summarized below come from discussions in which the author took part, including Africa IGF sessions, Internet Society chapter meetings, IETF meetings, and exchanges with academics and engineers. They form a qualitative synthesis, not the result of a systematic survey, and are consistent with independent research on African contributions to standards development [RIA-2022].¶
Participation rarely results from a single intervention. It generally progresses along a continuum:¶
The first stages mostly depend on actors outside the IETF: they are the object of Track A. The later stages depend more on the IETF's own practices: they are the object of Track B. Neither track is sufficient alone. Lowering barriers within the IETF has limited effect if few people in a region know the IETF exists, and local mobilization stalls if newcomers find no path from first participation to contribution.¶
Examples of this approach include the session "Bridging the Gap: Strengthening African Participation in the IETF" at the Africa IGF 2025, the session "Africa at the Standards Table: Why Participation in the IETF Matters" at the Africa IGF 2026 in Accra (3 November 2026), and the workshop proposal "Standards for All: Bringing Global South Academia to IETF" submitted to the IGF 2026. Interest expressed by institutions in these discussions should not be read as formal commitments.¶
Local efforts can be amplified by organizations whose mandates already cover digital development, higher education, Internet infrastructure, or Internet governance in Africa:¶
Other organizations, such as Smart Africa and the African Telecommunications Union, could also contribute. In all cases, the aim is awareness, capacity building, recognition, and funding for individual participation. Such engagement implies no role for these organizations in IETF decision-making.¶
Holding an IETF meeting in Africa would be a strong signal that the IETF considers the continent part of its community, and a catalyst for the efforts of Track A. Such a meeting would allow hundreds of local students, engineers, academics, and policymakers to experience IETF work directly, including the hallway track; give visibility to standards work among regulators, universities, and the media; and leave lasting links between local participants and working groups.¶
The current policy already allows this: exploratory meetings outside the three main regions are possible under the "1-1-1-*" policy [RFC8719], and the IETF Administration LLC can schedule them through its normal procedures [RFC9712]. This document therefore asks:¶
Track A is what makes such a meeting worthwhile: its value depends on the presence of a local community prepared to take part in it and to stay engaged afterwards. Preparatory workshops, mirror events, and mentoring in the preceding years would help ensure that it is not a one-off event. In the longer term, the community could consider whether every major region should host a meeting at regular intervals.¶
Progress should be measurable. The following indicators and targets are indicative and intended to stimulate discussion; the first step is to agree on definitions and publish baselines, for example in the IETF Annual Report.¶
| Indicator | Latest public value | Indicative target 2030 |
|---|---|---|
| Participants based in Africa | 2.5% of survey respondents (2024) | 10% |
| RFCs with an Africa-based author | Less than 0.3% of authors | Doubled share |
| Working group chairs outside North America and Europe | About 8% | Measurable increase |
| IETF meetings in Africa | 0 | 1 |
| Onboarding materials in other languages | English only | 4 languages |
| Visa refusals among registered participants | Not published | Baseline published and reduced |
Any collection of data on participants, in particular on visa outcomes, must be voluntary, aggregated, and respectful of privacy.¶
A possible sequence is given in Appendix A.¶
This document has no direct security implications for Internet protocols. Proposals involving the collection of participation data, in particular on visa outcomes, raise privacy considerations; such data should be collected on a voluntary basis, minimized, aggregated before publication, and protected in line with the IETF's privacy practices.¶
This document has no IANA actions.¶
Phases are expressed relative to the start of community discussion of this document.¶
This section is to be removed before publishing as an RFC.¶
The author thanks Martin Vigoureux, Peng Shuping, Michael Richardson, Laurence Lundblade, and Vint Cerf for their thoughtful feedback on earlier versions of this document, as well as participants in the Africa IGF discussions and members of the Internet Society African chapters for their insights.¶