The team’s articlesPower and governance

Can Internet Coordination Evolve Beyond Registry Authority?

Networks need unique identifiers and reliable records. Lu Heng's Notes ask how to preserve those functions without giving a permanent administrator power over participants.

Contents

Three independent workshops connect around an open courtyard, beside a case of distinct blue tokens.
Common identifiers help independent participants work together. Lu Heng asks how those shared rules can remain usable without a permanent permission gate.

Imagine a shared address book that delivery companies need to serve a city. Keeping its entries accurate is useful. Giving its maintainer a permanent power to decide who may operate is a different proposition. Internet coordination faces that distinction at a much larger scale.

Networks need compatible identifiers and usable records to communicate. The question is whether providing those common reference points must also give a continuing institution authority over everyone who depends on them. Lu Heng's answer is that coordination should be designed so it does not require that authority.

Start with the function that must survive

An IP prefix identifies an address block, and an autonomous system number identifies a network participating in interdomain routing. Within a system whose participants intend to interoperate, these identifiers need consistent meaning. Conflicting claims cannot be resolved simply by declaring every claimant right.

That need establishes a coordination problem. It does not, by itself, settle who should govern future decisions, what political mandate a recordkeeper has, or whether users must remain dependent on one provider forever.

In Note 28, Lu Heng distinguishes maintaining number-resource records from enforcing sanctions or punishments. In his argument, administering a necessary service does not give a self-selected community the right to govern networks across different countries.

How a recordkeeper gains practical power

A registry need not carry packets to affect connectivity. Other organizations may use its records to construct routing filters, validate assertions or recognize a resource relationship. A change at the record layer can then alter decisions elsewhere.

The mechanism matters. A stale contact entry is not an automatic BGP withdrawal; an authorization change is not a universal Internet off-switch. The effect depends on the systems that consume the record and the policies their operators apply. The guide to changed registry data follows that chain.

Yet the absence of a single off-switch does not eliminate concentrated influence. If users cannot carry their evidence elsewhere or obtain compatible service without the incumbent's permission, nominally voluntary coordination can become a dependency they cannot realistically leave.

A smaller common rulebook

Note 64 proposes three connected principles: a minimum initial specification, future decisions made locally, and voluntary adoption.

The initial rules should precisely define what must remain common for uniqueness, interoperability and security. Participants should be able to check valid state against those rules themselves. Ordinary validity should not depend on asking a permanent committee to recognize it.

Later changes become operational because people implement and adopt them. A participant may remain with compatible existing rules, adopt a change or choose a different compatibility set. A refusal to adopt is not, in this proposal, a disciplinary offence. It also cannot guarantee interoperability with systems using incompatible rules.

This is a design requirement, not a demand to use a particular blockchain. Signatures or replicated databases can help establish evidence, but they do not decide which initial records deserve recognition, resolve every conflict or make other networks adopt a replacement.

What a credible alternative has to demonstrate

A working transition must answer questions that a slogan cannot. How are duplicate claims detected? What evidence establishes control? Can participants reproduce a record's history and verify changes locally? How does a new implementation remain compatible with the networks that matter to its users?

It must also show how someone can leave a failing coordinator without abandoning their operational history. Copying a database is only one step. Other participants must be able to validate and use the exported state; security assertions, routing relationships and continuity still need to work.

A replacement that requires one new organization to approve every future decision would recreate the same dependency. The relevant test is whether participants can maintain accurate, compatible operation without that permanent permission layer.

Build the exit while the network still works

The strongest reason to prepare is the cost of discovering an inescapable dependency during a dispute or outage. Customers still need access while institutions disagree. Continuity should be part of the architecture, rather than a favour negotiated after service is at risk.

Begin with one address block: trace its records, the parties allowed to change them, and the systems that consume them. Then ask what evidence and compatible services would have to remain available if the present coordinator disappeared.

Lu Heng's proposal aims beyond improving an administrator's behaviour. It asks for infrastructure in which verifiable common rules can survive the administrator. Read Note 64 for the design argument and the responsibilities that remain with participants.