In the early 1990s, a handful of engineers sat in a room and argued about how email should work. They emerged, years later, with a set of protocols that still route the majority of the world’s electronic mail. The process wasn’t fast. It wasn’t pretty. It was, by most accounts, a grinding, multi-year brawl over headers, encodings, and the exact semantics of a bounce message. Yet the result—the Simple Mail Transfer Protocol and its Multipurpose Internet Mail Extensions—has outlasted countless faster, sleeker alternatives. The lesson, one the industry keeps forgetting in its rush to ship, is that the standards which survive are usually the ones that took the longest to fight over.
This isn’t a fluke. It’s baked into how internet infrastructure gets built. When a protocol takes years to lock down, it means the working group has wrestled with edge cases, clashing business models, and the quiet resistance of operators who will simply refuse to deploy something that breaks their existing setups. The final document isn’t just a technical spec; it’s a record of a negotiated settlement between network operators, platform providers, and end-user advocates. The time spent is a rough proxy for the breadth of input and the depth of operational scars considered.
The IETF’s Rough Consensus and the Price of Haste
The Internet Engineering Task Force, the main body for internet protocol standards, runs on the principle of “rough consensus and running code.” The running code part is the kicker: no standard moves forward without at least two independent, interoperable implementations. That requirement alone can tack years onto a process, as implementers discover that what looked clean on a whiteboard crumbles when it hits real network topologies and legacy middleboxes.
Take HTTP/2. The push started in earnest around 2012, building on Google’s SPDY experiment, and the final RFC landed in 2015. Three years might sound quick, but SPDY had been deployed and beaten up since 2009. The working group burned much of its time not on the core multiplexing features, but on hashing out the header compression algorithm—a seemingly dull detail that had deep privacy implications, as later shown by HPACK’s resistance to the CRIME attack. The delay wasn’t bureaucratic sludge; it was the group’s insistence on a design that wouldn’t leak session cookies across compression contexts. That kind of foresight only happens when you give security researchers and protocol designers enough rope to break things.
Compare that to the rush to standardize WebRTC’s early versions. The initial excitement for real-time communication in browsers spawned a mess of draft implementations, but the lack of a finished signaling protocol meant different browser vendors built incompatible session description formats. For years, developers had to maintain separate code paths for Chrome and Firefox, gutting the very interoperability the standard was supposed to provide. The eventual stabilization of the WebRTC spec, capped by the 1.0 release in 2018, was a painful but necessary correction. The takeaway: a standard that ships too early isn’t a standard; it’s a proprietary API with a thin coat of openness.
When Infrastructure Standards Become Economic Battlefields
The slowest standards processes are rarely about technical elegance. They’re about who foots the bill for the infrastructure, who controls the data, and who gets to extract rent. The decade-long slugfest over email authentication—spanning SPF, DKIM, and DMARC—wasn’t a debate about cryptographic algorithms. It was a struggle between large senders who wanted to protect their brand domains, mailbox providers who wanted to cut spam, and mailing list operators who saw their forwarding models shattered by strict SPF policies. Each draft reflected a different power balance, and the final DMARC specification, published in 2015, was less a technical victory than a political armistice.
This pattern repeats up and down the stack. The Multiprotocol Label Switching architecture took nearly a decade to standardize because it threatened the business models of traditional IP routing vendors. The Border Gateway Protocol’s security extensions, RPKI and BGPsec, have been in the works for over fifteen years and still aren’t universally deployed, largely because they require network operators to hand routing autonomy to centralized trust anchors—a trade-off many operators find unacceptable. In each case, the delay isn’t a sign of failure but of genuine, unresolved conflict between stakeholders with legitimate, competing interests.
DNS over HTTPS: A Case Study in Fractured Trust
Maybe no recent protocol debate lays the stakes barer than DNS over HTTPS. What started as a privacy enhancement—encrypting DNS queries to block surveillance and manipulation—quickly blew up into a governance crisis. Traditional DNS operators, including plenty of ISPs and enterprise network admins, saw DoH as a threat to their ability to filter malicious domains and enforce acceptable-use policies. Mozilla’s decision to turn on DoH by default in Firefox, routing queries to Cloudflare, was read as a unilateral restructuring of the internet’s name resolution hierarchy.
The IETF’s DNS over HTTPS working group spent years chewing over the implications, producing RFC 8484 in 2018. But the standard itself didn’t settle the governance questions. It just specified the protocol; the decisions about which resolvers to trust and how to discover them were left to application developers and operating system vendors. The result is a fractured landscape where different browsers and devices make different choices, and where enterprise network operators are still scrambling to adapt. The standard was published relatively fast by IETF clocks—about two years—but the real negotiation is ongoing and will probably drag on for another decade.
The Hidden Costs of Expedited Standards
When standards are rushed, the costs rarely land on the authors. They land on network operators who have to build workarounds, on end users who get degraded service, and on the wider ecosystem that has to swallow the technical debt. The fast-tracked standardization of the WebSocket protocol in 2011, for instance, led to widespread deployment of a framing mechanism that was incompatible with many existing HTTP intermediaries. Proxy operators had to choose between breaking WebSocket connections or upgrading their infrastructure—a cost that never made it into the standardization calculus.
Similarly, the rapid uptake of the Server Name Indication extension for TLS created a privacy vulnerability that took years to patch. SNI sends the destination hostname in cleartext during the TLS handshake, letting network observers profile user behavior even when the subsequent connection is encrypted. The fix, Encrypted SNI, was proposed almost immediately but didn’t get standardized until 2018 as part of TLS 1.3, and even then, deployment has crawled. The original SNI spec was published in 2003, after a relatively short working group process, and its privacy implications were noted but not prioritized. Two decades later, we’re still cleaning up the mess.
These examples point to a structural problem: standardization bodies are incentivized to produce documents, not to guarantee long-term operational sustainability. The engineers who write the specs are often not the same people who will maintain the networks running them. The IETF’s mantra of “rough consensus and running code” is meant to bridge this gap, but when the running code comes from a single dominant vendor, the consensus can be more rough than genuine.
The QUIC Protocol: A Deliberate Exception
QUIC, the transport protocol that underpins HTTP/3, is a notable counterexample. Developed mainly by Google and deployed at scale before standardization, QUIC could have hardened into a proprietary lock-in mechanism. Instead, the IETF’s QUIC working group spent nearly five years redesigning the protocol to separate the transport layer from the application layer, making sure it could carry traffic beyond just HTTP. The process was contentious, with serious pushback from network operators who feared losing visibility into traffic characteristics. The resulting standard, published as RFC 9000 in 2021, reflects a careful balance: it encrypts more of the transport layer to prevent ossification, but it also provides explicit signals for network management that earlier encrypted protocols lacked.
The QUIC working group’s deliberate pace wasn’t a sign of dysfunction. It was a recognition that a protocol designed to replace TCP—the internet’s most fundamental transport mechanism—couldn’t be rushed. The group actively sought input from network operators, middlebox vendors, and enterprise network administrators, folding their feedback into the design. The result is a standard that, while not perfect, has a much higher chance of universal deployability than a proprietary alternative shoved through a faster process.
What Operators Can Learn from the Slowest Standards
For network operators and infrastructure engineers, the history of protocol standardization offers a few practical lessons. First, sustained, unresolved debate in a working group isn’t a red flag; it’s often a sign that the group is grappling with real operational constraints that a faster process would just steamroll over. When a draft cycles through multiple revisions without reaching consensus, it usually means the problem space is genuinely thorny and that premature standardization would produce a spec that works in the lab but falls flat in the field.
Second, the most durable standards are those that explicitly document their own limitations and trade-offs. The BGP specification, for example, is remarkably blunt about its security weaknesses, and that honesty has let operators develop compensating controls over time. Standards that pretend to solve every problem often create new ones by hiding their assumptions. A good standard tells you not just what to implement, but what to watch out for.
Third, operators should be wary of standards that emerge too quickly from a single vendor’s codebase. The history of internet protocols is littered with “standards” that were really just documentation of a dominant implementation, and that became de facto standards only because the market had no alternative. True interoperability requires a specification that multiple parties can implement independently, and that requires time for review, testing, and disagreement.
The Role of the Network Operator in the Standards Process
One of the quiet dysfunctions of the current standards ecosystem is the underrepresentation of network operators in working groups. The IETF’s membership is dominated by vendors and platform companies, with relatively few participants from the enterprises and service providers who will actually deploy the protocols. This imbalance means that operational considerations are often raised late in the process, after significant design decisions have already been locked in, leading to delays and acrimony.
Operators who want to avoid being blindsided by new standards should consider participating directly in the standards process, or at least monitoring working group mailing lists and providing feedback during last-call reviews. The IETF’s processes are open to anyone, and the barrier to entry isn’t technical expertise but the willingness to read drafts and offer constructive comments. A single well-reasoned message from an operator who has actually deployed a protocol at scale can carry more weight than a dozen messages from vendors with theoretical concerns.
FAQ
Why do some internet standards take so long to finalize?
Long standardization timelines are usually a sign that the protocol involves significant operational or economic trade-offs. Working groups must reconcile the interests of network operators, platform providers, and end users, each of whom may have conflicting requirements. The IETF’s requirement for multiple independent implementations also adds time, as implementers discover and resolve ambiguities in the specification. A standard that takes five years to develop is often more durable than one that takes five months, because the longer process surfaces edge cases and deployment challenges that a rushed process would miss.
How can network operators influence the standards process?
Network operators can participate directly in IETF working groups by joining mailing lists, attending meetings, and submitting comments on draft specifications. Even passive monitoring of working group discussions can provide early warning of protocol changes that will affect operational networks. Operators who cannot commit to full participation can still make an impact by responding to last-call reviews with concrete, experience-based feedback. The IETF values operational input, and a single message describing how a proposed standard would break a real network can significantly influence the outcome.
What are the risks of deploying a protocol before it is fully standardized?
Pre-standard deployments can create de facto standards that are difficult to change, even when flaws are discovered later. Early adopters may find themselves locked into a proprietary implementation that diverges from the eventual standard, requiring costly migrations. Additionally, pre-standard protocols often lack the security review and operational guidance that accompany a finalized specification, exposing deployers to unknown risks. The safest approach is to deploy pre-standard protocols only in controlled environments where the cost of change is low, and to plan for a migration path to the standardized version once it is available.
The Long View
The internet’s most critical infrastructure—the protocols that route packets, resolve names, and deliver email—wasn’t built in a hurry. It was built through a process that valued rough consensus over rapid iteration, and that forced designers to confront the messy reality of a network operated by thousands of independent actors with divergent interests. The standards that emerged from this process aren’t elegant. They’re full of compromises, legacy cruft, and design decisions that make sense only in historical context. But they work, and they’ve worked for decades, because they were forged in the fire of genuine, sustained disagreement.
As the internet enters its next phase of evolution, with encrypted transport protocols, decentralized identity systems, and new network architectures, the temptation to accelerate the standards process will be strong. Platform companies will push for faster adoption of their preferred designs. Policymakers will demand quick solutions to pressing problems. But the lesson of the past four decades is clear: the best standards are the ones that took the longest to agree on, because that time was spent building the trust and understanding necessary for a protocol to survive in the wild. Speed is not the enemy of good standards, but it is rarely their friend.
For the operators and engineers who will deploy these next-generation protocols, the advice is simple. Pay attention to the working group debates. Read the dissenting opinions in the RFCs. And when a standard seems to be taking too long, ask yourself whether the delay is a sign of dysfunction or a sign that the working group is doing its job. More often than not, it is the latter.