Trust does not scale. A system that works fine among three people who share a Slack channel and a coffee machine can fall apart the moment it has to serve three thousand strangers, three network operators with conflicting business models, or three jurisdictions with incompatible legal assumptions. The political economy of internet protocols is, at bottom, a long argument about what to do when participants cannot be trusted. This article looks at the design patterns that make systems function under distrust: explicit threat models, verifiable claims, economic incentives, and failure isolation. It draws on routing security, certificate transparency, distributed consensus, and content moderation infrastructure to show how technical choices distribute power among network operators, end users, and platform providers.

Distrust is not a bug to be eliminated. It is a design input. The systems that survive contact with real-world incentives are usually the ones that assumed someone would cheat, lie, or defect, and built accordingly.

Start with the Threat Model, Not the Architecture

Most failed systems do not fail because their cryptography was weak. They fail because nobody wrote down who was allowed to misbehave and what the consequences would be. A threat model is a list of participants, their capabilities, their incentives, and the specific harms the system must prevent or detect. Without it, security becomes a collection of rituals.

Consider the Border Gateway Protocol (BGP). BGP was designed in an era when network operators were assumed to be competent and mostly honest. The protocol has no built-in mechanism to verify that a route announcement is true. A network can announce a prefix it does not control, and that announcement can propagate globally. The result is route hijacking, traffic interception, and occasional multi-hour outages. The threat model was implicit and optimistic. The operational cost of that optimism has been substantial.

A more useful approach is to ask three questions before writing any code or deploying any service:

• Who can act? Identify every class of participant, including those who are not supposed to exist.
• What can they do that would harm others? Be specific. Vague harms produce vague defenses.
• What evidence would prove harm occurred? If the answer is “none,” the system cannot be audited, and auditing is the only reliable backstop when prevention fails.

This is not a theoretical exercise. The Resource Public Key Infrastructure (RPKI) exists because BGP’s original threat model was too permissive. RPKI lets network operators cryptographically attest that they are authorized to originate specific IP prefixes. It does not make BGP trustworthy. It makes some BGP announcements verifiable, which is a smaller and more achievable goal.

Verification Beats Trust, but Verification Has Costs

The phrase “trust but verify” is popular and mostly useless. Verification is not a supplement to trust; it is a replacement for it. When you verify a claim, you are not trusting the claimant. You are trusting the verification mechanism, which is a different and often smaller target.

Certificate Transparency (CT) is a useful case study. Before CT, a certificate authority could issue a certificate for any domain, and the domain owner might never know. The system relied on the honesty of hundreds of certificate authorities, some of which were compromised or sloppy. CT changed the model by requiring certificates to be logged in public, append-only ledgers. Domain owners can monitor those logs for certificates they did not request. Browsers can require that certificates be logged before they are accepted.

CT did not make certificate authorities trustworthy. It made their actions observable. That is a meaningful distinction. Observability creates accountability, and accountability changes behavior even when it does not change incentives perfectly.

The cost is real. CT logs are large, and running a log requires operational discipline. Monitors must be deployed and maintained. The ecosystem added complexity to reduce reliance on trust. That tradeoff is usually worth it, but it is not free, and pretending otherwise leads to systems that look secure on paper and collapse under operational load.

Incentives Are Part of the Protocol

Technical designers often treat incentives as someone else’s problem. That is a mistake. A protocol that assumes participants will act against their economic interest is a protocol that will be ignored, bypassed, or gamed.

Email authentication provides a clear example. SPF, DKIM, and DMARC are designed to make it harder to forge email from a domain. But adoption has been uneven for years. The reason is not technical complexity alone. The reason is that the costs and benefits are distributed unevenly. A domain that sends no email has little incentive to publish a DMARC policy. A domain that sends email through many third-party services has a strong incentive to avoid a strict policy, because a misconfigured policy can break legitimate mail. The protocol works, but only where the incentives align.

Distributed consensus systems face a sharper version of this problem. Bitcoin’s proof-of-work mechanism is often described as a way to prevent double-spending. It is also a way to make defection expensive. A participant who wants to rewrite history must spend real resources, and the rest of the network can see that expenditure. The system does not assume miners are honest. It assumes that dishonesty is unprofitable under most conditions. That assumption has held, more or less, though the concentration of mining power has introduced new trust assumptions that are rarely discussed as candidly as they should be.

The lesson is not that incentives solve everything. They do not. But a system that ignores incentives is designing for a world that does not exist.

Failure Isolation: Assume Something Will Break

Systems built for distrust must also be built for failure. A single compromised component should not give an attacker control of the whole system. This principle is old, but it is violated constantly.

The Domain Name System (DNS) is a useful example. DNS is hierarchical, which means that a compromise at a high level can affect many domains. DNSSEC was designed to add cryptographic authentication to DNS responses, but it also introduced new failure modes. A misconfigured DNSSEC zone can make a domain unreachable. The system added security but also added a new way to break things. That is not an argument against DNSSEC. It is an argument for designing failure modes as carefully as success modes.

Content delivery networks and platform moderation systems face a different version of this problem. A platform that centralizes moderation decisions creates a single point of failure, both technically and politically. A platform that distributes moderation to communities creates inconsistency and abuse. There is no clean answer, but there are better and worse tradeoffs. The better ones tend to isolate failures so that a bad decision in one community does not become a global policy.

Failure isolation also applies to organizational design. A system that requires a single administrator to hold all the keys is a system that will fail when that administrator is unavailable, compromised, or simply wrong. Multi-party authorization, rotation schedules, and break-glass procedures are not bureaucratic overhead. They are the operational expression of a threat model that includes the system’s own operators.

What This Means for Internet Governance

The governance of internet infrastructure is often discussed as a contest between governments, corporations, and civil society. That framing misses the deeper point: the technical design of protocols already encodes governance decisions. Who can verify a route? Who can revoke a certificate? Who can update a root zone? These are not neutral engineering questions. They are decisions about power.

When a protocol assumes trust, it concentrates power in the hands of those who are trusted. When a protocol requires verification, it distributes power to those who can perform or request verification. When a protocol aligns incentives, it shapes behavior without requiring anyone to be virtuous. These are political choices, made by people who often do not think of themselves as political actors.

The internet has survived as long as it has partly because many of its core protocols were designed with a healthy pessimism about human behavior. That pessimism is worth preserving. It is not cynicism. It is the recognition that systems which depend on universal good behavior are systems that will eventually be exploited by someone who does not share the designer’s assumptions.

Practical Takeaways for System Designers

If you are building a system that must work across organizational boundaries, start with these steps:

• Write the threat model in plain language. If you cannot explain who is allowed to misbehave and what happens when they do, you do not have a threat model.
• Prefer verifiable claims over trusted assertions. Every time you accept a claim without evidence, document why verification was not possible or not worth the cost.
• Map the incentives. For each participant, ask what they gain by following the rules and what they gain by breaking them. If the second number is larger, expect the rules to be broken.
• Design for partial failure. Assume that some component, some operator, or some process will fail. Make sure the failure is contained and observable.
• Treat observability as a security control. Logs, monitors, and audits are not just for debugging. They are how you detect defection when prevention fails.

These steps will not make a system perfect. Nothing will. But they will make it more likely to survive contact with people who do not share your assumptions, which is the only kind of people a real system will encounter.

Frequently Asked Questions

What does it mean to build a system that does not require trust?

It means designing so that participants can verify the behavior of others instead of relying on their promises. Verification can take many forms: cryptographic proofs, public logs, economic penalties, or independent audits. The goal is not to eliminate all trust. Some trust in the verification mechanism itself is unavoidable. The goal is to shrink the trusted base to the smallest possible set of components and people.

Why do some protocols still rely on trust if verification is possible?

Because verification has costs. It adds latency, complexity, storage requirements, and operational burden. In some cases, the cost of verification exceeds the expected cost of the harm it would prevent. That calculation is often implicit and sometimes wrong. Protocols that rely on trust should be able to explain why verification was not worth the cost, and that explanation should be revisited as the threat environment changes.

How do incentives fit into protocol design?

Incentives determine whether participants will follow the rules when no one is watching. A protocol that aligns incentives with desired behavior is more resilient than one that depends on goodwill. But incentives are not a substitute for verification. They are a complement. A system with good incentives and no verification can still be gamed by a participant who finds a way to profit from defection. A system with verification and no incentives may be ignored by participants who see no reason to use it.

What is the relationship between technical design and power?

Technical design distributes power by determining who can act, who can verify, and who can be held accountable. A protocol that centralizes trust centralizes power. A protocol that distributes verification distributes power. These effects are often unintended, but they are real. Designers who ignore them are still making political choices; they are just making them without looking.

This article is part of a continuing series on the political economy of internet protocols. Future pieces will examine the governance of root zone operations, the economics of certificate authority markets, and the design of distributed moderation systems.

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.

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.

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.