Summary
- RFC 9707 records barriers that survive an active connection: poor quality, expensive pages, unsupported scripts, service dependencies, filtering and unreliable circumvention can all separate connectivity from meaningful access.
- The RFC is an IAB workshop report. It says participant views do not necessarily represent the IAB, that the material was not interpreted or validated by the report, and that the report does not attempt to capture consensus.
- A barrier-to-remedy ledger should connect each bounded observation to the decision layer that can act, then record adoption and outcome separately. This is Daniel Kade’s editorial proposal, not an IETF or IAB mandate.
A connection indicator is a tempting finish line. It is countable, comparable and politically useful. A household either appears to have a link or it does not; a region receives a coverage colour; a programme reports another person “connected.” The metric is not false. The error is asking it to certify more than it observes.
RFC 9707 begins after that finish line. Its central premise is that merely having Internet access is not enough. Someone may have radio coverage, an account and packets crossing a link, yet still be unable to use the public, commercial or social service that made the connection matter. The barrier may be performance. It may be the price of moving a modern webpage over a metered plan. It may be an application that rejects an otherwise valid writing system. It may be a service whose technical dependencies are weaker for one population. It may be a filter, a legal order, or a circumvention tool that leaks the traffic it promised to protect.
Those failures do not belong to one layer. That is what makes the report valuable—and easy to misuse.
A report that preserves disagreement
The Barriers to Internet Access of Services workshop ran online from 15 to 17 January 2024. The Internet Architecture Board convened it around three broad subjects: community networks, evidence about the digital divide, and censorship with circumvention. RFC 9707, published in the IAB stream as Informational in February 2025, preserves the proceedings.
Its strongest governance sentence is a disclaimer with operational force. The views belong to participants and do not necessarily reflect the IAB. The report draws from presentations and discussion notes without interpretation or validation. It does not attempt to capture consensus.
That does not make the evidence disposable. It tells the reader what kind of artifact it is. Publication proves that the IAB considered the record worth preserving. It does not turn every presentation into an IAB finding, combine unlike measurements into a global baseline, or authorize an intervention. A proceedings document can widen the agenda while leaving the burden of proof and the decision path open.
The distinction matters because institutional prestige travels faster than caveats. A claim described as “in an RFC” can be repeated as “the IETF found,” then as “the Internet community agreed,” and finally as “operators must.” Each step adds authority that the source did not supply. The resulting mandate may be rhetorically strong and procedurally ownerless.
Community ownership does not remove operational constraints
The first workshop session examined community networks. These networks can extend connectivity where commercial incentives are weak and can place infrastructure, knowledge and governance closer to the people using it. RFC 7962 shows why they cannot be reduced to a romantic alternative to the carrier: ownership, finance, topology, spectrum, hardware, maintenance and decision models differ widely.
RFC 9707 records the practical tensions. Quality of experience can be hard to guarantee when skills and equipment vary. Satellite backhaul may introduce uneven performance. Transit and the path from a community to a content cache still cost money. Spectrum choices can be shaped by commercial and geopolitical pressure. Manageability requirements written for a well-resourced operator may fit badly in a volunteer or locally administered environment.
The governance mistake would be to assign every gap to “the technical community.” A protocol designer can document manageability considerations. An equipment maker can improve diagnostics. A CDN can offer a different commercial arrangement. A spectrum authority decides access to frequencies. A local network chooses its operating model. A community decides whether the trade is acceptable. These actors may coordinate, but none completes the others’ work merely by publishing guidance.
So the evidence record must ask two questions together: who experiences the barrier, and who controls the lever that could alter it? “Community network quality” is too broad to be actionable. A measured loss rate on a particular backhaul, an unavailable maintenance skill, a transit price, or a spectrum constraint points to a different owner and a different remedy.
Service access fails after the link succeeds
The digital-divide session offers three mechanisms that resist a single score.
One presentation compared DNS dependencies for Australian government sites serving Indigenous users with dependencies for sites serving the general population. The report describes differently configured dependencies as evidence worth investigating. It also keeps an essential uncertainty: qualitative follow-up is needed to understand why the difference exists and whether it creates a tangible divide for users. A dependency graph is not a lived outcome. It can identify where to look, but not close causation on its own.
Another presentation addressed universal acceptance of domain names and email addresses. Standards and policy recommendations can permit multilingual identifiers while software still rejects them. A specification may be complete; a form validator, account system or mail product may remain incompatible. Here the gap is not connectivity and not necessarily missing standardization. It is adoption distributed across applications that each control a small but decisive gate.
The affordability presentation moves to another surface. As pages become heavier, users who pay for data by volume pay more simply to open the same service. A site can be reachable in the network sense and prohibitive in the household-budget sense. Average throughput will not expose that cost. The relevant record needs page weight, local data price, income context and the task the user was trying to complete.
These mechanisms share a result—nominally connected people fail to receive equal service—but not a remedy. Reducing page weight does not fix script acceptance. Updating an application does not change a DNS dependency. Re-architecting a public service does not set the price of mobile data. Combining them into a single “digital inclusion” programme can hide precisely the responsibility needed for execution.
Censorship evidence has several control planes
The censorship session makes attribution even harder. RFC 9707 records differences in legal orders, provider obligations, techniques, blocklists, devices and transparency across jurisdictions and networks. DNS tampering, HTTP interference and SNI-based filtering can produce similar user symptoms while leaving different technical traces. Providers subject to the same broad instruction may implement different lists or methods.
Measurement can show that an intervention occurred from a particular vantage point at a particular time. It may fingerprint a technique, compare providers or locate a device. It cannot by itself repeal the order, disclose the hidden list, force a provider to publish a notice or guarantee that a countermeasure is lawful and safe for the user.
Circumvention is also not a binary success state. A VPN can establish a tunnel while leaking IPv6 or non-browser traffic. A product can promise privacy while its failure modes violate the user’s actual expectation. A technique that works in one network may attract blocking in another. Legal exposure may fall on the user, provider or intermediary differently. “VPN available” is therefore no more conclusive than “Internet connected.”
The proper record separates at least four surfaces: the legal or administrative instruction; the operator’s implementation; the independent measurement; and the user-facing behavior of a circumvention tool. A transparency protocol may help one surface. Privacy engineering may help another. Judicial, legislative or commercial action belongs elsewhere. Calling every remedy “an IETF solution” would erase the boundary between technical competence and political authority.
From a barrier catalogue to an accountable chain
RFC 9707’s takeaways point toward further research, better operational documentation, manageability considerations, privacy work, transparency and possible discussion in several IETF or IRTF venues. They are directions, not evidence that a working group was chartered, a protocol was approved, a government acted or a product changed. The RFC has no IANA actions, and it describes the report itself as having no security impact.
The gap between a valuable observation and an executed remedy needs its own public structure. The barrier-to-remedy ledger proposed here is an editorial device, not a field required by RFC 9707.
Start with the barrier as observed, not as branded. Record the affected service or task, population, geography, network, device and time window. Name the measurement method and vantage point. Preserve sample limits, contrary observations and unknown causation. A user account, dependency graph and active measurement are different evidence types; do not average them into false certainty.
Next record the decision layer. Is the lever in a protocol specification, application implementation, operator configuration, public-service architecture, commercial contract, spectrum rule, court order or local governance arrangement? Name the actor able to decide and the actor expected to execute. If the parties differ, the handoff is part of the evidence chain.
Then describe the remedy narrowly: change a validation rule, reduce a page budget, diversify a dependency, expose a block reason, improve tunnel behavior, publish a management practice. Record the proposal’s forum and status. A workshop suggestion, individual draft, research-group output, IETF consensus document, procurement rule and deployed change are not interchangeable.
Finally, keep adoption and outcome open until observed. Which products, operators or institutions implemented the change? When and over what scope? Did the original barrier move? What new cost or exclusion appeared? Can the action be reversed if it harms the people it was meant to help?
This structure protects both urgency and restraint. It prevents caveats from becoming an excuse to ignore evidence, while preventing evidence from being promoted into authority it did not earn.
Meaningful access is a chain of local decisions
RFC 8890’s assertion that the Internet is for end users gives the investigation a direction: judge architecture by the people ultimately affected, not only by the intermediaries operating it. RFC 9620 supplies questions about accessibility, censorship resistance, transparency, privacy and remedy. Neither document creates one global administrator of access.
That limit is a strength. The Internet’s shared specifications can define minimum interoperable behavior. Later decisions still occur in products, networks, markets, public bodies and communities. Adoption may be voluntary, contested or partial. Outcomes must be observed where people use the system.
The connection metric remains useful. It is simply the first receipt, not the last. Service access requires additional receipts for affordability, capability, language, dependency, filtering and safety. The workshop report is also useful. It is evidence entering a decision system, not the decision system’s final voice.
Governance fails when it celebrates a link that does not deliver a service, or invokes a report that does not own the remedy. It improves when every transition remains attributable: observed, interpreted, decided, implemented and measured. RFC 9707 does not close that chain. It gives the Internet community a more honest place to begin it.
Sources
- BIAS workshop group record
- Heng Lu: Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
- Heng Lu: On Why BTW Media Exists
- Heng Lu: The Policy Mirror
- IAB announcement of RFC 9707
- Workshop slides: web affordability and inclusiveness
- Workshop slides: community networks and quality
- Workshop slides: DNS dependencies and Indigenous users in Australia
- Workshop slides: universal acceptance and digital inclusion
- Workshop slides: online censorship in India, Pakistan and Indonesia
- Workshop slides: security, privacy and usability in the VPN ecosystem
- RFC Editor record for RFC 9707
- RFC 7962: Alternative Network Deployments
- RFC 8890: The Internet Is for End Users
- RFC 9620: Human Rights Protocol and Architecture Considerations
- RFC 9707: Report from the IAB BIAS Workshop
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
