Summary

  • RIPE NCC's 12 August review describes multiple LIR accounts as a shrinking population with a continuing operational cost; it proposes discussion, not a decided sunset.
  • Any simplification should be governed by an exception-retirement register that reconciles resources, sponsorships, contacts, access, billing and audit state before and after each change.

A small population can leave a large state surface

On 1 August 2026, RIPE NCC counted 410 members with multiple LIR accounts. They represented about 2.1% of the membership and held 708 additional accounts, 3.4% of all LIR accounts. Only 41 members had opened 67 additional accounts during the preceding 24 months.

Those numbers make change look easy. They do not make it safe.

The RIPE Labs review lists the places where the exception lives: fragmented member information, separate audit and closure handling, resource transfers, billing contacts, compliance checks, fraud controls, portal context and the assignment of a member's single vote to the correct account. The population has contracted; the number of meanings attached to an account has not.

RIPE NCC says it will present the subject at RIPE 93 and invites community discussion. It has not announced that additional accounts will close, set a migration date or adopted a replacement rule. This distinction matters. A staff diagnosis is evidence for deliberation, not authority to rewrite member state.

The 2016 decision produced an installed system

The exception predates IPv4 exhaustion. It once accommodated independent business units and acquired companies that wanted separate administration. The last-/8 rule changed its incentive. When each new LIR account could receive a final allocation, the value of opening an account became entangled with the value of scarce IPv4.

In May 2016, RIPE NCC members voted to restore the ability to create additional accounts: 508 yes, 289 no and 44 abstentions. The implementation specified that moving resources between LIR accounts of the same member would still fall under transfer policy. That is an important boundary. Common legal membership did not make every internal move a clerical relabelling.

Ten years later, the original assumptions can be reconsidered. But an authorised exception has accumulated legitimate reliance. An organisation may have separated invoices, contact teams, sponsored resources, maintainers, portal permissions or audit histories for reasons unrelated to obtaining address space. History explains why a feature exists; it does not classify every current user.

The unit of retirement is not the account

A bulk instruction to “merge accounts” would collapse several different transitions.

The legal member is one object. Each LIR account is another. Allocations and assignments have their own registry histories. Sponsored independent resources connect an end user to a sponsoring LIR. Maintainers and contacts control particular updates. Portal roles determine who may see or request what. Invoices and arrears affect closure. Audits, transfer restrictions, disputes and pending tickets may prevent a clean move.

Routing is separate again. Consolidating two administrative accounts does not itself prove a change in origin AS, announcement, customer service, beneficial control or contract. A registry transition should describe those external facts only when evidence establishes a separate change.

The safe question is therefore not “which account disappears?” It is “which state attached to that account must be preserved, reassigned, closed, disputed or left untouched?”

An exception-retirement register

RIPE NCC should publish the schema before proposing an irreversible programme. For each affected member, the protected working record would list:

  • the verified legal member and every account in scope;
  • each resource and its registry, transfer and sponsorship state;
  • maintainers, authorised contacts and portal roles;
  • billing status, open audit items, restrictions, disputes and pending requests;
  • the proposed destination for every item, including an explicit “no change” state;
  • the authority for the transition and any member consent or objection;
  • pre-transition and post-transition fingerprints;
  • validation results, unresolved exceptions, correction route and rollback boundary.

Member-specific detail need not be public. The public layer can report counts by state: eligible, awaiting member confirmation, blocked by an open process, executed, verified, corrected or retained by exception. It should show which rules and data snapshot produced each count.

This is not an argument for permanent complexity. It is a way to remove complexity without destroying evidence. The ledger must survive the simplification of the gatekeeper's systems.

Decisions must come in the right order

First, RIPE NCC can inventory the exception and publish aggregate dependencies. Second, it can ask members whether the one-member-one-LIR model should become the default for new accounts, existing accounts or both. Third, it can present transition choices with costs, affected populations and appeal routes. Only an authorised decision should trigger execution.

Different decisions may need different authority. Service design, contractual terms, charging and number-resource policy do not become one question merely because the same account touches them. The 2016 record itself shows this division: the GM authorised additional accounts, while transfer policy continued to govern resource movement.

A default can include bounded exceptions. A member in a regulated separation, unresolved acquisition, insolvency process or contested sponsorship may need temporary account separation. The exception should have a reason class, reviewer, expiry or review date and safe public aggregate—not a permanent invisible waiver.

Sources