University of Toamasina / ISOC Comoros Chapter

Comoros karimattoumanimohamed@gmail.com

General inclusion participation meeting venues Africa outreach 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. About This Document The latest revision of this draft is available on the IETF Datatracker at . Source and revision history are maintained at , where comments can be submitted as issues. Discussion is welcome on the gendispatch@ietf.org mailing list.

Introduction 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 (). 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 ():

• Track A, outside the IETF (): demystify the IETF and its work, and bring academics, students, and young engineers toward it, with the support of regional institutions.
• Track B, within the IETF (): lower barriers to entry and hold an IETF meeting in Africa, as a strong signal and as the point where the two tracks converge.

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 . It builds on existing work on diversity and meeting policy .

The Participation Gap

Indicators The publicly available indicators, although partial, point in the same direction:

• In the 2024 IETF Community Survey, 2.5% of respondents were based in Africa, compared with 40.4% in Europe and 39.4% in North America .
• Africa-based contributors account for well under 1% of RFC authors: an analysis of author contact details found 15 RFCs with an Africa-based author as of January 2022 , and an analysis of Datatracker data found that African contributors represent less than 0.3% of RFC authors .
• Leadership is geographically concentrated: according to the same Datatracker analysis, about 92% of working group chairs are based in North America or Europe .
• No IETF meeting has been held in Africa to date. Under the current meeting policy, meetings rotate primarily among North America, Europe, and Asia, and other regions can only be reached through exploratory meetings .

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 ().

Barriers 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 .

Awareness:

Many students, researchers, engineers, and policymakers do not know the IETF, its open participation model, or how an Internet-Draft becomes an RFC. This barrier comes before all the others.

Recognition:

University evaluation and promotion systems rarely value standards work, which discourages faculty and doctoral students from contributing.

Cost and mobility:

Travel and accommodation costs and visa uncertainty limit in-person attendance.

Distance from the "hallway track":

Remote participation gives access to sessions, but not to the informal exchanges where much trust and collaboration are built. Time-zone differences add to this.

Language:

Work is conducted in English, which raises the entry cost for speakers of French, Arabic, Portuguese, and other languages, especially at the beginning.

A Two-Track Approach Participation rarely results from a single intervention. It generally progresses along a continuum:

1. Awareness: knowing what the IETF is and that anyone can participate.
2. Learning: understanding how standards are developed and how to engage.
3. First participation: joining a mailing list, a hackathon, or a meeting, remotely or in person.
4. Mentoring: being accompanied through the first discussions and reviews.
5. Contribution: reviewing, implementing, and co-authoring Internet-Drafts.
6. Authorship and leadership: authoring RFCs and taking on roles such as working group chair.

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.

Track A: Action Outside the IETF

Demystifying the IETF

• Include sessions on Internet standards participation, as a recurring item, in the Africa IGF and in national and regional IGFs, with IETF participants as speakers.
• Organize local "IETF awareness" activities led by Internet Society chapters, universities, and regulators, in local languages where useful.
• Organize mirror events at universities during IETF meetings, where students follow selected sessions together with a local facilitator.
• Encourage participation in the IETF Hackathon, which is open, free, and often the easiest first contact with IETF work.

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.

Bringing Academia Toward the IETF

• Recognition: RFCs undergo public review that has been argued to be comparable to academic peer review, and it has been proposed that they be treated as scholarly publications . Universities could take RFCs and substantive IETF contributions into account in hiring, promotion, and doctoral evaluation.
• Curriculum: Introduce Internet standards development into networking and security courses, for example through assignments based on reviewing or implementing active Internet-Drafts, in partnership with university networks such as the Association of African Universities.
• Research: Encourage doctoral and research projects that lead to Internet-Drafts or implementations, and connect them with relevant working groups and IRTF research groups.
• Research and education networks: Involve African research and education networks (such as WACREN, UbuntuNet Alliance, and ASREN), whose engineers already operate IETF-standardized technologies.

Youth and Technical Communities

• Hold preparatory workshops before IETF meetings, for example alongside the African Internet Summit or AfNOG, to help newcomers choose working groups, read drafts, and prepare contributions.
• Build mentoring pipelines connecting students and young engineers with experienced participants, building on existing programs rather than duplicating them.
• Form national contact groups, gathering chapters, universities, operators, and regulators, to identify and accompany potential contributors.
• Promote the view that contributing to Internet standards is a matter of technical capacity and self-determination, not a distant activity reserved for others.

Advocacy Toward Regional and International Institutions Local efforts can be amplified by organizations whose mandates already cover digital development, higher education, Internet infrastructure, or Internet governance in Africa:

• African Union Commission (AUC): recognize participation in open standards development in the implementation of the Digital Transformation Strategy for Africa, and encourage Member States to reflect it in national digital strategies, skills programs, and research funding.
• United Nations Economic Commission for Africa (UNECA): as host of the Africa IGF secretariat, support a recurring session on standards participation, and contribute research and data on African participation in standards development organizations.
• UNESCO: drawing on its mandates in higher education and multilingualism and on its Internet Universality (ROAM-X) indicators , support academic recognition of standards work and the translation of onboarding materials.
• AFRINIC: as the Regional Internet Registry for Africa, and together with regional technical events, host preparatory workshops and help identify technical contributors, within the limits of its institutional capacity.
• Internet Society (ISOC): building on its Policymaker Program and fellowship activities and on its African chapters, expand awareness and onboarding activities 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.

Track B: Action Within the IETF

Lowering Barriers to Entry

• Onboarding in more languages: translate the Tao of the IETF and key newcomer materials into French, Arabic, Portuguese, and Spanish, and maintain a multilingual glossary of IETF terms. Standards work itself would remain in English.
• Mentoring: encourage working group chairs and experienced participants to mentor newcomers from underrepresented regions, in coordination with the IETF Education and Outreach Directorate .
• Remote participation: keep improving remote participation, and consider time zones of underrepresented regions when scheduling interim meetings.
• Funding: consider a dedicated budget line, decided by the IETF Administration LLC , to support participants from underrepresented regions, complementing existing fellowship programs.

An IETF Meeting in Africa 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 , and the IETF Administration LLC can schedule them through its normal procedures . This document therefore asks:

1. that the IETF Administration LLC assess the feasibility of an exploratory meeting in Africa, including candidate cities, visa accessibility for participants, safety, connectivity, and cost; and
2. that venue assessments in general give explicit weight to visa accessibility for participants from all regions, within the framework of .

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.

Measuring Progress 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. Indicative Inclusion Metrics

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.

Why This Matters to the IETF

• Better standards: participants who deploy networks under constraints such as intermittent connectivity, mobile-first access, or limited bandwidth bring use cases and review that improve standards for everyone. The goal is not to create a separate "African" agenda, but to have African engineers contribute to all areas of IETF work.
• Relevance: much of the future growth of Internet use is expected in regions that are underrepresented today; their engineers will implement and operate IETF standards.
• Legitimacy and adoption: standards developed with input from all regions are better positioned for global adoption.
• Same quality bar: broader participation adds review and implementation capacity; it does not change how consensus is reached or the criteria for adopting a standard.
• Remote is necessary but not sufficient: remote tools give access to sessions but not to the relationships that turn newcomers into contributors.

Next Steps

1. IETF community: discuss this document in GENDISPATCH, and identify the appropriate home for its proposals, whether existing directorates and programs, a time-bound design team, or a BoF.
2. IETF Administration LLC: assess the feasibility of an exploratory meeting in Africa, publish participation baselines, and consider dedicated participation support in a forthcoming budget cycle.
3. IESG, IAB, and working group chairs: support mentoring of newcomers from underrepresented regions and review progress on the indicators periodically.
4. Communities in underrepresented regions (Internet Society chapters, universities, research and education networks, technical communities): carry out the actions of , starting with awareness activities, national contact groups, and preparatory workshops.
5. Regional and international institutions: include IETF participation in their capacity-building, higher-education, and Internet governance programs, and fund individual participation.

A possible sequence is given in .

Security Considerations 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.

IANA Considerations This document has no IANA actions.

Informative References ACM SIGCOMM Computer Communication Review, Vol. 40, No. 1 Proceedings of the 2025 International Conference on Electrical and Computer Engineering Researches (ICECER), IEEE IETF Administration LLC Research ICT Africa UNESCO Internet Society IETF

Indicative Roadmap Phases are expressed relative to the start of community discussion of this document.

Months 0-6:

Discussion in GENDISPATCH and regional forums; first national contact groups and awareness activities; publication of participation baselines; translation of key onboarding materials begins.

Months 6-18:

Preparatory workshops and mirror events around IETF meetings; first university partnerships and mentoring pairs; feasibility assessment of an exploratory meeting in Africa.

Months 18-36:

Evaluation against the indicators of ; if the assessment is positive, scheduling of an IETF meeting in Africa, with local preparation building on Track A.

Changes since -05

• Restructured the document around a two-track approach: action outside the IETF (demystifying the IETF, bringing academia and youth toward it, institutional advocacy) and action within the IETF (lowering barriers, an IETF meeting in Africa as signal and point of convergence, measuring progress). Shortened the document by merging overlapping sections.
• Replaced unsourced figures with sourced indicators (2024 IETF Community Survey, Research ICT Africa 2022, Attoumani Mohamed and Velo 2025).
• Restored a References section.
• Replaced references to the IAOC, dissolved under RFC 8711, with the IETF Administration LLC.
• Anchored the meeting proposal in the exploratory meeting mechanism of RFC 8719 as updated by RFC 9712.
• Replaced the unsupported claim about German academic standards with a reference to Carpenter and Partridge (2010).
• Added advocacy toward regional and international institutions (AUC, UNECA, UNESCO, AFRINIC, ISOC), with the clarification that it implies no role in IETF decision-making.
• Replaced the proposed working group with a request to discuss the appropriate home for the proposals in GENDISPATCH.
• Made targets indicative; replaced the calendar roadmap, whose dates had passed, with a phased roadmap.
• Added the Africa IGF 2025 and 2026 sessions as examples.
• Added Security and IANA Considerations.

Acknowledgments 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.