Summary
- ICP-2 was accepted in 2001 as essential requirements and a framework for recognizing new Regional Internet Registries. Its text addresses entry: regional scale, broad LIR and ISP support, bottom-up policy, neutrality, technical capacity, funding, records, and confidentiality.
- The document was drafted for a world moving from three incumbent RIRs toward possible African and Latin American regionalization. It did not define suspension, conditional recognition, emergency service limitation, derecognition, successor selection, cure rights, independent review, or resource-holder protection for a recognized registry that later fails.
- Modern derecognition authority therefore needs its own rule. It should begin from the claimed power, define a measurable legal and operational test, and only then ask whether the old entry criteria are evidence of continuing obligations.
The entry checklist has been asked to do exit work
The central error in current RIR governance debate is not that ICP-2 is obsolete. The error is treating it as if the document already answered a question it was not built to answer. ICP-2 gave ICANN a set of criteria for deciding whether a proposed regional registry should be recognized. It did not create a complete later-life code for what happens if a recognized registry loses effective governance, mismanages elections, becomes captured by one interest, fails service obligations, or needs temporary continuity support while domestic courts and members argue over control.
That distinction matters because recognition has different consequences at entry and at exit. At entry, the candidate seeks a public delegation of responsibility. The existing system asks whether the candidate has regional scale, support from networks, transparent policy processes, technical competence, funding, record keeping, confidentiality practices, and a viable activity plan. If the answer is no, the old service arrangements continue. Operators may be disappointed, but the registry system is not removing an institution on which years of resource records and service expectations already depend.
At exit, the institution is not a proposal. It is the registry of record for resource holders, reverse DNS delegations, route-security material, registration data, transfer reliance, billing records, membership rights, local employment, contracts, litigation positions, and community expectations. A failed exit rule can harm networks that did not cause the governance failure. A hasty recognition threat can also become bargaining leverage for one faction inside a domestic dispute. The question is therefore not merely whether an incumbent still resembles the candidate once described by ICP-2.
The question is what remedy follows, who decides, what evidence is tested, how ordinary services continue, and how the affected community can challenge or cure the finding.
The ICANN-hosted ICP-2 text is explicit about its entry purpose. It says the document was developed through the Address Supporting Organization with help from APNIC, ARIN, and RIPE NCC, accepted by the ICANN Board on 4 June 2001, and used as essential requirements and a framework for considering applications for recognition of new RIRs. The same page says the criteria were requested so ICANN could evaluate applications for recognition of new RIRs. Those are not incidental words. They define the problem the criteria were designed to solve.
If a modern actor wants to derive derecognition power from ICP-2, the burden is therefore high. It must explain which part of the entry criteria creates a later remedial authority, which body may trigger that authority, how the body distinguishes failure from dispute, what cure is available, what service can be moved, what records can be inspected, and what limit protects the registry system from political or commercial capture. Without those additional rules, ICP-2 can identify values and obligations, but it cannot safely carry the whole weight of a modern exit decision.
The 2001 document belongs to a regionalization moment
ICP-2 is best read against the state of the registry system it describes. The introduction records a world in which three RIRs distributed address space received from IANA and then allocated it to Local Internet Registries or Internet Service Providers. It lists existing coverage as Europe and the Middle East through RIPE NCC, Africa through ARIN and RIPE NCC, North America through ARIN, Latin America including the Caribbean through ARIN, and Asia-Pacific through APNIC. It then says Africa and Latin America had already announced intentions to create new RIRs.
That background is not decorative. It explains nearly every criterion that follows. The drafters were concerned about how to add regions without fragmenting address space, confusing operators, undermining global aggregation goals, or forcing networks into an institution they did not support. The key problem was not how to remove a failing incumbent. The key problem was how to decide when a served region should be transferred to a new regional institution.
This regionalization setting also explains why the text expected the number of RIRs to remain small. The aim was not institutional monopoly for its own sake. It was operational coherence: one registry per region, stable coordination among RIRs, address-space aggregation, and a clear service point for networks. A world of overlapping registries would have risked duplicate claims, inconsistent records, disputed reverse DNS, fractured policy, and costly confusion for operators who simply needed number resources to remain usable.
The expansion context is also visible in the support requirement. ICP-2 asked a new RIR to demonstrate broad support of LIRs and ISPs in the proposed region. The reason was migration. Existing networks were already receiving registration services from an incumbent RIR. A candidate could not prove legitimacy by presenting elite letters or a name for the region. It had to show that a very substantial majority of the affected networks were prepared to support the new institution, take services from it, participate in its bottom-up development, and support it financially.
That is an entry consent problem. The candidate must show that the community can move from an existing arrangement to a new regional body without being coerced, abandoned, or split. Derecognition is different. There, the resource holders are already inside the institution. Their problem may be loss of trust, disputed representation, captured governance, missing records, or service risk. Some may want replacement, some may want rehabilitation, some may want external audit, and many may want continuity above all.
The old support requirement helps define what legitimacy looked like at entry, but it does not by itself state how much support is needed to withdraw recognition from an incumbent or impose a successor.
The 2001 document also predates many later reliance questions. It does not speak in the language of emergency operators, escrow, delegated service handoff, independent compliance audit, post-emergency review, or cure before derecognition. Those concepts appear in later reform debates because the old expansion checklist cannot be stretched indefinitely. The more the registry system matures, the less plausible it becomes to treat entry standards as automatic exit machinery.
The criteria are obligations, but not remedies
ICP-2 contains real obligations. It is not a ceremonial statement. It expects a registry to have broad regional support, open policy development, neutrality, technical ability, policy consistency, a supported activity plan, funding, records, and confidentiality. Those obligations remain analytically useful when a registry appears to be failing. If a recognized registry cannot treat requestors equally, cannot keep records, cannot maintain independent operations, cannot run an open membership body, or cannot protect registration information, the ICP-2 values are clearly implicated.
The hard question is remedy. An obligation says what condition should exist. A remedy says what happens when it does not. The original document is strong on the first and thin on the second. It does not establish a ladder of consequences. It does not say whether a breach leads to informal consultation, formal audit, public notice, conditional recognition, supervised cure, temporary service support, emergency transfer, suspension, or derecognition. It does not allocate decision power between ICANN, the other RIRs, the affected registry, the affected members, domestic courts, and the global numbering community.
This gap can be hidden when everyone agrees. If a candidate lacks support, ICANN can reject recognition. If a new RIR has technical gaps, it can wait. If a funding plan is weak, it can be revised. The entry setting allows a simple yes, not yet, or no. The mature failure setting does not. A failing incumbent can still be the only body with the customer data, staff knowledge, legal authority, reverse-DNS arrangements, billing records, and community memory needed to keep services running. Removing recognition can make the failure worse unless the remedy is sequenced.
That is why a later-life standard must separate diagnosis from response. A diagnosis might say that a registry lacks impartial governance, lacks effective record custody, or lacks member support. The response might still be rehabilitation rather than removal. It might require an independent audit, a transparent election reset, preservation of records, service escrow, conflict controls, or a published cure plan. Only when those steps fail, and only if the harm of tolerating non-compliance outweighs the harm of intervention, should derecognition become a live option.
The NRO RIR Governance Document Version 2 is useful precisely because it treats that distinction as a design problem. The page carries a 28 August 2025 draft date and says the document covers recognition, operation, and potential derecognition. It defines recognition, derecognition, RIR services, emergency continuity, emergency operator, resource holders, and members. It also states operating obligations, audit concepts, emergency continuity, rehabilitation, and derecognition effects. That draft may not be the final settlement, but its structure is evidence that the original criteria need additional machinery before they can govern failure.
The lesson is not that ICP-2 should be discarded. The lesson is that it should be used in the right position. It can identify the values a registry must continue to satisfy. It can supply historical context for why regional support, neutrality, technical competence, records, and confidentiality matter. It cannot, standing alone, tell the world how to remove or replace a registry after decades of reliance.
Broad support was migration evidence, not a recall vote
The broad support criterion is one of ICP-2's most consequential provisions. It says the new RIR must demonstrate broad support from LIRs and the ISP community in the proposed region. It calls for clear consensus, a very substantial majority, willingness to receive services, active participation, and financial support. It also asks the candidate to show every effort to contact existing LIRs, including public mailing lists, web sites, and individual contact records.
This is a demanding standard, but its direction matters. The support being tested was support for creating a new RIR and moving service relationships into it. It was not a recall ballot against an incumbent. The affected networks were already served by ARIN, RIPE NCC, APNIC, or some combination. The candidate had to show that the served community wanted the new regional body enough to make migration plausible.
That entry framing matters when people later try to use broad support as a modern derecognition trigger. A support letter is not the same as an auditable authorization. A statement from a government ministry is not the same as support from resource holders. A petition from visible community leaders is not the same as a denominator-weighted result among networks that receive service. A conference applause line is not the same as evidence that existing service agreements can move without coercion. ICP-2 understood that problem at entry; it required evidence of contact, consensus, and future membership.
For derecognition, the support question must be even more precise. Is the relevant community all resource holders, voting members, LIRs, ISPs, governments, civil society actors, technical operators, or the broader numbering community? Are legacy holders counted? Are suspended or litigating members counted? Are affiliates aggregated? Are small networks counted equally with large address holders? Does financial contribution matter? Is silence opposition, neutrality, or non-response? What proof is required that a person signing a letter can bind the network named in the letter?
ICP-2 does not answer those questions. It supplies the idea that support must be broad and real. It does not supply the denominator. Treating the old phrase as a self-executing modern mandate would invite selective evidence. One side could collect letters from governments. Another could collect statements from large address holders. Another could point to mailing-list posts. Each might be genuine, but none would necessarily prove regional authorization.
The correct use of ICP-2 is therefore restrained. It tells a modern reviewer to demand proof, not mood. It tells the reviewer to distrust support claims that lack contact records and financial or operational commitment. It tells the reviewer that migration is difficult and cannot be imposed casually. It does not tell the reviewer that any visible coalition can authorize derecognition.
One region, one registry was a continuity rule
ICP-2's one-region principle is often misunderstood. The document says each region should be served by a single RIR under one management and in one location, because multiple RIRs in one region could fragment address space, create coordination difficulty, and confuse the community. The point was operational stability, not institutional invincibility.
The principle helped justify regional expansion. If Africa or Latin America moved toward its own registry, the system needed to avoid two competing regional registries claiming the same service population. Operators needed one authoritative registry of record. IANA needed a clear allocation counterpart. Other RIRs needed one peer for coordination. The global routing system needed coherent allocation history and policy.
That same continuity logic cuts against casual derecognition. If one region should have one registry because fragmentation is harmful, then removing an incumbent without a successor plan is dangerous. The remedy must not create the very confusion ICP-2 tried to avoid. It must keep records coherent, reverse-DNS processes intact, resource-holder service stable, and policy authority legible. A derecognition decision that creates rival claimants, inconsistent databases, or uncertain contractual authority would violate the spirit of the one-region rule even if it were framed as enforcement.
The one-region rule also limits the temptation to solve governance failure by multiplying institutions. A crisis may produce proposals for a new registry, a temporary service body, a subregional split, an external operator, or a parallel member association. Some of those arrangements may be necessary for continuity. But the more they resemble competing long-term registries, the more they collide with ICP-2's anti-fragmentation logic.
Therefore the one-region principle should be read as a constraint on both incumbents and interveners. An incumbent cannot invoke the principle as a shield against scrutiny while failing the duties that justify its role. ICANN and the other RIRs cannot invoke failure as a reason to create an open-ended rival structure without a measured service handoff and final accountability. The principle supports a narrow remedy: preserve one authoritative service point, repair the institution if possible, and make any temporary support visibly temporary.
This is why modern emergency continuity language is so valuable. It recognizes that service may need temporary support without immediately declaring a permanent successor. It can define scope, duration, publication, affected services, feedback, return conditions, and post-action review. ICP-2's one-region rule supplies the reason for that caution. It does not supply the caution's details.
Technical competence was a threshold, not a license to supervise
ICP-2 required technical competence because a new RIR cannot be legitimate if it cannot operate. The criteria listed production-grade global Internet connectivity, DNS servers for reverse DNS, suitable infrastructure, and enough technically capable staff to maintain service levels. Those requirements were grounded in practical risk. A regional registry is not only a meeting room or membership association; it is a service institution with data, protocol, and reliability duties.
But technical competence at entry should not be converted into a general supervisory license. ICANN's ability to ask whether a candidate can run registration services does not automatically become a standing authority to manage an incumbent's technical choices. Nor does a technical problem automatically justify derecognition. A registry can have a service outage, staff turnover, delayed systems project, or security weakness that demands repair without proving that the institution must lose recognition.
The better test is functional and proportional. Which RIR services are impaired? Which resource holders are affected? Is the risk temporary, chronic, or expanding? Is the registry willing and able to cure? Are records available for verification? Can other RIRs provide limited support without becoming political managers? Does the problem threaten the Internet Numbers Registry System or only a local administrative process? These questions require evidence, not a general appeal to the technical competence clause.
The AFRINIC case shows why the line matters. Much of the visible concern around AFRINIC has concerned governance, elections, record custody, impartiality, and member confidence, while staff have continued to preserve many day-to-day registry services. A remedy that treats institutional crisis as identical to total technical incapacity could overreach. A remedy that ignores governance because packets still route could underreact. The old technical criterion is a starting point, not a final answer.
This distinction also protects ICANN. Without proportional standards, any technical criticism of an RIR could become an argument for broad recognition intervention. That would place ICANN in a role the original document did not design: a continuous technical regulator of regional registries. The numbering system needs coordination, not central managerial control. Entry competence, continuing service obligations, independent audit, and emergency assistance should each have separate thresholds.
The later NRO draft points in that direction by defining RIR services and performance, continuity, operational requirements, audit, emergency continuity, and derecognition separately. That separation is not bureaucratic decoration. It is how the system prevents a solvable service problem from becoming a constitutional crisis, and how it prevents a constitutional crisis from being dismissed as merely internal because some services still function.
Record keeping creates auditability, not automatic transfer
ICP-2's record-keeping provision is among its most durable insights. It says RIRs must maintain proper records of registry activity, including information collected from LIRs during address assignments, because the data is needed for later requests and for the auditability necessary to demonstrate responsible and neutral operations. It also expects core documentation and operational-audit information to be available in English for review by other RIRs, IANA, or ICANN.
This is a powerful continuing obligation. A registry that cannot preserve member records, allocation history, policy records, election materials, correspondence relevant to authority, or operational data cannot prove neutrality. In a crisis, record keeping may become the difference between repair and speculation. If the evidence is missing, captured, inaccessible, or selectively disclosed, every actor argues from fragments.
But record keeping is not the same as an automatic transfer order. ICP-2 did not say that records may be seized, copied wholesale, made public, or moved to a successor whenever one actor alleges non-compliance. It also required confidentiality. Information collected in registration is to be kept in strict confidence and used for registration purposes, with transfer only to another RIR or IANA upon request, or elsewhere with written agreement from the served LIR or ISP. The document therefore holds two principles together: auditability and confidentiality.
Modern failure rules must preserve both. A compliance review may need records. An emergency operator may need enough data to perform defined services. Other RIRs may need verification to protect continuity. But the review must be scoped, logged, legally grounded, and subject to data protection limits. Otherwise, a governance intervention can become an uncontrolled disclosure of commercially sensitive and operationally sensitive registry information.
The later NRO draft recognizes this tension by linking continuity and emergency operation to escrow or data-protection controls. It also defines RIR services and resource holders, and it contemplates audits by external independent auditors. The point is not that the draft is perfect. The point is that modern failure requires a records architecture that ICP-2 only foreshadowed.
For derecognition, record keeping should be treated as proof infrastructure. It should answer: what happened, who authorized it, what resources are affected, what service commitments exist, and whether the registry can recover. It should not become a shortcut around due process. The fact that records are reviewable does not decide who controls the institution. It allows the decision maker to test facts before choosing a remedy.
AFRINIC's recognition shows entry at its clearest
The 2005 recognition of AFRINIC is the cleanest example of ICP-2 operating as intended. The ICANN Board resolution of 8 April 2005 recited provisional recognition in 2004, completion of the transition plan, an updated application, a favorable assessment from the NRO, and the ICANN President's determination that the application fully conformed with ICP-2. The Board then proclaimed AFRINIC a fully approved and recognized RIR for the Africa service region.
The IANA report on AFRINIC recognition reads like an entry evaluation because that is what it was. It reviewed each ICP-2 principle. It described the Africa region, the transition plan, outreach, the incumbent RIRs, the support of existing registries through the NRO, and IANA's conclusion that AFRINIC satisfied the criteria. On support, the report described regional outreach, public forums, member communications by incumbent RIRs, independent contact with ISPs, public mailing lists, a website, meetings, and direct contact with LIRs and ISPs. It concluded that a very substantial majority was prepared to support AFRINIC, participate in bottom-up processes, and make financial commitments.
That report demonstrates the virtues of ICP-2. It forced a candidate to show regional scale, community support, policy process, impartiality, technical ability, global-policy compatibility, activity planning, funding, records, and confidentiality. It also demonstrates the limits. The report did not have to decide whether a recognized registry could later be placed under emergency operation, whether recognition could be suspended, or how a successor would receive records if governance collapsed. Those questions were outside the application setting.
This matters because AFRINIC later became the stress case for the opposite problem. The same institution that entered through a classic ICP-2 review later faced prolonged governance crisis, litigation, receivership, election controversy, and external concern about continued compliance. That history should caution against reading the entry file as an exit constitution. The stronger the entry file is, the more obvious it becomes that the exit question is different.
An entry recognition file says: this organization is ready to become the regional registry. A failure response must ask: what is failing, what relies on the institution, what can be cured, what must be preserved, who can decide, and what remedy is least harmful while still protecting the numbering system. The first question can be answered by a checklist. The second requires a remedial design.
A modern crisis creates inherited reliance
By the time a registry fails, reliance is distributed. Resource holders rely on registration data, invoices, membership status, transfer approvals, reverse DNS, RPKI material, public directory records, and service desks. Other RIRs rely on coherent allocation history and inter-registry coordination. Governments rely on the local corporate presence and continuity of national networks. Courts may rely on the registry's assets and legal duties. Staff rely on employment and operational knowledge. Buyers, lessors, lenders, auditors, and insurers rely on registry records to assess address rights and network exposure.
ICP-2 did not need to map all of this reliance in 2001 because the candidate had not yet accumulated it. A new registry's application could be rejected without unwinding decades of records. That is why the absence of a failure rule was understandable then and hazardous now.
Inherited reliance changes the morality of intervention. A regulator-like actor might see a defective election and want a strong response. A resource holder might see the same response as a risk to its allocations. A domestic court might see external recognition pressure as interference. A small network might want service continuity more than governance theory. A large holder might have enough leverage to shape the remedy. A government might want regional autonomy. An operator outside the region might want global stability. A serious rule must make these interests visible rather than letting the loudest one define failure.
The remedy must also distinguish institutional control from service operation. A temporary operator may be able to handle defined services without deciding who owns the local company. An independent audit may verify records without choosing a board. A court may stabilize assets without understanding global numbering consequences. ICANN may evaluate recognition implications without becoming the domestic corporate authority. The old entry checklist does not draw these boundaries.
This is the reason derecognition should be treated as last resort. If a recognized registry can be rehabilitated, the safer path is to repair governance while preserving the service institution. If services are at immediate risk, temporary continuity can be scoped. If records are contested, preservation and independent review can begin. If a faction claims support, the support can be tested against an auditable denominator. Only after these steps fail should successor recognition become the main remedy.
The point is not institutional sympathy. It is protection of the networks. Derecognition can be legitimate, but only if it is less harmful than continued non-compliance. ICP-2 helps define non-compliance. It does not supply the harm test.
A compliance notice is not a complete constitution
The 2025 ICANN correspondence about AFRINIC made the gap visible. In the 25 June 2025 letter, ICANN reminded AFRINIC's appointed receiver that ICANN had recognized AFRINIC in 2005, that AFRINIC continued to have responsibilities under ICP-2, and that ICANN had not yet initiated a compliance review. The letter then said a review might be necessary because of allegations around the election process, powers of attorney, access to membership lists, use of an AFRINIC mark in campaign communications, record keeping, and member confidence.
That letter is analytically valuable because it shows recognition power before final action. It was not a completed derecognition decision. It was a notice, a preservation demand, and a warning that evidence could support a future review. It cited ICP-2 values around support, equal treatment, impartiality, independence, and records. It also opposed proceeding with the election as matters stood.
The 3 July 2025 letter sharpened the position. ICANN said the receiver's response did not provide sufficient documentation, said annulment of the election did not answer many questions, and reiterated that it reserved rights to initiate a compliance review for potential material non-compliance with ICP-2. The NRO, according to the letter, confirmed that ICANN was acting in alignment with ICP-2.
Those letters may have been justified as crisis communications. They also show why the underlying rule must be written. A notice can be necessary, but it should not become the constitution by which everyone infers future consequences. The letters left open who would evaluate disputed facts, what standard of proof would apply, what specific review steps would follow, what cure period would exist, what service limits could be imposed, how members could be heard, and how any conflict with domestic court authority would be managed.
This is not a criticism of drafting under pressure. It is a criticism of relying on pressure drafting as institutional design. In a crisis, correspondence must be fast. It will often be incomplete. It may be read strategically by factions, courts, members, journalists, and counterparties. That is exactly why the rule should exist before the next letter is needed.
The modern rule should therefore separate notice, evidence preservation, formal review, audit, interim safeguards, cure, emergency continuity, and derecognition. Each stage should have a trigger, scope, publication duty, confidentiality rule, decision maker, review path, and service-continuity plan. ICP-2 can remain the historical and normative reference. It should not be forced to become the missing procedure.
The 2025 draft proves the original gap
The NRO's 2025 draft governance document is sometimes treated as a policy proposal about future powers. It is also evidence about the past. If ICP-2 already contained a complete lifecycle rule, the draft would not need to define recognition, operation, emergency continuity, audits, rehabilitation, and derecognition in such detail. Its existence confirms that the 2001 criteria were not enough for the mature registry system.
The draft's preamble says it succeeds ICP-2 and covers the complete lifecycle of an RIR, from establishment to operation and potential derecognition. It says the document sets rules for recognizing new RIRs, operating obligations, and criteria and procedures for derecognition. That framing directly contrasts with ICP-2's narrower title and application setting.
The draft also changes the vocabulary. It defines resource holders, members, numbering community, RIR services, service region, recognition, derecognition, emergency continuity, emergency operator, and proposal. The old document had no comparable lexicon because its problem was simpler. It could discuss LIRs, ISPs, support, and new registry competence without building a full remedial architecture.
Most importantly, the draft separates recognition from derecognition. It says ICANN shall have no power to recognize or derecognize an RIR unless it has received a proposal approved by the RIRs under the relevant section. It sets out audits, ongoing operational requirements, emergency continuity, rehabilitation, derecognition as last resort, handoff effects, and readiness for transfer. Whether every detail is ultimately accepted is less important than the structure: derecognition is not presumed to be the reverse of recognition.
That is the correct conceptual move. Entry and exit are linked, but not symmetrical. Entry asks whether the candidate can be trusted with the function. Exit asks whether the incumbent has failed so seriously, and repair has become so inadequate, that the community is better served by replacement. The evidentiary burden, reliance analysis, and remedy plan are different.
The draft also makes clear that modern recognition power must constrain ICANN, not only RIRs. A written derecognition rule prevents ICANN from acting on vague authority, while also preventing an RIR from claiming that recognition can never be reviewed. It gives affected communities a way to test both overreach and inaction. That is exactly what the 2001 document could not do, because it was not written for that institutional age.
The draft should therefore be read as a warning against historical overclaim. ICP-2 supplies values and entry criteria. A successor rule must supply lawful remedy.
The missing test is failure plus remedy
A modern derecognition standard should not begin with the word "derecognition." It should begin with the claimed failure and the proposed remedy. The reviewer should ask four questions in order.
First, what duty is failing? The answer must be tied to a recognized obligation: regional support, open membership, impartial treatment, independent operation, technical service, policy compliance, financial independence, record keeping, confidentiality, continuity, dispute resolution, or ecosystem stability. Vague distrust is not enough. Institutional embarrassment is not enough. Disagreement with policy outcomes is not enough.
Second, what evidence proves the failure? The answer should identify records, audit findings, court orders, membership data, service metrics, election materials, public policy records, financial statements, and verified complaints. A pile of letters is not enough unless each letter is tied to authorization, denominator, time, scope, and conflict checks. A public allegation is not enough unless the underlying records can be tested.
Third, what cure has been offered or refused? A registry may be non-compliant and still repairable. The rule should identify cure steps, deadline, independent verification, member notice, interim service limits, and consequences for non-cooperation. The cure path protects both sides. It gives the registry a fair chance and gives the wider community evidence if the registry will not fix the problem.
Fourth, what remedy is proportionate? The remedy may be public notice, external audit, records preservation, election reset, conflict guard, temporary service support, limited emergency operation, conditional recognition, or derecognition. Each remedy should match the failure. A missing audit record should not automatically produce replacement. A captured board election should not be treated as harmless if it controls the registry's future. Proportionality is the bridge between ICP-2 values and modern enforcement.
This sequence would also reduce strategic use of recognition language. A faction could no longer simply say the registry lacks support. It would have to define the denominator and show authorization. ICANN could no longer rely on broad concern. It would have to specify the trigger and remedy. An RIR could no longer dismiss every concern as internal politics. It would have to answer the duty and evidence.
ICP-2 does not contain this sequence. It points toward some of the duties, but it does not organize the remedial test. The modern rule must do that work openly.
Expansion history should discipline current power
The temptation in governance crisis is to read history as a grant of whatever authority the moment requires. Because ICANN approved new RIRs in 2001 and 2005, one might infer that ICANN can withdraw approval whenever the criteria appear unmet. Because existing RIRs helped evaluate AFRINIC, one might infer that the incumbent RIRs can collectively decide the fate of a troubled peer. Because support was required at entry, one might infer that support letters can authorize replacement. Each inference contains a fragment of truth and a dangerous leap.
The safer reading is narrower. ICANN had a role in recognizing new RIRs. Existing RIRs had expertise and a legitimate coordination interest. Regional support was central to legitimacy. None of those points automatically decides mature failure. They identify the actors and values that must be present in a modern rule. They do not replace the rule.
This narrower reading is more faithful to the document. ICP-2 repeatedly speaks of new RIRs, applications, establishment, and migration from existing service arrangements. It treats the existing registry system as deeply embedded and emphasizes the risks of fragmentation and confusion. It asks for open processes and auditable records, but it does not specify how a recognized registry is removed from the system.
Expansion history should therefore discipline current power in two ways. It should prevent incumbents from claiming permanent immunity, because recognition was always conditional on principles that serve the community. It should also prevent interveners from claiming open-ended power, because the original recognition criteria were not an enforcement charter.
For operators, this distinction is practical. Networks need to know whether a registry can be trusted, whether records will remain valid, whether resource rights will be respected, and whether political disputes will interrupt services. They do not benefit from a contest over slogans. They benefit from a written rule that states what failure means, who can prove it, what cure is available, and how continuity is maintained.
The 2001 criteria were a responsible answer to the problem of regional expansion. Treating them as a complete answer to modern failure would make them do work they were never designed to do. A stronger system would honor ICP-2 by preserving its values while writing the missing remedy in plain public terms.
Sources and analytical limits
The ICANN ICP-2 text supports the central historical claim: the criteria were accepted in 2001 as essential requirements and a framework for recognizing new RIRs, in a period when Africa and Latin America were expected to regionalize. The same text supports the discussion of regional scale, broad LIR and ISP support, bottom-up policy, neutrality, technical competence, activity plans, funding, records, and confidentiality.
The ICANN Board resolution recognizing AFRINIC and the IANA report on AFRINIC's application support the entry-review analysis. They show application, transition plan, NRO assessment, IANA review, and final recognition. They do not define a later derecognition procedure.
The NRO RIR Governance Document Version 2 is used as evidence of reform direction and the design gap left by ICP-2. It is described according to the draft date shown on the NRO page and is not treated as already resolving every legal or operational question.
The ICANN letters of 25 June 2025 and 3 July 2025 are used as examples of recognition and compliance language becoming consequential in a mature crisis. No finding is made on the truth of every allegation described in those letters, no claim is made that ICANN completed a formal compliance review, and no domestic court question involving AFRINIC is decided here.