When the HTTP/2 spec finally landed as RFC 7540 in May 2015, it had been nearly sixteen years since HTTP/1.1. The working group burned over three years arguing about header compression alone. From the outside, that looks like institutional paralysis. If you’ve ever operated a network or kept a service alive at scale, though, that timeline signals something rarer: a standard that actually accounted for who holds power—endpoints, intermediaries, operators. The web standards that stick, that don’t fracture the network, that don’t quietly hand the keys to a single vendor, are almost always the ones that took the longest to agree on. Speed in standards-making correlates with concentrated power. Deliberation correlates with distributed resilience.
This piece walks through three protocol efforts that make the relationship between development pace and power distribution painfully clear: HTTP/2, DNSSEC, and IPv6. Each took well over a decade from initial draft to meaningful deployment. Each got shaped by operational friction, competing economic interests, and the thankless work of preventing unilateral control. Understanding why they took so long matters for anyone who relies on internet infrastructure—which is to say, everyone—but especially for operators, platform architects, and policy-minded engineers who recognize that protocol design is governance by other means.
The Hidden Cost of Fast Standards: How Speed Concentrates Control
Standards that move quickly tend to do so because the design space is narrow and the number of stakeholders is small. That’s not automatically bad—it’s how QUIC got started inside Google before it was brought to the IETF. But when a protocol ships fast and grabs adoption before broader review, the entity that drove the design owns the implementation landscape. Others can implement, but they’re playing catch-up on a field where the first mover has already set the defaults, optimized its own infrastructure, and built a user base that treats the protocol as synonymous with the company’s product.
Look at SPDY, the precursor to HTTP/2. Google built SPDY to solve real performance problems—head-of-line blocking in HTTP/1.1 was making the web slower, and Google’s business depends on a fast web. SPDY was deployed in Chrome and on Google’s servers years before HTTP/2 was standardized. By the time the IETF HTTP Working Group started its work, SPDY was the de facto baseline. The working group didn’t start from scratch; it started from Google’s design, with Google’s implementation experience, and with the quiet understanding that rejecting SPDY entirely would mean fighting Chrome’s market share. The resulting HTTP/2 standard is better for having been debated, but the power asymmetry was baked in from the start. The longer deliberation inside the IETF—especially around header compression, where the working group replaced SPDY’s deflate-based approach with HPACK after demonstrating security vulnerabilities—is what stopped a single vendor’s optimization choices from becoming the internet’s permanent overhead.
What “Slow” Actually Means in Standards Bodies
When engineers complain that the IETF or W3C is “slow,” they’re usually pointing at the gap between having a problem and getting a published RFC. But that gap isn’t empty. It’s filled with interoperability testing, security reviews, and the messy process of discovering that your elegant solution breaks when deployed across networks with different economic incentives. The DNS Security Extensions (DNSSEC) specification took over a decade from initial drafts to deployment not because the cryptography was hard—it wasn’t—but because every design choice had implications for who controls the trust hierarchy. Should the root zone be signed? Who holds the root key? What happens to national ccTLDs that don’t want to participate? These aren’t technical questions you can resolve with a faster hash function. They’re governance questions disguised as protocol parameters.
DNSSEC’s slow path meant that by the time it was deployable, the operational community had a clear understanding of the tradeoffs. Zone operators knew the signing overhead. Resolver operators understood the amplification risks. The root signing ceremony became a public, auditable process rather than a unilateral decision by a single authority. The delay wasn’t a bug; it was the feature that prevented DNSSEC from becoming a mechanism for centralized control of the domain name system.
IPv6: The Thirty-Year Negotiation Over Addressing Power
No protocol illustrates the relationship between development speed and power distribution better than IPv6. The IETF recognized address exhaustion in the early 1990s. The first IPv6 specification was published in 1995. Meaningful deployment didn’t begin until the 2010s, and global adoption only crossed 40% in 2023. This gets described as a failure, routinely. It’s more accurately a thirty-year negotiation over who gets to assign addresses, how routing tables are structured, and whether the internet’s core architecture would remain distributed or consolidate around a few large providers.
The slow transition preserved a critical property: anyone can still get provider-independent address space and route it on the global internet without permission from an incumbent. If IPv6 had been rushed—if the IETF had prioritized deployment speed over architectural integrity—the result would likely have been an internet where only large carriers and content networks could obtain routable addresses. Small operators, enterprises, and new entrants would be forced behind carrier-grade NAT, dependent on the very incumbents the protocol was supposed to circumvent. The delay was the cost of maintaining the internet’s distributed routing architecture.
Network operators who lived through this period understand the tradeoff viscerally. They dealt with dual-stack complexity, with broken IPv6 implementations in consumer equipment, with the operational burden of maintaining two address families. Many still question whether the transition was worth it. But the alternative—a rushed adoption of a protocol that concentrated addressing power—would have fundamentally changed who can participate in internet infrastructure. The slow transition preserved the possibility of a distributed network, even if it didn’t guarantee one.
The NAT Question: A Deliberate Non-Solution
Network Address Translation became the de facto workaround for IPv4 exhaustion, and it’s worth examining why the IETF didn’t simply standardize a more scalable NAT architecture instead of pursuing IPv6. The answer reveals the governance philosophy embedded in protocol design. NAT creates asymmetry: hosts behind a NAT can initiate connections outward, but external hosts cannot easily initiate connections inward. This asymmetry favors large content providers who can afford to maintain publicly reachable endpoints. It disadvantages peer-to-peer applications, self-hosted services, and any architecture that treats endpoints as equals.
The IETF’s refusal to embrace NAT as a permanent solution was a deliberate choice to preserve the end-to-end principle—the idea that the network should not discriminate between endpoints. This wasn’t a technical decision so much as a value judgment about what kind of network the internet should be. A fast, pragmatic solution would have optimized for content delivery and accepted a permanent client-server hierarchy. The slow, principled path preserved the possibility of a more distributed architecture, even if market forces have since pushed much of the internet toward centralization anyway.
WebRTC: When Speed Creates Fragmentation
Not all slow standards succeed, and not all fast standards fail. But WebRTC offers a cautionary example of what happens when standardization can’t keep pace with deployment. Google released WebRTC as an open-source project in 2011, and browsers shipped implementations before the IETF and W3C had finished the specifications. The result was a real-time communications framework that worked brilliantly within Chrome but created interoperability nightmares across browsers, codecs, and signaling protocols.
The codec dispute alone consumed years. Google pushed VP8 (and later VP9) as mandatory-to-implement, while others insisted on H.264. The IETF eventually settled on both as mandatory, which satisfied no one and increased implementation complexity. Meanwhile, the signaling layer was left deliberately unspecified—an unusual choice for a communications protocol—because the working group couldn’t reach consensus. This meant that every WebRTC application had to build its own signaling, fragmenting the ecosystem and making cross-service interoperability effectively impossible. The standard shipped fast, but the parts that would have enabled a truly open, interoperable real-time web were the parts that needed the most negotiation—and those were precisely the parts that got deferred or abandoned.
The Governance Layer Hidden in Plain Sight
What distinguishes a standard that successfully distributes power from one that concentrates it isn’t the technical elegance of the solution. It’s the process by which the standard was developed. Standards that emerge from a single organization and are later brought to a standards body for ratification tend to encode that organization’s assumptions and economic interests. Standards that are developed in the open, with participation from multiple stakeholders who have conflicting incentives, tend to produce more balanced outcomes—but they take much longer.
The IETF’s culture of “rough consensus and running code” is often misunderstood. The “running code” part doesn’t mean shipping first and standardizing later. It means that proposals should be backed by implementation experience to prove they work, but the consensus process still requires working through objections from operators, competing vendors, and other affected parties. This is slow by design. When a working group skips the consensus part and just ships—as happened with aspects of WebRTC—the result is a standard that works for the dominant implementer but creates friction for everyone else.
DNS-over-HTTPS: A Case Study in Process Failure
DNS-over-HTTPS (DoH) represents a recent example where the standardization process moved relatively quickly but the governance implications were not adequately addressed. DoH encrypts DNS queries inside HTTPS connections, which improves privacy by preventing on-path observers from seeing which domains a user is resolving. But it also shifts DNS resolution from the operating system—where it can be managed by network administrators, enterprise security policies, and parental controls—to the browser, where it defaults to a small set of public resolvers operated by companies like Cloudflare and Google.
The technical specification was sound. The governance model was not. By the time network operators and enterprise administrators understood the implications, browsers had already shipped DoH enabled by default. The IETF working group had focused on the protocol mechanics—message format, transport, security properties—but had not adequately addressed the operational and policy questions: Who controls the resolver? What happens to split-horizon DNS? How do enterprise security controls interact with browser-enforced resolution? These questions were left to implementation decisions, which meant they were effectively decided by the browser vendors. The standard was fast. The power concentration was predictable.
What Slow Standards Actually Protect
When a protocol takes years to standardize, it’s usually because the working group is wrestling with questions that aren’t purely technical. These questions include: Who bears the operational cost of deployment? Who controls the trust anchors? What happens to existing infrastructure? Can a new entrant implement the standard without permission from incumbents? Does the protocol create new gatekeepers or eliminate existing ones?
The Border Gateway Protocol (BGP) has been extended and refined over decades, and it remains the routing protocol of the internet not because it’s elegant—it isn’t—but because its slow evolution has preserved the distributed control that defines internet routing. Every autonomous system can set its own routing policies. No single entity controls the routing table. Attempts to replace BGP with something cleaner and more centralized have repeatedly failed, not because the engineering was bad, but because operators recognized that a clean-slate routing protocol would inevitably concentrate control in the hands of whoever designed and deployed it first.
This is the pattern that repeats across successful internet standards: the ones that preserve distributed control are the ones that took long enough for the power dynamics to become visible and contestable. The ones that concentrated power—whether intentionally or not—tended to move faster, because fewer stakeholders had to agree.
What Operators Should Watch For
For those who run networks, build on platforms, or make procurement decisions that depend on protocol stability, there are practical signals that a standard is likely to distribute power rather than concentrate it:
Multi-vendor implementation before ratification. If only one organization has working code when the standard is published, that organization owns the deployment timeline and the de facto interpretation of ambiguous parts of the spec. HTTP/2 had multiple implementations before RFC publication. WebRTC did not.
Operational community engagement. Standards that are developed primarily by protocol designers without sustained input from the people who will operate them tend to create operational surprises. The IETF’s DNSOP working group exists precisely to catch these issues, but it can only do so if given time.
Explicit discussion of incentives. A standard that doesn’t acknowledge who benefits from its adoption and who bears the costs is hiding something. The best working group discussions surface these tensions explicitly rather than pretending they don’t exist.
Deployability analysis. The IETF requires a “deployability considerations” section in many working group documents, but the quality varies enormously. A substantive analysis that addresses migration paths, backward compatibility, and operational impact is a sign that the working group took governance seriously.
What This Means for the Next Generation of Standards
The internet’s protocol stack is not static. New proposals emerge regularly: MASQUE for proxying, OHTTP for oblivious HTTP, various privacy-enhancing extensions to DNS and TLS. Each of these will either distribute power or concentrate it, and the speed of standardization is a leading indicator of which outcome to expect.
This doesn’t mean that all slow standards are good or that all fast standards are bad. It means that speed is a signal worth paying attention to. When a standard moves from proposal to deployment in under two years, ask who benefits from that speed. When a standard takes a decade, ask what power struggles were being negotiated during that time. The answers will tell you more about the future of the internet than any technical analysis of the protocol itself.
The next time someone complains that the IETF is too slow, consider what they’re really saying. They’re saying that the process of negotiating power among network operators, platform providers, and end users should be faster. But power negotiations that happen too quickly tend to produce winners and losers, not equilibria. The internet’s distributed architecture is an accident of history and a product of deliberate, painstaking, often maddeningly slow consensus-building. Preserving it requires the same.
Frequently Asked Questions
Why do some web standards take so long to finalize?
Long standardization timelines typically reflect the complexity of negotiating competing interests among network operators, browser vendors, content providers, and end users. When a standard affects who controls infrastructure, who bears operational costs, or who can participate in the network, the working group must resolve these governance questions before publishing. The technical specification is often the easy part; the power dynamics are what consume years of debate.
Does a slow standardization process guarantee a better outcome?
No. Some standards take a long time because of deadlock, not deliberation. The key distinction is whether the delay is spent resolving substantive disagreements about power and control, or whether it’s procedural obstruction. Standards that emerge from genuine multi-stakeholder negotiation tend to be more resilient, but speed alone is not a guarantee of quality—it’s a signal that warrants closer examination of the process.
How can network operators influence protocol development?
Operators can participate directly in IETF working groups, either by attending meetings or contributing to mailing lists. More practically, they can join operator-focused groups like NANOG or RIPE that provide feedback to standards bodies. The most effective influence comes from sharing operational experience—what breaks in real deployments, what creates management burden, what shifts control away from operators—rather than advocating for specific technical solutions.
What should I look for when evaluating a new protocol standard?
Examine who implemented it first, who controls the default configuration, whether migration from existing protocols is addressed, and whether the standard creates new dependencies on specific organizations. A standard that can be implemented independently by multiple parties without permission from a central authority is more likely to distribute power than one that requires coordination through a single provider or platform.