In the early 1990s, a small knot of engineers sat in a forgettable conference room, arguing about email. The question on the table sounded almost trivial: should the protocol allow attachments? The Multipurpose Internet Mail Extensions (MIME) specification, which eventually let us send images, audio, and formatted text, took more than five years to lock down. That wasn’t because the problem was technically unsolvable. The delay was the point. The Internet Engineering Task Force (IETF) and its peers have long grasped that the protocols running the internet’s plumbing—routing, addressing, transport—are not neutral engineering artifacts. They are governance instruments. Every header field, every default setting, every extension point encodes a decision about who gets to control what. When a standard is rushed, the distribution of power it hard-codes tends to favor whoever shouted loudest in the room, and that is rarely the most representative voice. The standards that took forever to agree on, by contrast, often became the bedrock precisely because they survived a gauntlet of objections from operators, implementers, and users who knew that technical choices are political choices by another name.
The Hidden Governance of Consensus Timelines
When people talk about internet governance, they usually point to institutions like ICANN or the ITU. But the real action often happens earlier, in the IETF’s working groups, where a protocol’s defaults are fought over line by line. The length of those fights isn’t a sign of bureaucratic bloat; it’s a sign that the participants understand what’s at stake. A protocol that takes years to finalize—think BGP, DNS, or TCP itself—has been hammered against the objections of incumbent network operators, equipment vendors, and the end users who will never read the RFC but will live with its consequences for decades.
Consider IPv6. The address exhaustion problem was obvious by the early 1990s. A naive observer might have expected a quick technical fix. Instead, the standardization dragged on for years, tangled in competing proposals, bitter arguments over header formats, and a transition mechanism debate that still isn’t fully settled. The delay frustrated early adopters, but it also prevented a rushed design that might have baked in even deeper asymmetries. The final protocol, with its vast address space and simplified header, reflects a balance between the largest transit providers and the smallest edge networks. That balance took time to find.
MIME and the Attachment Wars
MIME’s story is worth retelling because it was never just about attachments. It was about who gets to define what a message is. Before MIME, email was plain ASCII text. That limitation wasn’t an accident; it was a control point. It kept email simple enough that anyone could write a client, but it also kept email impoverished. When the push for rich content arrived, it threatened to splinter the ecosystem into proprietary silos—Lotus Notes, Microsoft Mail, and others each had their own scheme. The IETF’s multi-year slog produced a standard that preserved interoperability while opening the door to rich content. The linchpin was the content-type header, a tiny piece of metadata that let senders declare what they were sending and receivers decide how to handle it. That header is a governance tool. It shifts power to recipients, letting them reject or render content according to their own policies, not the sender’s. It took years to get right because every constituency had to be convinced the balance was tolerable.
DNSSEC: A Cautionary Tale of Urgency
If MIME is a success story, DNSSEC is a cautionary tale about what happens when urgency drives the timeline instead of consensus. The Domain Name System Security Extensions were supposed to add cryptographic authentication to DNS responses, blocking cache poisoning attacks. The need was genuine, and the initial specs came together fairly quickly in the late 1990s. But the operational community pushed back hard. DNSSEC demanded changes to the DNS delegation model that many registrars and TLD operators found onerous. The split between key-signing keys and zone-signing keys, meant to simplify key rollover, instead created an operational tangle that few were ready to manage. Deployment stalled for more than a decade. The standard was technically sound but politically tone-deaf. It didn’t account for the incentives of the people who would have to implement it. The lesson isn’t that DNSSEC was a bad idea. It’s that the standard’s relatively quick development—compared to, say, BGP—skipped the slow, bruising negotiation phase that might have produced a more deployable design. The IETF later had to retrofit operational guidance through RFCs like 6781, essentially doing the consensus work after the fact.
BGP: The Protocol That Refuses to Be Replaced
The Border Gateway Protocol is the internet’s routing backbone, and it’s also a monument to the virtues of slow evolution. BGP-4 was standardized in 1994, but its roots stretch back to the late 1980s, and its development was marked by fierce debate between the operators of large transit networks and the growing number of multihomed stub networks. The result was a path-vector protocol that gives each autonomous system significant autonomy over its own routing policies. That autonomy is both a strength and a weakness. It enables the internet’s decentralized structure, but it also enables route leaks and hijacks. Numerous attempts to replace BGP with something more secure have failed, not because the alternatives were technically inferior, but because they couldn’t replicate the political settlement that BGP represents. Network operators are loath to cede the policy control that BGP gives them. Any replacement would have to navigate the same power dynamics that BGP’s original designers spent years negotiating. The slow pace of BGP’s initial development embedded a set of power relationships that have proven remarkably sticky.
HTTP/2 and the Speed Trap
Not all slow standards succeed, and not all fast ones fail. But the HTTP/2 process offers a useful contrast. The IETF’s HTTP Working Group began work on HTTP/2 in 2012, using Google’s SPDY protocol as a starting point. The standardization took about three years, which is relatively fast by IETF standards. The result was a protocol that significantly improved web performance, but it also deepened the web’s dependence on encryption and centralized infrastructure. HTTP/2’s multiplexing features work best when all resources come from a single origin, which incentivizes the use of content delivery networks and reverse proxies. The protocol’s design choices, made under pressure to improve speed, had the side effect of consolidating control over web traffic into fewer hands. The subsequent development of HTTP/3 and QUIC has only accelerated this trend, moving more of the transport layer into user-space and under the control of large platform operators. The speed of standardization, driven by the urgency of performance improvements, may have come at the cost of a more distributed architecture.
The Political Economy of Consensus
Why do some standards take so long? The answer lies in the IETF’s own mantra: “rough consensus and running code.” The “rough consensus” part is often misunderstood. It doesn’t mean a simple majority vote. It means the working group has addressed all serious objections and the remaining dissent isn’t strong enough to derail the process. That’s a high bar, and it gives significant power to anyone who can articulate a well-reasoned objection. In practice, this means large network operators, equipment vendors, and platform providers can slow down a standard that threatens their interests. But it also means smaller players, if they’re persistent and technically credible, can force changes that protect their position. The process is adversarial by design, and the timeline is a function of how deeply the standard cuts into existing power structures.
This isn’t a flaw. It’s a recognition that internet protocols are not neutral. They allocate costs and benefits, they create gatekeepers, and they determine who can innovate without permission. A standard agreed upon too quickly is likely to have overlooked some of these distributional effects. The IETF’s culture of “humming” rather than voting, its insistence on multiple interoperable implementations before advancement, and its tradition of marathon working group sessions are all mechanisms for surfacing hidden power dynamics. They slow things down, but they also make the final product more legitimate.
When Speed Wins and Quality Loses
There are counterexamples, of course. The WebRTC standard, which enables real-time communication in browsers, was developed relatively quickly and has been widely adopted. But WebRTC benefited from a clear, limited scope and a pre-existing consensus among browser vendors about the need for open real-time communication. More often, rushed standards create problems that take years to fix. The early versions of the Simple Network Management Protocol (SNMP) were designed and deployed rapidly, but their security model was so weak that they became a persistent vulnerability for network infrastructure. The fix, SNMPv3, took over a decade to gain traction, and even today, many devices ship with SNMPv1 or v2c enabled by default. The initial speed of standardization created a legacy of insecurity that the industry is still paying for.
What This Means for Infrastructure Governance
The relationship between standardization timelines and power distribution has practical implications for anyone involved in network operations or internet policy. First, it suggests that patience is not just a virtue but a strategic necessity. When a new protocol is proposed, the instinct to push for rapid adoption should be tempered by a careful analysis of who benefits from the default settings. Second, it highlights the importance of participation. The IETF is open to anyone, but effective participation requires technical expertise and sustained engagement. Organizations that fail to invest in the standards process cede influence to those that do. Third, it underscores the need for post-standardization monitoring. Even well-designed protocols can be implemented in ways that undermine their original intent, and the real-world effects of a standard often become visible only after deployment.
FAQ
Why do some internet standards take so long to finalize?
The IETF’s consensus process requires addressing serious objections from all participants, not just a majority. This means that standards affecting power dynamics—like routing, addressing, or content handling—often face prolonged debate as different stakeholders negotiate the distribution of control. The resulting timeline reflects the complexity of balancing competing interests rather than technical difficulty alone.
Does a longer standardization process always produce a better protocol?
Not necessarily. Some protocols, like early versions of SNMP, were standardized quickly and later required significant fixes. However, for core infrastructure protocols where the stakes are high—such as BGP or MIME—the extended timeline allowed for thorough stress-testing against operational realities and diverse stakeholder requirements, leading to more resilient and widely adopted standards.
How can network operators influence the standards process?
Network operators can participate directly in IETF working groups, submit Internet-Drafts, and provide feedback during last-call reviews. The most effective influence comes from sustained engagement, operational experience, and technically sound arguments. Even small operators can shape outcomes if they identify specific harms or deployment challenges that a proposed standard would create.
What are the risks of standards developed outside traditional bodies?
Proprietary protocols or those developed in closed industry consortia often lack the broad legitimacy and interoperability focus of IETF standards. They may embed control points that favor specific vendors or platforms, and they typically do not undergo the same rigorous, multi-stakeholder review. The result can be fragmentation, vendor lock-in, and reduced long-term flexibility for network operators and end users.
The next time you hear complaints about the IETF’s glacial pace, consider what’s actually happening in those working groups. The delays aren’t just about bikeshedding or perfectionism. They’re a form of governance, a way of ensuring that the protocols that underpin the internet don’t quietly encode the interests of the powerful at the expense of everyone else. The best standards are the ones that took so long to agree on that everyone forgot there was ever an alternative.