Summary

  • AFRINIC’s official archive and canonical policy page mark AFPUB-2009-ASN-001 “Implemented” on 26 May 2010. That proves a public status decision and the completion of a bounded regional policy-lifecycle step. It does not prove that IANA’s global allocation process, an AFRINIC production system, a member request or an operator’s network changed on that date.
  • The chronology prevents the regional label from being enlarged into a global effective date. An official presentation at AFRINIC-12 said the proposal had passed all regions and had received AFRINIC Board ratification, yet had not formally passed from the NRO Executive Council to the ASO Address Council. The NRO-EC transfer occurred on 13 July, the ASO-AC forwarded the proposal on 22 July, and ICANN ratified it on 21 September.
  • The amendment itself was narrow: keep distinguishing 16-bit and 32-bit-only ASN inventory through 31 December 2010, then operate an undifferentiated pool from 1 January 2011. Its practical concern was compatibility. Nominal inventory was not the same as inventory that every requesting network could safely use while deployed systems were still catching up.
  • The proper resolution is neither to erase 26 May nor to accept the word “Implemented” as a complete operational receipt. A credible account would identify the decision instrument, the institutional layer, the responsible actor, the effective scope, the affected procedure or system, test results, transaction examples, exceptions, fallback arrangements and reconciliation with the upstream global state.

The date that outran the global chain

On 26 May 2010, AFRINIC’s monthly archive recorded AFPUB-2009-ASN-001 and displayed its status as “Implemented.” The canonical policy page repeats both the status and the date. It also records Board approval on 25 May. Read by itself, that sequence looks linear: approval on one day, implementation on the next.

The wider institutional record breaks that apparent simplicity. At AFRINIC-12, an official NRO-NC and ASO-AC presentation reported that the ASN proposal had passed in all five regional processes during 2009 and 2010 and that the AFRINIC Board had ratified it in May. But the same presentation said the proposal had not yet formally passed from the NRO Executive Council to the ASO Address Council. That presentation was delivered during the meeting held from 23 May to 4 June, so it is contemporaneous boundary evidence, not a reconstruction made years later.

The outstanding steps were material. The NRO Executive Council sent the final proposal to the ASO Address Council on 13 July. The ASO-AC forwarded it to the ICANN Board on 22 July. A final public-comment period followed from 23 July to 13 August. ICANN announced ratification by its Board Executive Committee on 21 September and said staff would take the necessary implementation steps. The retrieved public record does not establish the exact date on which IANA’s production allocation process reflected that final policy.

These records can coexist without making AFRINIC’s entry meaningless. The most supportable reading is also the narrowest: AFRINIC had completed its own regional policy lifecycle, published the operative amendment and assigned it a regional implementation status. A regional registry can finish its part of a coordinated process before every upstream or global step is complete. What cannot be inferred is that AFRINIC’s label completed those other steps, changed IANA’s rules by itself or reached backward in time once ICANN ratified the policy in September.

The point is not semantic perfection. It is attribution. Internet number coordination distributes work across institutions. A regional community may form a technical judgment. A regional corporate body may approve it. Registry staff may prepare a procedure. The NRO-EC may transmit a common proposal. The ASO-AC may verify and forward it. ICANN may ratify it. IANA staff may alter an upstream service. A request may then pass through the changed process, and an operator may finally observe a usable result. Calling any one of those acts “implementation” does not establish the others.

What the amendment actually changed

AFPUB-2009-ASN-001 addressed a particular deadline in the treatment of Autonomous System Number inventory. An ASN uniquely identifies a network connected to more than one other network that controls its own routing policy. At the time, the coordinated system distinguished inventory in the older 16-bit range from 32-bit-only inventory. The amendment extended that distinction for one year, through 31 December 2010. From 1 January 2011, allocations were to operate from an undifferentiated 32-bit pool.

That is the relevant delta. It is unnecessary—and would obscure this case—to restate the pre-existing allocation algorithm, block sizes, replenishment calculations or protocol-transition mechanics. The issue on 26 May was not the invention of the ASN system. It was whether AFRINIC’s public implementation status for the one-year extension corresponded to a regional readiness step, a changed regional operating procedure, a globally effective rule or an observed production result.

The amendment’s rationale gives that question practical weight. Issuance of 32-bit-only ASNs had been slower than anticipated, reflecting continuing compatibility concerns. A registry could possess adequate ASN stock in aggregate while having less stock that a requesting network could safely use with its actual equipment, software, peers and operating practices. The distinction between inventory classes therefore served as a temporary compatibility accommodation. It helped avoid treating nominal supply as fully substitutable supply.

This was a scarcity problem in an operational sense rather than a claim that ASNs and IPv4 addresses are the same resource. When a class of inventory cannot be used without costly changes or coordination failures, headline quantity can conceal effective shortage. Extending the separate treatment of legacy-compatible inventory could buy time for deployed systems to catch up. It could also postpone the discipline of transition. Both effects make evidence of actual requests, failures and remediation costs more useful than institutional confidence alone.

Nothing about the rationale proves what happened inside AFRINIC on 26 May. It does not identify a changed database table, request form, allocation script, staff instruction, training document or exception procedure. It does not show a member request handled differently on 27 May than on 25 May. It does not show an IANA allocation made under a changed upstream rule. The rationale explains why the amendment mattered; it is not a transaction trace.

Four dated acts, not one continuous mandate

The first essential distinction is between the regional technical judgment reached in November 2009 and the later implementation status. AFRINIC-11 recorded consensus on 27 November. That record is an earlier lifecycle step and technical input into the coordinated process. It is not evidence of unanimous, representative, member-wide or operator-wide assent, and it is not a sovereign mandate. The subject here is what AFRINIC recorded six months later, not a re-litigation of who spoke at the meeting or how the compatibility case was developed.

The second act is regional corporate approval. Here the official chronology contains a discrepancy that should remain visible. AFRINIC’s own history says the Board approved the proposal on 25 May 2010. An ICANN background report records AFRINIC Board adoption on 24 May. The sources do not explain the one-day difference. It may concern time zones, meeting and recording conventions, or something else, but choosing among those possibilities would be invention. The correct treatment is attribution: ICANN records 24 May; AFRINIC records 25 May.

The third act is AFRINIC’s public implementation classification on 26 May. This is a proved act. It fixed a date in the regional archive, presented the proposal as implemented and gave staff, members and peer institutions a definite statement of regional position. It may have reflected completed internal preparation. The record, however, does not disclose the precise meaning AFRINIC assigned to the term or whether publication time and service effectiveness were identical.

The fourth act is global ratification and subsequent implementation work. The June presentation demonstrates that the formal NRO-EC-to-ASO-AC passage was still outstanding after AFRINIC’s date. July brought the NRO-EC transfer and ASO-AC forwarding. September brought ICANN ratification and an instruction that staff take the necessary steps. Those are not administrative footnotes that can be collapsed into the May label. They identify separate actors and separate control surfaces in the global chain.

A later AFRINIC policy-development-process text helps explain why precision is reasonable. That text distinguished approval from implementation and required announcement of adoption and implementation dates. But it was itself implemented on 11 November 2010. It is therefore contextual evidence about AFRINIC’s later public terminology, not proof that its provisions governed the May act. Applying it retroactively would replace one ambiguity with another.

The surrounding chronology contains a second discrepancy worth preserving. AFRINIC’s history records a last-call period from 4 to 19 December 2009, while ICANN records 2 to 17 December. Again, the reason is unknown. Neither discrepancy invalidates the policy. Together they show why institutional histories should expose the source and function of each timestamp instead of converting multiple records into an artificial single date.

The differences also show why dates should be typed rather than merely listed. A meeting date, corporate adoption date, publication date, announced implementation date and production effective date are not rival answers to one question. They answer different questions. AFRINIC’s 25 May entry and ICANN’s 24 May entry both concern Board action as their sources describe it; AFRINIC’s 26 May entry concerns the published implementation status. None can silently stand in for the July transfers or September ratification.

Typed dates make corrections safer. If later evidence explains the one-day difference, it can be appended without erasing either source record. If an internal deployment record appears, it can occupy its own field rather than being forced onto 26 May. This preserves the contemporaneous history while allowing the operational account to improve. It also prevents a cleaner later narrative from claiming certainty that the surviving records do not supply.

A layered test for the word “implemented”

The evidence supports a six-stage test. Each stage answers a different question, and passing one does not imply that all later stages have passed.

Layer What the public record proves What it does not prove
Regional governance complete AFRINIC recorded consensus in November 2009, Board approval in May 2010 and an implementation status on 26 May. Operator-wide assent, sovereign authority or completion of the global chain.
Regional operating procedure ready The dated status makes regional readiness a plausible and strong interpretation. The particular procedure, system, form, instruction, test or staff action that changed.
Global policy ratified ICANN ratified the common policy on 21 September after the July forwarding steps. Retroactive global effectiveness on 26 May or completed operator compatibility.
Upstream IANA process changed ICANN said staff would take necessary implementation steps and published final wording. The exact production completion date, configuration change or upstream transaction in the available record.
Transaction observed No direct example has been retrieved for the May event. A changed AFRINIC-to-IANA allocation or member request caused by the amendment.
Operator outcome verified The rationale records a general compatibility and inventory risk. Which African network changed behaviour, avoided failure or incurred cost because of the amendment.

This test avoids two symmetrical errors. One is institutional inflation: treating a regional label as if it exercised every control in the system. The other is operational nihilism: saying nothing happened because no packet trace or change ticket is public. Something did happen. AFRINIC completed and announced a regional lifecycle state, publishing a definite position within a coordinated system. The missing evidence concerns the scope and mechanics of that state change, not the existence of the public act.

The distinction also protects the institutions involved. If “Implemented” meant regional policy adoption plus readiness, saying so would prevent observers from blaming AFRINIC for later global steps it did not control. If it meant a change to a named regional procedure, identifying that procedure would let members test the claim. If it meant only publication of the final regional text, a layer label would preserve the historical act without suggesting a deployment that the record cannot substantiate.

The strongest defence of 26 May

The strongest defence is practical. A regional registry should not wait for the last global ceremony before preparing for a coordinated change. Staff need time to understand the amendment, identify dependencies, revise procedures, test compatibility and communicate with requesters. If every region postponed all local work until ICANN’s final step, the common policy could be formally complete while one or more regional services remained unready. Early regional completion reduces that risk.

On this view, the 26 May label legitimately marked AFRINIC’s part as done. The proposal had passed regional processes across all five RIRs. AFRINIC’s Board had approved or adopted it in May, notwithstanding the one-day difference between the two official histories. Publishing the amended text and a dated status removed uncertainty about AFRINIC’s position. Other actors could count the African regional precondition as complete while the common proposal advanced through the NRO, ASO and ICANN stages.

That defence deserves full credit. The chronology does not prove an attempt to usurp the global process, a mistaken deployment or an effort to mislead. Local implementation and common-policy effectiveness can be different milestones. A service organisation often must prepare before a dependency is live. The fact that the upstream chain remained unfinished is not evidence that AFRINIC should have done nothing.

The defence is stronger, not weaker, when implementation is described precisely. “Regional lifecycle complete; operating procedure ready pending global ratification” would communicate useful readiness without claiming an IANA state change. A date can coordinate teams and institutions even before an external dependency is active. Such a status is a real operational asset because uncertainty itself imposes delay and cost.

The strongest objection

The strongest objection is also practical. The unqualified word “Implemented” can collapse layers that users need to distinguish. Someone reading the archive may reasonably infer that the policy had become effective in the relevant service, not merely that AFRINIC had completed a regional governance step. Yet the contemporaneous presentation says the proposal had not entered the formal NRO-EC-to-ASO-AC passage, and ICANN’s ratification was nearly four months away.

Without a layer tag or change record, the label can become a substitute for evidence. It does not say whether a request form accepted a different instruction, whether staff used a revised procedure, whether inventory was classified differently, whether an upstream dependency was merely anticipated, or whether the date marked publication rather than production. A later reader cannot reproduce the transition from the archive entry alone.

This objection is not an accusation that the status was false, unlawful, deceptive or incompetent. Its precise operational meaning is unproved. Nor does the date mismatch establish misconduct. The problem is an audit problem: the public noun is broader than the public receipt. The answer is to supply the missing receipt, not to infer motive.

Running-code primacy and the compatibility reality

The amendment existed because deployed reality did not move at the speed earlier planning had assumed. Registry classification could preserve access to legacy-compatible ASN inventory for longer, but a declaration could not make routers, management systems, peering practices or vendor implementations ready. No implementation date could transform an unusable ASN into a usable one for a particular network.

Running-code primacy therefore imposes a simple order of proof. Begin with what operators could actually request, receive, configure and exchange. Then ask whether the registry procedure and upstream allocation process supported that reality. Only after those questions should the archive label be used as evidence of operational completion. Public policy language is a map of intended coordination; working systems and observed transactions show the terrain.

This order does not subordinate governance to engineering folklore. It makes the service accountable to its reason for existing. The temporary inventory distinction was justified by compatibility constraints. Evidence of pass and fail cases, exception handling, request latency and operator remediation would reveal whether the accommodation worked. In their absence, the official rationale establishes the risk, while the actual distribution of benefits and costs remains unknown.

It also disciplines scarcity claims. A headline stock number is misleading if a material share cannot be deployed by the requesters who need it. Conversely, an assertion of incompatibility should not become a permanent exemption from transition. Measurements by compatibility class, with holder-identifying information protected, would let the system distinguish a real constraint from habitual delay.

The implementation evidence ledger

The May record could be made auditable through a compact ledger linked to the policy entry. The first field should identify the decision instrument and actor at each layer: regional consensus, Board approval, regional status publication, global procedural transfer, ICANN ratification and IANA service work. Each should have its own timestamp. Where histories differ, the ledger should preserve both dates and their attributions rather than silently select one.

The second field should state scope. Did 26 May mean that the regional text was published, that a staff procedure had been approved, that a system was ready but waiting for an upstream dependency, or that production treatment of requests had changed? A status can carry several of those meanings, but each should be named. The affected workflow, form, database behaviour, API behaviour or staff instruction should be identified at the level needed to reproduce the claim without exposing security-sensitive details.

The third field should record tests and observable transactions. Relevant evidence would include compatibility test cases for both inventory classes, pass and fail results, an anonymised before-and-after request example, latency, an IANA-to-RIR transaction where applicable and reconciliation between regional inventory treatment and upstream policy state. The aim is not to publish member secrets. It is to connect an institutional statement to an observable service state.

The fourth field should cover exceptions and reversibility. A registry should publish the conditions for waiver, manual handling, rollback and sunset. If an upstream step is delayed, the record should say whether regional readiness remains dormant, whether a temporary procedure applies and who may activate or suspend it. If a change produces unexpected operator failures, the fallback should already be known.

The fifth field should capture economic reality: inventory by compatibility class, operator-reported incompatibility, remediation cost and the point at which continued accommodation becomes more costly than transition. These metrics should not identify resource holders. Their function is to test whether the policy rationale matches actual demand and whether nominal stock corresponds to usable supply.

Finally, an independent audit receipt should connect the announced status to the named state change. Independence need not mean a grand tribunal. It can mean that someone other than the implementing owner confirms that the instrument, procedure, test and transaction evidence agree. The resulting record would strengthen the 26 May act by showing exactly what AFRINIC completed and exactly what still depended on the global chain.

No such direct-event record appears in the available material. There is no first-party change ticket, deployment checklist, ASN request ledger, IANA transaction, configuration diff, staff notice, test result or before-and-after member service record for 26 May. That absence must be stated plainly. It does not prove those records never existed; it means the public claim cannot rely on them unless they are produced.

The authority boundary

The May act is strongest when understood as bookkeeping and coordination. AFRINIC is a private bookkeeper and coordinator for unique Internet number registration. It may maintain records, administer bounded service procedures, preserve uniqueness and coordinate consistency with peer institutions. It has no sovereign, legislative, regulatory, police, prosecutorial, judicial, punitive, confiscatory or ownership power. It does not own networks or number resources and cannot bind operators by force merely by attaching a status to a policy page.

Consensus in the regional process was technical input, not a principal conferring governmental authority. Board approval could authorise action within AFRINIC’s corporate and service instruments; it did not turn a regional organisation into a legislature for Africa. ICANN ratification proved ICANN’s act under the common-policy chain. NRO and ASO records prove the procedural acts they describe. None of those institutional statements self-proves authority beyond the relevant instrument.

That boundary makes the implementation label more credible, not less. A private coordinator does not need sovereign power to publish a procedure, prepare inventory handling or coordinate with IANA. It needs a clear service mandate, accurate records, interoperable practice and evidence that the change serves the uniqueness function. The thinner the claimed function, the easier it is to audit and defend.

What can be concluded—and what remains unknown

The most reliable conclusion is bounded. AFRINIC publicly classified AFPUB-2009-ASN-001 as implemented on 26 May 2010 after a regional technical judgment and May Board approval. That act completed a regional lifecycle step and made AFRINIC’s service position definite within a global process. It did not ratify the global policy, and the contemporary record affirmatively shows that formal NRO-EC and ASO-AC steps were still outstanding.

The operative amendment extended separate treatment of 16-bit and 32-bit-only ASN inventory to the end of 2010, after which allocations were to proceed from an undifferentiated pool. The rationale concerned the gap between nominal inventory and practically usable inventory during a compatibility transition. This explains why early preparation and a clear regional position had operational value.

The record does not establish whether 26 May was an announcement date, effective date, publication date, internal deployment date or some combination. It does not identify the internal authoriser beyond the recorded Board step, the staff owner, the systems or procedures changed, the training material used, any test or rollback plan, a changed IANA allocation, a member request handled differently, or the amount of affected demand in the AFRINIC region. It does not explain the 24/25 May Board-date discrepancy or prove that the archive timestamp equals service effectiveness.

Nor does the later September record provide a precise IANA production completion date in the available material. ICANN ratified the policy and said staff would take necessary implementation steps. That proves a later global corporate act and intended follow-through, not the exact transaction at which the upstream service changed. Operator outcome remains another distinct layer: the rationale identifies compatibility risk, but no named African operator outcome can be attributed to the May status.

The counterfactual check

Four counterfactuals test the bounded conclusion. First, suppose AFRINIC had waited for ICANN ratification before beginning any internal preparation. The region could then have become the lagging dependency after a legitimate common policy was approved. That possibility supports early readiness and gives the 26 May milestone practical value; it does not establish what preparation occurred.

Second, suppose readers treat 26 May as the global effective date. They would have no coherent account of the June presentation, the July NRO-EC and ASO-AC steps or the September ratification. The result would be an institutionally false chronology even if the regional archive entry remained accurate on its own terms.

Third, suppose the label had no operational content beyond publishing the regional text and closing AFRINIC’s lifecycle. That would still be a governance act with coordination value. It would simply be weak evidence for a changed service. The distinction matters because rejecting an enlarged claim does not require pretending the underlying act never occurred.

Fourth, suppose the archive had included a layer tag and one anonymised transaction trace. Much of the present ambiguity would disappear. Readers could distinguish regional readiness from global effectiveness without arguing over institutional vocabulary, and AFRINIC could claim full credit for its actual work without being credited—or blamed—for controls held elsewhere.

These tests all point to the same rule. Interpret the public date at the narrowest layer directly proved, then enlarge the conclusion only when a corresponding instrument and observable receipt support the enlargement. That method works whether the missing evidence would ultimately show a substantial internal deployment or a publication-only milestone.

The proper historical description is therefore exact but not dismissive. On 26 May, AFRINIC finished a bounded regional act, published the amendment and announced an implementation status. The global chain was unfinished. The operational content behind the regional label remains only partially visible. A better record would preserve all three facts at once.