Summary
- The IETF's consensus method is issue-based rather than vote-based. RFC 7282 asks whether technical objections have been understood and answered; RFC 2026 tests specifications through openness, implementation, interoperability, operational experience, and appeal. These are standards-process virtues directed toward technical output.
- RFC 3935 defines the IETF's mission as producing engineering documents, says standards describe how to interoperate rather than mandate use or police users, and limits IETF control to protocols or functions for which it accepts responsibility. That scope does not confer authority over contracts, corporate interests, registry accounts, or scarce address holdings merely because they affect the Internet.
- A number-resource policy forum may properly use rough consensus for technical policy design, but an adverse rule affecting an identified holder needs additional legitimacy: a valid mandate, a defined constituency, notice, evidence, conflict control, proportionality, reasoned decision, and independent review. RFC 8714's formal treatment of trustees and property reinforces the point that legal control is not exercised by a hum alone.
A method formed around engineering work
The first IETF meeting took place in January 1986 in San Diego. The meeting records describe a small technical gathering, not a legislature and not a licensing court. The institution that grew from it had to coordinate engineers from autonomous networks and competing organizations without a government capable of ordering everyone to implement one design. Its power would depend on useful specifications, voluntary adoption, and the ability of implementations to communicate.
That origin explains rough consensus better than any slogan. Protocol design contains uncertain tradeoffs. A packet format can be elegant but expensive to implement. A security mechanism can be strong but impossible to deploy across installed equipment. A transition can preserve architectural purity while stranding users. Experts can disagree honestly, and waiting for unanimity can allow one entity to block work indefinitely. Simple majority voting is also defective: the number of people in a room says little about whether a protocol will converge, survive failure, or interoperate.
The IETF developed a method suited to this problem. Entities expose technical objections in public. Editors revise documents. Implementers test assumptions. Chairs determine whether significant issues have been addressed. The Internet Engineering Steering Group reviews proposed publication. Decisions can be appealed when procedure or judgment fails. The resulting specification gains influence because engineers can inspect it, implement it, and observe whether it works.
The method's legitimacy is epistemic before it is coercive. It is good at discovering defects and building a design that autonomous networks can choose to deploy. “Running code” supplies evidence that a proposal is more than rhetoric. Interoperability demonstrates that independent implementations share enough meaning to communicate. Operational experience reveals failure modes that argument alone misses.
None of this requires the IETF to seize an unwilling entity's equipment or extinguish a contract. A network that rejects a voluntary protocol may lose compatibility or market relevance, sometimes severely, but the IETF standard is not itself a judicial order transferring the network's assets. The distinction between influential coordination and compulsory disposition was present from the beginning. It should remain visible when other Internet institutions borrow the IETF's language.
RFC 7282 makes consensus a test of issues, not a count of people
RFC 7282, published in 2014, is the clearest account of the IETF's consensus discipline. It rejects the idea that humming is an anonymous ballot. A hum can help a chair locate the state of discussion, but the volume does not decide the technical question. Rough consensus exists when objections have been addressed, even if they have not all been accommodated.
That formula is exact. To address an objection is to understand it, evaluate its consequences, and decide whether the design must change. An objector may remain dissatisfied. The chair can nevertheless conclude that the group has considered the issue and that declining the requested change does not defeat the work's technical requirements. Conversely, a large majority cannot erase an unanswered technical defect. One informed objection can matter more than a hundred unsupported preferences.
RFC 7282 therefore gives the consensus caller a demanding role. The chair needs command of the purpose and architecture of the work. The decision must rest on a reasoned account of issues, not popularity, organizational status, persistence, or the desire to finish. Humming begins a conversation or tests the chair's understanding; it does not substitute for the explanation.
This method is well fitted to design. Consider two wire formats. Entities can identify parsing complexity, extensibility, ambiguity, bandwidth, implementation cost, and backward compatibility. They can build both, run tests, and compare failure. Even a value-laden tradeoff can be disciplined by the charter and the requirements document. The relevant question is whether the chosen format meets the technical purpose at acceptable cost.
The fit becomes weaker when the proposition is “this identified party should lose control of a scarce resource.” The critical objections may concern title, contract, corporate authority, reliance, discrimination, evidence, or jurisdiction. A chair's technical judgment cannot establish those facts. Running code cannot determine who signed a valid agreement. Interoperability does not decide whether a transfer was authorized. An issue-based discussion remains useful, but the subject requires institutions competent to find facts and apply law.
The error is not using consensus outside a protocol working group. Consensus can improve many collective decisions. The error is treating the quality of the deliberative method as a source of substantive jurisdiction. A fair conversation among engineers does not acquire the power to dispose of another person's rights merely because all objections were discussed.
RFC 2026 defines a standards process and repeatedly marks its scope
RFC 2026, the 1996 statement of the Internet Standards Process, is equally instructive. It describes standardization of protocols and procedures. Its goals are technical excellence, prior implementation and testing, clear documentation, openness and fairness, and timeliness. A mature Internet Standard is stable, well understood, technically competent, supported by multiple independent interoperable implementations, informed by operational experience, publicly supported, and recognizably useful.
Those criteria supply a theory of technical legitimacy. A specification should survive exposure to interested parties and real networks. The process is flexible because different technologies require different evidence. It is open because affected implementers must be able to inspect and challenge design. It includes conflict-resolution and appeal mechanisms because chairs and steering bodies can err.
RFC 2026 also distinguishes categories. Not every RFC is a standard. Internet-Drafts have no formal status and can change or disappear. Technical Specifications describe protocols, services, procedures, conventions, or formats. Applicability Statements explain how specifications should be used in a defined context. Best Current Practice documents record community conclusions about operations or IETF procedure. The labels matter because publication does not create unlimited authority.
The document addresses intellectual property rights associated with standards, but that does not transform the IETF into a general property tribunal. Its IPR provisions seek enough disclosure and permission for specifications to be evaluated and implemented. They manage the relationship between standardization and rights held elsewhere. They do not assert that consensus can cancel a patent, transfer a copyright, or decide every dispute over ownership.
This is a useful analogy for number resources. A registry policy can specify the technical and administrative conditions under which a transfer will be recorded. It can define the evidence the registry needs, the serialization of changes, and the safeguards against conflicting claims. Those are procedural and interoperability questions. Whether a particular seller had authority to transfer, whether a creditor has an enforceable interest, or whether a registry may revoke a long-standing holding can require contract and law beyond the policy text.
RFC 2026's openness remains necessary in that setting. It is not sufficient. The standards process assumes that success will be demonstrated through adoption and operation. A resource holder cannot “decline to implement” a revocation while keeping the authoritative registration unchanged. When the forum's decision is executed through a unique database, the effect is closer to administration than recommendation. The process must be upgraded to match the consequence.
RFC 3935 supplies the limiting principle
RFC 3935, the IETF mission statement adopted in 2004, states the boundary with unusual clarity. The IETF's mission is to produce high-quality, relevant technical and engineering documents that make the Internet work better. Its cardinal principles include open process, technical competence, a volunteer core, rough consensus and running code, and responsibility for protocols the IETF owns.
The definition of a standard is decisive. An IETF standard says, in substance, that if an implementer wants to perform a function according to the standard, this is how to do it. The document expressly distinguishes that from mandating use or policing users. The benefit lies in interoperability: independent products work together because they implement the same specification.
The “protocol ownership” principle is also bounded. When the IETF takes responsibility for a protocol or function, it accepts responsibility for all aspects of that protocol. When it is not responsible for a protocol or function, it does not seek control merely because the subject touches the Internet. This is institutional self-restraint, not weakness. Competence and legitimacy increase when a body knows which questions belong elsewhere.
Number-resource governance touches protocols, but address interests are not reducible to protocol design. The IETF defines the syntax and behavior of the Internet Protocol and related mechanisms. IANA and the Regional Internet Registries maintain allocation and registration hierarchies. Incorporated registries contract with members or customers. Operators route addresses. Lessors and lessees divide use and control. Courts determine corporate, contractual, insolvency, and property questions under applicable law. No single layer inherits authority over all the others.
RFC 3935 consequently rebuts two opposite errors. The first says engineering has nothing to contribute to rights disputes. That is false. Technical facts determine whether a remedy will fragment routing, create conflicting certificates, expose private data, or interrupt service. The second says engineering consensus can settle the rights dispute because addresses are technical identifiers. That is also false. The fact that a valuable interest is represented in a technical system does not make every dispute about it a protocol question.
The limiting principle is competence tied to function. Rough consensus can determine the best technical specification within the IETF's responsibility. It cannot manufacture jurisdiction over a separate institution's contracts or a holder's legal interest.
Scarcity changed the consequence without changing the slogan
The consensus language migrated into number-resource forums while the economic character of IPv4 changed. Allocation policy was developed when regional free pools still distributed addresses according to demonstrated need. The registry's decision affected access to a technical input, but an applicant could often return with a revised request, obtain future space, or expand through ordinary allocation. The opportunity cost was real; the capital value was less visible.
Exhaustion changed the environment. IPv4 blocks became transferable, leasable, financeable, and essential to businesses whose revenue depends on stable address use. Acquisitions routinely assign value to address holdings. Cloud services, hosting companies, access networks, security providers, and content platforms can face substantial migration costs if a block is lost. Reputation and deliverability accumulate around address history. A registry entry can influence routing authorization, reverse DNS, customer confidence, and the ability to transact.
This does not settle whether an address is “property” in every legal system. The bundle may include contract rights, membership status, registration interests, usage authority, delegation, and operational acceptance rather than one universal title. The safer description is capital-like: the interest can carry durable economic value, support production, transfer between parties under rules, and expose its controller to major loss.
Policy consequences therefore grew while familiar procedures remained. A mailing-list conclusion that once adjusted future allocation criteria can now affect an existing asset-like position. A rule can restrict transfer, impose fees, condition service, alter registration, or authorize revocation. Entities may still call the result bottom-up consensus, but the legal character of the effect does not depend on the name of the meeting.
The shift requires a consequence test. If a rule mainly defines how independent systems interoperate, standards legitimacy may be primary. If it allocates a shared free pool prospectively, representative policy legitimacy may suffice with ordinary safeguards. If it changes an identified holder's existing control or value, adjudicative and legal safeguards become central. One forum can perform more than one function, but it must announce which function it is performing and use the corresponding procedure.
Rough consensus did not become defective when scarcity arrived. It became incomplete for a new class of decisions. The correct response is to preserve its issue-based rigor while adding the authority that high-impact disposition requires.
RIR policy forums are not IETF working groups
Regional Internet Registry communities often share important features with the IETF. Meetings are public or broadly accessible. Proposals are documented. Mailing lists preserve debate. Entities include operators with practical knowledge. Chairs assess support and opposition. Policies evolve through implementation experience. These similarities make IETF language attractive.
The constituencies are different. The IETF's fundamental entity is the individual, as RFC 3935 emphasizes. A person contributes technical judgment rather than casting a corporate or national vote. That design helps resist bloc voting in standards work. It is less obviously representative when a decision redistributes costs or changes a company's resource rights. Five technically expert individuals may resolve a protocol objection better than a large uninformed crowd; they do not thereby represent the capital at risk.
RIR forums also combine roles. The community may develop policy. Registry staff assess implementation. A board oversees the corporation. Members elect some directors. The registry signs agreements, controls databases, charges fees, and applies policy to cases. Governments, legacy holders, non-member assignees, downstream users, and affected customers may have different access to each part. “The community decided” can obscure which people participated, what authority they had, and which corporate body adopted the result.
The word “consensus” can further conceal thresholds. One region may use a formal policy-development process with a chair's judgment and later board ratification. Another may require demonstrated support and absence of sustained opposition. Global policy passes through several regional forums and the Address Supporting Organization before ICANN action. The procedures can be legitimate, but their legitimacy comes from charters, bylaws, agreements, incorporation law, and consent relationships in addition to deliberative quality.
That distinction should be explicit in every policy record. The forum should state whether it is advising, making technical policy, exercising delegated corporate authority, or establishing a rule to be incorporated into contracts. It should identify who is bound and why. A chair's declaration of consensus should not be presented as the entire legal act if board adoption, contractual notice, or statutory authority is also required.
Borrowing the IETF's best habits is beneficial: answer objections, publish reasons, test implementation, and allow appeal. Borrowing its aura while omitting the source of binding authority is not.
Participation is not the same as representation
Open attendance is one of the Internet community's most important protections. Anyone able to join a list can expose an error that insiders missed. Yet openness answers who may speak, not who may authorize disposition of another party's interest.
Participation and representation solve different problems. Technical participation broadens knowledge. Representation supplies a defensible connection between a decision and the people burdened by it. An open room can contain no small holders, no customers from affected countries, and no directors authorized to speak for the company whose address block is at risk. Conversely, a representative vote can be technically uninformed. Good governance needs both.
A number-resource forum should therefore maintain several evidence channels. Open technical discussion should remain individual and merit-based. Holder consultation should verify resource control and prevent affiliates from multiplying influence. Member approval should follow the registry's corporate constitution where required. Public authorities should be heard on lawful public-interest questions without receiving control over private technical administration. Identified parties facing adverse action should receive notice and a case-specific hearing.
These channels need not all carry equal weight on every issue. A route-security format should be led by technical evidence. A fee schedule should account for the members who finance the institution. A rule extinguishing a registration should focus on the affected holder's rights, evidence, and review. A global allocation principle should include every region and protect smaller networks from domination by address volume alone.
The forum should publish a representation statement with each consequential policy. It should identify participation by stakeholder class and region, disclose concentrated submissions, explain how absent groups were reached, and state which constituency had formal authority. Raw comment counts should not be treated as a mandate. Neither should expertise be treated as ownership of the decision.
Rough consensus remains useful inside this structure. It can identify whether technical objections were answered across the channels. It cannot collapse all channels into one undifferentiated “community.” The more a policy resembles disposition of existing rights, the more direct the authorization connection must become.
Running code cannot answer a title question
Running code is persuasive because a technical claim can often be tested. Two implementations either exchange conforming messages or they do not. A congestion-control design produces observable behavior. A cryptographic transition can be measured for failure, latency, and compatibility. Evidence does not eliminate judgment, but it narrows disagreement.
Property and control questions rely on different proof. Was a contract validly formed? Did a director have authority? Did a merger transfer the relevant interest? Does a security agreement attach? Is a court order final, stayed, or limited? Did the holder receive notice? Does a policy amendment apply to legacy resources? These questions use documents, testimony, legal rules, burdens of proof, and jurisdiction. Code can preserve and present evidence; it cannot decide the legal meaning unaided.
Automated policy enforcement makes the category error more dangerous. A registry can encode a rule that freezes an account or rejects a transfer. The consistency of the software does not validate the rule's authority. A perfectly interoperable revocation mechanism can still revoke the wrong party. Technical correctness and lawful application are separate propositions.
The same is true of route-origin authorization. Cryptographic systems can prove that a statement was signed by a key linked to a registry hierarchy. They do not prove that every earlier administrative decision in the hierarchy was legally justified. Trust anchors make an asserted state machine-verifiable; they do not transform contested institutional facts into natural facts.
A mature system should therefore attach a legal authority reference to high-impact machine actions. The action record should identify the applicable policy, contract term, corporate approval, or judicial order; the authenticated requester; the evidence status; the effective time; and the review route. Automation should preserve holds where authority is disputed rather than forcing a false binary conclusion.
Technical consensus can design that evidence architecture. It can specify signatures, logs, data formats, and secure state transitions. It should not claim that the architecture determines who deserves to win the underlying dispute. Running code is evidence of deployability, not a deed.
RFC 8714 shows how the IETF treats actual property control
The IETF's own administrative arrangements provide a revealing contrast. RFC 8714, published in 2020, concerns selection of trustees for the IETF Trust. The Trust exists to acquire, hold, maintain, and license intellectual property and other property used in IETF administration. Its beneficiary is the IETF as a whole.
When the IETF addressed that property-holding function, it did not say that a working-group hum would determine every exercise of trustee power. RFC 8714 specifies five trustees, allocates appointment among the IETF Nominating Committee, the IESG, and the Internet Society Board, defines terms, provides recall routes, and requires a Trust Agreement change to implement the structure. The process is connected to identifiable legal offices and instruments.
This does not mean RFC 8714 is a property code for Internet numbers. It concerns the IETF Trust and a particular administrative reorganization. Its analytical value is narrower and important: the IETF community itself distinguishes technical consensus from the legal machinery needed to hold and administer property. Community consensus can authorize the design of that machinery within the IETF's competence, but trustees then act under the trust and applicable law.
The companion administrative reforms strengthen the point. RFC 8711 describes the IETF Administrative Support Activity and a distinct legal entity able to execute contracts and manage operations. Technical standards work remains protected from ordinary administrative control, while contracts, budgets, employment, and assets receive a defined institutional home. Separation preserves both missions.
Number-resource governance needs an equivalent clarity of offices. Policy forums can develop general rules. Registry corporations can adopt and administer those rules within their legal authority. Independent panels can find contested facts. Courts can decide legal rights. Technical operators can execute bounded changes. Appeals can review the proper layer. A consensus call should identify which office it advises or authorizes; it should not pretend to be every office at once.
RFC 8714 is therefore not an exception to rough consensus. It is evidence of its mature use. Consensus designed an accountable legal arrangement instead of substituting itself for one.
Four legitimacies must be kept separate
Internet governance debates often treat legitimacy as a single quantity. In this field it has at least four components.
Technical legitimacy asks whether a rule preserves uniqueness, security, interoperability, stability, and deployability. Rough consensus and implementation evidence are strong tools here. An objection matters according to its technical substance, not the wealth or status of the speaker.
Institutional legitimacy asks whether the body acted within its charter, bylaws, delegation, and procedure. A technically excellent rule can be invalid if adopted by the wrong organ or outside scope. Minutes, quorum, conflicts, publication, and appeal matter.
Affected-party legitimacy asks whether the people who bear the consequence had meaningful notice, voice, and representation. Open participation helps, but a targeted adverse action requires more than the theoretical ability to monitor a mailing list. The institution should identify reliance and provide a hearing proportionate to risk.
Legal legitimacy asks whether the action respects contract, corporate law, administrative law where applicable, property and insolvency rules, court orders, and jurisdiction. Community norms cannot waive another party's statutory rights merely by describing the dispute as technical.
These legitimacies can support one another and still reach different answers. A proposed transfer policy may be technically sound, properly adopted, broadly supported, and lawful. Another may be technically sound but beyond the board's authority. A court order may be legally binding but technically dangerous to implement without a staged plan. The responsible response is to reconcile layers, not declare one supreme in every case.
Decision records should address all four. The technical section explains architecture and operational evidence. The institutional section identifies authority and procedure. The affected-party section records notice, representation, and unresolved reliance. The legal section identifies governing instruments and review. Any section can be short when the consequence is minor. None should be silently assumed when the policy disposes of substantial existing control.
This framework preserves the IETF's achievement. It does not ask protocol engineers to become judges. It asks governance bodies to stop using engineering legitimacy as a substitute for powers they must obtain elsewhere.
The authority matrix for number-resource decisions
A practical distinction can be expressed as an authority matrix.
Protocol syntax and behavior belong primarily to technical standards institutions. Their output should be open, interoperable, implementable, and responsive to technical objections. Adoption ordinarily remains voluntary, though market and network effects can be strong.
Global uniqueness and registry synchronization belong to coordinated number-registry institutions operating under publicly defined delegations. Technical consensus should shape formats and procedures. Authority to change state must be authenticated and auditable.
Prospective allocation from a common free pool belongs to representative policy bodies under registry constitutions and coordination agreements. Fairness, technical need, scarcity, and regional effects all matter. Rules should be general and published before application.
Voluntary transfer between competent parties belongs to holders and counterparties within valid registry policy, contract, and law. The registry verifies conditions and preserves the authoritative chain; it does not invent missing title.
Adverse cancellation, compelled transfer, freezing, or material restriction of an existing holding requires a valid legal or contractual basis, case-specific evidence, notice, cure where feasible, proportionality, reasoned decision, and independent review. Technical forums can define safe execution but should not be the sole adjudicator.
Emergency continuity permits narrow temporary technical action when delay threatens service or authoritative records. It should not decide permanent title. The action must be time-limited, logged, reviewable, and reversible.
Corporate governance of a registry belongs to members, directors, officers, receivers, and courts under the incorporating law and governing documents. A global technical body may condition recognition on functional standards. It cannot simply erase the corporation's legal structure.
The matrix prevents a common slide. A discussion begins with a technical need, produces rough consensus on a mechanism, and ends with an institution claiming authority over assets needed to operate the mechanism. At each transition, the decision maker should name the additional mandate. If no mandate exists, the technical result remains advice or a proposed condition, not self-executing disposition.
Due process is not an enemy of deployment
Engineers sometimes resist legal procedure because delay can preserve a vulnerability or block a needed transition. Lawyers sometimes resist emergency operation because temporary facts can harden into permanent control. Both concerns are valid.
The solution is tiered procedure. General technical standards should continue through open, iterative consensus. Prospective registry policies should include impact analysis, implementation testing, notice, and a delayed effective date. Case-specific adverse decisions should use an evidentiary record and independent review. Genuine emergencies should permit temporary action under narrow triggers with rapid post-action scrutiny.
Due process can improve technical results. Notice reveals dependencies that the registry did not know. A reasoned decision forces the institution to map the rule to facts. Conflict disclosure identifies incentives to misuse a security rationale. A stay preserves state while an appeal tests authority. Proportionality encourages a targeted certificate suspension or account safeguard instead of a destructive blanket revocation.
Procedure should also have time limits. A holder cannot use endless repetition to block a rule after objections have been answered. RFC 7282's insight remains relevant: addressed does not mean accommodated. Once a competent decision maker has considered the objection, explained the legal and technical answer, and offered the required review, the matter can proceed. Due process guarantees a fair path, not victory.
Conversely, speed cannot cure lack of authority. An institution should not implement first and search for a mandate later unless a genuine emergency power exists. “The community supported it” is not enough when the record does not identify the community, the support, or the legal basis.
The best system makes both delay and action accountable. It publishes triggers, deadlines, interim protections, evidence burdens, and decision owners before a crisis. That is the governance equivalent of implementation testing.
Appeals must review the right kind of error
RFC 2026 and related IETF procedures include appeals because consensus callers and steering bodies can make mistakes. In standards work, an appeal may ask whether a technical objection was ignored, whether procedure was followed, or whether a decision was reasonable within the process.
Number-resource disputes require a broader appeal map. A technical appeal reviews interoperability, security, and operational feasibility. A policy appeal reviews whether the forum properly assessed consensus and stayed within scope. A corporate appeal reviews board or officer authority under governing documents. A contractual dispute forum interprets the service agreement. A court reviews legal rights and orders within its jurisdiction.
No single appeal body is ideal for all errors. An IETF-style steering group can correct a chair's failure to address a technical objection. It is not necessarily equipped to decide beneficial ownership or insolvency priority. A domestic court can issue a binding order about a corporation, but it may need expert evidence and a staged remedy to avoid global technical harm. The system should route questions rather than demand that one institution absorb every competence.
Interim relief is especially important. If a disputed transfer is immediately executed, reversal may disrupt multiple downstream users. If a valid security response is automatically stayed, abuse may continue. Decision makers need bounded tools: preserve the record, suspend only new changes, maintain existing routing, separate public and private data, or appoint a neutral technical custodian.
Appeal independence should be real. A board reviewing staff, peers reviewing a peer, or a certifier reviewing its own report may supply expertise but not sufficient distance. High-impact cases need members without institutional or commercial conflicts, access to the underlying record, authority to provide effective relief, and published reasons.
Rough consensus becomes stronger, not weaker, when its decisions are appealable on the correct grounds. Confidence does not require pretending that engineering judgment is infallible or universally competent.
The capture risk changes with the entity of decision
Every consensus process faces capture. In protocol work, a vendor may dominate attendance, an editor may control text, or a loud faction may exhaust opponents. Open archives, independent implementations, chair judgment, and appeals mitigate the risk. Deployment supplies a further check: a technically poor standard may not be adopted.
Resource policy creates additional incentives. Incumbent holders may restrict new entrants. Buyers and sellers may favor transfer rules that increase liquidity. Registries may favor policies that expand fees or discretion. Governments may seek control. Security firms may favor mandatory services they sell. A large corporate group may appear through many affiliates. A temporary majority may impose costs on absent legacy holders.
Running code is a weaker market check when the registry controls the authoritative record. A holder cannot route around an adverse database decision as easily as an implementer can reject a protocol. That increases the need for formal conflict controls.
Forums should disclose organizational affiliations and material interests while preserving individual technical participation. Holder consultations should consolidate controlled affiliates. Chairs should explain how concentrated submissions were treated. Policy authors should publish who benefits, who pays, which existing rights change, and what alternatives were rejected. Registry staff should separate neutral implementation advice from institutional advocacy.
Policies that benefit the decision maker deserve heightened review. A registry proposing greater revocation power, a transfer platform proposing mandatory market routing, or an incumbent proposing entry barriers should not be disqualified automatically. Their expertise may be essential. Their claims should be tested by an independent body with counter-evidence and reasoned findings.
The IETF insight remains central: dominance is not volume or persistence. For resource policy, a second insight must be added: technical merit is not freedom from economic interest. A sound decision addresses both the objection and the incentive behind the proposed power.
Implementation cannot be treated as retrospective consent
Standards gain practical authority when implementers adopt them. It is tempting to extend that logic to registry policy: a holder continued using the registry after a policy changed, so the holder must have accepted the rule. That inference is unreliable when exit is costly or unavailable.
A network may retain its registration because no substitute authoritative registry exists, because renumbering would disrupt customers, or because transferring the block requires the same institution's approval. Continued operation under those conditions proves dependence, not necessarily consent. The stronger the registry's exclusive position, the weaker the inference from silence or continued use.
Contract law may still make a properly notified policy amendment binding. The point is not that every amendment requires an individual signature. It is that the source of obligation must be the valid contract, corporate instrument, or legal rule, including its amendment clause and protections. Deployment cannot supply authority that the governing instrument withholds.
The distinction mirrors the difference between protocol compatibility and resource custody. When many networks implement a protocol, they provide evidence that the specification is useful and interoperable. When many holders comply with a registry rule, their conduct may reflect agreement, but it may also reflect the inability to preserve service otherwise. The observation needs institutional context before it becomes evidence of authorization.
Legacy holdings make the problem sharper. Some resources originated under earlier policies, government contracts, informal practices, or terms unlike the current service agreement. A later consensus cannot assume that every historical interest entered the same amendment structure. The registry should identify the legal bridge for each class rather than treating database presence as blanket consent to future disposition.
A fair amendment regime should publish material changes, explain their authority, allow meaningful comment, provide sufficient lead time, preserve pending transactions, and distinguish prospective conditions from adverse changes to established interests. Where a change substantially alters transferability, revocation risk, or liability, holders may need a vote, express acceptance, an exit right, or independent review depending on the governing documents and law.
Consent analysis also protects the community from opportunistic dissent. A holder that expressly agreed to a valid amendment mechanism cannot avoid an unfavorable general rule simply by calling number resources property. The institution should apply the agreed procedure consistently and provide the promised review. Precision cuts both ways: monopoly dependence is not consent, and dissatisfaction is not exemption.
The standards tradition remains useful here because it values adoption evidence without confusing adoption with metaphysical truth. Registry governance should be equally disciplined. Implementation can show feasibility and reveal impact. Only a valid rights-bearing relationship can show why the rule binds the holder.
A disciplined borrowing of rough consensus
RIR policy forums should continue to borrow rough consensus, but with explicit modifications.
First, define the question. Separate technical design, general policy, corporate adoption, and case adjudication. Do not ask one consensus call to decide all four.
Second, publish the mandate. Identify the charter, bylaw, agreement, delegation, or law that authorizes the body to make the decision and the parties it binds.
Third, classify objections. Technical objections receive architecture and implementation answers. Rights objections receive contractual and legal analysis. Representation objections receive constituency evidence. Conflicts receive independent review.
Fourth, test implementation. Model data changes, routing effects, certificate consequences, costs, and migration. A policy that cannot be safely executed should not be rescued by strong sentiment.
Fifth, measure affected interests. Identify existing holders, prospective applicants, customers, small networks, regions, and public functions. Explain who participated and who did not.
Sixth, use case procedure for adverse action. General consensus can establish a valid rule; it should not be treated as proof that an identified party violated the rule. The case needs evidence and a neutral decision maker.
Seventh, preserve appeal. Publish the record, reasons, effective date, interim protection, and correct review forum.
Eighth, review outcomes. Just as operational experience can cause an Internet standard to evolve, evidence of disproportionate loss, evasion, concentration, or technical failure should trigger policy revision. Existing lawful decisions remain stable unless the review body orders otherwise.
This borrowing honors the IETF rather than imitating its rituals. It retains openness, issue-based reasoning, technical competence, and revision through experience. It adds what a rights-affecting institution cannot avoid: authority, representation, adjudication, and law.
The conclusion is a boundary, not a rejection
Rough consensus is one of the Internet's great institutional inventions. It enables autonomous entities to produce common technical rules without demanding unanimity or surrendering to majoritarian counting. RFC 7282 improved the method by centering addressed objections. RFC 2026 tied standards to implementation, interoperability, openness, and appeal. RFC 3935 stated a mission and, crucially, its limits.
The method should not be weakened by asking it to perform a task it was not designed to perform. A protocol standard earns authority because independent networks can implement it and communicate. A decision disposing of a capital-like number-resource interest needs a different connection between decision maker and subject. It must show who granted the power, who was represented, what facts were proved, what law applies, why the remedy is proportionate, and where the decision can be challenged.
Technical and legal authority are not adversaries. Technical consensus can design safer registries, evidence formats, transfer mechanisms, certificate systems, and emergency controls. Law and institutional procedure can establish who may invoke those mechanisms and protect against misuse. Holder participation can reveal reliance. Independent review can reconcile errors.
The IETF's own treatment of property and administration confirms the mature approach. Community consensus can create formal structures, but trustees hold property through a trust, appointments occur through defined bodies, contracts sit in a legal entity, and recall follows stated rules. The hum does not sign the deed.
For number-resource policy, that sentence should become a discipline. Use rough consensus to find the best technical answer. Use valid institutions to adopt general rules. Use evidence and due process to apply them. Use courts and competent tribunals for rights they are empowered to decide. Never let the prestige of engineering consensus conceal a missing grant of authority.
Rough consensus was built for protocols. It can inform governance. It cannot, standing alone, dispose of property.