Network Operator Groups Are the Last Functional Standards Body

The IETF writes the RFCs. The IEEE writes the cables. The MEF and OIF and IETF and ITU all write specifications that vendors implement. None of them write the document that tells you how to actually deploy any of it in production.

That document gets written, when it gets written, by network operator groups. It rarely gets called a standard, it rarely gets a number, and it rarely shows up in vendor literature. It is the document that bridges the spec to the working network. And it's increasingly the only standards-like artefact in the internet ecosystem that scales.

What standards bodies actually produce

The IETF produces RFCs. RFCs describe protocols, data formats, and interoperability requirements. They are written to be implementable by multiple independent parties. They are not written to be deployed by an operator who hasn't yet read the protocol spec.

The IEEE produces equipment specifications. Ethernet, optical interfaces, physical-layer details. These are precise, technical, and assume the reader is implementing the standard at the silicon or systems level. An operator deploying the resulting equipment isn't typically reading the IEEE document.

The OIF, MEF, ITU, and similar bodies fill in the gaps between IETF and IEEE — interoperability profiles, deployment scenarios, regulatory considerations. Useful work. Slow to produce. Targeted at vendors and large carriers, not at operational practice.

What none of these bodies produce is the document that says: "given this RFC and this IEEE spec, here is how you actually deploy it in a network, what gotchas you'll hit, what your configuration should look like, what to monitor". That document is the operational gap.

What NOGs actually produce

Three classes of artefacts.

Mailing list archives. Public, searchable, and over time they become the operational deployment guide for whatever protocol or technology is being deployed. A new operator wanting to deploy RPKI today doesn't read the RFC. They read three years of NANOG and RIPE list discussions about deploying RPKI, where the practical gotchas got debugged in public.

Conference presentations. Operators present what they actually deployed, what failed, what worked, with real numbers from real networks. These presentations are the closest thing the industry has to peer-reviewed operational research. Other operators cite them and replicate the patterns.

Best Current Operational Practice documents. Occasionally formal, more often informal. A handful of NOGs produce documents that codify the rough consensus of the community on how to deploy something. These documents sit between the standards-body output and the vendor documentation, and they're often the practically useful document.

These artefacts are not coordinated. They are not certified. They are not even reliably indexed. They are, collectively, the operational deployment guide for the internet, and they exist almost entirely because volunteer operators put them there.

Why standards bodies don't do this

Three structural reasons.

Resource model. Standards bodies are funded by member dues and consume staff time on document production. The document-production cycle is optimised for protocol specifications, not operational guidance. Operational guidance requires field experience, which standards-body staff typically don't have.

Output format. A formal standard goes through review cycles that take years. Operational practice changes faster than the review cycle. By the time a formal document codifies a practice, the practice has evolved past it.

Incentive misalignment. Vendors are heavily represented in standards bodies. Vendors have incentives to keep operational deployment knowledge inside their commercial documentation rather than in public standards. The cleanest deployment guides would commoditise vendor support contracts. Vendors don't fund work that competes with their own value proposition.

NOGs aren't subject to these constraints. The work happens because operators have problems and other operators have solutions and the mailing list is where they meet.

Examples where NOG-driven practice beat the spec to the punch

BGP route filter recommendations. The "deploy these specific filters" recommendations that protected against route hijacks have been operator-driven since the 1990s. The standards equivalent appeared years later, and the standards version is still less prescriptive than the operator community consensus.

RPKI operational tooling and threshold guidance. When to drop versus when to warn, how long to give your RPs to converge, how to integrate with your existing route policy. None of this is in any RFC. All of it is in three years of NOG mailing list discussions.

MTU coordination across peering boundaries. Long-running operator practice on what MTU to advertise and what to accept, with adjustments by region and by peering relationship. No RFC tells you any of this. It lives in operator conversations.

BCP38 deployment patterns. The RFC says do BCP38. The operational practice for actually deploying BCP38 in heterogeneous networks, with the right ACLs and the right testing, lives in operator-produced practice documents and informal training.

Where the NOG model breaks

The honest version of this argument has to include where the model doesn't work.

Onboarding new operators. A new network operator joining the field today inherits 30 years of accumulated operational practice in mailing list archives and conference videos. There's no index. There's no curriculum. The learning curve is real and the dropout rate is non-trivial.

Geographic gaps. NOGs are strongest in North America and Europe. Other regions have less-developed NOG communities. The operational practice that's well-codified in the NANOG and RIPE archives is less accessible to operators in regions whose own NOGs are smaller.

Vendor capture risk. Some NOGs in some regions have drifted toward vendor-dominated agendas. The original peer-to-peer model breaks when a single vendor's account team is the loudest voice in the room. This isn't fixed; it varies by NOG and by year.

Volunteer burnout. The work is unfunded. The volunteers cycle through. Continuity is fragile. Communities that have been functioning for 30 years are not guaranteed to function for 30 more.

What this means for the next ten years

The standards-body ecosystem isn't going to fix itself in the direction of producing more operational guidance. The economics don't support it. The IETF will keep producing protocols. The IEEE will keep producing physical-layer specs. Everyone else will keep producing interoperability profiles.

The operational deployment guidance will keep being produced by NOGs, on the same volunteer model, with the same uneven coverage. The networks that participate in NOG communities will have access to the practice. The networks that don't will continue to discover operational reality through painful production-failure.

The question for any operator reading this is not whether NOGs matter. It's whether your network is benefiting from the work the NOGs are doing. The answer is binary: either you participate, or you don't.

The standards bodies will keep writing the documents. The NOGs will keep writing the deployment guides. The deployment guides are the ones that determine whether your network actually works.

Show up to the meetings. Read the lists. Participate. The operational standards body that's still functional is yours to keep functional.