Summary
- The IETF's rough consensus developed inside a bounded engineering method. Objections were judged for technical substance, specifications were exposed to implementation and interoperability evidence, and publication did not by itself compel anyone to deploy a protocol.
- RIR policy processes retained the vocabulary of open participation, chairs, consensus calls and unresolved objections, but applied it to rules that can determine allocation eligibility, transfer recognition, registration status and continuity. One registry implementing a policy is not the equivalent of independent running code.
- Consensus remains useful for refining number policy and identifying technical failure. It should not be treated as proof that affected operators authorized a distributive rule. High-impact registry policy needs separate evidence of authority, operational effect, cost distribution, contractual notice, review and practical exit.
The borrowed phrase concealed a change of entity
"Rough consensus and running code" was memorable because it joined a decision method to a reality check. The phrase did not say that a room's mood created technical truth. It said almost the opposite: discussion could move without unanimity, but working systems were entitled to defeat elegant theory. A specification earned weight by coordinating independent actors that could test it, reject it, revise it or simply decline to implement it.
Regional number policy adopted the first half of that inheritance more successfully than the second. Across the RIRs, public lists, open meetings, chairs, last calls, objections and consensus became the accepted grammar of policy development. That grammar brought real gains. It made many allocation rules visible, allowed practitioners to identify operational errors and restrained simple majority control.
The entity being decided had changed, however. An IETF working group usually settles the behavior of a protocol, format or procedure within a defined technical remit. A number-policy forum can settle whether an applicant qualifies for a scarce block, whether a transfer is recognized, what evidence a holder must provide or which conditions attach to registration. Those decisions can alter asset value, market access and service continuity. They do not become narrow engineering questions merely because network engineers discuss them.
The central mistake was therefore not borrowing consensus. Institutions routinely learn from one another. It was borrowing a conclusion rule without carrying over the conditions that made the rule tolerable: bounded scope, technical falsifiability, implementation diversity, voluntary adoption and a clear distinction between specification and command. Once those conditions disappeared, consensus language began doing work it was never designed to do.
1992 joined an engineering credo to a new administrative layer
The historical timing matters. Dave Clark's 1992 IETF plenary formulation, preserved in RFC 7282, opposed kings, presidents and voting to rough consensus and running code. In the same year, RFC 1366 proposed regional registries as a response to address-space administration and routing-table pressure. The Internet needed both better protocol coordination and distributed number administration as commercial and international growth accelerated.
These developments shared people, practical concerns and institutional style. The regional registry was not conceived as a sovereign legislature. It was an administrative answer to scale: distribute registration work, preserve uniqueness, improve local service and support routing architecture. Early guidance connected conservation, aggregation and accurate records to address-management decisions.
That proximity made IETF practice an attractive source of legitimacy. If open technical collaboration could produce global protocols without a government or formal membership roll, an open regional forum could appear capable of producing number policy by the same method. The resemblance was strongest when allocation judgments were close to routing constraints and the unallocated pool was treated as a technical commons.
But proximity was not identity. A packet format can be implemented by several teams and tested across a wire. An allocation rule divides scarcity among applicants. A transfer rule determines which transactions an authoritative registry will recognize. A utilization threshold can favor one network design over another. A legacy-resource rule can change the practical leverage of parties whose claims predate the registry. Those are administrative and distributive choices informed by engineering, not protocol designs waiting to compile.
The institutional fork was visible from the beginning. Regionalization solved a coordination problem while creating a decision point over access. The more valuable and exhausted IPv4 became, the less plausible it was to treat every registry choice as an extension of protocol engineering.
Rough consensus was never a softer name for majority rule
The RIRs were right to reject a crude vote as the only measure of technical merit. RFC 2418 says that 51 percent does not constitute IETF rough consensus and warns that dominance is not measured by volume or persistence. RFC 7282 develops the stronger account: a chair should examine whether material technical objections have been addressed, not count how many people support each side.
That method solves a real failure of voting. A minority implementer can discover that a proposed message sequence deadlocks. One security reviewer can identify an attack that a hundred expressions of support do not answer. A deployed network can show that an assumption about topology is false. The objection matters because it predicts failure, not because the objector controls a ballot.
RIR processes imported much of this reasoning. LACNIC's published process says consensus does not depend on counts of yeses, noes and abstentions and requires critical technical objections to be resolved. APNIC distinguishes a show of hands from a vote and asks chairs to work through minor and major objections. RIPE relies on reasoned objections, chair assessment and last call. AFRINIC materials expressly invoke rough consensus, and its 2026 chair-selection guidance even requires practical understanding of RFC 7282.
Those are not cosmetic similarities. They demonstrate a conscious lineage. The problem is that the IETF test asks whether an objection reveals a defect in a technical outcome. A registry forum must also confront objections about authority, unequal cost, contract, reliance, market structure and rights. Calling all of them "technical" either excludes valid concerns or disguises political judgment as engineering.
The IETF's legitimacy comes from the artifact, not the meeting
RFC 3935 defines the benefit of an Internet standard through interoperability: multiple products implement the same specification and work together to provide useful functions. It also says an IETF standard describes how to do something consistently; it does not imply that the IETF mandates use or polices compliance.
That boundary changes the meaning of consensus. The working group is not presumed to represent every person affected by the Internet. It is trying to produce a technically competent public artifact. The artifact can be inspected, implemented and compared with alternatives. If the text is ambiguous, independent teams may produce incompatible behavior. If the design is impractical, deployment may stall. If it is useful, autonomous networks and vendors can adopt it without asking the working group for political permission.
The meeting is therefore only one part of the proof. Open participation can improve the specification and reveal objections. Area review, last call and appeals add procedural checks. Yet the standard's durable force comes from what independent systems do with it. A crowded room cannot make two incompatible implementations exchange traffic.
RIR policy reverses this relation when the registry's authoritative record makes the decision effective. The forum discusses; chairs find consensus; the secretariat implements; account holders face the resulting condition. The policy does not need independent adoption to bind within that registry relationship. The institution can point to the process as the source of validity even when the governed operator never participated and no alternative registry service is available.
This does not make every RIR policy illegitimate. It means the IETF analogy cannot supply legitimacy by itself. The artifact in number policy is a rule exercised through institutional control, not merely a specification offered to autonomous implementers.
Running code was a veto held by reality
The "running code" half of the credo is often reduced to a cultural slogan. Its deeper function is evidentiary. A design claim should encounter implementation cost, state transitions, error handling, interoperability, security failure and operational scale before rhetoric hardens into certainty.
The historical standards process made that principle unusually concrete. RFC 2026 described an Internet Standard as stable, technically competent and supported by multiple independent interoperable implementations with substantial operational experience. Under its former three-level system, advancement to Draft Standard required at least two implementations from different code bases and documented interoperability.
The current position is more nuanced. RFC 6410 reduced the standards track to Proposed Standard and Internet Standard and removed the formal interoperability-report requirement. It did not declare implementation irrelevant. Advancement to Internet Standard still requires at least two independent interoperating implementations, widespread deployment and successful operational experience. RFC 6410 says deployment and use can demonstrate interoperability even without a separate report.
This nuance matters because criticism of RIR policy should not romanticize the IETF. Proposed Standards can be published before implementation, some documents never progress, and running code can be concentrated in a few vendors. The IETF does not perfectly realize its own credo.
Even so, the decisive feedback loop remains available. Protocol claims can be tested by parties outside the institution. Failures are observable at interfaces. Alternative implementations can expose ambiguity. Operational evidence can motivate revisions. RIR policy often has no equivalent independent trial before authoritative application.
A secretariat implementation is not independent implementation
RIR policy documents often include implementation analysis. RIPE's process provides for an impact analysis covering likely effects and work required. ARIN staff and legal review can identify operational, legal and liability concerns. APNIC staff manage implementation after endorsement. These are valuable safeguards and should not be dismissed.
They are not the same as two independent implementations. A registry secretariat translating approved text into forms, account checks and internal procedures demonstrates that one institution can administer its own rule. It does not show that independent operators interpret the rule consistently, that another provider can reproduce the service, or that affected networks can continue operating under a different implementation.
The difference is structural. In protocol development, implementations are often controlled by distinct organizations that meet at a public interface. Neither implementation can make the other conform by altering an authoritative account. Successful interoperation is evidence that the specification carries meaning across control boundaries.
In registry policy, one body may write the operational procedure, evaluate evidence, update the record and determine whether an applicant passed. The account holder cannot expose ambiguity by running a competing policy engine whose output receives equal recognition. A favorable internal readiness assessment can therefore coexist with high external cost, inconsistent judgment or no practical exit.
Calling the deployed policy "running code" confuses automation with independence. A web form that enforces a threshold is code. It does not prove the threshold is justified. An automated transfer check can be reliable while the underlying eligibility rule remains contestable. The relevant test is not whether software exists, but whether the claimed result survives independent operation, adversarial cases and comparison with the burden imposed on those governed.
Interoperability disciplines scope
IETF work is not always narrow, but the demand for interoperability creates a natural boundary. A working group must identify which systems exchange what information and what consistent behavior is necessary at that interface. Its charter, milestones and document scope can be challenged when the work expands beyond the protocol or function it owns.
RFC 3935 states a protocol-ownership principle: when the IETF is not responsible for a protocol or function, it does not attempt to exert control over it. The statement is institutional self-description, not a constitutional law for every Internet body. It nevertheless captures an important restraint. Technical competence does not become general jurisdiction because the Internet is affected.
RIR policy has a weaker limiting interface. "Management of Internet number resources" can cover allocation, registration, transfers, documentation, holder status, leasing, route-security services and enforcement. Each topic is connected to the registry record, so institutional convenience can make expansion appear in scope.
The appropriate technical minimum is much narrower: preserve uniqueness, maintain accurate authoritative state, support necessary discovery and delegation, and avoid changes that make the shared numbering architecture fail. Beyond that minimum, a registry rule needs an additional source of authority. A decision about commercial leasing may affect record accuracy, but that connection does not by itself determine the permissible business model. A transfer rule may prevent duplicate registration, but uniqueness does not decide every eligibility condition.
Interoperability asks what must be common for systems to work together. Registry policy too often asks what the incumbent institution can administer consistently. Those are different questions. The second invites a broad administrative domain where the first would permit plurality.
Voluntary adoption was the missing constitutional brake
An IETF publication does not normally switch on a protocol across the Internet. Vendors decide whether to implement it. Operators decide whether and when to deploy it. Purchasers may require it by contract, and regulators may incorporate it under law, but those external bodies must own their decisions. The IETF itself does not police usage.
Voluntary adoption is not pure freedom. Network effects, customer requirements and dominant vendors can make deviation expensive. A protocol may become practically unavoidable. Yet the path from publication to consequence remains visible. Adoption produces evidence, and an actor imposing a requirement can be identified.
RIR policy can become effective through the registry's control of authoritative recognition. An operator that entities cannot simply implement a different allocation policy while preserving the same registration relationship. Refusal may mean no allocation, no recognized transfer, a disputed record or loss of access to a service. Regional exclusivity makes exit far harder than declining a new protocol feature.
This changes what consensus must prove. In the IETF, rough consensus can justify publishing a specification for the world to test and adopt. In an RIR, the same conclusion can activate a rule against parties who neither participated nor possess a substitute provider. The burden should therefore rise, not remain identical.
At minimum, the policy record should identify the contractual or corporate authority for the consequence, which affected classes received notice, whether the change applies prospectively, what reliance is protected, how evidence is challenged and what realistic alternative exists. Open attendance is not a substitute for those protections. The right to enter a meeting is weaker than the right to refuse a rule without losing continuity.
Open participation does not identify the principal
The IETF avoids a formal membership electorate. RFC 7282 notes that voting is impractical partly because the organization cannot identify who would receive a vote. Entities are recruited for expertise, implementation and relevant perspectives. Consensus evaluates issues rather than representative mandates.
That structure is defensible for producing technical specifications. It is dangerous when translated into a claim that entities authorize burdens on absent operators. A public mailing list can be open to everyone while still attracting a small, specialized and employer-supported population. The people who can follow every version, attend meetings and answer last-call messages are not necessarily a sample of every network that will bear the rule.
RIR descriptions often shift between "community," "membership" and "Internet community." APNIC says policies are decided by the membership and broader Internet community. RIPE policy is made through an open community separate from the RIPE NCC corporate membership. ARIN permits interested persons inside and outside the service region to participate while assigning formal roles to its Advisory Council and Board. These arrangements can all facilitate expertise, but they do not identify one common principal.
A entity may speak from operational experience without being authorized by their employer. A consultant may know the policy better than most resource holders while representing no affected account. A registry employee may provide essential facts while the institution has an implementation interest. None of these facts invalidates the person's argument. They limit what participation can prove.
Consensus can establish that the observed forum addressed objections. It cannot establish that the governed population consented. RIR policy needs a separate account of who bears the decision and which legal, contractual or membership relationship authorizes it.
Technical objections are not the whole objection set
The strongest version of rough consensus gives a valid technical objection more weight than many unsupported preferences. That is precisely why the phrase becomes unstable in distributive policy. What counts as a valid objection when the rule allocates cost and opportunity rather than selects packet behavior?
Suppose a transfer proposal preserves uniqueness and can be implemented securely but increases transaction time for smaller holders. The objection is not a protocol failure. It concerns cost distribution. Suppose a needs-based rule is administratively consistent but discounts leasing or cloud models. The dispute concerns economic assumptions and equal treatment. Suppose a legacy holder challenges new contractual conditions. The issue may involve reliance, title and jurisdiction. None can be resolved by showing that software runs.
If chairs consider only "technical" objections, consequential harms can disappear from the consensus test. If they broaden technical to include every policy concern, the chair receives unbounded discretion to weigh law, economics and rights without a defined standard. Either move breaks the original method.
The answer is to classify objections. Technical integrity objections concern uniqueness, routing architecture, security, data consistency and operational feasibility. Administrative objections concern staffing, systems and cost of delivery. Distributional objections concern who gains, pays or loses options. Rights objections concern contract, reliance, notice, remedy and continuity. Evidence and decision authority differ across those classes.
Rough consensus is strongest in the first class. It can help refine the second. It cannot, without more, authorize the third or settle the fourth. A policy record that labels each unresolved objection would be more honest than one universal consensus declaration.
The five RIRs did not copy one identical procedure
The migration should not be described as a coordinated act of textual copying. The five regions developed different procedures, legal structures and decision chains. Their variation itself shows why "the RIR consensus model" is too simple.
RIPE's current PDP emphasizes openness, transparency, reasoned objections, impact analysis, working-group chair judgment and last call. Its documentation also distinguishes policy from RIPE NCC business practices and implementation procedures. APNIC combines Policy SIG consensus, an APNIC Member Meeting consensus stage, a final comment period and Executive Council endorsement. LACNIC defines consensus through meaningful opinions and resolution of critical technical objections rather than vote totals.
ARIN is more visibly corporate. Its Advisory Council makes policy decisions by roll-call majority, recommends text, and the Board reviews the history before adoption. Staff and legal review form part of the record. The broader discussion is consensus-oriented, but formal institutional votes remain visible. AFRINIC's history includes rough-consensus calls, Board ratification, appeals and repeated disputes about how online and meeting participation should be weighted.
These distinctions matter. Some regions keep corporate ratification explicit; others present chair-assessed community consensus as the decisive conclusion. Some require detailed impact material; others rely more heavily on discussion stages. Some distinguish membership from the open forum more clearly than others.
The common borrowed element is not one procedure. It is the belief that open, bottom-up, consensus-based discussion can legitimate number policy. That belief should be tested against each region's actual authority chain rather than celebrated as a brand. Where a Board adopts the policy, the Board should own the decision. Where contracts incorporate it, the contract should state how changes bind. Where chairs declare consensus, the declaration should not claim representation it cannot demonstrate.
RFC 7020 records the boundary but does not solve it
RFC 7020 is valuable because it acknowledges institutional separation. It describes the IETF as responsible for non-policy aspects of Internet addressing, including architectural definitions, technical goals and constraints, specialized blocks and related recommendations. It says relevant IETF recommendations must be considered in number-policy discussions, while registry structure, policy and process evolve elsewhere.
The document also records that ICANN and RIR policy superseded policy and operational material in RFC 2050. That is a mature admission: early technical guidance did not remain the permanent source of allocation authority merely because it had an RFC number.
Yet institutional separation alone does not confer legitimacy on whatever replaces the old guidance. Saying that RIR communities develop policy identifies a venue. It does not prove that every affected operator authorized the venue, that consensus measures the right population or that distributional choices are technically necessary. RFC 7020 is an IETF-produced description of responsibility, not a universal grant of legislative power.
Its best principle is more modest. Technical recommendations should be considered regardless of venue. Consideration means the RIR cannot ignore an architectural constraint because policy is made elsewhere. It does not mean the IETF can decide regional rights. Conversely, the IETF boundary prevents an RIR forum from using technical language to claim competence over every commercial or legal consequence associated with an address.
The relationship should be evidentiary. The IETF supplies specifications, constraints and implementation experience. The registry institution supplies an explicit authority chain for any binding rule. Neither can borrow the other's legitimacy without explanation.
Impact analysis is necessary but still mostly predictive
An impact analysis can expose the work a policy will require, the records affected, the legal questions raised and the likely implementation date. It is one of the most useful RIR safeguards because it forces prose to meet administration before adoption.
Prediction is not observation. Staff can estimate how many requests will be affected, but applicants may change behavior. A transfer restriction can drive transactions into less visible structures. A documentation requirement can favor firms with counsel and disadvantage smaller operators. A route-security condition can interact with software and upstream practices in ways a registry cannot observe from its own service perimeter.
The IETF's implementation tradition suggests a stronger model: reversible trials where possible, explicit failure criteria and evidence gathered from more than the implementing institution. A number policy cannot always be piloted without unequal treatment, but many components can be tested. Data formats can interoperate. Verification steps can be timed. Appeals can be simulated. Historical cases can be replayed. Voluntary early adopters can expose burden. Independent providers can attempt to reproduce the decision from the same evidence.
The review should continue after adoption. Did processing time change? Which classes withdrew requests? How often did staff exercise discretion? What errors were corrected? Did the expected routing or registration benefit occur? Who paid for compliance? A policy called current should earn that description through measured effect, not merely the absence of a new proposal.
Running evidence for number policy is broader than running code. It includes operating outcomes, market responses, continuity incidents and appeal results. The key is that the institution does not grade itself using only the metrics it controls.
Policy diversity is evidence that the issue is not a wire standard
RIR policies differ on transfers, documentation, allocations, legacy treatment and many procedural details while the global Internet continues to route across regional boundaries. That coexistence proves two things at once. Some common number architecture is indispensable, and much regional policy is not required for packet-level interoperability.
If two networks can exchange traffic while their registries apply different transfer eligibility rules, no single eligibility rule can be defended as the equivalent of a common wire format. It may still serve a legitimate regional purpose. The institution must identify that purpose and justify the burden in its own name.
Policy diversity can be useful evidence. A region that adopts a rule becomes a natural comparison with regions that do not. Outcomes will never be perfectly controlled: markets, law, address supply and membership differ. Even imperfect comparison is better than treating one consensus call as proof of universal necessity.
The comparison should ask narrow questions. Did registration accuracy improve? Did disputes fall or move elsewhere? Did transaction time rise? Did unused space become more available? Did smaller operators face higher fixed costs? Did routing incidents change? Were rights preserved during transition? The answers can support revision without implying that the region with a different rule is technically incompatible.
This approach also limits global harmonization. Common policy is justified where divergence creates duplicate authority, unusable delegation or another demonstrable coordination failure. Convenience for incumbent institutions is not enough. The burden lies with anyone who wants a regional administrative preference to become a global condition.
Legitimacy is an empirical question, not a property of the process diagram
Independent research makes the gap between access and authorization harder to ignore. Jesse Sowell's comparative work on bottom-up Internet institutions separated active consensus, passive consensus and procedural review across RIRs. It also identified a recurring assumption: these mechanisms work as sources of authority only if participation is sufficient to connect the active forum to the wider population whose interests are invoked. The existence of multiple access points did not answer who participated most consistently or effectively.
More recent research by Mathias Jongen and colleagues examined legitimacy beliefs concerning AFRINIC, APNIC and LACNIC. Their findings were not uniformly hostile. APNIC and LACNIC received substantial approval across constituencies, while evaluations of AFRINIC were more divided. That variation is important because it rejects two easy stories at once. RIR legitimacy is neither guaranteed by the institutional model nor disproved by the absence of elections resembling a state.
The practical lesson is to measure what process rhetoric tends to assume. Who knew about the proposal? Which operator classes contributed? Did respondents believe the institution was entitled to make this kind of decision, or merely that its service was useful? Did acceptance survive when the rule imposed direct cost? Could a dissatisfied operator obtain correction or leave?
These questions do not convert legitimacy into an opinion poll. A technical minority can still be right, and a popular rule can still violate a contract. The evidence instead prevents an institution from asserting that openness necessarily produced authorization. Approval, participation, technical soundness, lawful authority and operational dependence are separate facts. A credible RIR should want to know all five.
A better RIR test separates specification, service and rights
Number governance would become clearer if proposals were divided into three instruments. The first is a technical specification: formats, state transitions, identifiers, signatures, discovery and interoperability behavior. It should be tested through independent implementations and operational trials. Rough consensus among technically competent entities is highly relevant here.
The second is a service rule: submission channels, response times, evidence handling, security controls, correction and continuity. It should be assessed against measurable service outcomes, cost, accessibility and provider replaceability. Operator experience matters more than room sentiment.
The third is a rights rule: eligibility, transfer restrictions, adverse action, contractual incorporation, reliance, appeal and the effect of exit. It needs an identified legal or corporate authority, notice to affected parties, reasoned proportionality and an enforceable remedy. Technical consensus can inform feasibility but cannot supply the missing authority.
Some proposals contain all three. A route-security policy may specify data entities, establish service procedures and attach consequences to a holder. The solution is not to pretend the categories are separable in operation. It is to prevent one type of evidence from deciding every category.
The final record should show which technical claims were tested, which service outcomes are expected, which rights change, who authorized the change and when it will be reviewed. Chairs can still summarize consensus on the technical question. Boards or other accountable bodies must own consequential rights choices. Contracts must reveal how the result reaches account holders.
This structure would preserve the useful inheritance from the IETF while ending the fiction that one consensus label performs engineering, administration and constitutional authorization at once.
The replacement for running code is demonstrated operational effect
RIR policy cannot always be compiled into competing implementations, but it can still be subjected to a discipline of demonstrated effect. Every proposal should begin with a falsifiable problem statement and a baseline. How often does the alleged problem occur? Which records or operators are affected? What cost or risk follows? Which evidence would show that the proposal failed?
The proponent should then state the mechanism. A rule may improve accuracy by requiring a defined proof, reduce duplication through a state check or improve continuity through escrow and export. The mechanism must connect the requirement to the claimed result. Moral language about stewardship or community is not a substitute.
Before activation, the institution should test representative cases, edge conditions, appeals and reversal. After activation, it should publish outcome measures and error rates. High-impact rules should expire or return for review unless the evidence supports continuation. Where another region uses a different mechanism, comparative results should be considered.
Independent operational evidence is crucial. Operators can document transaction delay, renumbering exposure, customer impact and integration cost. Brokers, security researchers and civil-society reviewers may identify incentives or exclusions. Their claims should be checked, not accepted by status. The registry should disclose the limits of its own measurement.
This is not an attempt to replace judgment with metrics. Some harms are rare and catastrophic; some benefits are difficult to quantify. The purpose is to keep policy answerable to the world outside the forum. Demonstrated effect plays the role that running systems play in protocol work: it gives reality standing against a polished rationale.
Exit is the adoption test RIR policy never had
The strongest discipline on a standard is the possibility that implementers will not adopt it. The strongest discipline on a service provider is the possibility that customers can leave without losing the thing being served. Traditional regional registry arrangements provide little equivalent pressure because moving the registration service for the same number resources is limited, uncertain or unavailable.
Voice is not a substitute for exit. An operator can post to a list, attend a meeting, contact a Board and pursue an appeal while remaining dependent on the same authoritative institution. These channels may correct errors, but their existence does not make the relationship voluntary in the same sense as protocol deployment.
A credible exit right would preserve accurate state, provenance, pending disputes and global uniqueness while allowing the holder to move to a qualified provider. It would not permit duplicate registration or evasion of lawful orders. It would make the registry compete on service and restraint rather than on control of the record.
Even before such portability exists, policy analysis should include an exit-impact statement. Does the proposal make movement harder? Does it centralize non-exportable evidence? Does it bind security credentials to one institution? Does it impose conditions that survive termination without a clear justification? Does it allow continuity during dispute?
The answers reveal whether a rule resembles an interoperable standard or a dependency expansion. A standards tradition without an adoption or exit constraint can become the opposite of its origin: consensus at the center, compulsion at the edge.
Consensus should find a workable answer, not manufacture a mandate
Rough consensus still belongs in RIR policy development. It is better than allowing the loudest faction to win a simple poll. It encourages reasoned objection, revision and compromise. It can reveal when a proposal cannot survive technical scrutiny. The repair is not to replace every discussion with corporate voting.
The repair is to limit what the consensus finding claims. Chairs should say which questions were considered, which technical objections were resolved, which non-technical objections remain, who participated and what evidence was missing. Silence should be described as silence, not consent. A small but informed discussion can produce a useful recommendation without being portrayed as authorization from a region.
Binding effect must come from a separate and visible chain. If a Board adopts the policy under corporate documents, state that fact. If an account contract incorporates future policies, identify the clause and the limits of amendment. If law constrains the rule, record the legal review. If membership approval is required, distinguish members from open entities. If operators retain a practical exit, explain it.
This separation protects everyone. Chairs are not forced to act as legislators. Technical entities can focus on evidence without being treated as representatives. Boards cannot hide behind "the community." Account holders can identify the decision-maker and remedy. The IETF can remain an important source of technical constraint without becoming a borrowed sovereign.
A nine-part discipline for future number policy
A more rigorous policy record would answer nine questions.
First, what operational problem is observed, and what baseline supports it? Second, which part is required for uniqueness, interoperability, security or another narrow technical function? Third, what independent implementation, replay, trial or cross-provider evidence tests the mechanism? Fourth, which operator classes bear cost or lose options?
Fifth, what authority makes the rule binding: contract, corporate decision, membership act or law? Sixth, how were affected operators notified, including those absent from the policy forum? Seventh, what alternatives or equivalent controls remain available? Eighth, what review, stay, appeal and correction exist? Ninth, can the operator or service migrate without losing valid registration state or creating duplicate authority?
No single answer is sufficient. A technically necessary state transition can still be administered unfairly. Broad participation can still produce a rule outside the institution's authority. A lawful Board decision can still be technically destructive. A smooth implementation can still impose an unjustified market burden.
The discipline is intentionally harder than a consensus call because the consequence is harder than publishing a specification. A registry rule can change the conditions under which an existing network preserves recognized access to a foundational identifier. Its legitimacy should not depend on whether a chair heard enough support after objections were discussed.
The IETF's best contribution is not a ritual phrase. It is the insistence that technical claims meet independent reality, that competence has boundaries and that a standard does not police its own use. RIR policy should borrow those restraints before borrowing any more prestige.
The missing half was the part that restrained power
Regional registries did not make a mistake by opening policy discussion or by seeking consensus. Those choices were more accountable than closed administrative discretion. The error was constitutional inflation: treating a method for producing workable technical agreement as if it also represented affected operators and authorized binding distributional choices.
The lost constraints explain the inflation. Running code meant theory could lose. Independent implementations meant one institution did not grade its own specification. Interoperability defined the necessary common surface. Voluntary adoption separated publication from command. Narrow protocol ownership limited the standards body's jurisdiction.
RIR policy retained public discussion and chair judgment but often replaced those external checks with one authoritative implementation. Once the policy changed the registry record, the operator had few practical ways to refuse. "Community consensus" then did more than technical rough consensus ever promised: it supplied the rhetoric of representation, the rule and the defense of the institution enforcing it.
The route forward is neither government takeover nor procedural nostalgia. It is thinner common policy, stronger operational evidence, explicit authority, classified objections, measurable review and portable service. Technical questions should receive technical consensus. Rights questions should receive rights protections. Institutional decisions should be owned by the institutions that make them.
Rough consensus remains valuable when it is a disciplined search for an answer that works. It becomes dangerous when the search method is mistaken for a mandate. The RIR system borrowed the words. Its next reform should recover the limits.
Evidence and analytical limits
RFC 1366, RFC 1466 and RFC 2050 support the historical account of regionalized number administration and the close relationship between routing, conservation and registration concerns. They do not establish present RIR authority or validate every later regional policy.
RFC 2418, RFC 3935 and RFC 7282 support the account of IETF rough consensus, technical objections, interoperability, protocol-ownership limits and the absence of IETF power to mandate deployment. These documents describe IETF practice and ideals; they do not prove that every working group follows them perfectly.
RFC 2026 and RFC 6410 support the historical and current role of independent implementation, deployment and operational experience in standards maturity. RFC 6410 removed a formal interoperability-report requirement, so the article does not claim that every current IETF publication requires two implementations before initial approval.
RFC 7020 supports the described division between IETF technical responsibility and number-policy venues and records that RIR and ICANN policy superseded parts of RFC 2050. It is an institutional description, not independent proof that any particular regional policy is legitimate.
The public PDP materials of ARIN, APNIC, RIPE, LACNIC and AFRINIC support the comparative description of each institution's stated process. They are evidence of published procedure, not neutral proof that participation is representative, implementation is consistent or every consensus call is sound.
Jesse Sowell's comparative study of bottom-up Internet governance supports the distinction among active consensus, passive consensus and procedural review and records participation as an unresolved legitimacy question. Mathias Jongen and co-authors' 2026 study supports the claim that legitimacy beliefs vary across RIRs and are not inherent in the institutional design. Neither study decides the validity of a particular current policy.
Lu Heng's analysis of rough consensus and the RIR system supplies the article's central critical framing: RIR institutions retained consensus language after weakening running-code discipline and extending policy into operator rights. The detailed nine-part test and three-instrument separation are this article's analytical proposals.