Summary

  • The IETF's running-code tradition is best understood as an anti-rhetorical discipline. Independent implementation, interoperability testing, and operational experience can reveal ambiguity, hidden state, scaling limits, unsafe defaults, and claims that work only on paper.
  • The evidence is neither uniform nor self-interpreting. A prototype proves less than independent interoperable implementations; a controlled test proves less than diverse deployment; widespread deployment may show usefulness while also reflecting first-mover advantage, bundled distribution, or switching cost.
  • Running code answers engineering questions within an authorized standards process. It does not identify who may decide non-technical policy, convert operators into an electorate, override an unresolved rights objection, or expand the IETF's remit beyond the protocols and functions for which it accepts responsibility.

A compile is an argument with witnesses

Technical meetings are vulnerable to a particular kind of confidence. A proposal is presented with a clean architecture, a sequence diagram, and a set of requirements that seem mutually compatible. The vocabulary is precise. Each criticism has an answer. Yet the apparent coherence may depend on assumptions that have never occupied the same machine, crossed the same administrative boundary, or survived the same failure.

Running code interrupts that confidence. A parser has to decide what an underspecified field means. A state machine has to leave one state and enter another. Two independent implementations have to agree not merely about the happy path but about malformed input, retransmission, downgrade, timeout, recovery, and version skew. An operator has to know what happened at three in the morning without access to the author's mental model. A deployment has to coexist with equipment and policy that the design team did not control.

This is why implementation can operate as an anti-rhetorical check. It replaces the statement that a design is implementable with evidence that someone implemented it. It replaces the statement that a specification is clear with evidence that independent readers produced compatible behavior. It replaces the statement that a feature is operationally useful with evidence that a network chose it, kept it, and could support it. The evidence does not end argument, but it makes some forms of argument more expensive to sustain.

The check matters particularly in the IETF because the institution does not command adoption. Internet standards are followed voluntarily across autonomous networks, products, jurisdictions, and commercial relationships. A document can be approved, published, and still fail to become common practice. Conversely, an implementation can spread before a specification is stable. The standards process therefore lives between text and use. Neither can safely be treated as a complete account of the other.

The error is to turn a useful discipline into a theory of authority. Code can falsify a claim about packet processing. It cannot, by executing, establish that its author's preferred distribution of cost is fair. Deployment can show that operators tolerate a mechanism. It cannot prove that affected users consented to every consequence. Market success can show coordination around a choice. It cannot show that the IETF should regulate matters outside its technical mission. The evidentiary force of code is real precisely because its limits can be stated.

The 1992 credo was a rejection of decision by posture

The familiar phrase entered IETF memory through David Clark's presentation at the 1992 plenary: rejection of kings, presidents, and voting; belief in rough consensus and running code. RFC 7282 later used the credo to explain an institutional preference. No single person dictates the answer, counting heads is not the decision rule, and engineering should not proceed in a vacuum without practical experience.

The two halves constrain different temptations. Rough consensus prevents an implemented proposal from winning merely because its sponsor arrived first. The group must consider technical objections, including objections raised by a minority. Running code prevents a verbally attractive consensus from insulating itself against physical evidence. Participants may agree on a design and still discover that it cannot be implemented as described, cannot interoperate, or imposes costs that the discussion failed to see.

That combination is more demanding than the slogan often sounds. It is not rule by whoever has a demonstration. It is not a plebiscite among implementers. It is not permission for a chair to announce that debate is over because one code base works. Code enters a deliberative process in which its provenance, coverage, independence, and relevance can be questioned. Consensus enters an engineering process in which assertions remain exposed to tests.

RFC 3935, the IETF mission statement, gives the combination institutional form. It describes standards based on participants' combined engineering judgment and real-world experience implementing and deploying specifications. It also lists open process, technical competence, a volunteer core, and protocol ownership. Those principles do not collapse into one another. Real-world experience informs judgment; it does not replace open participation. Technical competence supports the IETF's voice on technical matters; it does not confer general jurisdiction.

The mission statement also makes usefulness concrete. The value of an Internet standard lies in interoperability: multiple products implementing a standard can work together to deliver useful functions. That formulation points away from theatrical prototypes and toward plural evidence. The relevant question is not whether any code runs. It is whether implementations, users, and networks can coordinate through the specification under conditions that matter.

Running code is therefore best read as an institutional refusal of unearned abstraction. The author must show more than a polished draft. The working group must examine more than the loudness of support. The chair must distinguish a real answer to an objection from collective impatience. The IESG must consider the quality and operational implications of the proposed standard. At every level, claims should meet the strongest available evidence.

RFC 2026 made experience a goal without making it a universal gate

RFC 2026 describes the Internet Standards Process as seeking technical excellence, prior implementation and testing, clear documentation, openness and fairness, and timeliness. It describes a mature Internet Standard as stable, well understood, technically competent, supported by multiple independent interoperable implementations with substantial operational experience, publicly supported, and recognizably useful.

This is an important endorsement of evidence from practice. Standards do not mature only because time passes or because successive committees approve them. Experience should change the specification. Ambiguity should be removed. Implementation choices that produce incompatible behavior should become explicit. Operational hazards should affect applicability, defaults, and security guidance. A standard that no one can use does not become better by acquiring a formal label.

But the process has changed since 1996, including the structure of the standards track. More importantly, implementation has never operated as one identical precondition for every IETF publication. RFC 7942 says directly that implementation is not required for publication as an RFC and notes that Proposed Standards have been published without it. It records that the Routing Area once applied an implementation requirement, that the general requirement was later lifted, and that individual working groups may impose their own rules.

That variability is not evidence that running code is empty. It is evidence that the slogan is a method of judgment rather than a mechanical gate. Some specifications can and should be implemented early. Some coordinate behavior that cannot be meaningfully tested until dependencies mature. Some document an architecture or process. Some respond to urgent interoperability needs where delaying publication would preserve worse fragmentation. Evidence requirements should match the claim and maturity level.

A mandatory universal rule would also invite games. Sponsors could produce a nominal implementation that covers only the easy path. Two products could share a library while being counted as independent. A test could be designed around the implementation rather than the specification. Code could exist without users, operational support, security review, or credible maintenance. The appearance of compliance would then replace the discipline the rule was intended to create.

The better reading of RFC 2026 is cumulative. Prior implementation and testing are among the process goals. Independent interoperability and substantial operational experience are strong evidence at mature standardization. Openness, fairness, documentation, and public support remain separate requirements. Implementation strengthens a technical case; it does not purchase exemption from the rest of the process.

Not all running code carries the same evidentiary weight

The phrase compresses several different things. At the lowest level, code may compile. That demonstrates that one programming language accepted one representation of the design. It may still never exchange a packet, process hostile input, or survive a restart. Compilation is useful to the author and nearly irrelevant to a claim of interoperability.

A single prototype proves more. It can expose whether the state machine is coherent, whether required data is available, and whether the basic mechanism is computationally plausible. It can reveal omissions in the draft. Yet the same team may have written both the text and the code, carrying the same unstated assumptions into each. Agreement between those artifacts can be self-agreement.

An independent implementation raises the standard. A second team interprets the specification without relying on every private explanation available to the first. Differences become evidence about ambiguity. Even then, two implementations may not have been tested against each other, may share dependencies, or may implement different subsets. Independence is a factual question, not a count in a table.

Interoperability testing is stronger when it covers versions, optional features, failure paths, extension handling, and recovery. A pair of implementations that complete one scripted exchange establish less than a matrix showing that several systems communicate under varied conditions. Negative tests matter. A protocol that interoperates only when every input is well formed and every message arrives in order has not met the Internet.

Operational deployment adds another layer. Networks introduce heterogeneous equipment, administrative boundaries, incomplete upgrades, monitoring constraints, and incentives absent from a test event. Operators discover whether the protocol is diagnosable, whether failures are contained, whether configuration is comprehensible, and whether benefits justify continuing cost. Long-lived deployment can expose interactions that a laboratory cannot efficiently simulate.

Widespread use is not the final rung of an objective ladder. It may be excellent evidence of utility, stability, or implementer interest. It may also reflect a dominant vendor, bundling, default settings, legacy dependence, contractual leverage, or the absence of a coordinated migration path. The more deployed a mechanism becomes, the harder it can be to separate technical merit from the cost of leaving it.

The working group should therefore ask what proposition each implementation fact supports. "There is code" supports existence. "Two independent implementations interoperate" supports a degree of clarity and compatibility. "Several operators have run it under mixed conditions for years" supports operational viability within those conditions. None of those statements alone supports universal safety, optimality, fairness, or institutional jurisdiction.

RFC 7942 turned folklore into a modest evidence practice

The implementation-status mechanism in RFC 7942 is valuable because it does not pretend that code speaks for itself. Authors may include a temporary section in an Internet-Draft describing known implementations. The suggested information includes the responsible organization, maturity, feature coverage, compatible draft versions, licensing, experience, contact details, and the date of the update. Interoperability reports and test descriptions can also be recorded.

Each field answers a predictable source of inflation. Maturity distinguishes a research prototype from production use. Coverage prevents implementation of one feature from being represented as implementation of the whole proposal. Version compatibility exposes whether a demonstration tracks the draft under review or an older design. Licensing affects whether others can inspect or test the implementation. Dates prevent stale claims from appearing current.

The mechanism is deliberately non-mandatory. Working groups decide how to use the information. The section is removed before RFC publication because implementation status changes over time and should not become frozen in the archival specification. Chairs and Area Directors are asked to prevent it from becoming a marketing venue, and the standard language warns that listing does not imply IETF endorsement.

These are not administrative details. They express the right epistemic posture. Implementation is evidence contributed by interested parties. It can be useful without being verified in every respect. It can help prioritize work, expose protocol flaws, support interoperability testing, and show that difficult features are implementable. It can also become advertising if provenance and limitations disappear.

RFC 7942 includes a crucial limit: code should never substitute for a clear specification. An implementation can resolve ambiguity for itself, but an Internet standard must allow others to reproduce the intended behavior from the public text. "Read the dominant code base" is not interoperability. It transfers authority from an open document to a maintained artifact controlled by a narrower group.

That limit also protects later entrants. A new implementer should not need personal access to the original team to discover required behavior. An operator should not have to reverse engineer one vendor to understand failure. A reviewer should be able to compare code against a specification rather than treating code as the specification. Running code disciplines text only when text remains capable of disciplining code.

Interoperability is evidence against private meaning

One of the strongest governance properties of independent implementation is that it makes private assumptions visible. A draft may appear complete to its authors because they share years of discussion, common libraries, and a sense of what a sentence "obviously" means. A second implementation arrives without that background. If it behaves differently, the difference can reveal that the standard contains private meaning.

Private meaning is not always deliberate. It can reside in defaults, units, ordering, error handling, or the point at which a timer begins. It can result from a diagram that omits a transition everyone in the original team remembers. The problem is institutional regardless of intent. A specification available to all is not genuinely open if only insiders can implement it correctly.

Interoperability testing can therefore function as a test of accessibility. It asks whether the published artifact carries enough information across organizational boundaries. The answer is especially important when implementations come from teams with different languages, product architectures, and operational environments. Agreement reached under diversity is stronger evidence than agreement among closely related code bases.

The same logic applies to extensibility. A protocol may work between the original pair while leaving no safe behavior for unknown fields, new message types, or partial deployment. Independent implementers often force the group to specify what old systems do when new systems appear. They expose whether extension points are real or decorative.

Yet interoperability does not prove that the interoperable behavior is desirable. Two implementations can faithfully reproduce a privacy leak, an unfair allocation of processing cost, or a dangerous default. Compatibility is a property, not a moral verdict. It tells the group that the text can coordinate behavior. The group must still decide whether that behavior serves the Internet and falls within the IETF's legitimate technical role.

That is the first boundary against policy overreach. A technical fact can establish that systems agree. It cannot alone establish that the agreement respects every affected interest. Open review and reasoned consensus remain necessary because implementation tests the mechanism, not the full legitimacy of choosing it.

Deployment evidence is stronger than demonstration and messier than doctrine

Operators encounter the protocol as a dependency, not a thesis. They must schedule upgrades, interpret alarms, manage partial adoption, train staff, and explain outages. Their experience can reveal that a feature considered optional in the draft becomes operationally mandatory, that a safe default is too expensive to deploy, or that a failure signal is indistinguishable from ordinary loss. Such findings deserve more weight than repeated assurances that the architecture is elegant.

Deployment also tests incentive compatibility. If every participant benefits only when others bear the cost, voluntary adoption may stall. If early adopters become less reachable, the transition design may punish the behavior the standard seeks. If security depends on a receiver rejecting traffic that its customers expect, commercial pressure may defeat the rule. Code can run while the deployment model fails.

Operator evidence is strongest when it is specific. Which network conditions existed? Which versions and features were enabled? How many administrative domains participated? What failures occurred? What fallback was used? Which metrics changed? What remained unobserved? A statement that "operators support this" is rhetoric unless the underlying experience can be inspected.

It is also necessary to look for missing operators. Large backbone networks, content platforms, access providers, enterprise networks, community networks, and small service providers do not have identical constraints. A design that is easy for a team with dedicated protocol engineers may be impractical for a small operator. A feature that benefits a large sender may shift state or traffic to networks with less bargaining power.

Deployment reports can underrepresent failures because failed trials disappear, companies protect incident details, and engineers with negative experience lack time to write drafts. Successful implementers often remain active in the working group because the feature matters to them; those who abandoned it may leave. The surviving record can therefore overstate success without anyone falsifying a claim.

The remedy is not to discount operators. It is to improve the evidence. Working groups can ask for conditions, counterexamples, failed trials, independent measurements, and explicit uncertainty. They can distinguish a vendor's product roadmap from a network's observed result. They can invite operators who bear different costs. Practical experience should discipline the meeting rather than arrive as an unchallengeable credential.

Code can be a constituency without becoming an electorate

Implementers and operators have legitimate standing in IETF deliberation because they bring information that others may not possess. They know where a specification is ambiguous, what deployment costs, and which assumptions fail. The IETF mission statement's commitment to technically competent input from any source supports listening to that evidence.

But evidence and authority are different. The IETF is not a membership organization with an operator chamber or a vendor franchise. RFC 7282 explains that the difficulty of defining who would vote is one reason IETF decisions are not made by ballots. Giving votes only to those with code would not solve the problem. It would create a new boundary that favors participants with engineering budgets, existing products, access to test infrastructure, or control over deployed systems.

An implementation-weighted electorate would also invite circularity. A design favored by incumbents is easier for incumbents to implement. Their implementations then become evidence of consensus. Alternative teams are told they lack running code, even though the disputed choice raises the cost of producing it. First deployment would acquire both market and procedural advantage.

None of this means that unsupported objections should stop work. Rough consensus permits progress after a technical objection has been honestly considered and found insufficient. RFC 7282 is explicit that agreement by a large majority to dismiss an objection is not enough; the group must reason about it. Code may supply the answer. A test might show that the predicted failure does not occur under relevant conditions, or that a mitigation works.

The chair's task is to evaluate issues, not count repositories. An objector who presents a reproducible failure may deserve more attention than ten implementers reporting success on the happy path. Conversely, a person who repeatedly predicts failure without engaging contrary measurements does not gain a veto. The weight comes from the technical issue and evidence, not from institutional status.

Operators should therefore be treated as expert witnesses and affected participants, not as a hidden upper house. Their experience can defeat an engineering claim. Their preference does not automatically settle a rights question or authorize the IETF to decide an external policy matter.

Market adoption can conceal coercion, inertia, and switching cost

Standards communities often use deployment as a retrospective vote. If a protocol spreads, the market is said to have selected it. This can be informative, but it is too simple for governance.

Adoption can occur because a mechanism is technically superior. It can also occur because a major platform enables it by default, a procurement requirement names it, a dominant vendor bundles it, or an installed base makes alternatives costly. Users may adopt a service whose protocol choices they cannot see. Operators may retain a weak mechanism because coordinated replacement is riskier than continued exposure. Compatibility pressure can turn voluntary adherence at the network level into practical compulsion for an individual actor.

These paths matter when deployment evidence is used in a standards decision. A working group should ask whether adoption demonstrates benefit or merely dependence. It should identify who chose, who paid, who could exit, and who was not consulted. A billion endpoints can be evidence of reach while saying little about informed preference.

The distinction becomes acute in privacy and security. A deployed identifier may be useful to operators and invasive for users. An authentication mechanism may reduce one attack while concentrating control in a small set of services. A filtering signal may improve network management while burdening speech or access. Code can measure some effects. The existence of code cannot decide how competing interests should be balanced.

The IETF can and should consider technical externalities. Protocol design affects privacy, security, centralization, accessibility, and operational autonomy. Refusing to examine those effects would be an artificially narrow idea of engineering. But examining an effect does not grant unlimited authority to regulate the social domain in which it appears. The institution must tie its action to protocol design, interoperability, secure operation, and its defined mission.

Deployment evidence should therefore be disaggregated. Technical adoption, user choice, operator necessity, vendor distribution, and legal mandate are not synonyms. A meeting that uses one word for all of them invites market power to masquerade as engineering truth.

A working group needs a claim-and-evidence ledger

The practical response is not a new bureaucracy around every draft. It is a disciplined habit: state the claim, identify the evidence that could support or falsify it, and record the limits of what was observed.

For implementability, a prototype may be enough to show that the core algorithm can run within plausible resources. The record should identify omitted features and untested environments. For clarity, independent implementations and divergence reports matter. For interoperability, the group should examine a matrix of versions, options, and failure paths. For scalability, controlled load tests, modeling, and production measurements may be needed. For deployability, upgrade sequence, fallback behavior, monitoring, and operational cost matter.

Security claims need adversarial tests and an explicit threat model. Privacy claims need data-flow analysis and evidence about linkability, retention, and observers. Reliability claims need failure injection and recovery results. Claims about decentralization need evidence about control points and realistic concentration, not merely the number of protocol roles described in the draft.

Each entry should separate observation from inference. "Three independent implementations exchanged these messages" is an observation. "The extension design is interoperable" is an inference bounded by the tested versions and features. "The protocol will work at Internet scale" is a broader inference requiring additional evidence. The ledger makes the distance visible.

The group should also record negative and missing evidence. Which implementation stopped? Which trial failed? Which operator class was absent? Which optional feature had no independent code? Which measurement came from a party with a commercial interest? Disclosure does not disqualify the evidence; it lets participants assign weight intelligently.

Finally, the ledger should state what the evidence cannot decide. It may show that a mechanism can enforce a policy bit. It cannot establish who is entitled to set the bit. It may show that a blocking method is accurate under a test corpus. It cannot establish that blocking is legitimate in every jurisdiction or context. It may show that central coordination improves efficiency. It cannot decide that concentration is acceptable without broader reasoning.

This modest practice would make running code more influential, not less. Evidence gains force when exaggerated claims are stripped away.

Rough consensus and running code must correct each other

RFC 7282 frames consensus around unresolved issues rather than percentages. An objection need not be accommodated, but it must be addressed. Running code can provide a particularly strong form of address because it allows the group to test a predicted defect. It can also reveal that the majority misunderstood the objection.

Suppose an objector argues that two permissible state transitions create incompatible interpretations. The authors reply that every reasonable implementation will make the same choice. Two independent implementations choose differently. The code does not automatically select the right transition, but it defeats the claim that the text is unambiguous. The working group must amend the specification or explain why one behavior is non-conforming.

Now suppose the objector predicts that a retry mechanism will collapse under a specific loss pattern. Several implementations are tested, the pattern is reproduced, and the mitigation holds across realistic conditions. The group may reasonably decide that the objection has been answered, while documenting the test boundary. The objector retains the right to challenge the consensus call through the process in RFC 2026, but does not acquire a substantive veto.

The reverse case is equally important. A dominant implementation may exhibit a behavior not required by the draft. Participants begin to describe that behavior as the standard because it is what networks do. Rough consensus can restore the distinction. The group can decide whether to specify, discourage, or remain silent about the behavior after examining effects and alternatives. Installed code is evidence about reality, not an amendment procedure.

Chairs should be especially cautious when code appears late. A demonstration immediately before a consensus call can create social pressure without allowing independent reproduction. An implementation report should identify version, coverage, and test conditions early enough for response. If code changes a material premise, reopening a focused issue is not procedural weakness. It is the point of the anti-rhetorical check.

The ideal interaction is iterative. Discussion identifies claims. Implementation tests them. Results refine text. Independent implementation tests the refinement. Deployment exposes additional conditions. Consensus evaluates the remaining issues and records why the evidence is sufficient. Neither code nor consensus receives the last word permanently because Internet conditions change.

Failure evidence deserves institutional protection

Success is easier to demonstrate than failure is to preserve. A team that completes an interoperable exchange can schedule a presentation, publish a repository, and show a trace. A team that abandons an implementation may leave no report. An operator that disables a feature after an incident may be constrained by customer confidentiality, security exposure, or commercial embarrassment. The standards record can therefore accumulate visible successes while losing the experiments that defined the real boundary.

This asymmetry matters because one well-described failure can be more informative than many routine successes. If ten implementations parse ordinary input and one crashes on a standards-compliant extension, the relevant question is not the success rate. It is whether the extension rule is ambiguous, the implementation is defective, or the specification permits a dangerous state. If several large networks deploy successfully while a small access provider cannot diagnose partial failure, the result may reveal an operational burden hidden by staff scale rather than an outlier to be ignored.

Working groups should make it safe to report failed implementation and deployment without turning every defect into an argument against publication. A failure note can identify the draft version, attempted feature, environment, observed result, suspected cause, and whether the team plans to continue. It can protect sensitive details while preserving the technical lesson. Chairs should ask explicitly for abandoned approaches and negative tests when the positive evidence appears unusually uniform.

The institution should also distinguish absence of evidence from evidence of absence. No reported failure may mean the mechanism is robust. It may mean nobody tested the dangerous condition, that implementers share one library, or that unsuccessful teams left the conversation. A claim such as "no operator has observed this problem" should identify the observation window, participating networks, measurement method, and reporting channel before it receives weight.

Counterexamples require scrutiny too. A failing prototype may misread the draft. A deployment incident may result from configuration unrelated to the protocol. An objector may select an unrealistic workload. The answer is reproduction and diagnosis, not dismissal by status. Can another team produce the behavior? Does the specification permit it? Does the condition occur in networks the standard claims to serve? Can a mitigation be described and independently tested?

This is where implementation evidence can improve institutional fairness. Participants with less influence may struggle to prevail through eloquence, meeting attendance, or repeated mailing-list presence. A reproducible artifact gives the objection a portable form. Reviewers can run it, inspect it, and compare results without relying entirely on the claimant's reputation. The artifact does not eliminate judgment, but it reduces the amount of trust demanded from the room.

Failure archives should remain connected to the decision. If the group proceeds, the consensus record should state whether the failure was reproduced, what change or limitation answered it, and which uncertainty remains. If later deployment reaches the same boundary, future reviewers can see whether the condition was anticipated or whether assumptions changed. That continuity converts dissent from a moment of friction into reusable engineering knowledge.

Institutional protection for negative evidence is therefore part of the running-code tradition. The point is not to reward failure or make every experiment permanent. It is to prevent polished success demonstrations from becoming the only code that counts. An anti-rhetorical check must be available to the critic as well as the sponsor.

Running code cannot authorize non-technical policy power

The strongest boundary comes from the IETF's own mission. RFC 3935 says the IETF accepts responsibility for all aspects of a protocol or function when it takes ownership, and conversely does not attempt to exert control over a protocol or function for which it is not responsible merely because that matter touches the Internet. This is a rule against jurisdiction by proximity.

Protocols inevitably interact with policy. Naming affects discoverability. Encryption affects monitoring. Identifiers affect privacy. Routing and filtering affect reachability. Standardized formats affect accessibility and market entry. The IETF cannot design responsibly by pretending these consequences are non-technical noise.

Yet consequence does not equal unlimited mandate. The institution can specify how a protocol behaves, identify foreseeable effects, choose safer defaults, and decline designs that make the Internet work worse. It cannot derive authority over employment, criminal law, platform moderation, competition, national security, or human rights adjudication merely because software can implement a rule relevant to those subjects.

Running code is especially dangerous as a bridge to overreach because implementation creates an aura of inevitability. Once a mechanism exists, participants may move from "we can build this" to "we should standardize it," then to "the IETF has decided the underlying policy." Each step requires a separate justification. Feasibility does not prove desirability. Standardization does not create legal command. Technical consensus does not settle every external legitimacy question.

The same boundary protects the IETF from capture. A vendor cannot arrive with deployed code and demand standard status as recognition of market success. A government cannot present a functioning control mechanism and treat implementation as proof that the policy belongs in the standards layer. An operator coalition cannot convert infrastructure ownership into authority over users whose interests differ.

Where a proposal has significant non-technical effects, the working group should specify its technical objective, identify affected parties, examine alternatives, and explain why the chosen behavior is within the charter and mission. It should seek competent input from outside its usual circle without pretending to become a legislature. The output should distinguish protocol requirements from deployment policy and legal obligations.

That is not timidity. It is institutional competence. A body strengthens its technical authority by refusing authority it cannot legitimately exercise.

Three recurring tests for meetings under pressure

Consider first a proposal with polished text and no implementation. The absence of code is not automatically fatal under current IETF practice. The working group should ask why implementation is absent, whether the proposal is implementable at this stage, what risks remain speculative, and whether publication at the proposed maturity level is appropriate. It may progress the work, seek a prototype, choose Experimental status, or narrow the claim. The answer depends on evidence, not ritual.

Consider next a proposal with one production deployment controlled by its author. This is meaningful evidence of feasibility and interest. It is weak evidence of independent readability and interoperability. The group should examine code provenance, draft version, feature coverage, operational conditions, and whether other implementers can reproduce the behavior. It should resist both dismissing real experience and treating one deployment as a mandate.

Finally, consider a widely deployed mechanism that creates a disputed externality. The group should not ignore deployment, because replacing the mechanism may impose serious compatibility cost. Nor should it say that installed base ends the policy question. It should document current dependence, technical alternatives, migration paths, affected interests, and the exact scope of IETF authority. Legacy weight belongs in the engineering analysis, not on the throne.

These tests point toward a consistent method. Ask what claim is being made. Ask what the code actually demonstrates. Ask who produced and controls the evidence. Ask which environments and affected parties are missing. Ask whether the proposed decision remains within the institution's technical responsibility. Ask what would change the conclusion.

The result may still be contested. Standards work involves judgment under uncertainty. The objective is not to eliminate discretion but to make it answerable to evidence and bounded by mission.

A better meaning for the credo

The enduring value of running code is not that software is more truthful than people. Software embodies people's assumptions, incentives, errors, and power. Its value is that execution exposes some claims to consequences that prose can postpone. It creates artifacts others can inspect, test, compare, and break.

A mature working group should seek a chain of evidence rather than a talisman. Clear text permits independent implementation. Independent implementation tests shared meaning. Interoperability tests coordination. Deployment tests operational fit. Diverse deployment tests whether the result survives beyond the sponsor's environment. Public reasoning connects those facts to the decision.

At each step, the institution should preserve the distinction between support and authority. Running code may support a finding that a design is comprehensible, interoperable, resilient, or useful. It may defeat a claim that an objection is merely theoretical. It may justify revising or abandoning a favored proposal. It may establish that a migration is technically possible.

It does not show that a large deployer speaks for small networks. It does not transform users into consenting parties. It does not make a vendor's default a community decision. It does not permit a working group to avoid an objection about rights by showing that enforcement is efficient. It does not expand the IETF's control to every social question touched by packets.

Rough consensus supplies the open judgment that code lacks. Running code supplies the practical friction that consensus lacks. RFC 2026 adds goals of fairness, clarity, testing, and timeliness. RFC 3935 supplies mission and scope. RFC 7942 offers a transparent way to describe implementation evidence without turning it into endorsement. Together, these materials support a demanding but limited principle.

Make the claim run. Make independent systems meet. Make deployment conditions visible. Then ask whether the evidence answers the actual question and whether the IETF is authorized to decide it. Running code is an excellent witness. It is not a sovereign.

Evidence and analytical limits

RFC 7282 supports the historical attribution of the 1992 credo and the analysis of rough consensus as attention to unresolved issues rather than vote counting. It is Informational and describes principles; it does not establish a mandatory implementation threshold or confer decision rights on implementers.

RFC 2026 supports the account of the standards process goals, the importance of prior implementation and testing, and the mature standard's association with independent interoperable implementations and operational experience. The current standards process has been updated by later RFCs, so the article does not treat every original maturity rule as unchanged.

RFC 3935 supports the IETF's mission, open-process and technical-competence principles, the role of real-world implementation and deployment experience, interoperability as the value of a standard, and the boundary supplied by protocol ownership. The distinction between engineering evidence and non-technical authority is an institutional inference from those stated principles.

RFC 7942 supports the description of optional Implementation Status sections, their suggested content, their benefits and limitations, and the warning that code must not replace a clear specification. The claim-and-evidence ledger proposed here is an analytical recommendation, not an existing IETF requirement.

The IETF Guide to Working Groups supports the current public explanation that chairs determine rough consensus, that polls are not formal votes, and that minority concerns must be addressed even when they are not accepted. The article does not infer that every working group applies implementation evidence in the same way or that every deployment report is independently verified.