From the Field to the Protocol: Guidance for Civil Society on Informing IETF Work

2.1. Internet Governance and the Multistakeholder Model

The World Summit on the Information Society (WSIS) defined Internet governance as "the development and application by governments, the private sector and civil society, in their respective roles, of shared principles, norms, rules, decision-making procedures, and programmes that shape the evolution and use of the Internet" [TUNIS]. The definition assigns this work jointly to all stakeholders, each acting in its own role.¶

Twenty years later, the WSIS+20 review reaffirmed this model. On 17 December 2025, the UN General Assembly adopted the review's outcome document by consensus [WSIS20]. Among other decisions, it made the Internet Governance Forum (IGF) a permanent forum of the United Nations. The IGF is the principal venue where civil society engages in Internet governance, often through national and regional initiatives.¶

The multistakeholder model therefore presumes that civil society has a role in shaping the Internet. That presumption has been realized in policy forums such as the IGF far more than in the technical community, which includes the IETF and the Regional Internet Registries (RIRs).¶

2.2. The Role of the IETF in Technical Internet Governance

The IETF, founded in 1986, develops voluntary technical standards that network operators, equipment vendors, and software developers choose to implement [IETF-INTRO]. It has no membership: anyone can participate by joining a mailing list or attending a meeting, and over 7,000 people take part in a given year. Decisions are made by rough consensus rather than by voting or intergovernmental negotiation. Its work is conducted in English.¶

The IETF's mission is to make the Internet work better by producing high-quality technical documents that influence how the Internet is designed, used, and managed. Its mission statement explicitly acknowledges that the Internet "isn't value-neutral, and neither is the IETF" [RFC3935].¶

The IETF's reach is global, but the people who implement and deploy its work are regional. Network operators run networks in specific countries and regions, and much of the discussion about deployment and implementation takes place in regional operator communities and in the Regional Internet Registries (RIRs). The IETF specifies the technical basis of Internet number resources, while the RIRs develop policy for them in their regions, taking the IETF's technical recommendations into account [RFC7020].¶

The IETF sits within a wider set of bodies. The Internet Architecture Board (IAB) provides architectural oversight of Internet protocols and procedures [RFC2850]. The Internet Research Task Force (IRTF) complements the IETF's standards work with research in areas of importance to the evolution of the Internet [RFC2014]. Where IETF working groups focus on near-term engineering and standards, IRTF research groups are small, focused, and longer-term, and they study topics related to Internet protocols, applications, architecture, and technology. Participation is by individual contributors rather than by representatives of organizations. The IRTF Chair is appointed by the IAB and manages the research groups together with the Internet Research Steering Group (IRSG). Research groups do not set standards, but their findings can inform IETF work, and some are published as RFCs in the IRTF stream.¶

The IRTF has also been the main place where the relationship between Internet protocols and human rights is studied. The Human Rights Protocol Considerations Research Group (HRPC) was proposed in January 2015 [I-D.doria-hrpc-proposal]. Its early work set out a methodology for mapping technical concepts in protocols to the rights to freedom of expression and association [I-D.varon-hrpc-methodology]. HRPC was chartered in November 2015 [HRPC-ANNOUNCE] to research whether standards and protocols can enable, strengthen, or threaten human rights as defined in the Universal Declaration of Human Rights and the International Covenant on Civil and Political Rights, with a particular focus on freedom of expression and freedom of assembly [HRPC-CHARTER]. Its charter sets three aims: to expose the relationship between protocols and human rights; to propose guidelines for protecting the Internet as a human-rights-enabling environment, modeled on the privacy considerations in [RFC6973]; and to raise awareness of these issues in both the human rights and technical communities.¶

HRPC has since produced research into human rights protocol considerations [RFC8280] and updated guidelines for conducting human rights reviews of protocols and architectures [RFC9620]. Its charter is currently under review, and a rechartering has been proposed [HRPC-CHARTER].¶

2.3. The IETF Community: What Is Known

Several scholars have analyzed the IETF community and its norms. The IETF has been characterized as a private governance regime that resists government oversight [DENARDIS2009] [TENOEVER2020], in which a prevailing belief holds that technical bodies and the standards they produce are largely free of political influence [CATHFLORIDI2017] [DENARDIS2014]. Ethnographic research on human rights advocacy found that IETF engineers tend to see standards as voluntary and non-prescriptive, so that advocacy perceived as prescribing outcomes met resistance [CATH2021]. More recent work has examined how the community frames emerging issues such as environmental sustainability, and found that concerns framed outside its technical mandate receive little attention [JANSEN2026]. Within HRPC, an effort to map the community's positions on whether protocols are political ended without consensus [I-D.irtf-hrpc-political].¶

Participants have also documented structural factors that limit diversity in the IETF. These include how participants and their employers judge the return on their investment, the cost of travel to in-person meetings, the steep technical learning curve, the exclusive use of English, and the difficulty newcomers face in finding where their work fits [I-D.gont-diversity-analysis].¶

In 2021, the IAB convened the "Show me the numbers" workshop on analyzing IETF data [RFC9307]. Participants observed that defining and measuring diversity is itself a challenge. They identified women, individuals from the African continent, and network operators among the communities that are underrepresented or not participating. They also cited the ICANN At-Large model as an example of how stakeholders who are currently absent might be involved.¶

Participation data reflect this concentration. Among respondents to the 2025 IETF Community Survey, 40.6% were based in Europe and 35.9% in North America, while 3.2% were based in Africa, 3.1% in Latin America, and 1.3% in the Middle East [IETF-SNAPSHOT-2025]. Within Latin America, participation has grown gradually since the 2010s, led by Brazil [SILVA2025].¶

The gap in participation reflects a wider gap in technology development. The largest technology companies are headquartered predominantly in the United States, and much of the applied research on Internet technologies takes place in North America and Europe.¶

3.1. Human Rights as a Framework for Civil Society Work

For most CSOs working on technology, the framework is human rights. Work at the intersection of human rights and technology has a history of at least thirty years, and organizations doing it now exist in most countries. They research how people use technology in their communities; document Internet shutdowns, censorship, and surveillance as they happen; follow and engage in local and regional policy initiatives on technology; support journalists, activists, survivors of abuse, and at-risk communities in using technology safely; and run digital security trainings, helplines, and incident response. They do this in local languages, with direct knowledge of local networks, devices, legal environments, and political conditions.¶

This work complements the IETF's. The IETF specifies how protocols work, and CSOs see what happens to people once those protocols are deployed and used. The question addressed here is how the IETF can benefit from that work and the approaches behind it.¶

3.2. Informing the IETF About Users

The IAB has stated that the Internet is for end users, and that when their interests conflict with those of other parties, the IETF should prioritize protecting end users [RFC8890]. Those conflicts are where the main opportunity lies. Weighing them well takes evidence, not assumptions, about users' needs, expectations, harms, and impacts, and CSOs are among the most direct sources of that evidence.¶

CSOs do not need to acquire the technical skills expected of IETF participants to contribute. What they can bring to IETF discussions is knowledge of how protocols are actually used, and by whom.¶

The work of the Detecting Unwanted Location Trackers (DULT) working group is one example of the IETF addressing an actual social harm. DULT is standardizing a protocol that lets nearby devices detect location-tracking accessories that are being used to track people without their knowledge, and its charter commits it to work with gender-based violence experts throughout development [DULT-CHARTER]. Its threat model is grounded in how stalking and abuse occur [I-D.ietf-dult-threat-model]. Building on this, a collective of Latin American feminist helplines and researchers examined the threat model against their own casework [PITG-DULT]. They found that in their region, monitoring more often occurs through shared accounts, location-sharing features, and parental control applications than through tracking tags. They also found that cost and device market share change the likelihood of several threats, and that the attacker frequently has continuous physical access to the victim's devices. Their conclusion, that a threat model rooted in one region "cannot be taken as a universal standard," illustrates both the value of local knowledge and the need for it to reach working groups.¶

That knowledge also has to come from many places. Civil society participation in technical standard-setting is itself concentrated: organizations based in North America and Europe tend to be better funded, and most standards forums meet in those regions, while barriers to participation fall disproportionately on organizations from elsewhere [DPBR2023]. The helplines' review of the DULT threat model shows how expertise treated as general can turn out to be rooted in a single country. For this reason, contributions grounded in regional and local contexts matter most.¶

3.3. Why Now

Civil society is no longer new to technical standards. In recent years, CSOs and human rights defenders have moved from commenting on technology from the outside to taking part in how it is specified. WITNESS's participation in the Coalition for Content Provenance and Authenticity (C2PA), which develops standards for verifying the origin and history of digital content, is one example [WITNESS2025]. Content provenance can help counter misinformation, but it can also create privacy and safety risks for journalists, activists, and human rights defenders. WITNESS's experience shows what civil society can contribute to a standards process: systematically assessing potential harms (identifying 38 in the case of C2PA), proposing mitigations, and pressing for human rights to be considered in governance and implementation, not only in the specification itself. It also shows the limits. Participation that depends on an organization's own resources is fragile, and WITNESS concludes that it must be built into standards processes, not left to chance.¶

Within the IETF, there is already a precedent. When the Detecting Unwanted Location Trackers (DULT) working group was chartered in 2024, its charter included an explicit commitment: "The WG will work with gender-based violence experts throughout development of the protocol" [DULT-CHARTER]. The charter also requires the working group to carry out a threat analysis before publishing the protocol, and to consider people who do not have a device capable of running a detection system. The working group's chairs highlighted the commitment to gender-based violence experts when announcing its formation [DULT-BLOG]. The review of the DULT threat model by Latin American helplines (Section 3.2) shows both the value of that commitment and its limits: expertise drawn from one region does not cover every context. CSOs, in other words, already have experience, methods, and evidence to offer. What is still missing is a shared sense of how that contribution reaches IETF work, and HRPC's charter review is a good moment to work on it.¶

4.1. Topics

The focus here is on work already done in the IETF and IRTF, and on how CSOs can feed into the debates around it. The RFCs mentioned below give a broad overview of where IETF work and CSO interests overlap. They are starting points, not a complete map. On privacy, [RFC6973] provides guidelines for privacy considerations in protocol design, [RFC7258] declares pervasive monitoring an attack to be mitigated in protocol design, and mechanisms such as DNS over HTTPS [RFC8484] and Oblivious HTTP [RFC9458] limit what network observers can learn. On connectivity, [RFC9620] asks whether protocols work on low-bandwidth, high-latency connections and whether they support internationalization, localization, and accessibility. On censorship, [RFC9505] surveys censorship techniques worldwide and the protocol elements they exploit, and Encrypted Client Hello [RFC9849] encrypts some of the metadata those techniques rely on. More broadly, [RFC8280] and [RFC9620] describe how protocol design choices relate to human rights. CSOs can inform each of these areas with evidence from the field: how people are surveilled or identified in practice, how they connect and where services fail them, and which blocking techniques are used, against whom, and how well circumvention tools work.¶

4.2. Approaches: What CSOs Bring and How to Frame It

CSOs contribute from their own point of view. Perspectives the IETF rarely hears directly include:¶

• Usage: how people actually use protocols and services, including on shared, second-hand, or low-cost devices.¶

• Impacts: what happens to people when protocols are deployed, both harms and benefits.¶

• Literacy: what users understand about the technologies they rely on, and where design assumptions about users break down.¶

• Context: the regional and local conditions (legal, political, economic, linguistic, network) that change how a protocol behaves in practice.¶

Such contributions are more likely to inform IETF work when they:¶

• Are specific: they tie an observed effect to a particular service, protocol, or deployment.¶

• Distinguish design from deployment: a harm may come from a specification, an implementation, or an operator's choices, and only some of these are within the IETF's scope. As [RFC9620] notes, a protocol's impact cannot be judged from its design alone.¶

• Are scoped: they state where, when, and for whom an observation holds.¶

• Are reproducible where possible: they include methods or data others can check, including through partnerships with measurement researchers.¶

• Protect the people they describe: anonymization, consent, and care in publication come before completeness.¶