Summary

  • The IETF's "running code" tradition is an evidence discipline. Implementations can reveal ambiguous text, incompatible assumptions, missing error handling, unworkable state machines, and false performance expectations. Interoperability across independent code bases is stronger evidence than one demonstration, and successful deployment is stronger again.
  • The labels matter. An IETF Code Sprint improves the Datatracker, Mailarchive, and other tools used by the standards community. An IETF Hackathon implements or tests existing and evolving standards. An interoperability event exercises combinations of implementations. A working group, IETF Last Call, and the IESG handle standards decisions. Participation in one activity does not silently transfer authority from the others.
  • Hackathon teams are self-selected around projects that have champions, code, equipment, and available entities. Their results can establish feasibility under stated conditions. They do not represent operators that lack prototypes, users affected indirectly, firms that cannot release engineers, jurisdictions with different requirements, or organizations for which migration and opportunity costs dominate laboratory performance.
  • The proper response is not to weaken running code. It is to label the claim each artifact supports, disclose implementation independence and coverage, publish failures as well as successes, connect test results to open working-group issues, and require separate operational, economic, rights, and transition evidence before treating implementation momentum as broad acceptance.

"Code sprint" covers activities with very different authority

The phrase sounds decisive. A group gathers, writes software, connects systems, fixes bugs, and presents a result before the standards meeting begins. Compared with a long argument over hypothetical behavior, the code appears to supply reality. It can be tempting to move directly from "the implementation worked" to "the protocol choice has been validated," and from there to "the community has accepted the choice."

That sequence collapses different institutions and different claims. The IETF uses at least three related forms of concentrated coding activity. The Code Sprint, organized by the Tools Team, works on the IETF's own open-source infrastructure: the Datatracker, Mailarchive, xml2rfc, and other services used to develop and publish specifications. A Code Sprint contribution can improve how the institution operates. It ordinarily says nothing about whether a network protocol is technically sound or should be deployed.

The IETF Hackathon, first held in 2015, brings developers and subject-matter experts together around implementations of existing or evolving Internet standards. Teams may create prototypes, add protocol features to open-source projects, test combinations, improve test harnesses, clarify drafts, or reproduce problems. These results can feed directly into working-group discussion.

An interoperability event is narrower still. It connects two or more implementations under defined conditions to discover whether they interpret a specification compatibly. Such an event may occur inside a Hackathon, beside one, or elsewhere. Its evidentiary strength depends on independence, coverage, environment, test design, and the transparency of results.

Standards authority remains elsewhere. Working groups consider issues and seek rough consensus. IETF Last Call exposes a proposed action to wider review. The IESG evaluates publication and status. Mailing lists preserve the route for people who were not in the coding room. Implementers provide highly relevant evidence, but an event roster is not a membership roll and a results presentation is not a ballot.

This taxonomy is not pedantic. If a Code Sprint is confused with a Hackathon, maintenance of institutional software can be rhetorically attached to protocol legitimacy. If a Hackathon is confused with a working group, the people able to assemble code over a weekend can appear to decide the specification. If interoperation is confused with deployment, a controlled test can stand in for years of operational, economic, and user experience.

The title's warning therefore begins with precision: participation in concentrated coding authorizes a claim about the work actually performed. It does not confer a general protocol mandate.

Running code is an anti-rhetorical check

The case for implementation evidence is strong. Specifications are abstractions written in natural and formal language. Authors can believe two implementations will behave alike while silently carrying the same assumption. A state machine can be complete on paper but fail when messages are delayed, reordered, duplicated, or lost. A field can be syntactically defined but impossible to populate consistently. Error behavior may be omitted because everyone assumes it is obvious, until two code bases choose opposite defaults.

Writing code forces choices. Connecting independent code bases exposes whether those choices match. Running traffic through them reveals resource use, timing, interactions, failure recovery, and edge cases that discussion alone may not surface. An implementation failure can be more valuable than a successful demonstration because it identifies the exact point at which the specification's confidence exceeded its clarity.

RFC 3935, the IETF mission statement, describes rough consensus and running code as the combination of entity engineering judgment and real-world experience implementing and deploying specifications. The conjunction matters. Judgment without implementation can drift into elegant but unusable design. Code without reasoned consensus can optimize the needs of whoever happened to implement first.

Running code also constrains status. A vendor can claim that a feature is easy, but an open implementation may show unexpected complexity. An author can dismiss an interoperability concern, but a repeatable test can demonstrate it. A dominant implementation can embody one reading while an independent code base reveals that the document permits another. The evidence changes the argument from reputation to behavior.

This is particularly important when the meeting contains unequal confidence and institutional standing. A newcomer with a failing trace may have stronger evidence than a senior entity with an intuition. A small implementation can force a large vendor to explain an undocumented dependency. The code gives chairs and reviewers something testable around which to organize discussion.

The governance error is not giving such evidence too much technical weight. It is giving it the wrong kind of weight. A passing test is evidence for a proposition bounded by its setup. It is not consent from every affected party, proof of profitable deployment, or a complete assessment of rights and incentives.

Feasibility, interoperability, deployment, and acceptance are different findings

A useful evidence ladder begins with feasibility. One implementation executes the proposed behavior. This proves at least that one team could translate some version of the specification into code in one environment. It may also reveal performance or complexity. It does not prove that another team will read the text the same way.

The next rung is independent implementation. A second code base built without sharing the decisive implementation choices reduces the chance that success came from a common undocumented assumption. Independence is not established merely by different product names. Two wrappers around the same library, two forks from one repository, or two teams using the same reference code can produce nominal multiplicity without interpretive diversity.

Interoperation is stronger. Independent implementations exchange valid messages and achieve the intended function across exercised features. The test should identify versions, options, topology, data, expected results, failures, and features not covered. A demonstration of the happy path does not establish error recovery, security properties, scale, or optional combinations.

Operational experience adds duration and environment. Code runs amid real routing policies, traffic distributions, upgrades, outages, monitoring systems, hardware variation, middleboxes, staff procedures, and customer expectations. Operators discover whether failures are diagnosable, whether rollback works, whether state can be migrated, and whether the feature interacts safely with existing systems.

Deployment breadth adds heterogeneity. A protocol that works in one hyperscale network may not fit an access provider, enterprise, community network, mobile operator, public-sector environment, or small hosting company. A feature validated on modern equipment may be uneconomic on an installed base with long replacement cycles. Breadth does not require universal adoption, but it tests whether success depends on one organization's architecture.

Acceptance is different again. An operator may agree that a protocol is technically implementable and still reject migration cost, licensing terms, liability, privacy effects, customer disruption, or changes to commercial relationships. An end user may receive lower latency while losing meaningful control. A government network may face legal obligations not present in the test environment. Those positions are not refutations of feasibility. They are evidence about consequences beyond it.

The ladder prevents both inflation and dismissal. A prototype should not be criticized for failing to prove global adoption; that was not its job. Nor should it be presented as if it did. Each artifact becomes more useful when its claim is exact.

The standards process already distinguishes these levels

The formal standards architecture does not treat every implementation as a mandate. RFC 6410, adopted in 2011, reduced the Standards Track to Proposed Standard and Internet Standard. The first level can still evolve as implementation experience accumulates. Advancement to Internet Standard requires at least two independent interoperating implementations with widespread deployment and successful operational experience, no interoperability-breaking errata, and no unused features that greatly increase complexity.

Those criteria are more demanding than a weekend result. They join implementation plurality to deployment and operation. They also recognize that unimplemented features can be a liability rather than a sign of ambition. A specification is mature not because somebody made it run once, but because independent systems interoperate, the design survives use, and complexity corresponds to demonstrated need.

RFC 7942 provides a lighter and earlier mechanism. An Internet-Draft may include an Implementation Status section describing organizations, implementations, maturity, coverage, version compatibility, licensing, and experience. The practice is encouraged rather than mandatory. Working groups decide how to use the information. Chairs and Area Directors are asked to prevent the section from becoming a marketing venue, and the time-sensitive section is normally removed before RFC publication.

That design contains an important institutional safeguard. Implementation status informs deliberation; it is not a badge embedded permanently in the standard. The recommended text expressly says that listing an implementation does not imply endorsement. A working group may give due consideration to the experimentation and feedback while still asking whether the implementation is independent, partial, current, licensed, and relevant to the issue before it.

Earlier guidance was similarly careful. RFC 5657 warned that a list of implementation names is limited public evidence to demonstrate interoperability. A useful report explains how interoperation was established, what was tested, what failed, and whether mailing-list clarifications were required. The distinction between a product list and an evidence report is exactly the distinction between participation and proof.

The IETF therefore already has the conceptual tools needed to resist mandate inflation. The weakness arises when social momentum moves faster than formal labels. A crowded demonstration, a polished results presentation, or repeated use by prominent code bases can make an option feel settled before operational and distributional questions have received equivalent attention.

Rough consensus does not count laptops

Working-group consensus is not determined by the number of implementations or the number of people at a Hackathon table. RFC 7282 explains that dominance should not be inferred from volume or persistence and that minority views must be addressed. The goal is to identify open issues, understand objections, and determine whether the group has reasoned through them.

Running code can resolve an objection. If someone claims a field cannot be parsed unambiguously, independent implementations may show otherwise. If a proposed transition is said to be impossible, a prototype may identify a workable mechanism. If two designs are debated on performance grounds, repeatable measurements can replace speculation.

Code can also sharpen rather than resolve an objection. A prototype may work only with privileged access, a proprietary component, a modern hardware feature, or an assumption about deployment control. That result transforms a general concern into a specific boundary. The group must then decide whether the boundary is acceptable, can be removed, or needs to be documented.

Other objections are not answerable by implementation alone. An operator may argue that the migration requires coordination unavailable across its customer base. A civil-society entity may identify a privacy harm. A smaller vendor may show that a mandatory feature creates a cost barrier. A rights holder may disclose licensing conditions. Code can illuminate these claims, but the fact that one team accepted the cost or possessed the right does not answer them for others.

The absence of an operator from the event is not agreement. The presence of one engineer from a company is not authorization to bind that company, much less its sector. IETF entities act as individuals; affiliation discloses context but does not convert contributions into corporate votes. The same principle that prevents companies from owning seats also prevents a table of company-affiliated implementers from becoming an industry mandate.

A chair should therefore ask two questions after a successful demonstration. What technical issue did this result answer? Which objections remain outside the scope of the test? Treating the second question as hostility to running code mistakes evidence discipline for resistance.

Hackathon participation is selected by readiness

IETF Hackathons are free and open, and they deliberately welcome newcomers and subject-matter experts who are not developers. RFC 9311 describes their aims as bringing open-source collaboration into standards activity and introducing developers and early-career professionals to the IETF. These are meaningful access strengths.

Open registration does not produce a representative sample of affected parties. Projects need champions. Champions post topics, attract teams, prepare repositories or equipment, and organize work. Entities choose projects based on skill, interest, employer priorities, available code, and the likelihood of making progress. A technology with an active champion and mature open-source base can assemble visible results more readily than an operational concern held by organizations unable to send developers.

Readiness therefore selects evidence. The approach closest to implementation may produce more artifacts, demonstrations, and entities than an alternative requiring standards text, hardware changes, procurement, or cross-operator coordination. That does not make the ready approach wrong. It means visible code partly measures the resources already accumulated around it.

Vendor support can amplify the effect. A company that pays engineers to build an implementation before the meeting arrives with code, test expertise, equipment, and time. Independent developers may join and improve it, but the initial architecture shapes the tasks available. A smaller competitor may agree technically yet lack staff for the event. An operator may be interested but unable to expose production equipment. A user group may experience consequences without having a plausible coding project.

The event format also rewards bounded tasks. A parser, test vector, protocol option, or interoperability fix can show progress in hours. Cost allocation, privacy, long-term maintainability, and market dependency require different methods. They are less likely to appear in a rapid results presentation even when they determine whether deployment is legitimate.

These selection effects do not invalidate outcomes. They define the population from which outcomes arise. A source-aware working group should record who implemented, what resources were shared, whether code bases were genuinely independent, and which affected roles were absent. This turns participation from an implied mandate into transparent evidence context.

The first Hackathons showed the value and the boundary

The first IETF Hackathon was held before IETF 92 in 2015 with approximately 50 entities. The event grew quickly. By IETF 101 in London in 2018, the official account reported about 220 onsite and 20 remote entities across 35 projects. Work on TLS 1.3 offered a prominent example of implementations developing alongside an evolving specification.

The IETF 101 Hackathon account described repeated TLS 1.3 projects from 2016 through approval of the specification in 2018. The value was temporal as well as technical: implementers did not wait for the RFC before discovering ambiguity and interoperability problems. Feedback could improve the document while choices remained open.

This is the strongest case for proximity between code and standards. An implementation built after publication may reveal a flaw when correction is expensive. Parallel implementation makes the draft answer to reality before installed systems depend on it. Multiple teams can test whether a revision breaks compatibility or whether an extension point behaves as intended.

The case still does not make the Hackathon sovereign. TLS 1.3 did not become consequential because a project table met. Its specification underwent working-group development, review, Last Call, and IESG action. Implementations and later deployments supplied evidence. Browser, server, library, content-provider, enterprise, and operator decisions supplied adoption. Security analysis and real use continued after publication.

The event's contribution can be stated without inflation: it shortened the distance between specification and implementation feedback. It helped detect defects, improve clarity, connect implementers, and create confidence that independent code could follow the evolving design. Those are major achievements.

What it could not establish was universal acceptance of every consequence. Organizations not in the room still decided whether and when to deploy. Compatibility with existing infrastructure still mattered. Security properties still required analysis beyond successful handshakes. Market concentration among implementations remained a separate question.

A mature account of running code celebrates the feedback loop while preserving each later test. The lesson from TLS 1.3 is not that Hackathons can authorize a protocol. It is that timely implementation evidence can make the authorized standards process better.

The L4S interoperation event shows why claim labels matter

The IETF 114 Hackathon in 2022 provides an unusually concrete case. An L4S interoperability event brought together 32 engineers from 15 organizations. According to the official event account, they tested combinations of five congestion-control algorithms across seven network-equipment implementations spanning DOCSIS, Wi-Fi, and 5G contexts. Teams found and often fixed bugs, tuned parameters, and produced early benchmarks. One reported result showed up to a fifty-fold reduction in packet-delay variation relative to Cubic flows under the tested conditions.

This is high-value implementation evidence. It involves more than one code path, more than one organization, several access technologies, and direct testing. Bugs found before broader deployment are a public benefit. Parameter adjustments and implementation experience can improve specifications and deployment guidance. The team gave results to the relevant working group rather than treating the event as an isolated showcase.

The same facts define the boundary. "Up to" identifies a best observed result, not a universal effect. A four-day event cannot reproduce every traffic mix, queue configuration, legacy device, operational policy, failure mode, or incentive. Fifteen organizations are materially broader than one vendor, but they are not all access providers, application developers, equipment vendors, regulators, public networks, or end users affected by congestion behavior.

The event account is a project summary, not an independent audit. That does not make it unreliable; it means readers need test definitions, configurations, raw measurements, code versions, unsuccessful combinations, and follow-up deployment evidence before generalizing. A result presentation is designed to report progress quickly. A standards decision should ask what the event did not test.

Commercial consequences are also external to the benchmark. An operator must assess equipment support, upgrade sequencing, monitoring, troubleshooting, customer equipment, capacity policy, staff training, and coexistence. A vendor must decide which algorithms to maintain. Application developers may face incentives different from access networks. Users may experience benefits or harms depending on traffic and deployment choices.

The right interpretation is neither "the event proved L4S for everyone" nor "the event was only a demo." It proved that specified combinations could be implemented and exercised, exposed defects, and generated bounded performance evidence. It did not speak on behalf of absent operators or convert technical success into a duty to deploy.

A working implementation can still be operationally incomplete

Protocol code typically sits inside a service. Operators need installation, configuration, monitoring, alarms, logging, rollback, capacity planning, security response, accounting, and staff procedures. A packet exchange can succeed while the service remains impossible to run safely at scale.

RFC 5706 was written because operations and management considerations were often addressed too late. It asks whether deployment has been discussed, whether a specification scales operationally, how coexistence works, how correct operation is verified, what metrics matter, and whether the protocol creates new dependencies or traffic effects. These are not embellishments after the "real" protocol. They determine whether the protocol can be maintained.

A Hackathon can test many of these questions if the project is designed for them. Teams can build telemetry, inject faults, test downgrade and rollback, exercise configuration errors, or compare monitoring across implementations. The problem is not the venue. It is inference from the typical success path. A green demonstration often answers reachability and basic function more clearly than diagnosis, recovery, and cost.

Scale creates another gap. A feature may work among a few endpoints while creating state, CPU, memory, signaling, or support burdens across millions. Hardware in the test may be current; deployed hardware may remain in service for a decade. Operators may have vendor combinations absent from the event. Configuration that is simple for an author may be hazardous across a distributed operations team.

Operational evidence must therefore identify environment and duration. How many nodes ran? What traffic and faults were present? Which monitoring detected failure? Was rollback attempted? Did independent teams configure the feature from the specification? Were existing services disrupted? What human intervention was required? What remained untested?

An implementation report becomes stronger when failures are preserved. If a team needed an undocumented flag, a mailing-list clarification, or expert assistance, that is not embarrassing noise. It is evidence that ordinary deployment may encounter the same barrier. Recording it lets the working group improve the text and lets operators price adoption honestly.

The difference between a running protocol and an operable service is where much of the absent operator's interest resides.

Deployment is governed by incentives as well as packets

Technical compatibility does not make adoption self-executing. Organizations deploy when benefits exceed costs under their own constraints. Those costs include engineering, hardware, support, training, legal review, customer communication, coordination, and the risk of being early while peers remain incompatible.

RFC 8170 treats transition planning as a distinct discipline. A credible plan should understand existing deployment, explain incentives for each involved entity, define phases and success criteria, provide a contingency for failure, and communicate with affected entities. The document specifically notes that barriers can be non-technical and can include operational practices, personnel training, accounting, billing, legal, and regulatory incentives.

This is the point at which a prototype's constituency becomes visible. The people writing the code may receive the direct benefit: a new capability, cleaner architecture, product feature, research result, or reduced implementation uncertainty. The operator may receive a migration project. A customer may receive better performance but face compatibility risk. A smaller vendor may need to implement a complex feature merely to remain substitutable.

RFC 5218 similarly distinguishes technical quality from protocol success. It discusses implementation availability, restrictions on use, business-model effects, cost, and the fit between incentives and deployment. Freely available code can materially improve adoption, but an available implementation does not remove every operational or commercial barrier.

The working group should therefore ask for an incentive map when a protocol changes behavior across organizational boundaries. Which actors must upgrade first? Who pays before benefits appear? Can deployment be incremental? Does one actor impose costs on another? Is rollback available? What happens if only dominant vendors implement? Does reference code reduce entry cost or entrench one architecture?

These questions do not require the IETF to regulate business models. They keep the technical claim honest. If success requires coordination or subsidy, the specification should not be defended solely by showing that a well-resourced team implemented it. If incentives are outside the IETF's competence, that limit should be visible rather than filled by an assumption of acceptance.

Code does not settle intellectual-property rights

An implementation can run while its right to run remains uncertain. A team may possess a license, rely on an open-source grant, avoid a patented feature, or simply not know that a claim exists. Technical success and legal freedom are separate propositions.

RFC 8179 requires disclosures in defined circumstances and allows licensing information to inform working-group evaluation. It also states that the IESG, IAB, Internet Society, and IETF Trust do not identify all relevant rights, evaluate applicability, or take a position on validity and scope. Implementers make legal and commercial decisions using the available disclosures and other advice.

This boundary directly limits mandate claims. The presence of two implementations does not necessarily mean two independent parties possess durable rights to ship, distribute, operate, and maintain them on acceptable terms. RFC 6410 accordingly requires, when controlled technology is necessary for an Internet Standard, at least two independent, separate, successful uses of the licensing process. That is more than two passing test runs.

Open-source code helps but does not collapse the analysis. The repository license covers copyright permissions in the code under its terms. It does not automatically resolve third-party patents, trademarks, data rights, export controls, or contractual dependencies. A permissive reference implementation may also include optional paths that avoid the legally sensitive mechanism, making nominal implementation evidence misleading for full coverage.

Hackathon reporting should therefore include licensing and coverage as RFC 7942 recommends. Did the code implement the relevant feature? Under what software license is it available? Is it a clean independent implementation or a derivative? Are known IPR disclosures linked? Did successful interoperation depend on controlled technology? These are evidence questions, not legal verdicts by the event.

Rights also extend beyond implementers. A protocol can affect user privacy, control, access, and data flows even when every software license is clear. RFC 8890 warns that technical decisions enable some uses and discourage others, and that the IETF should consult affected communities rather than assume entities' experience represents all end users.

Code can demonstrate what becomes possible. It cannot, by executing successfully, decide whether every enabled use is legitimate.

Absent operators are not a silent approval bloc

Network operators are often invoked as if they were a single constituency: "operators need this," "operators will not deploy that," or "the operational community was represented." In reality, an access network, cloud provider, enterprise, mobile carrier, exchange, public network, community network, and small hosting company can face different equipment, incentives, regulation, and customers.

One operator's implementation is valuable evidence about its environment. It does not authorize a statement about all operators. Ten operators at a test event provide broader evidence, especially if their architectures differ. They still do not bind nonparticipants. The IETF's individual-participation principle makes this especially clear: people contribute expertise; they do not cast organizational votes.

Absence can have many meanings. An operator may lack travel or staff budget, consider the proposal premature, depend on a vendor roadmap, be unable to expose systems, or focus on incidents and service continuity. A small network may not have a protocol developer even though it will bear deployment effects. Silence can reflect satisfaction, indifference, resource scarcity, or ignorance. It cannot safely be converted into consent.

This creates a practical burden for working groups. They cannot wait for every affected network to participate. Nor can they declare broad operational acceptance from the people already present. They need targeted evidence. Operations-area review, outreach to relevant operator forums, deployment surveys with stated limits, implementation and transition reports, and documented dissent can expose conditions absent from the Hackathon.

The standard itself remains voluntary. RFC 3935 defines an IETF standard as a description of how to do something if one claims conformance, not an attempt by the IETF to mandate use or police deployment. That principle is a protection against overreach and a statement about the source of adoption. Operators accept a protocol through deployment decisions, contracts, regulation, customer demand, and interconnection needs, not because implementers occupied enough tables.

Voluntary status does not make IETF choices harmless. A standard can become commercially unavoidable when dominant platforms adopt it, procurement requires it, or regulation incorporates it. That is why working groups should consider absent operators before market momentum hardens. But the later external force should not be backdated into a claim that the Hackathon supplied a mandate.

End users are farther from the coding table

Many protocols are not directly visible to end users. A routing change, name-resolution mechanism, transport feature, authentication format, or management protocol may be implemented by specialists. The person affected may never know which standard shaped latency, privacy, accessibility, security, switching cost, or service availability.

RFC 8890 treats this distance as a responsibility rather than permission to ignore users. It notes that the IETF has no unique insight into what is good for end users and should engage affected communities, especially when decisions may harm them. It also rejects the assumption that a government entity or civil-society organization automatically represents all users in a jurisdiction or cause.

A Hackathon team can include user advocates and subject-matter experts. It can build tests for privacy leakage, usability, accessibility, or switching. This broadens evidence. Yet users usually do not appear as implementable endpoints with a clear success signal. A feature can pass every packet test while concentrating control, increasing surveillance, or making exit expensive.

The difference is between capability and welfare. Code proves that a mechanism can perform an action. It may measure speed, failure, or compatibility. Whether the action serves users requires a model of who benefits, who is exposed, what alternatives remain, and how control can be exercised. Those are not anti-technical questions. They concern the architecture the code makes real.

Affected communities also face a translation cost. A working group can ask them to read an evolving draft, follow a long list, and join an event organized around repositories. That invitation is formally open but may be practically inaccessible. Outreach should frame the consequence in the community's terms, identify choices still open, and offer a route to submit evidence without becoming a full-time protocol author.

Implementation momentum can otherwise create a timing trap. By the time users recognize an effect, multiple code bases and products depend on the chosen behavior. Reconsideration is then described as too costly. Running code, intended as an anti-rhetorical check, becomes a source of path dependence.

The safeguard is early impact analysis parallel to implementation, not after it. The faster the code advances, the earlier the working group should ask whose interests are not represented by the success signal.

Code Sprint authority is narrower still

The IETF Code Sprint deserves separate treatment because its results are operationally important but constitutionally easy to overstate. The Tools Team convenes volunteers to improve services such as the Datatracker, Mailarchive, and document-production tools. At IETF 114, eighteen Code Sprint entities produced more than thirty pull requests across Datatracker and xml2rfc work, with contributions continuing through the week.

Those changes can materially affect participation. Search, agenda, submission, review, identity, metadata, and publication features shape how easily people discover and contribute to standards work. A poor tool can exclude; a good one can lower cost. Tool maintainers therefore exercise consequential engineering judgment.

But contributing code to the institutional platform does not give a volunteer authority over protocol content. A feature that records related implementations can improve evidence visibility. It does not endorse the linked implementation. An agenda improvement can make sessions legible. It does not decide which technical proposal has consensus. A document tool can enforce syntax. It does not determine the policy expressed by that syntax.

The reverse boundary also matters. A working group should not treat a tool's current data model as a substantive limit merely because code exists. If the Datatracker cannot represent an important distinction, the answer may be to improve the tool, not compress the institution's reasoning into the available field. Infrastructure should serve public decisions rather than silently define them.

Code Sprint changes need their own accountability: review, tests, security, privacy, accessibility, maintainability, deployment, and user feedback from the people who rely on IETF services. The authority comes from the Tools Team's role and the adopted maintenance arrangements, bounded to those services. It does not arise from the number of pull requests.

Separating Code Sprint and Hackathon authority strengthens both. Tool contributors receive credit for maintaining the institution without their work being misdescribed as protocol validation. Protocol implementers can report evidence without implying they maintain institutional systems. Working groups remain responsible for technical consensus.

The phrase "running code" connects these activities culturally. It does not erase their mandates.

Vendor concentration can hide inside implementation plurality

Two interoperating implementations are stronger evidence than one, but numerical plurality can conceal common control. Code bases may share a library, corporate parent, principal author, test suite, funding source, hardware dependency, or commercial incentive. Even genuinely independent teams may represent the same segment of the market.

The purpose of independence is epistemic. Different implementers should be capable of exposing ambiguity because they approach the text without relying on the same hidden decisions. Organizational names are an imperfect proxy. A fork can diverge meaningfully; two corporate products can share almost everything. Reports should describe code lineage and decisive dependencies rather than merely count logos.

Market diversity is another question. A server and client from two dominant platforms may interoperate perfectly while smaller implementers face prohibitive complexity. An open reference implementation can lower that barrier, but it can also become the only practical code path. If every product embeds it, protocol interoperability may be high while implementation diversity is low.

RFC 9518 connects implementation and deployment diversity to the ability of users to switch. A standard that is technically open can still support centralization if alternatives are too costly to implement or maintain. Complexity, proprietary extensions, data advantages, and sticky intermediaries matter alongside packet compatibility.

Hackathon metrics should therefore distinguish entity count, organization count, independent code-base count, dependency diversity, role diversity, and eventual deployment diversity. None alone supplies legitimacy. Together they reveal whether running code is testing the specification from several directions or repeatedly exercising one implementation family.

This is not an argument for excluding large vendors. Their engineers, products, equipment, and deployment data are often indispensable. The concern is unmarked concentration. A working group should know whether a successful test spans competing implementations, shared components, operators, applications, and constrained environments.

Transparency also protects vendors from unfair inference. Affiliation does not prove coordination, and sponsorship does not prove control of a technical outcome. The evidence should identify actual code and dependencies rather than treating every employee as an instructed corporate delegate.

The governance objective is a result robust enough to survive outside the organizations most able to produce it first.

Failure is evidence and should travel with success

Hackathon reports naturally celebrate progress. Teams have limited presentation time, sponsors and organizers want to show value, and entities deserve recognition. The result can emphasize features completed, bugs fixed, and benchmarks improved while compressing failed configurations, unresolved ambiguity, and setup dependence.

For standards quality, the failures may be more important. A pair that did not interoperate identifies a specification or implementation problem. A feature nobody attempted may signal complexity or missing demand. A test abandoned because equipment was unavailable defines an evidence gap. A result possible only after an author explained the intended behavior shows that the text was not independently sufficient.

The reporting format should preserve these facts without turning the event into an audit tribunal. Each project can publish a compact matrix: implementations and lineage, specification version, features attempted, successful combinations, failed combinations, deviations, clarifications required, performance environment, code links, licenses, and open questions. Teams should be able to mark unknown rather than convert missing evidence into success.

Working-group chairs can then map the matrix to issues. Which failures require draft text? Which are code bugs? Which expose deployment assumptions? Which remain controversial? The meeting should not receive only a highlight slide; it should receive a set of claims that can be reviewed asynchronously.

Negative results also protect against implementation theater. A project with a polished demonstration but narrow coverage should not outrank a project that discovered fundamental difficulty. RFC 3935 explicitly recognizes that a failed experiment can be more relevant than a technically competent standard useful only in special cases.

Longitudinal follow-up matters. Did fixes from the event enter released code? Did the specification change? Did later implementations reproduce the result? Did deployment expose a different failure? A one-time report can establish a moment. Standards maturity depends on what survives afterward.

The phrase "running code" should include code that crashed, disagreed, consumed too much state, or proved the design uneconomic. Reality constrains standards most effectively when inconvenient outcomes remain visible.

An evidence ledger should prevent mandate inflation

Every implementation claim should identify five boundaries.

First, the proposition: what exactly did the work demonstrate? Examples include parseability, feature coverage, interoperability, performance under a stated load, fault recovery, migration, or deployment. "Working implementation" is too broad when only one path was exercised.

Second, the population: which code bases, organizations, roles, networks, and users were represented? Independence and code lineage should be explained. Absence should be recorded by role, not treated as opposition or consent.

Third, the environment: what hardware, topology, traffic, version, configuration, duration, and support were required? Could a team reproduce the result from public material without author assistance? Were failures and untested features retained?

Fourth, the consequences: what operational, economic, legal, privacy, security, accessibility, or market questions remain? Which belong inside the working group's technical competence, and which require consultation or external decision? A limitation is not solved by omitting it.

Fifth, the decision path: where will the result be considered? A Hackathon presentation should link to the relevant draft and public issue. The working group should record how the evidence affected text or consensus. Last Call should expose unresolved material concerns. Deployment claims should be updated as experience accumulates.

This record is not a bureaucratic burden if kept proportionate. It replaces vague prestige with reusable technical knowledge. Implementers gain recognition for precise findings. Chairs gain a basis for evaluating objections. Operators can assess relevance to their environment. Later researchers can distinguish a demonstration from deployment.

Most importantly, the record prevents a shift in claim type. "Two implementations exchanged messages in this topology" cannot silently become "the industry supports the protocol." "Fifteen organizations joined the event" cannot become "operators accepted the cost." "Open-source code exists" cannot become "all implementers possess necessary rights." Each larger claim requires additional evidence.

Running code remains central in this model. It simply carries a label strong enough to keep its authority intact.

Running code is strongest when it refuses borrowed authority

The IETF Hackathon has earned its place because it makes specifications answer to implementation earlier. It brings developers into standards work, catches ambiguity, creates test tools, connects independent code, and gives working groups evidence that argument alone cannot supply. The Code Sprint sustains the tools through which the institution itself works. Interoperability events expose whether products can communicate. These are distinct and valuable functions.

Their value is reduced when participation is described as mandate. A room of implementers is selected by readiness, resources, interest, and project champions. It rarely includes every kind of operator, vendor, user, or affected institution. Even a broad event exercises bounded environments. Code that runs can remain hard to operate, costly to migrate to, concentrated in one dependency, restricted in use, or harmful in ways a packet test does not measure.

The standards tradition already recognizes the difference. Proposed Standards can evolve. Internet Standard maturity requires independent interoperation, widespread deployment, and successful operational experience. Implementation Status sections are informative and time-sensitive. Consensus addresses objections rather than counting heads. IPR rules disclose information without pretending the IETF adjudicates every right. Transition guidance asks about incentives and failure plans.

The practical rule is simple. A prototype authorizes a feasibility claim. An independent pair can authorize an interoperability claim for tested features and conditions. Deployment can authorize an operational-experience claim for the environments observed. None of these authorizes a claim that absent parties accepted commercial burdens, surrendered rights, or delegated decision power.

Working groups should preserve that chain in public records. Name the code, lineage, versions, coverage, environment, failures, licenses, and unanswered questions. Connect results to draft issues. Seek operational and user evidence beyond the implementers. Revisit assumptions after deployment. Give failed experiments the same analytical dignity as successful demonstrations.

"Rough consensus and running code" works because neither half is sovereign. Consensus without code can ignore reality. Code without bounded consensus can turn the resources of early implementers into an unexamined agenda. Together they can produce standards whose technical authority is earned, whose limits are visible, and whose adoption rests on evidence rather than a mandate nobody gave.