What is running-code betrayal in RIR governance

Imagine a network serving customers normally. Its equipment works, its connections work and other networks can reach it. Then the organisation maintaining its address records changes the conditions under which it will recognise that network. The cables have not moved, but the operator now has to defend the administrative basis on which others depend.

This is the conflict Lu Heng calls running-code betrayal: institutions invoke a tradition created to help networks work, then use that tradition to justify power over the networks themselves. In Note 61, his criticism goes beyond whether a meeting was fair. He asks why the meeting should have that power in the first place.

What does “running code” mean here?

Running code means software and systems that have actually been implemented and used. For an Internet service, that includes the real work of connecting networks and keeping customers reachable. A proposed design is tested against this operational reality.

The IETF's mission statement connects engineering judgement with experience implementing and deploying specifications. Its discussion of rough consensus explains why counting supporters is not a substitute for addressing technical concerns. These are methods for producing useful engineering, not a general mandate to govern everyone affected by the Internet.

Lu Heng applies that distinction to Regional Internet Registries, or RIRs. A registry helps coordinate number resources so networks can distinguish one resource from another. Its usefulness comes from supporting that shared function. His argument is that the function does not give the institution unlimited authority over the people using it.

The reversal: the network starts serving the procedure

Consider a rule intended to prevent two unrelated networks from claiming the same number. That rule addresses a shared technical problem. Now consider a rule deciding which customers an operator may serve, which commercial arrangements it may use, or whether its resources should remain attached to a particular administrator.

Those decisions reach much further. Saying that participants approved them does not establish that every affected operator or customer authorised the participants to make them.

The reversal occurs when the operator must reorganise a working service around an institution's preference, while the institution treats completion of its procedure as a sufficient answer to the consequences. The process continues to function. What changes is whose interests it serves.

Why a database decision can matter outside the database

A registry does not carry every packet. Changing a record is not the same as switching off every router. The influence comes through dependence: providers, customers and other systems consult records and related evidence when recognising a resource and deciding how to handle it.

That creates a chain between an administrative decision and a service people use. The consequences depend on the particular record, the technical systems involved and the decisions of the organisations relying on them.

To see the chain, follow one address block through a business. Who maintains its registration contacts? Who publishes its routing authorisations? Which networks carry its traffic? Which customers have embedded its addresses in their own settings? A disagreement at the recordkeeping layer can require work across all of those relationships.

What the AFRINIC discussion contributes

Note 61 uses the AFRINIC dispute to develop a specific criticism: Lu Heng argues that a narrow coordination role was expanded through interpretations of regional use, institutional recognition and transfer conditions. He also challenges the wider registry system's defence of that expansion.

His account distinguishes where traffic flows from whether a holder can move its administrative relationship. A restriction on exit can create dependence even while ordinary routing continues. This is why he treats portability as a structural question, rather than a minor convenience.

The Note contains his detailed reading of the policy record, institutional statements and litigation. The broader question for this introduction is understandable without accepting every institutional claim: when the coordinator is disputed or unavailable, can the people running the network preserve their service without its continuing permission?

Why better participation is not enough

More accessible meetings, clearer explanations and better ways to object can improve a process. They do not by themselves answer what the institution is entitled to decide.

Lu Heng's criticism is therefore not simply that consensus should reflect more participants. It is that coordination must remain limited by the work it exists to support. A procedure cannot supply its own unlimited mandate by declaring that its participants agree.

That is also why replacing one committee with another would leave the central problem intact if the new committee remained the indispensable source of recognition.

The proposed alternative: make validity independently checkable

Note 65 develops the constructive answer, Running-Code Primacy. Its proposed common layer contains the minimum rules needed for uniqueness, proof of control, security and interoperability. Participants should be able to check those rules locally against distributed state.

Later changes become operational through implementation and voluntary adoption. Participants that keep compatible older rules need not ask a standing institution for permission to continue. A participant can reject a state that fails the rules it runs; that technical rejection is different from an institution punishing someone for declining a later policy.

This is a proposed architecture. Making it work requires conflict handling, secure proofs, visible compatibility and practical transition paths. Publishing a document or copying a registry file does not, by itself, make other networks accept a successor.

Why prepare while the network is still working?

Continuity cannot be improvised by changing a label during a crisis. Operators and their counterparties need usable records, ways to verify them and a tested understanding of what survives a transition.

The reader's test is simple: does a rule protect something that networks genuinely need in common, or does it preserve the administrator's ability to decide for them? Then ask whether the useful coordination can continue if that administrator disappears.

Read Note 61 for the critique, Note 65 for the proposed design, and Note 72 for its statement of rights. Together they move from what has gone wrong to what the shared layer should actually do.