Running-Code Primacy: The Patch Needed to Preserve the Internet’s Original Design

The seven previous Heng.lu notes in this sequence are:

Note 52: On When Registry Power Becomes Detached from Liability: Why the Present RIR Coordination Model Cannot Survive in Its Current Form
Note 53: On Why Internet Number Resources Are Not Political Property
Note 56: Thick Governance in Regional Internet Registries Turns Uniqueness into Double Extraction
Note 58: From Double Extraction to Sovereignty Inversion: How Nations Lose Sovereign Control to RIRs for US$100
Note 59: The Poverty Penalty: How the RIR Model Taxes the Poor While Calling It Equality
Note 61: Running-Code Betrayal: How the RIR System Turned Consensus Against the Technical Community
Note 62: Mandate Laundering: From RIR Fantasy to Transition Architecture

The seven previous essays were not a reform program for the Regional Internet Registries.

They were an autopsy.

They traced the same institutional pathology through different layers: liability detached from consequences; number resources renamed as political property; uniqueness turned into double extraction; sovereignty inverted; poverty taxed in the name of equality; consensus turned against the networks it was meant to serve; and finally a mandate laundered until an administrator began to sound like a sovereign. The sequence matters because the failure was not a bad board, a bad registry, a lawsuit, or an uncomfortable market event. It was a systemic defect appearing under different disguises. The CircleID author page now displays that sequence clearly, including Running-Code Betrayal and Mandate Laundering. (circleid.com)

This essay is not about making the RIRs better governors.

It is about explaining why the current registry order cannot be the endpoint, and why the least disruptive repair is a supplement to the Internet’s original technical design.

That supplement is Running-Code Primacy.

The need is no longer theoretical. In a recent CircleID exchange, John Curran presented the incumbent argument in its strongest form. His thesis is that the authority of the RIR system is not merely a by-product of limited technical coordination, but the result of a historical chain: the White Paper, ICANN, the ASO, ICP-2, the transition of IANA oversight, and the private sector’s continuing multilateral governance. He argues that the authority of the RIR system results from operating within the private-sector multilateral model promoted by the United States Government. (circleid.com)

That argument is useful because it makes the dispute visible.

The question is no longer whether a historical delegation existed. Of course it did. The question is whether a historically delegated coordination function can then expand into a permanent governance mandate through the same procedural machinery it controls. The incumbent answer is yes: delegation, recognition, institutional continuity, and community procedure become a self-renewing mandate.

The answer required by the Internet’s original technical design is no.

The original Internet tradition was narrower, harder, and better. RFC 3935 states that the IETF’s purpose is “to make the Internet work better”; it grounds the work in technical competence, real-world implementation, and “rough consensus and running code.” It also states that when the IETF is not responsible for a protocol or function, it does not attempt to exercise control over it. (rfc-editor.org) RFC 7282 repeats David Clark’s old phrase: “We reject: kings, presidents and voting” and “We believe in: rough consensus and running code.” (rfc-editor.org) RFC 9592 makes the anti-sovereign point even clearer: the IETF does not run, control, or police the Internet, and is not “the protocol police.” (rfc-editor.org)

That tradition never meant that documents were magical. It meant documents mattered when they helped systems work. It meant process was tolerated because it served deployment. It meant a room was useful only when it disciplined itself around operational reality.

The registry layer borrowed that legitimacy.

It never fully accepted that discipline.

That is the missing patch.

What Running-Code Primacy Means.

Running-Code Primacy means that Internet coordination systems must be interpreted strictly, with reference to the minimum technical function that originally justified the existence of operating networks.

The number-resource layer exists to protect systems in operation: uniqueness, interoperability, routing-related continuity, security assertions, proof of control, and the minimum common semantics needed for independent networks to work together.

It does not exist to manufacture political authority.

It does not exist to police commercial morality.

It does not exist to turn the geography of a service into a property title.

It does not exist to turn a mailing list into a legislature.

It does not exist to let a private registry make already-operating network assets disappear because it changed its internal policy theory.

A registry is not a state.

A database contact is not a notarized corporate power of attorney.

A service region is not a people.

A policy room is not a legislature.

A registry can describe operational reality. It does not create it.

This is not conservatism. Running-Code Primacy does not say that deployed systems can never change. It says institutional power over change must not be justified through historical delegation, circular recognition, or ritual procedure. It must be justified through deterministic rules that operators can verify locally and through adoption in systems in operation.

The correct order is: initial specification, distributed-ledger state, local validation, running implementation, voluntary adoption, compatibility set, and then documentation.

The wrong order is: policy room, declaration, claimed obligation, compliance label, and forced operational compliance.

The RIR system failed because it increasingly chose the second order.

The key correction is this: after the initial specification, there is no continuing institution to ask for permission. No committee decides whether non-adoption constitutes a violation. No registry declares a participant invalid simply because it refuses to accept a later change. There are only code, ledger state, validation, adoption, compatibility, local rejection, forking, and selective interoperability.

An operator that rejects a later change does not break the Internet. It may remain in an older compatibility set. It may fork. It may disconnect. It may stop interoperating with participants that adopted incompatible rules. But it cannot break the interoperability of others that continue running mutually compatible code.

The design intuition is the same one that makes distributed ledgers useful: no permanent institution is needed to decide ordinary validity. Participants locally validate state transitions under deterministic rules. An invalid state is not punished by an institution. It is ignored by participants that do not accept it.

That is the essential patch missing from number-resource coordination.

The Design Failure Was Present from the Beginning.

The first RIR architecture assumed a low-value world.

Number resources seemed technical, abundant, administrative, and low-conflict. In that world, informality seemed efficient. Open mailing lists seemed representative. Contact-based administration seemed sufficient. Limited-liability contracts seemed harmless. A regional registry could look like a simple address book.

IPv4 scarcity destroyed that premise.

IPv4 addresses became scarce, transferable, financeable, leasable, capitalizable, litigated, subject to sanctions, and integrated into active networks. The registry layer ceased to sit above administrative entries. It began sitting above productive infrastructure. It began sitting above asset value. It began sitting above customer continuity, cloud deployment, telecommunications operations, national connectivity, court orders, and capital allocation.

The institutional form did not adjust to match that new risk.

It expanded.

The result is a system that still speaks the language of technical coordination while producing the effects of infrastructure governance. It asks operators to treat registry process as neutral while registry decisions affect commercial outcomes. It calls its participants a “community,” although many who bear the consequences never clearly authorized the people in the room to represent them legally.

NRS exposes the structural problem clearly: Internet number registries were designed as technical coordination bodies, but once IPv4 scarcity turned addresses into valuable assets, registry discretion became economic power; when coordination systems control capital, centralization becomes a structural risk and decentralization becomes a systems-engineering question rather than an ideological one. NRS also sets out the opposite design direction: one Internet, open and autonomous infrastructure, and decentralized governance with minimal human involvement at the core. (nrs.help)

That is the real problem. The registry layer was never adapted for the moment when a coordination table became a gateway to assets.

Running-Code Primacy is that adaptation.

It is not a doctrine of “better RIRs.”

It is a post-RIR discipline.

The Three Rules of the Patch

The constructive grammar is the revised Note 64: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption for Internet Coordination Systems: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

The names remain unchanged. The logic must be precise.

Minimum Initial Specification means the common layer contains only deterministic, locally verifiable rules required for uniqueness, interoperability, proof of control, shared security, and security assertions. It contains no business-model preferences, pricing theories, regional political sentiments, discretionary enforcement powers, or institutional mission expansion.

Localized Future Decision does not mean an institution decides which future decisions are local. That would simply reintroduce the authority layer. It means the initial specification does the limiting work in advance. After deployment, ordinary future decisions remain with the participants running the code. A participant may adopt, reject, fork, disconnect, or interoperate selectively. No participant can alter the interoperability of others that continue running mutually compatible rules.

Voluntary Adoption means a later change becomes real only through implementation, validation, deployment, and use. Publication is not reality. Recommendation is not reality. Institutional recognition is not reality. Non-adoption does not create an invalid state. A participant that does not adopt a later change remains in its existing compatibility set. A participant that emits states invalid under another participant’s deterministic rules may be ignored locally. The effect is compatibility selection, not institutional punishment.

These three rules do not rehabilitate registry sovereignty.

They prevent it from returning under another name.

APNIC: The Legal Structure Was the Risk

APNIC shows the first failure: the minimum was never specified strictly enough from the outset.

This is not a story about codes of conduct. It is not a story about etiquette. It is not a story about whether a critic was polite enough to an incumbent institution.

It is a story about legal structure.

In March 2023, LARUS published a legal review warning that APNIC’s governance structure created risks not only for one company in Brisbane, but for Internet governance across the Asia-Pacific region. The review stated that APNIC’s Director General had ultimate legal power to close APNIC and remove the elected Executive Council, and that urgent governance reforms were needed. It also noted that the structure raised questions about the security of Internet governance for more than one billion users in the Asia-Pacific region. (larus.net)

The first annex, the ASIC extract, provides the corporate foundation. APNIC Pty Ltd was registered as an Australian private company limited by shares, registered in Queensland. Paul Byron Wilson was listed as director and secretary. Share information showed a single ordinary share issued, with Paul Byron Wilson as the sole holder of that share. (larus.net)

That is not a normal way to house a critical regional Internet coordination function.

The second annex, Dr. Peter Felter’s legal opinion, draws the governance conclusion. It describes APNIC’s public structure—members, elections, Executive Council, Director General, and Secretariat—as a special committee based on clause 9.3 of the APNIC Pty Ltd constitution. It states that APNIC Pty Ltd has for 25 years been a private company controlled through one director, one shareholder, and one secretary, all the same person. (larus.net)

That distinction matters.

The community-oriented public institution was not the final legal container. It was a structure built on top of a private company.

The legal opinion then explains why that distinction matters. It states that APNIC’s constitution is subject to the company constitution and the powers of the corporation and its directors, officers, and members. Under that interpretation, APNIC’s public structure could be altered by resolution of the director of APNIC Pty Ltd; the opinion describes APNIC as, in effect, a department of APNIC Pty Ltd. (larus.net)

The most serious point in the opinion was not that APNIC was technically illegal. It was that legality and legitimacy are not the same. The opinion argues that the trust mechanism does not solve the problem because the Executive Council’s powers still derive from the director’s resolution establishing the special committee. It also notes that APNIC Pty Ltd is a private company with shares whose structure and objects do not correspond to the shareless, nonprofit organizational model normally associated with a public-interest regional registry. (larus.net)

That is the first design failure in its purest form.

A regional-scale number coordination system should not depend on a structure that requires lawyers to explain why a private company with one share, a special committee, a trust, and an elected council somehow amount to legitimate control of the Asia-Pacific Internet registry.

A critical coordination layer should be legible from the outside.

It should not require trust in documents behind documents.

It should not require members to discover, after years of institutional dependence, that the elected layer may not be the final legal layer.

It should not present the appearance of member governance while formal power resides elsewhere.

That is why Minimum Initial Specification must include distributed validity rather than institutional trust. Not because a future institution needs better governance, but because a future post-RIR system must not need that institution at all.

The common layer should not depend on the hidden control structure of a private company. It should define deterministic validation rules, proof-of-control states, state-transition rules, conflict rules, ledger replication, exit paths, fork paths, and compatibility sets. If APNIC disappears, captures itself, changes its legal posture, or refuses to recognize a valid state, the running network should not depend on APNIC’s recognition to know who controls which number resources.

The registry should not be the source of validity.

Distributed-ledger state, validated under the initial specification, should be.

ARIN: Policy Met the Reality of Assets

ARIN shows the second failure: legal and market reality can outrun registry theory.

The decisive event was the Nortel/Microsoft transaction. When Nortel entered bankruptcy, its 666,624 IPv4 addresses became valuable assets in the proceeding. The addresses were sold to Microsoft for $7.5 million. ARIN intervened under the theory that addresses were not property and could not be sold free of registry policy. Industry Canada supported that position. The bankruptcy court rejected it; Microsoft later signed a “legacy” agreement; and the practical result was clear: registry policy could no longer be the sole source of reality once courts and markets treated number resources as assets. (btw.media)

The important lesson is not that ARIN was especially defective.

The lesson is that the registry layer had entered a new category.

A registry is valuable because operators, courts, buyers, sellers, creditors, and networks trust it. It does not become authoritative by denying that dependence. It remains useful only if it reflects legal, market, and operational reality with sufficient accuracy.

Once IPv4 became scarce, registry process became a market interface. Transfer rules, need assessments, recognition delays, and regional restrictions ceased to be administrative details. They became asset frictions. Public analysis now describes a fragmented RIR rulebook in which five regional systems govern a market trading at roughly $18 to $45 per address, with conflicting rules capable of locking up assets, delaying mergers, and forcing separate corporate structures merely to retain address blocks. (btw.media)

That is not neutral coordination.

It is a regulatory effect without regulatory responsibility.

ARIN demonstrates why Voluntary Adoption matters. Registry policy retains credibility only while it describes what actors actually implement, trade, finance, litigate, and use. It becomes dangerous when publication is treated as sufficient to manufacture reality.

A registry that refuses reality does not become sovereign.

It becomes an obsolete database.

In a Running-Code Primacy design, the lesson is even clearer. Courts and markets do not need an incumbent registry to decide whether value exists. Operators do not need a committee to know whether a block routes. Participants need deterministic rules that enable proof of control, conflict resolution, visible ledger state transitions, and compatibility. The old registry may publish a view. A software client may display a view. A ledger explorer may display a view. None is the source of validity.

There is no registry to migrate to.

There is no registry to ask.

There is only distributed state that participants validate, accept, reject, fork, or interoperate with.

AFRINIC: When Registry Theory Threatened Operating Assets

AFRINIC is the central case because it reduced the problem to its essence.

The wrong story is that a problematic member paralyzed a regional registry.

That is the incumbent’s moral narrative.

The structural story is different. AFRINIC attempted to turn commercial use, customer geography, leasing, member relationships, and its internal policy interpretation into a claimed power to deregister already-operating number resources. Once that claim was made, the conflict could no longer remain a disagreement in a policy room. It became a test of whether a private registry could use regional rhetoric and normative silence to threaten assets integrated into operations.

The facts require no theatrical exaggeration. Public reports described the AFRINIC dispute as a straightforward commercial conflict over IP addresses that became Africa’s biggest Internet-governance story. They also noted that Cloud Innovation had often been presented as the villain, while later documentary material pointed to destructive forces inside AFRINIC itself and to litigation delayed, prolonged, and continued by AFRINIC representatives at its own cost. (btw.media)

That matters because it reverses the usual narrative.

The litigation did not create the structural failure.

It exposed it.

The relevant failure was already present when a private registry treated the absence of explicit permission as a basis for coercive control. Leasing was not a threat to uniqueness. Customer geography was not duplicate allocation. Commercial use was not a routing-security failure. A business model disapproved of by a registry was not a global invariant.

Yet the registry’s interpretation placed these elements inside a revocation framework.

That is the moment coordination becomes governance.

Reports state that AFRINIC sent Cloud Innovation a letter in March 2021 alleging policy violations and threatening termination of its membership; that in July 2021 the Supreme Court of Mauritius barred AFRINIC from cancelling Cloud Innovation’s membership; and that a new cancellation attempt was blocked in December 2021. (btw.media) That sequence is not the story of a registry calmly protecting the Internet. It is the story of registry authority meeting ordinary law.

Nor was the institutional collapse caused by too much registry power. The deeper problem was structural lock-in. If a registry has monopoly recognition over high-value live assets, any internal failure becomes an Internet-continuity risk. If members cannot leave the recognition system, registry failure becomes hostage power.

A registry may correct demonstrable registration fraud in its own data.

It may prevent duplicate allocations while the registry model exists.

It may maintain security assertions while participants depend on it.

But those are transitional functions of an older architecture.

In a post-RIR architecture, those functions are not performed by a registry. They are encoded in distributed-ledger state, proof-of-control rules, conflict rules, and locally verifiable transitions.

A private body should not turn leasing into regional betrayal.

It should not turn customer geography into a revocation trigger.

It should not treat commercial disagreement as technical invalidity.

It should not turn asset continuity into permission.

AFRINIC demonstrates the need for properly understood Localized Future Decision. There is no central body deciding that a future commercial decision “belongs locally.” Instead, the initial specification must ensure that these decisions never enter the common layer in the first place. Leasing, customer geography, commercial use, pricing, financing, customer mix, and deployment strategy remain outside deterministic validity rules unless they directly affect uniqueness, security, proof of control, or interoperability.

An operator cannot break other operators’ interoperability by leasing addresses.

It cannot break it by serving customers outside a registry’s historical region.

It cannot break it by using a business model the registry disapproves of.

In any case, an operator may fail to meet deterministic rules that other participants execute. In that case, others locally reject the invalid state. There is no punishment layer. There is no compliance tribunal. There is no regional sovereign.

That line is not ideological.

It is operational.

The Proxy Problem Is Not a Detail

AFRINIC’s election controversy made a second defect visible: representation.

NRS sets out its representation basis in direct legal terms. It states that listed members entrusted NRS with representation in RIR-governance matters and that each listed member granted a power of attorney. (nrs.help) During AFRINIC’s election dispute, NRS asked members to report whether their names appeared in voting records or whether their votes had been recorded without their participation, and stated that such factual reports would be handled through legal channels. (nrs.help)

That matters because it shows the difference between legal representation and community rhetoric.

The RIR system often collapses several categories into one: corporate representative, database contact, technical contact, employee, consultant, proxy holder, policy participant, regular mailing-list user. They are not the same.

A database contact may help administer records.

A power of attorney may authorize representation if valid and within its scope.

A policy participant may contribute expert knowledge.

A mailing-list participant may express an opinion.

None of these automatically becomes a legal principal for every company, customer, state, creditor, lender, buyer, lessee, or network bearing the consequences of a registry decision.

This distinction can be ignored only while the common layer remains thin. Once a registry claims power over revocation, transfer, leasing, market access, sanctions, asset continuity, or national infrastructure risk, representation becomes constitutional.

A room is not a mandate.

A mailing list is not a people.

A contact record is not a corporate power of attorney.

A service region is not a sovereign constituency.

This is not a matter of procedural rigor.

It is the difference between coordination and normative authority.

A Running-Code Primacy system avoids this problem by reducing the number of decisions that require representation in the first place. If validity is deterministic and local, there are fewer things to vote on. If future change is voluntary, there is no need to decide whether a non-adopter is in bad standing. If state is represented in a distributed ledger, there is no need to ask an incumbent registry to recognize a participant’s continuing existence. If compatibility sets are explicit, participants know with whom they can interoperate without consulting a policy room.

The best governance problem is the one system design removes.

RIPE NCC and LACNIC: The Club and the Choke Point

RIPE NCC and LACNIC do not show that some RIRs are more “civilized” than others. They show that the RIR model has two enforcement layers beyond the technical function: the club and the choke point.

The club decides who is respectable. The choke point controls the movement of registry status.

RIPE NCC’s refusal to accept LARUS sponsorship for RIPE 90 clearly showed the club layer. A member offered sponsorship. The registry ecosystem rejected it because of an unrelated dispute in another region. That was not a routing-security decision. It was not a uniqueness decision. It was not a deterministic validation rule. It was a form of private exclusion through control of access to spaces, visibility, sponsorship, and social legitimacy.

LACNIC also rejected the sponsorship. Different region, same pattern: the registry club protects itself by controlling rooms, visibility, and reputation.

That is not community. It is access control.

The sanctions layer is more serious because it shows the choke point in legal form. RIPE NCC states that, being based in the Netherlands, it must comply with EU sanctions; when they apply, it freezes registrations in the RIPE database, blocks acquisitions and transfers, and may treat cases as frozen if a party cannot provide sufficient documentation. It also checks against OFAC lists because of banking requirements. (RIPE NCC sanctions transparency)

This is not a criticism of RIPE NCC for complying with the law. A Dutch entity must comply with Dutch and EU law. The architectural problem is: why should a private entity in the Netherlands be the central recognition point for number-resource mobility across multiple countries, operators, and legal systems?

Sanctions may bind a bank. They may bind a Dutch entity. They may bind a counterparty that chooses not to trade. But they should not become a global condition of technical validity for everyone else.

That is the design failure.

The same centrality that lets the club exclude a critic also lets one jurisdiction freeze registry mobility. One is social enforcement. The other is legal enforcement. Both work only because the registry occupies a place where validity should not reside.

This connects directly to the three principles.

Minimum Initial Specification: club respectability, sponsorship eligibility, regional policy, sanctions classification, and reputation must never enter the common layer. The common layer must contain only deterministic rules for uniqueness, proof of control, conflict resolution, state transition, and security.

Localized Future Decision: legal risk, counterparty choice, sponsorship, commercial trust, and sanctions exposure belong to the actors that assume them. A Dutch entity may reject a transaction. A bank may reject a payment. A counterparty may refuse to interact. None of that is permitted to become global registry truth.

Voluntary Adoption: participants accept counterparties by running code, validating state, and choosing with whom to interoperate. Non-adoption is not misconduct. Local rejection is not global invalidity. A club rejection should not erase valid state. A sanctions obligation must limit the affected actor, not rewrite the global ledger of number resources.

That is why a distributed-ledger architecture is necessary. In a post-RIR system, ordinary validity is not decided by RIPE NCC, LACNIC, a sanctions desk, a meeting committee, or a sponsorship office. Participants validate state locally. Counterparties voluntarily accept or reject. Forks are visible. Compatibility sets are explicit. The central registry disappears as the source of truth.

The solution is not better etiquette.

It is not a more transparent sanctions queue.

The solution is to remove validity from both the club and the choke point.

Distributed state. Local validation. Voluntary counterparty acceptance. No registry as the source of validity.

The NRO Letter: The Escape Route Upward

The most serious evidence is not AFRINIC’s attempted overreach.

It is the system’s collective response.

In 2022, the Number Resource Organization wrote to the Government of Mauritius. The letter described the NRO as the coordination body for the world’s RIRs and stated that RIRs manage number resources in their respective regions. It said that the five registries perform the function of administering number resources under regionally adopted rules or global policies adopted unanimously. (nro.net)

The same letter criticized Cloud Innovation’s litigation, stated that more than 25 lawsuits had been filed, complained of court orders that froze AFRINIC’s accounts and halted elections, and said that AFRINIC had repeatedly asked Mauritius to be recognized as an international organization. The NRO urged the government to take measures to preserve AFRINIC’s independence and Internet stability in Africa. (nro.net)

That is the most revealing document in the entire story.

When a private registry collided with ordinary courts, the system’s reflex was not to reduce the scope of the mandate.

It was not to remove registry lock-in.

It was not to separate registry administration from enforcement.

It was not to define distributed validation.

It was not to question whether unilateral deregistration power over operating assets had been illegitimate from the beginning.

The reflex was an escape route upward.

A private coordination body cannot be technical when it wants discretion, community-based when it wants legitimacy, contractual when it wants fees, a non-owner when it wants to avoid liability, and quasi-international when it wants immunity from courts.

That combination is not governance.

It is a systemic form of “mandate laundering.”

If RIRs want public-law privileges, they must accept public-law responsibility. If they want private-law flexibility, they must accept private-law litigation. What they cannot coherently demand is private discretion, public-infrastructure importance, low accountability, weak representation, monopoly status, and quasi-diplomatic immunity at the same time.

That is the path to collapse.

Running-Code Primacy rejects it.

When a registry meets legal resistance, it must not escape upward seeking immunity. The architecture must contract downward, reducing itself to the strict running-code function that originally justified it.

Less sovereignty.

No registry as the source of validity.

Less enforcement.

More distributed validation.

ICP-2 Review Is Not Enough

The current system recognizes that something has broken.

ICANN’s public-comment page on the second draft of the RIR governance document states that the proposal would establish rules and criteria for recognizing new RIRs, operational obligations and requirements for existing RIRs, and derecognition rules; if adopted, it would replace ICP-2. The same page says the process began after the NRO asked the ASO to propose updates to give the RIR system greater accountability to the Internet community. (icann.org)

That may be necessary as a continuity measure.

It is not sufficient as a theory of legitimacy.

Recognition and derecognition rules answer a late question: when has a registry failed enough to be removed?

The earlier question matters more: why should a registry have enough power to fail catastrophically in the first place?

An ICP-2 successor that merely tightens recognition, auditing, transition, and derecognition may improve institutional hygiene while preserving the category error. It still assumes that the RIR is the primary sovereign form of number-resource coordination.

Running-Code Primacy asks a different set of questions.

How does the Internet continue if an RIR collapses?

How do number-resource assignments remain verifiable without permission from an incumbent?

How does uniqueness survive without monopolistic discretion?

How do we prevent registries from becoming coercive enforcement tools?

How do we keep commercial decisions outside deterministic validity except where a real global invariant is at risk?

How does coordination remain usable without an authoritative registry?

How does an operator validate ordinary state without consulting a permanent body?

How do we prevent rejection from becoming an infringement label?

These are not reform questions.

They are post-RIR questions.

Why This Is the Original Design Patch

The issue is not whether anyone likes incumbent registries.

The issue is whether the number-resource layer still follows the design discipline that made the Internet possible: minimal common rules, local validation, voluntary adoption, and running code.

Running-Code Primacy is not a public-relations strategy or an institutional compromise. It is the technical repair implicit in the original design. If the Internet was built to reject kings, presidents, and voting as sources of technical truth, the number-resource layer cannot recreate those forms through registry process, historical delegation, or community theatre.

Consensus alone can become ritual. Running code alone can be subordinated if the registry layer is placed above it as the source of recognition. The missing rule is interpretive and architectural: when institutional process conflicts with the minimum technical function required by systems in operation, running code has priority; and when a later change is proposed, it becomes real only through voluntary adoption by participants executing the validation rules.

That is how the original design is preserved, not abandoned.

The Internet mattered because it became the first global communications system that did not require prior permission from one sovereign, ministry, church, corporation, or gatekeeper. If that achievement remains worth defending, the number-resource layer cannot become the exception that invalidates the rule.

A system built to avoid kings cannot allow an accountant to aspire to become one.

The patch restores the original hierarchy: code first, operators first, deterministic validation first, distributed state first; institutions, if they exist during transition, only as non-authoritative artifacts, never as sources of validity.

What Post-RIR Coordination Requires

Post-RIR coordination does not mean chaos.

It means the common layer becomes thinner, more objective, more deterministic, and more distributed than the current RIR monopoly.

There is no registry to migrate to.

There is no new registry to crown.

There is no new priesthood.

There is a distributed ledger of number-resource state, with deterministic validation rules, proof-of-control mechanisms, conflict handling, compatibility sets, state-transition history, and local verification by participants.

The common layer must preserve identifier uniqueness, proof of control, transfer state, delegation state, routing-related security assertions, auditability, conflict metadata, and fork visibility.

The operator layer must control commercial use, leasing, customer geography, routing practices, financing, counterparty selection, and non-invariant business rules.

The adoption layer must determine what becomes real. A coordination rule matters only if operators can implement it, counterparties can accept it, markets can trust it, courts can understand it, and interoperability remains possible without making incumbent recognition the sole source of reality.

The enforcement layer must not be merged with the state layer. A distributed ledger can record state. It can validate transitions. It can expose conflicts. It can make proof portable. It must not simultaneously become prosecutor, judge, sanctioning authority, market regulator, commercial moralist, and asset custodian.

Most important is understanding portability correctly.

In a distributed-ledger world, portability does not mean moving from one registry to another registry. That remains registry thinking. There is no registry to migrate to. The holder’s proof of control, state history, and transferability do not remain trapped inside an incumbent database. They exist in verifiable shared state that participants validate locally and counterparties voluntarily accept.

Without that, every registry is a choke point.

With it, the registry ceases to be the source of validity.

Therefore, post-RIR coordination needs four design properties.

First, deterministic validity. A participant must be able to know whether a state transition, proof, delegation, transfer, or assertion is valid by applying the specification locally.

Second, compatibility sets. If participants adopt different future rules, the system must clearly describe compatibility boundaries rather than treating dissent as an infraction.

Third, distributed proof of control. A holder must not “move” its resources to another registry; it must prove control through valid ledger state that any counterparty can verify without incumbent approval.

Fourth, fork visibility. If rule sets diverge, the divergence must be explicit. Participants decide which compatibility set to run and with which counterparties to interact. A fork may isolate participants, but it does not give one side institutional power to erase the other.

That is not an argument for five better monopolies.

It is an argument against monopoly as the source of validity.

Why the Failure Path Is Predictable

If nothing changes, the failure path is clear.

First, more disputes will move from policy rooms to courts. Scarce assets attract legal scrutiny. Courts will be asked to freeze accounts, preserve records, block irregular elections, appoint judicial administrators, recognize transfers, or determine who may act on behalf of a registry.

Second, states will stop treating RIRs as harmless technical associations. Addressing continuity affects national connectivity, sanctions, law enforcement, telecommunications resilience, cloud infrastructure, and economic security. No state will indefinitely accept a foreign private entity as an unquestioned upstream point for national communications continuity.

Third, operators will route around registry authority where possible. If registries become political, insecure, unrepresentative, or disconnected from asset reality, operators will turn to private contracts, litigation-backed transfers, alternative certifications, national recognition, or de facto routing reality.

Fourth, the ICANN and NRO layers will be tempted to centralize. That would produce a denser version of the same problem unless the mandate itself is reduced.

Fifth, governments will be tempted to nationalize. That would be predictable and dangerous. If private registries claim quasi-sovereign authority without public accountability, states will eventually claim sovereignty. The result could be fragmentation, retaliation, conflicting registries, and political pressure on routing.

The Internet does not fail only when packets stop moving.

It also fails when the institutions describing who may use identifiers lose the trust of the operators that move those packets.

A distributed ledger does not solve every political problem. But it does something more important: it removes the permanent registry as the ordinary source of validity. That reduces the attack surface. It reduces institutional hostage power. It turns future disagreements into compatibility selection rather than administrative war.

The Question Changes

The old system asks: who has the mandate?

That is the wrong question.

The better question is: what does running code actually require?

Does this rule protect uniqueness?

Does it preserve interoperability?

Does it correct demonstrable registration fraud through deterministic evidence?

Does it protect routing-related security?

Does it maintain the accuracy of proof of control?

Does it enable local validation?

Does it remove dependence on a single incumbent?

Does it describe adopted reality or declare an unadopted obligation?

Can a participant reject it without being labeled invalid?

Can a participant verify ordinary validity without asking a registry for a status?

Can a counterparty voluntarily accept or reject the state?

Can a fork occur without one side being erased by an institution?

If the answer is not tied to the deterministic need of running code, that power should not reside in the common layer.

That is Running-Code Primacy.

For Discussion

This proposal is for discussion. It is not a final solution.

The next step should be a serious Internet-Draft or BCP-style document defining Running-Code Primacy for Internet coordination systems, beginning with number resources. The draft should not ask how to rehabilitate the RIR monopoly. It should ask how to build post-RIR coordination through distributed-ledger state, deterministic validation, voluntary adoption, counterparty acceptance, and explicit compatibility sets.

It should be evaluated by operators, lawyers, economists, protocol engineers, routing-security experts, market participants, governments, and critics.

The draft should ask difficult questions.

What are the global invariants?

Which validation rules are deterministic?

Which state transitions must be globally visible?

Which old registry powers are historical residue?

Which decisions belong to operators?

Which decisions do not require representation because they should never enter the common layer?

What is the rejection path?

What is the fork path?

What is the local-rejection path?

How does a holder prove control without an incumbent registry?

How does a counterparty verify state without a registry?

Can the Internet continue if an RIR collapses?

Can number resources remain unique without incumbent permission?

Can a participant validate ordinary state without a permanent institution?

Can a policy process distinguish a running-code invariant from institutional will?

Can the old registry layer disappear without losing verifiable state?

Can a registry describe reality without becoming sovereign over it?

Anyone interested may contact me through LinkedIn. Serious researchers, technical authors, institutions, or policy experts who want to help turn this into a first Internet-Draft and eventually an RFC or BCP discussion, if the community finds it useful, may contact me. The LARUS Foundation and I are willing to support and fund serious research in this direction.

The RIR system failed in its initial design because it never asked what running code actually required.

It asked who could speak in the room.

The next system must reverse that order.

It is not mandate laundering.

It is not running-code betrayal.

Running-Code Primacy.

Appendix: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption for Internet Coordination Systems

Note 64

Abstract

This document describes a design pattern for Internet coordination systems whose purpose is to provide shared technical reference points without creating continuing authority over the participants who run the system. It defines three linked principles: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

Under this model, the Initial Specification defines only the deterministic, locally verifiable rules needed for uniqueness, interoperability, proof of control, shared security, and security. After the Initial Specification, future changes are not approved by a central body. They are adopted, ignored, forked, or abandoned by participants running code.

The intended design pattern is a distributed ledger of valid state, or an equivalent mechanism of distributed verifiable state, not a hierarchy of registries. There is no permanent registry deciding ordinary validity. Participants validate state locally, voluntarily accept counterparties, and decide which compatibility sets they run.

Non-adoption is not an infraction. A participant that does not adopt a later change remains in its existing compatibility set. A participant that emits states invalid under another participant’s accepted deterministic rules may be ignored locally by that participant. The effect is compatibility selection, forking, isolation, or selective interoperability, not institutional punishment.

This document does not define a wire protocol. It specifies a Best Current Practice (BCP) for the design of protocols, identifier systems, distributed ledgers, and coordination mechanisms that must not become permanent governance institutions.

1. Introduction

Many Internet systems begin with a limited technical purpose: allowing independent actors to interoperate through a common reference point, identifier space, validation rule, ledger state, or shared proof-of-control record. Over time, these systems often accumulate authority that was not necessary for initial interoperability.

This usually happens in three steps.

First, future questions are built into the foundational layer before they are technically necessary.

Second, decisions that should be made by participants running their own systems become dependent on recognition, interpretation, or status decisions by a permanent body.

Third, publication, registration, recommendation, or procedural approval is treated as sufficient to create operational obligations even when participants have not adopted the change in running systems.

The result is a fragile system. A technical reference layer becomes a governance layer. A registry becomes a control point. A coordination artifact becomes a source of future control.

This document proposes a different design discipline:

Minimum Initial Specification: define only the common deterministic rules needed for basic interoperability, uniqueness, proof of control, shared security, and security.

Localized Future Decision: after the Initial Specification, keep future decisions with participants running code. A participant may adopt, reject, fork, disconnect, or interoperate selectively. No participant can alter the interoperability of other participants that continue running mutually compatible rules.

Voluntary Adoption: make later changes real only through implementation, operation, validation, and adoption by participants running code.

These principles are related. A system that specifies too much at the outset preloads future control into the common layer. A system that maintains a continuing recognition layer allows authority to reappear after deployment. A system that treats publication as reality turns documentation into mandate.

The design intuition is simple: validity must be determined by deterministic rules that participants can verify locally against shared state. A participant may adopt a later change, reject it, fork, disconnect, or interoperate selectively. At most it may leave a compatibility set. By rejecting a change, it cannot break the interoperability of other participants that continue running mutually compatible rules.

This is the general lesson of distributed-ledger design: consensus rules are applied by participants running validation code and deciding which state they accept, not by an institution above them.

2. Scope

This document applies to Internet coordination systems, including but not limited to identifier systems, naming and numbering frameworks, protocol-extension mechanisms, proof-of-control systems, portability systems, distributed ledgers, and other architectures in which independent actors depend on a common technical reference point.

This document does not argue against common rules. It argues that common rules must be deterministic, minimal, locally verifiable, and limited to what the system actually needs to function.

This document does not require any specific distributed-ledger implementation. It requires a design property: participants must be able to determine validity by applying the Initial Specification locally to shared or replicable state, without asking a permanent authority for permission or status.

3. Conventions and Definitions

3.1. Requirement Language

The requirement terms in uppercase in this document are to be interpreted as defined by BCP 14, specifically RFC 2119 and RFC 8174.

3.2. Terminology

Initial Specification:
The set of rules, data structures, formats, invariants, validation procedures, state-transition rules, and conflict rules required for the first deployment of a system.

Common Layer:
The minimum set of shared rules or reference structure needed for independent participants to interoperate. The common layer is not an institution. It is the technical substance that participants implement and verify.

Distributed Ledger:
A replicated or otherwise distributed record of state transitions that allows participants to verify ordinary validity without depending on a permanent registry, committee, or other authority. The term does not require any specific consensus algorithm or implementation.

Deterministic Validation Rule:
A rule that allows a participant to decide, through local computation or local verification, whether a state, record, transition, assertion, or message is valid under a specified rule set.

Global Invariant:
A property that must remain common within a compatibility set to preserve uniqueness, basic interoperability, proof-of-control integrity, shared security, or security.

Participant:
An operator, implementation, node, network, organization, or other actor that runs, verifies, deploys, or depends on the system.

Compatibility Set:
A group of participants whose implemented validation rules allow them to interoperate with one another. A later change may create a new compatibility set if some participants adopt it and others do not.

Adoption:
Actual implementation, deployment, validation, and use by participants running the system.

Counterparty Acceptance:
A participant’s voluntary decision to accept, transact with, interoperate with, or trust another participant’s state under the validation rules it runs.

Non-Adoption:
A participant’s decision not to implement or use a proposed change. Non-adoption does not create an invalid state. It only means that the participant has not entered the compatibility set created by that change.

Local Rejection:
A participant’s local decision to ignore, reject, or not interoperate with a state, message, record, or transition that is invalid or incompatible under the validation rules it runs.

Fork:
A divergence in validation rules or operational practice that creates two or more compatibility sets.

Coordination Artifact:
A document, recommendation, implementation note, profile, reference implementation, ledger explorer, replica, or other artifact that helps participants coordinate. A coordination artifact does not create binding operational reality unless participants adopt it in running systems.

4. Problem Statement

Designers often try to reduce future uncertainty by writing too much into the foundational layer or leaving a permanent body to interpret future questions. This seems prudent. It is often dangerous.

Over-specification in the foundational layer has three costs.

First, it moves future decisions into a common layer where change is more difficult and capture has greater effect.

Second, it creates ambiguity between technical validity and institutional recognition.

Third, it encourages a body that maintains records, publishes documents, or convenes participants to treat those acts as authority over future reality.

The same problem appears after deployment. If a system requires a permanent body to approve changes, determine status, or interpret ordinary operation, the system has created a post-foundation control layer. That layer may begin as administration. It may become governance. It may become a choke point.

The design objective of this document is not better institutional discretion. It is to avoid the need for that discretion.

A well-designed Internet coordination system should define deterministic, locally verifiable validity rules from the start; represent valid state in distributed or replicable form; keep non-invariant decisions outside the common layer; and allow later changes to become real only when participants voluntarily adopt them in running systems.

5. Principle 1: Minimum Initial Specification

5.1. Statement

An Initial Specification SHOULD define only the minimum deterministic common rules necessary for basic interoperability, uniqueness, proof of control, shared security, and security.

5.2. Requirements

A design using this principle:

• MUST explicitly identify its Global Invariants.
• MUST define deterministic validation rules for each Global Invariant.
• MUST define how valid state is represented, replicated, verified, and updated.
• MUST NOT include a rule in the Initial Specification unless that rule is necessary to preserve a declared Global Invariant or enable initial deployment.
• MUST separate validation rules from policy preferences, commercial agreements, institutional roles, governance aspirations, and discretionary judgment.
• MUST allow participants to verify ordinary validity locally without requesting information from any institution, registry, committee, policy body, or other authority.
• SHOULD define data structures, signatures, proofs, state-transition rules, conflict rules, or other mechanisms needed for local verification.
• SHOULD define extension signaling, versioning, compatibility labeling, or fork identification when future variation is foreseeable.
• MUST ensure that required coordination artifacts are portable, auditable, reproducible, and replaceable.
• SHOULD prefer machine-verifiable objective conditions over subjective judgments of merit.
• MUST NOT make future institutional recognition the only way a valid state can be known, recorded, or used.

5.3. Design Implications

Minimum Initial Specification does not mean a vague specification. It means a strict specification only of what must be common.

A system still needs enough common structure to function. The discipline is to distinguish between:

• what must be common for uniqueness, interoperability, proof of control, shared security, and security; and
• what may remain outside the common layer because it belongs to operator preference, commercial practice, counterparty choice, deployment timing, or later adoption decisions.

A design that cannot clearly express its Global Invariants and deterministic validation rules should assume that it has specified too much discretion and too little verifiable substance.

6. Principle 2: Localized Future Decision

6.1. Statement

After the Initial Specification, Future Decisions SHOULD remain local to participants running code. A Future Decision becomes effective only for the compatibility set whose participants adopt it. No permanent authority is required to approve it, and non-adoption does not create an invalid state.

6.2. Requirements

A design using this principle:

• MUST NOT require participants to obtain permission from an incumbent institution, registry, committee, council, policy body, or other authority for decisions that do not alter the deterministic validation rules of the compatibility set to which they belong.
• MUST NOT create a permanent body whose recognition is the only way a later change can become operational reality.
• MUST distinguish validity under the Initial Specification from compatibility with an optional later change.
• MUST NOT treat non-adoption of a later change as invalidity.
• MUST allow participants to remain in an existing compatibility set when they do not adopt a later change.
• MUST allow participants to join a new compatibility set by adopting new validation rules or operational profiles.
• MUST allow participants to locally reject states, records, transitions, or messages that are invalid or incompatible under the validation rules they run.
• MUST allow participants to choose counterparties voluntarily according to the validation rules and compatibility sets they accept.
• MUST NOT authorize any institution, registry, committee, policy body, or other actor to declare a participant invalid solely because it rejected a later change.
• SHOULD make forks, versions, profiles, or compatibility sets explicit so participants know which rules they are running and with which other participants they can interoperate.
• SHOULD avoid any design in which an incumbent registry can prevent participants that remain valid from continuing to interoperate.

6.3. Design Implications

Localized Future Decision does not mean that a central authority assigns future decisions to local actors. It means the system is designed so that, after the Initial Specification, ordinary future decisions do not require such assignment.

The Initial Specification performs the limiting work in advance. It defines the minimum invariants necessary for uniqueness, interoperability, proof of control, shared security, and security. Everything else remains outside the common layer.

Future change is not approved centrally. It is adopted, ignored, forked, or abandoned by participants running code.

A participant that rejects a change may remain outside the compatibility set created by that change. It may disconnect from others. It may continue in an earlier compatibility set. It may fork. It may interoperate selectively. But it cannot break the interoperability of other participants that continue running mutually compatible rules.

The effect of an invalid or incompatible state is local rejection, not punishment. No one needs to determine that a participant is in bad standing. A participant running compatible validation rules simply does not accept the invalid or incompatible state.

7. Principle 3: Voluntary Adoption

7.1. Statement

Changes to an Internet coordination system SHOULD become operational reality through implementation, validation, deployment, counterparty acceptance, and adoption by participants, rather than through publication or declaration alone.

7.2. Requirements

A design using this principle:

• MUST NOT treat publication, recommendation, meeting approval, or procedural approval as sufficient to create a universal operational obligation.
• MUST allow new rules, extensions, profiles, or procedures to be deployed incrementally by participants that choose to run them.
• MUST allow participants to reject a later change without acquiring an invalid state, provided their own state transitions comply with the deterministic rules of their compatibility set.
• MUST allow participants to continue using an earlier compatibility set when the Initial Specification permits that continuity.
• MUST allow participants operating in one compatibility set to locally reject or ignore states from another compatibility set when the rules are incompatible.
• SHOULD define adoption paths for substantial changes, including version signaling, compatibility labeling, transition guidance, and test vectors.
• SHOULD define rejection paths for substantial changes, including how non-adopting participants continue operating, identify their compatibility set, and avoid ambiguous interoperability.
• MUST ensure that necessary coordination artifacts can be abandoned, replicated, reimplemented, or replaced without impossible transition costs.
• SHOULD make registries, recommendations, and coordination artifacts describe adopted reality rather than attempting to declare an unadopted future reality into existence.
• MUST NOT design a system in which the only way for a change to become real is prior recognition by an incumbent body.

7.3. Design Implications

Voluntary Adoption is the operational test of whether a change is useful, tolerable, and compatible with real deployment.

A proposal is not reality. A recommendation is not reality. A document is not reality. Reality appears when participants implement, validate, deploy, accept counterparties, and depend on the change.

Non-adoption creates no violation status. It creates only one fact: the participant has not entered the compatibility set created by the change.

This does not eliminate standards processes, documentation, implementation notes, explorers, replicas, or reviews. It limits their scope. They may help participants coordinate. They may publish reference material. They may describe adoption. They may recommend. But by declaration alone they cannot make an unadopted future reality binding on participants that do not run it.

8. Relationship Between the Three Principles

The three principles reinforce one another and are not effective in isolation.

Minimum Initial Specification ensures that the common layer contains deterministic validation rules rather than discretionary authority.

Localized Future Decision ensures that future decisions remain with participants running code rather than being recaptured by a central approval layer.

Voluntary Adoption ensures that later changes must survive contact with implementation, verification, counterparty acceptance, and use.

A system adopting only one or two of these principles can reproduce the same centralization by other means.

Minimum Initial Specification without Localized Future Decision can still allow authority to accumulate after deployment.
Localized Future Decision without Minimum Initial Specification can produce ambiguity because participants cannot determine validity locally.
Voluntary Adoption without deterministic validation can produce confusion because participants cannot distinguish compatible variations from invalid states.
Deterministic validation without distributed state can still leave participants dependent on a privileged registry.
Distributed state without fork visibility can conceal disagreement until operational failure.
Distributed state without voluntary counterparty acceptance can recreate coercion through another interface.

Together, the principles produce a system in which the common layer is thin, validity is locally verifiable, future change is voluntary, state is distributed, and no permanent institution is needed to decide ordinary operation.

9. Recommended Design Pattern

9.1. Deterministic Distributed Common Layer

The common layer SHOULD be limited to:

• stable identifier semantics;
• deterministic validity rules;
• conflict-resolution rules needed to preserve uniqueness;
• proof-of-control mechanisms;
• state-transition rules;
• network- or protocol-level interoperability requirements;
• shared security invariants;
• portable, auditable state formats;
• distributed or replicated state visibility;
• extension signaling and compatibility-set identification.

The common layer SHOULD NOT contain:

• business-model rules;
• pricing rules;
• regional political preferences;
• eligibility ideology unrelated to technical invariants;
• discretionary enforcement powers;
• subjective merit assessments;
• institutional mission expansion;
• any rule whose primary function is preserving an incumbent body’s authority.

9.2. Operator Decision Surface

The following SHOULD remain outside the common layer unless they directly alter a declared Global Invariant:

• deployment timing;
• commercial use;
• customer geography;
• leasing, financing, or transfer agreements;
• local eligibility preference;
• operational sequencing;
• routing practice not required for shared validity;
• business model;
• organizational structure;
• voluntary migration timing;
• optional profiles or extensions;
• counterparty choice.

Participants MAY adopt different decisions in these areas. Those decisions may produce different compatibility sets, commercial relationships, peering agreements, or operating communities. They do not create invalidity unless they violate deterministic validation rules within a compatibility set.

9.3. Adoption Cycle

Where possible, the preferred order for substantial system changes is:

• proposal;
• implementation;
• test vectors or deterministic verification method;
• limited deployment by willing participants;
• observation of interoperability and security effects;
• compatibility-set labeling;
• documentation or recommendation describing adopted reality.

A coordination artifact SHOULD follow adoption rather than attempt to anticipate it.

9.4. Forking, Local Rejection, and Counterparty Acceptance

A conforming design SHOULD treat forking, local rejection, and counterparty acceptance as normal design requirements rather than failures.

The system SHOULD define how a participant can:

• continue in an earlier compatibility set;
• adopt a new compatibility set;
• fork into a different compatibility set;
• verify state without depending on an incumbent registry;
• voluntarily accept counterparties;
• locally reject invalid or incompatible states;
• interoperate selectively where compatibility allows.

A system that cannot be forked, locally verified, or selectively interoperated with without destroying valid operation has probably hidden governance power inside its registry function.

10. Applicability and Limitations

This design pattern is particularly applicable when:

• the system is multi-actor and multi-jurisdictional;
• independent deployment matters;
• the coordination layer is intended to remain thin;
• future variation is likely but cannot be predicted in detail;
• lock-in or dependency would create governance risk;
• validity can be made deterministic or locally verifiable;
• distributed state can reduce institutional-capture risk.

It may be less directly applicable when:

• a single administrative domain is the intended architecture;
• strong real-time coupling requires uniform behavior at all times;
• life-safety considerations require immediate global uniformity;
• validity cannot be verified locally by any practical mechanism.

Even in these cases, designers SHOULD continue minimizing the common layer and avoiding discretionary future control where possible.

11. Non-Goals

This document does not:

• prohibit all coordination;
• require any specific distributed-ledger implementation;
• guarantee consensus;
• guarantee political neutrality;
• require all participants to adopt every later change;
• treat refusal to adopt as invalidity;
• legitimize incompatible local behavior under a claim of compatibility;
• eliminate the need for common rules critical to security.

12. Security Considerations

A thinner coordination layer may reduce capture risk, decrease the impact radius of institutional errors, and improve replaceability. However, greater local discretion and distributed state may also produce inconsistent security postures, downgrade paths, fragmentation pressure, ambiguous compatibility assertions, unsafe forks, disputes over ledger state, and attempts to forge proofs.

Therefore, designers applying this document MUST explicitly specify security invariants. In particular:

• authentication and authorization requirements necessary for shared validity MUST be deterministic and locally verifiable;
• proof-of-control mechanisms MUST resist forgery, replay, and unauthorized transfer;
• version negotiation and extension handling MUST prevent silent downgrades when security is affected;
• rejection, fork, and replacement paths MUST be analyzed for abuse and denial-of-service risk;
• compatibility labels SHOULD be clear enough to prevent accidental interoperability between incompatible rule sets;
• distributed state SHOULD be auditable and reproducible to detect inconsistent views;
• local variation MUST NOT be able to falsely claim compatibility with a rule set it does not satisfy.

The existence of security exceptions does not justify a general permission layer. It justifies only the deterministic security rules needed to preserve declared Global Invariants.

13. IANA Considerations

This document requires no actions by IANA.

14. References

14.1. Normative References

• RFC 2119 — Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, BCP 14, RFC 8174.

14.2. Informative References

• RFC 6709 — Carpenter, B. and B. Aboba, Design Considerations for Protocol Extensions, RFC 6709.
• RFC 7282 — Resnick, P., On Consensus and Humming in the IETF, RFC 7282.

Appendix A. Design Checklist

A design claiming conformance with this document SHOULD be able to answer the following questions clearly:

• What are the Global Invariants?
• Which deterministic validation rules preserve those Global Invariants?
• Which rules in the Initial Specification are strictly necessary for first deployment?
• How is valid state represented and verified?
• Is state distributed, replicated, or otherwise independently verifiable?
• Which future matters are intentionally left outside the common layer?
• Which future decisions can participants make without altering the compatibility set in which they are located?
• How does a participant adopt a later change?
• How does a participant reject a later change without being assigned an invalid status?
• How are compatibility sets labeled or discovered?
• How does local rejection work when a state is invalid or incompatible under the rules a participant runs?
• What is the fork path?
• How does a holder prove control without an incumbent registry?
• How does a counterparty verify state without a registry?
• Can participants verify ordinary validity without depending on an incumbent registry?
• Do registries and coordination artifacts describe adopted reality, or do they attempt to declare an unadopted future reality into existence?
• Has the system minimized the number of decisions built into the common layer?
• Has the system avoided any permanent authority determining participants’ ordinary status?
• Can participants voluntarily accept or reject counterparties?
• Can the system continue if all incumbent registries disappear?

Author Address

Lu
[TBD]