Summary

  • RFC 8280 and its 2024 update, RFC 9620, turn human-rights concerns into questions protocol developers and reviewers can ask. They are collaborative IRTF research documents, not IETF standards or compliance certificates.
  • The update's five review methods point beyond design text to experts, affected communities and running implementations. That is the important limit as well as the method's strength: a checklist can identify a possible impact, but cannot by itself establish how a deployed system affects people.

A question is only the beginning

A protocol document can be precise about packets and still be incomplete about consequences. It may say which intermediary can see a field, how a device behaves when a connection fails, or whether a service can be reached through more than one route. Those decisions can shape privacy, access, expression or reliability. But a line in a specification does not tell a reviewer who will deploy the feature, how operators will configure it, or what a person using the network will experience.

That gap sits at the center of the work Niels ten Oever helped build through the Human Rights Protocol Considerations Research Group, or HRPC. The group's first major research document, RFC 8280, was published in 2017 by ten Oever and Corinne Cath. It offered a vocabulary connecting technical properties to human-rights questions and a set of considerations for protocol developers. The document describes its own research as an early milestone, not a finished universal test.

The research behind it was more than a list of concerns. RFC 8280 describes analysis of RFCs and mailing-list discussion, more than 30 interviews with IETF community members at the 2015 Dallas meeting, and participant observation in working groups and mailing lists. Those methods helped researchers ask how engineering concepts were understood inside the standards community and where the effects on users might enter the discussion. The work belonged to the authors and the research group; it should not be recast as one person's invention.

Five ways to look beyond the document

In September 2024, RFC 9620, co-authored by Gurshabad Grover and ten Oever, updated RFC 8280. Its most useful addition for readers is a map of five ways a human-rights review can proceed. A reviewer can apply the guide's questions to a draft; read the text for effects that are perceived or speculated; interview technical experts; interview affected people and communities; and trace what happens when an implementation is running.

These are not interchangeable boxes. Reading a draft may expose a choice that has not yet become an operational fact. An expert interview can clarify what a design intends to do, but intention is not deployment. A conversation with people affected by a system can reveal an experience that the protocol text does not contain, yet attribution to one protocol may be difficult. Looking at running code or a deployed system can show behavior that the designers did not anticipate, but only for the implementation and conditions examined.

The document says this plainly: protocol impact cannot be deduced from design alone; usage and implementation also have to be studied for a full assessment. It also describes review methods as nascent and the wider practice as still developing. That caveat makes the guide more credible, not less. It tells an engineer what a question can open and what evidence is still missing.

The sequence matters in practical work. A reviewer who encounters a draft early may influence a design while alternatives are still relatively cheap. RFC 9620 says review can happen at different stages and that later review, including during Last Call, remains relevant, although it is less likely to cause major document changes. A review that appears only after deployment may still identify harm or a mitigation, but it cannot recover the same design options at the same cost.

From advocacy into protocol review

Ten Oever's biography helps explain why this bridge became his work. The University of Amsterdam profile describes his research on communication infrastructures through Science and Technology Studies and International Political Economy. It identifies him as a co-founder and former chair of HRPC and records earlier digital-rights work at ARTICLE 19. The IETF Datatracker profile lists him as a reviewer in the Human Rights Review Team and names both RFC 8280 and RFC 9620 among his RFCs.

This is a record of collaboration across communities, not evidence that ten Oever controlled the standards process. RFC 9620 is an Informational publication in the IRTF stream. Its own status says it is not an Internet Standards Track specification, not an IETF product and not a standard. The HRPC charter likewise says the research group exists to improve understanding and does not set policy for the IETF.

That boundary is important. A review can bring expertise, affected people's evidence and technical objections into a decision. The presence of those voices does not automatically make a group the authorized decision-maker, and publication of a questionnaire does not make an implementation rights-compliant. The research can sharpen the questions asked of protocol authors; the responsible engineering and policy bodies still have to explain which choices they make and why.

A review should leave an evidence trail

The strongest way to use RFC 9620 is as a prompt for a traceable review rather than a scorecard. For each concern, record the design choice and the draft stage, what evidence came from the document, which claims came from experts or affected communities, whether an implementation was examined, and what remains speculative. Identify alternative designs, operational constraints and the people who might bear a cost. If the system later changes, return to the same question with new evidence.

That discipline also protects against overstatement. A reviewer should not say that a protocol caused a harm merely because a question raised it; neither should a standards group say that a design is safe because a checklist was completed. The RFC itself notes the difficulty of attributing effects to a protocol, especially before wide deployment. A careful review distinguishes a risk hypothesis, a design property, observed behavior and a human outcome.

This is the lasting contribution of ten Oever's HRPC work: not a final catalogue that settles every dispute, but a way to make technical assumptions discussable and to show what would be needed to test them. Questions are useful because they change what designers inspect. Their limit is equally useful: where the answer depends on use, implementation and context, the document cannot stand in for that evidence.

Sources