We like to think of technical standards as quiet, neutral infrastructure—just the plumbing that makes the internet work. But every standard, from BGP to HTTP/3, is a record of choices. Choices about who gets to control traffic, who shoulders the operational costs, and whose interests get baked into the defaults. When a new protocol drops and the applause starts, it’s worth pausing to ask: who was in the room, and what were they optimizing for? For network operators, end users, and platform providers, the answers shape who holds power in ways that are easy to overlook but hard to undo.
Look around the landscape and you’ll see the fingerprints of these decisions everywhere—in the way DNS resolution has quietly migrated toward a handful of global resolvers, in how congestion control algorithms favor content-rich giants, in the assumptions about bandwidth and latency that leave community networks and rural ISPs scrambling for workarounds. The organizations that write the rules—the IETF, W3C, 3GPP—each have their own governance quirks, funding models, and dominant players. Knowing who sits at the table isn’t a parlor game; it’s a way to understand why your traffic takes the path it does, why some encryption models win out, and why the network sometimes feels like it was built for someone else.
The Room Where It Happens
Standards bodies aren’t some meritocratic ideal. They’re arenas where competing economic interests hash out technical specs that will, in turn, reshape markets. The IETF likes to talk about rough consensus and running code, but look at who actually shows up. Participation leans heavily toward engineers from big equipment vendors, content delivery networks, and hyperscale cloud providers. A 2021 Internet Society study found that over 60% of IETF participants came from just 20 organizations—mostly large corporations. That’s not a conspiracy; it’s a simple matter of who can afford to send engineers to three meetings a year and pay them to write drafts in between.
The result is a set of standards that mirror the operational realities of the people in the room. Take Multipath TCP (MPTCP). It was built with assumptions about middlebox behavior that made perfect sense for large content providers but created real deployment headaches for smaller network operators. The standard wasn’t malicious. It was just written by folks whose primary experience of the network was from the data center outward, not from the last mile inward.
Case Study: The QUIC Working Group
QUIC, the transport protocol that underpins HTTP/3, often gets held up as a triumph of internet engineering. And it does some clever things: it cuts latency, improves multiplexing, and encrypts transport-layer metadata that TCP left hanging out in the open. But the working group that produced it was dominated by Google employees in its early, formative years. Google had already rolled out its own version of QUIC across its services and Chrome before the IETF process even kicked off. The standard that emerged wasn’t a clean-slate design; it was a negotiation between Google’s existing implementation and the concerns of other large players—middlebox vendors and mobile network operators, mostly.
This isn’t a knock on the engineers involved. Plenty of them worked hard to accommodate different viewpoints. But the starting point matters. When a single organization deploys a protocol at scale before standardization, the standard becomes a process of ratifying—with some modifications—what that organization already built. The operational complexity of running a global anycast network gets plenty of attention. The operational complexity of managing a rural ISP with a pile of legacy CPE? Not so much.
Who Pays for the Defaults?
Protocol defaults aren’t just technical knobs; they’re economic levers. Consider the evolution of DNS. The original design assumed a hierarchical, fairly static namespace managed by a small set of trusted operators. As DNS became a vector for censorship, surveillance, and commercial data collection, new standards popped up: DNS over HTTPS (DoH), DNS over TLS (DoT), DNS over QUIC (DoQ). Each one tackled real privacy problems. But each one also shifted control over DNS resolution toward the application layer and, in practice, toward a handful of resolvers run by Google, Cloudflare, and a few others.
For a network operator running a local resolver to serve a community or enterprise, DoH can be a real pain. It bypasses local policy, makes troubleshooting a nightmare, and centralizes visibility into user behavior. The privacy benefits are genuine, but so is the power shift. The standard was written mostly by people who saw ISPs as adversaries, not as infrastructure partners. The result is a protocol that treats network-level DNS as a problem to route around, not a function to improve.
The Middlebox Conundrum
Middleboxes—firewalls, NATs, load balancers, deep packet inspection devices—often get cast as the villains of internet innovation. The IETF’s historical stance, laid out in RFC 1958, was that “the network is a simple, dumb, minimal packet transport.” Middleboxes spit in the face of that principle. But they exist because network operators have legitimate needs: security, address conservation, traffic management, regulatory compliance. When standards are written by those who control endpoints, middlebox concerns get treated as obstacles to engineer around, not as requirements to meet.
This sets up a vicious cycle. A new protocol ignores middleboxes. Middleboxes break the protocol. The protocol adds workarounds to evade middleboxes. Middlebox vendors adapt. The result is a more complex, more brittle network where only the biggest players can afford to keep up. The standard, by refusing to engage with the operational reality of middleboxes, ends up reinforcing the dominance of those who can deploy end-to-end solutions at scale.
The Governance Gap
Standards bodies have governance structures, but they weren’t designed to balance power. The IETF runs on open participation and rough consensus, which sounds democratic but in practice favors those with the time, expertise, and travel budgets to show up. The W3C has a more formal membership model, with fees ranging from $2,250 to $77,000 a year depending on organization size and location. The 3GPP is a consortium of national standards organizations, where influence is mediated by membership tiers and the ability to contribute to multiple working groups at once.
None of these models is inherently illegitimate. But they all produce standards that embed the priorities of their most active participants. When a standard gets praised for its technical elegance, it’s fair to ask: elegant for whom? A protocol that shaves milliseconds off a streaming video platform might add jitter to a VoIP call. A security mechanism that shields user data from passive surveillance might make it harder for a network operator to spot a DDoS attack. These aren’t bugs; they’re features, chosen by the people who wrote the spec.
The Transparency Problem
One of the stickiest challenges in standards governance is the lack of transparency around participation and influence. Meeting minutes often get published, but they rarely capture the informal conversations, the hallway huddles, or the design decisions made in corporate labs before a draft ever sees the light of day. The IETF’s “Note Well” reminds participants of their responsibilities, but it doesn’t require disclosure of commercial interests. An engineer from a large CDN can push for a protocol change without ever spelling out how it benefits their employer’s market position.
This isn’t a call for conspiracy theories. Most standards participants are acting in good faith, trying to solve real technical problems. But their definition of the problem is shaped by their employer’s architecture, customer base, and business model. When those perspectives dominate a working group, the resulting standard reflects a particular view of the internet—one where the network core is dumb, the edge is smart, and the user is a consumer of services rather than a peer on the network.
What Gets Left Out
When standards are written by a narrow set of participants, certain use cases get systematically short shrift. Community networks, municipal broadband, research and education networks, and operators in the Global South often lack the resources to participate in standards bodies. Their requirements—affordable backhaul, resilience under constrained power, operation by non-specialist staff—rarely show up in protocol design discussions.
The result is a stack of protocols that assumes always-on connectivity, abundant bandwidth, and a clean split between producers and consumers of content. For a community network in rural India that uses Wi-Fi long-range links and solar-powered relays, those assumptions don’t hold. The network is intermittently connected, bandwidth is scarce, and every node is both a producer and a consumer. Standards written for data centers and CDNs don’t serve these networks well, but they become the default because no alternative is standardized.
The Cost of Ossification
Protocol ossification—the tendency of deployed protocols to become resistant to change—often gets blamed on middleboxes. But ossification is also a product of who writes the standards. When a protocol is designed by a small group of large players, it tends to be optimized for their use cases. Once deployed, it becomes difficult to change because the installed base is enormous and the costs of change fall disproportionately on smaller operators. The large players who drove the original design can adapt; everyone else is stuck with the consequences.
This dynamic is visible in the slow adoption of IPv6. The standard was written by a relatively broad community, but the transition mechanisms were shaped by the operational realities of large ISPs and content providers. Smaller operators, who couldn’t afford dual-stack deployments or carrier-grade NAT, were left with few good options. The standard wasn’t malicious, but it was written by people who could afford the transition costs and who assumed others could too.
What Would Better Look Like?
Improving the representativeness of standards processes isn’t straightforward. Simply adding more participants from underrepresented groups doesn’t guarantee better outcomes if the process itself is structured around the needs of incumbents. Some proposals include funding travel and time for participants from smaller organizations, requiring disclosure of commercial interests in draft submissions, and creating formal mechanisms for incorporating operational feedback from diverse network environments.
There are precedents. The Internet Research Task Force (IRTF) has a more exploratory mandate and has produced work on congestion control and routing that considers a wider range of network conditions. The Global Network Initiative has brought together companies, civil society, and academics to address human rights issues in network operations. These models aren’t perfect, but they suggest that broadening participation and making assumptions explicit can lead to more resilient outcomes.
Another approach is to treat standards not as finished products but as hypotheses about how a network should operate, subject to empirical testing in diverse environments. This would require standards bodies to invest in measurement, to collect data on how protocols perform in different network conditions, and to revise standards based on that evidence. It would also require a cultural shift away from celebrating a standard’s adoption as an unqualified success and toward asking who benefited, who was burdened, and what alternatives were foreclosed.
FAQ
Why does it matter who writes internet standards?
Standards define the default behaviors of the internet. They determine how traffic is routed, how congestion is managed, how security is implemented, and how new services can be deployed. When a small set of organizations dominates the standards process, the resulting protocols reflect their operational priorities and economic interests. This can create barriers for smaller network operators, limit user choice, and embed power asymmetries into the infrastructure itself.
Are open standards processes like the IETF’s truly open?
The IETF is open in the sense that anyone can join mailing lists, attend meetings, and submit drafts. But effective participation requires significant time, expertise, and travel funding, which favors employees of large organizations. The IETF’s culture of rough consensus also means that objections can be overridden if a sufficient majority agrees, which can marginalize minority viewpoints. Openness does not guarantee representativeness.
How can network operators influence standards that affect them?
Network operators can participate directly in standards bodies, though this requires resources. They can also contribute to operator-focused groups like NANOG, RIPE, or the IETF’s own Operations and Management Area, which provide feedback on protocol deployability. Engaging early in the standards process, before implementations are widely deployed, is critical. Once a protocol is baked into hardware or software, changing it becomes exponentially harder.
What is an example of a standard that failed to account for operational diversity?
The initial deployment of DNS over HTTPS (DoH) is a clear example. It was designed to protect user privacy from on-path observers, but it centralized DNS resolution among a few large providers and broke local network management practices. Subsequent revisions have added mechanisms for discovery and opt-out, but the initial design reflected the priorities of application developers and content platforms, not network operators or enterprise administrators.
Standards are not neutral. They are the residue of power struggles, compromises, and unexamined assumptions. The next time a new protocol is announced with fanfare, the useful question is not just “What does it do?” but “Who wrote it, what did they optimize for, and who pays for the defaults?”