Summary

  • ICANN's June and July 2025 letters to AFRINIC's appointed receiver warned that a compliance review might be necessary, tied election irregularity and record concerns to ICP-2 obligations, and demanded substantiated answers. That was a recognition warning, not a complete replacement plan.
  • The missing rule is not only who may be an emergency operator. It is how registry services, member authority, records, RPKI material, reverse DNS, transfers, billing, confidential data, disputes and court constraints move during an emergency without harming ordinary resource holders.
  • A replacement rule should require defined triggers, operator consent, service scope, data escrow, portability tests, public notice, community input, time limits, handback, independent review and post-event reporting before a recognition threat can be converted into a service transition.

A threat without a receiving desk

The most important sentence after a failed registry is not "the registry is under review." It is "this is where the service will run tomorrow." A region can survive a board dispute, a lawsuit, a delayed election or even a temporary receiver if registration data, help desks, reverse DNS, RPKI, public lookup records, transfers, billing and member communications remain stable. It becomes fragile when recognition review is mentioned without a visible receiving desk for the public function.

AFRINIC made that distinction unavoidable. By June 2025, the African regional registry had already spent years inside a legal and governance crisis. Courts in Mauritius had appointed a receiver. The registry had lacked ordinary board governance. An election designed to restore the board was suspended and then annulled after allegations involving voting authority and powers of attorney. ICANN then wrote to the appointed receiver and put AFRINIC on notice that a compliance review might be necessary.

The warning was not casual. In the 25 June 2025 letter, ICANN connected the allegations to obligations under ICP-2, asked thirteen detailed questions, required a substantiated response within a day, demanded preservation of records and said the situation could raise serious questions about AFRINIC's ability to continue acting as an entity capable of responsibly managing numbering resources. In the 3 July 2025 letter, ICANN said the annulment of the election did not answer many of its questions and again reserved all rights to initiate a review.

That correspondence had a legitimate continuity motive. A regional registry is not an ordinary private association. It maintains a public reliance surface for address and autonomous-system records. If an election process is compromised or if records are not preserved, the damage can reach far beyond the people fighting in court. ICANN was right to ask about member support, equal treatment, impartiality, independence and record backups.

But the warning also exposed the missing replacement rule. If ICANN had moved from warning to formal review, and if a review found material non-compliance, what exactly would happen next? Would AFRINIC lose recognition immediately? Would another RIR operate only the technical services? Would the receiver remain in place? Would members keep paying AFRINIC? Would transfers continue? Would RPKI certificates remain valid? Would reverse-DNS changes be processed? Would confidential records be copied to a temporary operator? Would domestic court orders bind that operator?

Would resource holders have a way to challenge an incorrect transfer of their files?

The public answer was not clear enough. Press reporting at the time captured the risk. The Register reported on 26 June 2025 that ICANN's letter warned of possible compliance review and that, if AFRINIC failed such review, ICANN could ask another RIR to step in as an emergency registry for Africa. That sentence is a powerful idea. It is also not a procedure. A credible replacement rule cannot be a news-line explanation of possible emergency support. It must be a document that operators can execute and members can test.

The problem is not that emergency replacement should be impossible. The problem is that it should be hard, narrow and predesigned. A temporary operator can preserve service if the incumbent legal entity cannot do so. The same temporary operator can create a legitimacy crisis if selection, consent, data transfer, scope, time limit and handback are vague. In a region already suspicious of external power, "another RIR will step in" can sound less like continuity and more like displacement unless the rule is explicit.

The receiving desk must therefore be identified before the threat is used. Not necessarily by naming a permanent successor in advance, but by defining what kind of entity can serve, who must agree, what services it may operate, what data it may receive, what it cannot decide, how long it can act and how the affected community is heard. Recognition review without a replacement rule is half a bridge over a deep river.

The election crisis turned continuity into a practical question

AFRINIC's board election crisis was not merely an internal association matter. A regional registry's board controls budgets, executive appointment, oversight, legal posture, member accountability and the trust environment around technical services. A disputed election can therefore become a registry-service problem even if the database servers continue to answer.

The June 2025 election issue had several layers. ICANN described reports that members faced registration difficulties. It described a difference between ordinary proxy limits and powers of attorney for in-person voting. It relayed reports that some powers of attorney had been fraudulently obtained or lodged without authorization. It asked whether lists of authorized voting resource members had been shared externally and whether a third party had been authorized to use AFRINIC's logo in candidate endorsement communications. It also asked for the status of record keeping and backups of registration data and resource-member records.

Those questions show why election integrity and service continuity are linked. A forged voting authority is not the same as a corrupt resource transfer, but both depend on the institution's ability to recognize who may bind a member. A leaked member list is not the same as database corruption, but it suggests control weakness around confidential or sensitive member information. An unclear investigation is not the same as a service outage, but it weakens confidence that future decisions will be impartial and documented.

At the same time, the link has limits. A bad election does not automatically mean that every address record is unreliable. An annulled vote does not automatically require a new registry. A receiver's poor communication does not necessarily mean that the help desk cannot process routine tickets. A temporary board vacuum does not necessarily justify moving confidential records to another organization. The replacement rule must respect these distinctions.

This is where many crisis arguments fail. One side says continuity requires leaving the incumbent alone because any external intervention risks destabilizing services. The other side says governance failure proves the incumbent should be replaced. Neither answer is precise enough. Continuity requires a service map. Which services are working? Which services are at risk? Which decisions are contaminated by the governance defect? Which records need independent preservation? Which member rights need verification? Which changes can safely continue? Which changes should pause?

For AFRINIC, a service map would include public registration data, non-public account and member files, reverse-DNS delegations, resource certification state, pending transfers, billing, member communications, corporate authority files, policy records, help-desk queues, court orders, contracts with suppliers, bank access, and credentials. It would also include the dependencies that other actors use to rely on AFRINIC records: cloud onboarding, routing filters, due diligence, public procurement and legal opinions in address transactions.

The NRO recognized continuity as early as the receiver appointment. Its 14 September 2023 statement welcomed the receiver as a route toward functional governance and said the appointment would help ensure that members kept receiving registry services. That was the right frame: preserve services while governance is restored. But an extended crisis turns temporary preservation into a tougher question. If preservation itself fails, who takes over only the parts that must continue?

The rule must be able to answer without dramatizing every defect as replacement. It should begin from service triage, not institutional condemnation.

Emergency service is not successor governance

An emergency operator is not a new regional government. It should be a temporary service provider with tightly bounded authority. It may operate a help desk, maintain records, process defined routine changes, preserve reverse-DNS and RPKI continuity, hold data safely and report service metrics. It should not rewrite regional policy, restructure membership rights, settle private resource disputes, take sides in elections or become the permanent service institution by default.

The NRO draft RIR Governance Document Version 2 moves toward this distinction. It defines an emergency operator as a qualified entity selected to provide RIR services temporarily. It says emergency continuity may be initiated when an RIR cannot adequately provide all or part of its services.

It requires unanimous agreement of all other RIRs and ICANN, discussion with the affected RIR and its community where reasonably possible, prompt publication of rationale and scope, community engagement, cooperation in handover, the affected RIR's right to resume services once capability is restored and verified, and a ninety-day initial limit unless renewed under the same section.

That framework is useful because it rejects the idea that replacement is simply an institutional takeover. It treats emergency service as temporary, scoped and reviewable. It also requires post-event review, including a public report on circumstances, services provided, duration, return process, operator performance, feedback and improvements.

The details remain decisive. Temporary operation still requires credentials, records, staff knowledge, procedures, data-protection boundaries, authority to answer requests, service-level expectations and conflict rules. If these are not prepared, an emergency operator may be technically willing but practically blind. It may have no current copy of member authority files, no validated state of pending transfers, no safe way to sign or change resource certification material, no knowledge of court-restricted accounts, and no route to verify who may instruct it.

The emergency operator also needs a non-governance mandate. It should be able to process a routine contact update if the member's authority is verified. It should not decide whether a disputed board candidate was lawfully excluded. It should be able to preserve a pending transfer state. It should not adjudicate the commercial merits of the transfer if the incumbent registry had not reached a decision. It should be able to keep reverse-DNS delegations live. It should not impose a new regional reverse-DNS policy. It should be able to publish a status page. It should not campaign for a governance faction.

AFRINIC's crisis is exactly the case in which this boundary would matter. If another RIR had been asked to provide emergency services, African members would reasonably ask whether that RIR was only holding the utility function or absorbing regional authority. Courts in Mauritius would ask whether the temporary operator was respecting local orders. Other RIRs would ask whether they were assuming liability for contested records. Resource holders would ask whether their confidential records had moved and under what legal basis.

The rule should state that emergency service is not successor governance. The successor governance question may arise later if derecognition occurs, but it should not be smuggled into a ninety-day service bridge. That bridge should keep the lights on, preserve evidence, prevent irreversible damage and buy time for lawful restoration or a separately justified transition.

Operator consent cannot be assumed

The phrase "another RIR could step in" hides a hard consent problem. A regional registry is not a spare cloud instance. It is a legal entity with its own board, members, laws, risk appetite, staff capacity, budget, insurance, data-protection duties and regional accountability. Asking it to operate services for another region during a crisis raises operational and political risk.

The operator must consent knowingly. It must understand the service scope, records to be received, legal constraints, funding, indemnity, confidentiality duties, technical tasks, language needs, time limits, reporting obligations and exit conditions. It must know whether it is expected to provide only technical continuity or to handle member-facing decisions. It must know whether its own members will bear costs. It must know whether the affected region can challenge its actions.

Consent by the other RIRs also matters collectively. The NRO draft requires unanimous agreement of all the other RIRs and ICANN for emergency continuity. That is a strong safeguard. It reduces the risk that one external actor can install a favored operator. It also forces the system to confront capacity and legitimacy before action.

But unanimity has a cost. In a fast-moving outage, obtaining unanimous agreement may be slow. In a politically charged case, one RIR may hesitate because of liability or reputation. The rule should therefore distinguish readiness from activation. Readiness can be prepared in advance: service inventories, escrow expectations, standard confidentiality terms, temporary operator qualifications, funding formulas, communications templates, legal checklists and testing. Activation can then be narrower and faster because the actors are not inventing terms under pressure.

The affected registry's consent is more complicated. If the registry can adequately cooperate, emergency support should be discussed with it and its community. If the registry is unable to cooperate because of governance paralysis, court restriction or bad faith, the rule may need a path without full incumbent consent. But that path should be exceptional and explained. It should identify why cooperation was not reasonably possible, what legal basis permits limited handover, and how the affected registry can resume services once capability is restored.

Member consent is also not monolithic. The affected region's members are not a single voice. Some may fear the incumbent, some may fear external control, some may want rapid service restoration, some may be litigants, and many may simply need routine stability. A rule that requires total regional consensus would make emergency action impossible. A rule that ignores member views would lack legitimacy. The better answer is structured input: notice, short feedback windows where practical, protected channels for evidence, published summary of concerns, and post-event review.

In AFRINIC, operator consent and member legitimacy would be especially sensitive because the crisis already involved claims about voting authority, powers of attorney and member lists. Any emergency operator would need to avoid relying on the same disputed authority files without verification. It would also need a communications plan that reaches members directly through preserved contact records while protecting confidentiality.

Consent is therefore not a ceremonial signature. It is the difference between service continuity and contested occupation. The replacement rule should treat it as infrastructure.

Record portability is the core asset

The most important thing that moves in a registry emergency is not the brand, the office or the board minutes. It is the current state of the records. If the records are incomplete, stale, disputed, non-portable or legally inaccessible, no emergency operator can provide credible service. It will inherit a fog.

Record portability has several layers. The public layer includes registration entries visible through directory services, resource assignments and allocations, contact roles, routing-related references and reverse-DNS delegations. The protected layer includes account credentials, authority evidence, member files, billing records, legal documents, identity checks, non-public contacts, pending tickets, transfer evidence, dispute files and court constraints. The technical trust layer includes resource certification material, repository state, signing arrangements, reverse-zone details and operational credentials.

The governance layer includes member status, voting authority, board and committee records, policy documents and decision history.

Each layer has a different portability problem. Public data can be copied, but may not show who may instruct changes. Protected data may be necessary, but must be handled under confidentiality and data-protection rules. Technical trust material may require careful key and repository management; careless movement can break validation or create duplicate authority. Governance records may be contested; moving them without notation can turn a disputed authority into an accepted fact.

The 2001 ICP-2 text already recognized record keeping as essential. It required proper records of registry activities and archive information collected from LIRs in making address-space assignments, describing this data as needed for future evaluation and auditability of responsible neutral operations. That requirement was not written as a full portability rule, but it points to the core truth: registry continuity depends on records that can be audited.

The 2025 ICANN letter to AFRINIC asked the receiver to confirm the status of record keeping and backups of registration data and resource-member records. That question belongs at the center of any replacement rule. If records are backed up only inside the troubled institution, emergency continuity may be impossible. If backups exist but cannot be legally used, continuity is theoretical. If backups are current but lack authority evidence, routine lookups may continue while member actions become unsafe.

Portability should be tested before crisis. A registry should be able to produce a service inventory and a current encrypted escrow set under clear controls. The escrow set should not be a public data dump. It should be structured enough for an emergency operator to identify current public records, pending changes, authority files, confidentiality categories, technical trust material, reverse-DNS state, service tickets and disputes. It should be tested for restore into a controlled environment.

Testing is not the same as using. An emergency operator need not access confidential records during normal times. But an independent auditor can verify that the escrow exists, that it is current, that access controls are workable, and that a restore would be possible if the trigger occurs. The report can publish pass, fail and exception categories without exposing member secrets.

AFRINIC showed why this is not abstract. A crisis about voting authority, possible list access and record backups immediately raises the question whether the record state is trustworthy enough to move. A replacement rule must say how disputed records are carried: with notation, freeze, independent validation or exclusion from routine action until resolved. It must prevent a handover from laundering uncertain authority into clean operational state.

Record portability is therefore the core asset of replacement. Without it, the emergency operator is only a name. With it, replacement becomes a disciplined preservation act rather than a political act.

The data state must travel before authority travels

Authority should follow data state, not precede it. In a registry emergency, the system should first define the service state to be preserved, then decide which operator can lawfully and technically preserve it. If authority is moved first, the new operator may be forced to make decisions without knowing what it controls.

A migration file should contain a current service map. It should list public registry services, non-public member and resource-holder files, technical trust services, reverse-DNS responsibilities, pending requests, outstanding disputes, court orders, staff and vendor dependencies, credentials, monitoring, backup status, and communications channels. For each category, it should say whether the service is unaffected, at risk, frozen, restricted, disputed or unavailable.

The file should also identify transaction states. Pending transfers are especially sensitive. A transfer can be requested, under review, awaiting evidence, approved but not completed, disputed, held by court order, or delayed for fees. If those states are lost, buyers and sellers may face double filing, contradictory promises or lost priority. A temporary operator should not have to infer status from email fragments.

RPKI and reverse DNS require their own transition files. For resource certification, the operator must know certificate authority relationships, publication points, repository state, ROAs, validation expectations and emergency revocation limits. For reverse DNS, the operator must know parent-zone delegations, DS records where relevant, nameserver state and pending changes. These services can affect routing security, mail reputation, network diagnostics and cloud onboarding. They cannot be moved by general corporate language alone.

Billing and member standing also matter. If members must keep paying to preserve service, they need to know whom to pay and how payments are credited. If a member's good standing is disputed because bank accounts were frozen or invoices were delayed, a temporary operator should not turn that uncertainty into loss of voting or service rights without review.

The migration file should preserve legal context. Domestic court orders may restrict assets, governance decisions, communications or resource actions. The emergency operator must know which orders exist and how they affect service. It should not assume that an ICANN or NRO decision wipes away local law. Nor should a local order be read to destroy global service continuity when narrower compliance is available.

The rule should define a freeze point. At the moment emergency continuity begins, ordinary changes may need a brief controlled pause while state is reconciled. The pause should be short and published. Emergency changes that prevent service loss should remain possible. Once state is confirmed, routine low-risk services should resume under the temporary operator's limited mandate.

This is why the replacement rule cannot be only legal. It is operational. It is a procedure for moving a living record system without losing the present tense. The rule should be tested like an emergency drill. If the actors cannot reconstruct the current state in a test, they cannot promise continuity in a crisis.

Members need a migration procedure, not a slogan

For members and resource holders, replacement is experienced as a sequence of practical questions. Where do I log in? Who can sign? Does my invoice count? Can I update an abuse contact? Can I change a reverse-DNS delegation? Is my RPKI state valid? Can a pending transfer close? Will my confidential documents move? Which law protects my data? What if the old registry and temporary operator give different answers?

A replacement rule should answer those questions in advance. The public notice should state the emergency operator, start time, service scope, unaffected services, paused services, emergency contacts, member-authentication method, data-protection summary, dispute notation, billing treatment, expected duration and review route. It should avoid broad claims of institutional rescue and focus on service continuity.

Authentication deserves special care. If the crisis involves disputed member authority, the temporary operator cannot rely blindly on existing portal users or powers of attorney. It should use a layered verification method: current registry records, previously verified contacts, corporate authority evidence where needed, multi-contact confirmation for high-risk changes, and dispute flags where authority is contested. Low-risk public corrections may use lighter evidence. High-risk transfers or technical trust changes require stronger proof.

The procedure should preserve existing rights without expanding them. A resource holder should not gain a transfer right merely because emergency continuity begins. Nor should it lose a recognized service merely because governance is under review. The temporary operator should maintain the status quo of records unless a defined, verified change is allowed. That status quo should include dispute notation where the record is contested.

Communications should be direct and multilingual where the region requires it. A crisis in the AFRINIC region covers many countries, legal systems and operator communities. English may remain the official registry-system language for core review, but member-facing continuity needs clear accessible notices. The rule should define minimum communication channels: website notice, direct email to verified contacts, public status page, help-desk instructions, and periodic reports.

Members also need a way to submit evidence. If a member's contact file is wrong, if a pending request is missing, if a power of attorney is forged, if a transfer state is misrecorded, or if a court order affects its resources, the temporary operator needs a triage route. The route should be fast, documented and limited to continuity facts. It should not become a general forum for political argument.

The procedure should also protect staff. In many registry crises, staff keep services running while boards, courts and public factions fight. A temporary operator may need cooperation from incumbent staff, but staff may face conflicting instructions. The rule should state how staff can provide continuity information, preserve records and avoid personal exposure. It should not force individual employees to decide between domestic orders and global continuity expectations without legal clarity.

A slogan says "another RIR can step in." A migration procedure says how each member experiences Monday morning. The latter is what continuity requires.

What ICANN can legitimately demand

ICANN's legitimate demand in an AFRINIC-type crisis is evidence of service capability, neutrality and continuity. It can ask whether records are preserved, whether members are treated equally, whether governance can be restored, whether improper influence is contained, whether core services operate, whether backups are current, whether staff have authority to act, and whether the region's community is receiving truthful information. Those demands are consistent with the function ICANN performs in coordinating the recognized RIR system.

ICANN should not demand political loyalty, a preferred election outcome, a particular litigant's defeat, or a policy position chosen in Los Angeles. It should not use recognition to punish a region for disagreeing with a global actor. It should not convert concern about one member's influence into authority to approve every bylaw change. The line is service risk and recognized duty.

The June 2025 letter was strongest where it named concrete duties: community support, equal treatment, impartiality, independence, open membership, record keeping and backups. It was more vulnerable where it framed concerns about influences that might move AFRINIC policy to positions counter to global coordination. That may be a legitimate concern if influence compromises impartial service or the numbering system. It needs a precise evidence statement to avoid sounding like policy policing.

A replacement rule helps ICANN make better demands. Instead of asking broad questions under pressure, ICANN can map each request to a known trigger and service consequence. "Provide record-backup status because emergency continuity requires verified record portability." "Provide member-authority investigation results because routine governance and high-risk member actions depend on verified authority." "Provide service metrics because formal review requires evidence of operational capability." This makes the demand less political and more accountable.

ICANN can also demand preservation. Destruction or alteration of election files, resource records, authority evidence, backups, ticket logs or technical trust material would threaten review and continuity. A preservation notice is justified when credible crisis evidence appears. The notice should state categories, custodians, retention method and confidentiality.

ICANN can demand transparency from the receiver or governing body because public confidence is part of RIR service legitimacy. But transparency must be calibrated. Some investigation details, personal data, credentials and confidential member files cannot be published. The demand should be for a public status account, not reckless exposure.

Finally, ICANN can demand a cure plan. If the affected registry can restore governance, verify member authority, preserve records, repair services and submit to audit, replacement should remain unnecessary. The rule should make cure the preferred outcome. Replacement is not a victory. It is a controlled failure response.

What a replacement rule should say

The replacement rule should begin with triggers. Emergency continuity should be available only when an RIR cannot adequately provide all or a defined part of its services, or when continued provision creates a material risk to records, neutrality or service integrity that cannot be addressed by narrower measures. Formal derecognition should require a separate, higher threshold.

It should define eligible operators. An operator should be a qualified RIR or other approved entity with technical capacity, legal capacity, data-protection controls, financial ability, independence from the dispute, conflict disclosures, service experience and agreement to the temporary mandate. The operator's own governing body should approve the role under its own rules.

It should define consent and approval. Emergency operation should require agreement of ICANN and the other RIRs, discussion with the affected RIR and community where reasonably possible, and published reasons if full discussion is not possible. Permanent succession or derecognition should require the separate proposal route and published recommendations.

It should define service scope. The notice should list which services the operator will provide: public lookup, help desk, contact updates, transfer processing, reverse DNS, resource certification, billing, communications, records preservation, policy support or only a subset. Anything not listed remains outside the temporary mandate.

It should define data movement. The affected registry should regularly escrow a current, restorable set of necessary records under independent controls. Access should be event-triggered, logged, limited by confidentiality, and reviewed after use. Disputed records should move with notation rather than be silently normalized.

It should define member authentication. Routine low-risk requests, high-risk resource changes, transfer instructions, billing disputes and voting authority each require different proof. A crisis involving powers of attorney should not use powers of attorney as the only authority path without verification.

It should define technical trust continuity. RPKI, reverse DNS and directory services need specific handover steps, including freeze points, validation checks, repository state, delegation state, emergency contacts, old-service retention and return criteria.

It should define time limits and renewal. The NRO draft's ninety-day starting period is a useful baseline, but renewal should require updated reasons, performance evidence, community feedback and a handback or escalation plan.

It should define review. The affected registry, affected resource holders and the temporary operator should have routes to challenge scope, errors, overreach or unsafe instructions. Review must be fast enough to matter during the emergency.

It should define handback. The affected RIR should resume services once operational capability is restored and verified. Handback should include state reconciliation, audit, member notice, technical checks, incident report and lessons for the next emergency.

The rule should be detailed enough to run but restrained enough not to centralize ordinary registry autonomy. That is the balance AFRINIC exposed.

Ordinary reliance needs its own protection

The least visible constituency in a recognition crisis is often the most important one: the ordinary resource holder that did not cause the dispute. A small access provider, university network, regional exchange entity, content host, bank, hospital, research network or public agency may have no role in a board fight and no appetite for global institutional argument. It still depends on the registry to maintain accurate records, reachable contacts, reverse-DNS changes, resource certification state, abuse-contact data, account standing and evidence that its number resources remain legitimately held.

That ordinary reliance is why replacement cannot be designed only for boards, receivers, courts and global coordination bodies. The rule has to protect the people who experience registry failure as interruption, uncertainty and transaction risk. If the only public message is that ICANN may review recognition and another operator may step in, members are left to guess whether their daily services will be interrupted, whether existing credentials remain valid, whether a transfer already under review will be honored, whether confidential documents will be copied, and whether routine changes become evidence in a political conflict.

The reliance problem is practical. Network operators use registry records when filtering routes, assessing customers, investigating abuse, demonstrating resource rights to vendors, responding to procurement questions, proving continuity to banks and insurers, and passing due diligence in transactions. Even when packets keep flowing, a registry legitimacy crisis can make third parties hesitate. A cloud provider may ask for clearer resource evidence. A buyer may delay a transfer. A lender may discount address assets. A government buyer may question whether a supplier controls its resources.

A security team may treat stale registry records as a risk signal. These effects are not dramatic outages, but they are real costs.

A replacement rule should therefore define a reliance shield. During emergency operation, no resource holder should lose recognized service, account standing or routine rights solely because recognition is under review. The temporary operator should preserve the last verified resource state, mark contested records where necessary, and maintain routine low-risk services as soon as a short reconciliation pause is complete. High-risk changes can require stronger evidence, but ordinary reliance should not be frozen indefinitely because an election file is disputed.

The shield should also say what remains valid. Existing public registration records should remain publicly reachable unless a specific record is known to be unsafe. Existing resource certification state should be preserved while transition checks are performed. Existing reverse-DNS delegations should remain live unless there is a security or legal reason to change them. Existing tickets should retain their place in the queue with visible status. Existing invoices and payments should be reconciled rather than discarded. Existing confidential submissions should remain confidential under the temporary operator's duties.

This approach protects both sides of the legitimacy argument. It prevents a failing incumbent from holding members hostage by saying any external support would destroy service. It also prevents an external actor from using service continuity as an excuse to reorder member rights. The baseline is preservation. Change requires a defined reason, a defined authority path and a record that can be reviewed.

The reliance shield should include a standstill for punitive actions. During the initial emergency period, the temporary operator should not suspend resources, cancel membership, reject renewal, close a transfer, or change member standing because of records affected by the crisis unless immediate security, court compliance or clear fraud requires action. Fees can still be collected and routine obligations can still be maintained, but the operator should not convert administrative confusion into loss of rights.

Dispute notation is better than silent normalization. If two parties claim authority over the same member account, the temporary operator should mark the account as disputed, allow low-risk continuity services where safe, and require stronger proof for high-risk changes. If a transfer file is incomplete because a court order or staff access problem interrupted review, the file should be preserved with its state described. If a power of attorney is questioned, it should not be accepted or rejected by default merely because it was in the record set. It should be reviewed under the emergency authentication rule.

The same protection should apply to data. Members should know what categories of their information may be accessed by the emergency operator, why access is necessary, which confidentiality duties apply, where the data will be stored, how access is logged, when data will be returned or deleted, and how a member can report an error. This is not optional legal hygiene. In a multi-country service region, confidence in data handling is part of confidence in the replacement itself.

Ordinary reliance also needs public metrics. A temporary operator should report ticket volumes, service availability, routine request turnaround, paused service categories, dispute counts, technical trust status and expected handback milestones. The report need not expose sensitive member files. It should give members enough information to decide whether the bridge is working. Silence breeds rumor, and rumor raises transaction costs.

AFRINIC's crisis shows why this protection is central. The region's resource holders did not need a theoretical debate about recognition authority. They needed the registry to function, records to remain credible, and any external continuity plan to respect regional rights. A replacement rule that fails ordinary reliance will be judged not by its institutional theory but by whether members can still operate their networks on Monday morning.

The risk in doing nothing

The risk is not only that a failing registry might harm the region. The risk is that an undefined rescue power harms the region while trying to help. A vague threat can raise transaction costs, deepen factions, alarm courts, freeze investment, encourage opportunistic litigation and make every ordinary member wonder whether its service is about to move. A vague emergency operator can create data, liability and legitimacy problems that outlast the crisis.

Doing nothing also protects incumbents too much. If no replacement rule exists, a registry in crisis can argue that any move would be too dangerous. It can use the absence of a plan as a shield against review. That creates moral hazard. The worse the continuity plan, the more indispensable the incumbent appears. A critical institution should not become immune because replacement would be hard.

The right answer is not aggressive intervention. It is preparedness. The system should make replacement less attractive but more possible. Less attractive, because cure, audit and narrow safeguards should solve most problems before transition. More possible, because records, service maps and operator rules should exist if the public function truly cannot continue.

AFRINIC's crisis has already shown the cost of late design. Letters, court filings, media reports, member allegations and emergency concepts arrived while the services still had to run. That is the worst moment to decide who may hold records, who may authenticate members, who pays for the operator, who answers a transfer ticket, or how to restore services to the incumbent.

ICANN and the RIRs should treat the AFRINIC warning as a design deadline. Recognition review now has a visible precedent. The next step should be a replacement rule that members can read before they need it. The rule should be operational enough for engineers, legal enough for courts, bounded enough for regional autonomy and public enough for markets.

The goal is not to make derecognition easy. It is to make continuity credible. If a registry can be restored, restore it with evidence. If a temporary operator is needed, limit it. If records must move, move them with notation and confidentiality. If authority must change, publish reasons and review rights. If the incumbent returns, hand back cleanly. If it cannot, use a separate, reasoned succession route.

ICANN's AFRINIC threat was therefore a warning to the whole system, not only to one receiver. The recognition layer now needs the missing rule beneath it. Until that rule exists, every review threat will carry an unnecessary second threat: not only that the incumbent might fail, but that no one has yet written the safe way to replace the service without replacing the region's rights.

Sources