Summary

  • AFRINIC's June 2026 meeting record placed full AS0 ROA implementation, the technical transfer system and the abuse-contact update on paths dependent on or prioritised after MyAFRINIC v2; a separate staff assessment did the same for a hierarchical AS-SET proposal that was still in Last Call.
  • These are not four instances of one feature. They begin from different policy states, touch RPKI, cross-RIR procedures, internal validation, WHOIS and IRR, and require different users, tests, notices and correction paths.
  • A portal being available is therefore not evidence that a policy has been activated, still less that it operates as written. AFRINIC needs a policy-by-policy dependency and acceptance ledger that distinguishes a release baseline, partial and full states, test results, activation and post-launch evidence.
  • Shared infrastructure can be a prudent way to retire inconsistent legacy workflows and avoid duplicate engineering. Its risk is not common code by itself, but common language: an undifferentiated claim of progress can conceal which policy clock has actually stopped.

At the centre of AFRINIC's current policy pipeline sits one software milestone. On one side is MyAFRINIC v2, a comprehensive rebuild of the member portal. On the other are four different clocks. One measures whether AS0 route-origin authorisations for unallocated and unassigned address space have moved from internal testing and a partial state to full implementation.

Another measures whether a ratified transfer policy has acquired both the inter-registry procedures and the technical path needed to process eligible transfers. A third measures whether a ratified abuse-contact rule has become a working validation, notice and correction process. The fourth has not reached ratification at all: it is a Last Call proposal requiring hierarchical names for newly created AS-SETs.

The clocks share a dependency. They do not share a legal state, a system boundary or a definition of completion.

That distinction is easy to lose in a programme update. A portal has a recognisable public event: it launches, enters beta or opens to a class of users. Policy implementation is less singular.

It may require a rule to be ratified, software to interpret the controlling version, data to be prepared, permissions to be constrained, staff procedures to be mapped, affected users to test the path, a start time to be announced and failures to be corrected without erasing the original event. If those states are compressed into the word launch, a platform milestone can inherit the meaning of four policy outcomes it does not prove.

The official record does not establish that this has happened. It establishes something narrower and more useful: AFRINIC has publicly described a concentration of implementation dependencies. That concentration can be audited before anyone needs to allege a missed deadline, a defective feature or a harmed member.

The shared milestone

The minutes of AFRINIC-37, held on 24 June 2026, say work on MyAFRINIC v2 began in 2020, encountered multi-year budgetary and other resource constraints, and was later revived. The portal was then expected to go live by the end of 2026. The minutes also record a need to limit scope to avoid scope creep.

That statement deserves precision in both directions. Scope control is not evidence of failure. A product team rebuilding a consequential member portal has good reason to protect a release from an expanding list of demands. A smaller coherent release can be safer than a nominally comprehensive one that no representative user has tested. At the same time, the minutes do not identify which features were inside or outside the protected scope.

It would be wrong to infer that any of the four policy paths was cut.

AFRINIC's AfPIF 2026 page supplies another state marker. It calls MyAFRINIC v2 a comprehensive rebuild and says AFRINIC was gathering feedback ahead of user acceptance testing and a live beta. It invited member contacts for those programmes and asked for short interviews about real workflows. The page is evidence of preparation and recruitment.

It is not evidence that UAT ended, that beta began or ended, or that the production portal opened. Those later states require later records.

There is also a date that should not be made to carry more than its source permits. The staff assessment for the AS-SET proposal says resources had been channelled to MyAFRINIC v2, which was expected to go live by 15 November 2026. The meeting minutes use the broader expectation of year-end.

The two formulations may describe the same programme at different levels of specificity, but they are not a universal promise that every dependent policy would be implemented on 15 November. The exact date belongs to the AS-SET assessment. The broader date belongs to the June status account. Neither proves present completion.

Four paths, not one backlog

The current policy ledger identifies the AS0 policy, AFPUB-2019-GEN-006-DRAFT03, as ratified and Awaiting Implementation. AFRINIC-37's minutes provide a more granular snapshot. Internal testing was under way using evolved KRILL software. A beta was expected by the end of that month and was to be announced as partly implemented. Full implementation as written in the policy text depended on MyAFRINIC v2.

That is already at least four states: ratified, internally tested, partly implemented and fully implemented as written. The distinction is valuable because AS0 is not simply a page in a portal. The policy concerns RPKI ROAs for address space that AFRINIC has not allocated or assigned. A partial state might differ from the full state by covered objects, publication scope, exception handling, integration or correction behaviour.

The checked sources do not define that boundary in sufficient detail. They do, however, warn against replacing it with a binary label.

The Number Resources Transfer Policy, AFPUB-2020-GEN-006-DRAFT03, follows another path. AFRINIC's ratified-policy overview dates ratification to 4 February 2026. The AFRINIC-37 minutes say the policy covers intra-RIR and inter-RIR transfers, and report that reciprocity with the other four RIRs had been confirmed as of April. Implementation was under way, with Member Services mapping procedures with its counterparts.

Technical system implementation would be prioritised after MyAFRINIC v2.

Here, software is only one dependency. A transfer route also joins two administrative regimes, eligibility rules, evidence exchange, status messages and registry updates. An interface can exist while a specific route remains procedurally unavailable. Conversely, staff can have an agreed manual procedure before a member-facing tool is ready. The acceptance question is not whether a transfer screen appears.

It is whether each eligible route can move from a valid request through counterpart coordination to an attributable registry result, with a visible way to stop, reject, correct or resume it.

The Abuse Contact Policy Update, AFPUB-2018-GEN-001-DRAFT07, is also dated as ratified on 4 February 2026. The June minutes say technical implementation on internal systems was scheduled to be prioritised after MyAFRINIC v2 deployment was complete. This path is different again. A working abuse-contact policy needs more than a field.

It needs a definition of the record tested, a validation event, delivery and response states, notice to the affected party, a correction route and a disciplined account of consequences. The present article does not revisit what those consequences ought to be. It asks what would prove that the ratified version, rather than an earlier draft or an informal approximation, controls the implemented workflow.

Finally comes AFPUB-2026-ASN-001-DRAFT02. The policy ledger lists the proposal in Last Call. The proposal and staff assessment say WHOIS touchpoints and the MyAFRINIC IRR interface would require changes to prevent new non-hierarchical AS-SET creation. Existing AS-SETs would not be renamed. The implementation plan says the work could be prioritised after MyAFRINIC v2 concluded.

This path cannot be reported as implementation of an adopted rule because the checked record does not show ratification. Software planning before ratification can be sensible: an impact assessment should identify feasibility, affected systems and cost while a proposal is debated. But readiness planning and policy authority remain different.

If the proposal is later ratified, the first acceptance test must bind the deployed behaviour to the controlling text and effective time. Before ratification, the appropriate public state is proposal assessment, not policy activation.

Policy path State in the checked record MyAFRINIC v2 relationship Evidence still needed for acceptance
AS0 ROAs Ratified; listed as Awaiting Implementation; internal testing and a planned partly implemented beta reported Full implementation as written described as dependent on MyAFRINIC v2 Covered objects, partial/full boundary, test results, correction cases, activation and continuing publication evidence
Number-resource transfers Ratified 4 February 2026; procedure mapping reported under way Technical system implementation to be prioritised after the portal Route-by-route procedural and technical tests, counterpart state, notices, registry result and correction path
Abuse-contact update Ratified 4 February 2026 Internal technical implementation to be prioritised after portal deployment Exact controlling version, validation cases, notice and remediation tests, consequence boundary and exception handling
Hierarchical AS-SET names Last Call proposal, not ratified in the checked record WHOIS and portal changes assessed; priority after the portal; assessment cites 15 November expectation Later ratification, effective text, coverage of every creation touchpoint, old-object preservation and correction tests

Why release coupling changes the evidence burden

Common infrastructure is not a defect. It can be the correct answer to inconsistent legacy systems. If a policy touches a member's resource record, permissions, a registry object and an internal workflow, building one coherent platform may be safer than adding another isolated patch. Shared identity, common audit events and consistent notices can reduce contradictory states. The same release can also provide a disciplined point at which old and new behaviour are separated.

But common infrastructure creates a common scheduling boundary. A delay in identity, permissions, data migration or a foundational workflow can hold several policy features behind it. A decision to narrow release scope can place one path in a later increment. A defect in the shared layer can affect features whose policy purposes are otherwise unrelated. None of these outcomes is established in the checked record.

They are the ordinary mechanisms by which shared dependencies create correlated implementation risk.

The public-evidence burden therefore rises with the concentration. A generic statement that MyAFRINIC v2 is live would establish, at most, a platform state. It would not say whether an AS0 beta remained partial, whether an inter-RIR transfer path had passed a counterpart test, whether an abuse-contact notice could be corrected, or whether an AS-SET rule had legal authority and covered every creation route. One healthy login screen cannot answer four policy questions.

The reverse error is equally possible. A policy feature might operate through an internal or non-portal path before the portal is generally available. Calling the whole policy unimplemented merely because one public interface is absent could understate real work. This is why acceptance must be policy-specific and why a ledger should permit qualified states rather than force everything into not started or done.

The minimum acceptance ledger

The needed record need not be a public ticket system or source-code repository. It can be a compact table whose rows are policy paths and whose entries change through append-only status events.

First, the row must identify the policy title, identifier, version and legal state. That prevents a later interface from being attributed to the wrong draft. For AS-SET, the row must remain a proposal record unless ratification occurs. For the other three, it should cite the ratified instrument and effective interpretation.

Second, it must name the exact portal baseline. MyAFRINIC v2 is a programme name, not a testable build. Acceptance needs a release identifier or dated baseline sufficient to reproduce the state without disclosing code. If a later patch changes policy behaviour, the row should acquire another event rather than silently replacing the original claim.

Third, the dependency class should be visible. A portal user interface, WHOIS rule, IRR write path, RPKI publication process, internal staff workflow, data migration and inter-RIR procedure are different dependencies. Labelling them prevents a front-end release from inheriting completion credit for an untouched back-end or external process.

Fourth, each prerequisite and owner must be attributable. Ownership is not blame. It tells readers who can attest that a precondition has been met: Registry Products for a platform baseline, Member Services for a mapped transfer procedure, the relevant operational team for a publication or validation process, and the competent policy authority for the controlling text.

Fifth, each path needs a test case and acceptance criterion. AS0 needs defined coverage and failure/correction cases. Transfers need eligible route scenarios, including the point at which a counterpart state becomes authoritative. Abuse contact needs successful validation, failure notice, correction and exceptional-state tests. AS-SET, if ratified, needs proof that every creation touchpoint rejects what the rule prohibits while leaving existing objects within the promised treatment.

Sixth, the ledger should record who tested the path. Internal testing, member UAT and live beta answer different questions. Internal staff may verify a rule engine. Members reveal whether ordinary permissions and workflows make the feature usable. A beta can expose interaction between the feature and live-like data. The result should record material exclusions and unresolved cases, not publish individual member records.

Seventh, partial and full implementation must be defined before either label is used. Partly implemented is informative only if it names what is present, what is absent and what event changes the state. Otherwise it becomes a durable resting place with no falsifiable exit.

Finally, the row needs notice, activation, correction and observation. Readers should know when users were informed, when the rule began to govern an action, how an erroneous activation can be rolled back or corrected, and what post-launch evidence will show continued operation.

An availability percentage may be useful for the platform, but a policy outcome needs its own signal: publication coverage, completed eligible routes, validation and correction states, or rule enforcement across relevant write paths.

What the current record cannot say

The official pages are snapshots. They do not prove the present state on 27 August 2026 merely because they described an expectation in June or a testing invitation in August. They do not show that 15 November was missed; it had not arrived at the evidence cutoff. They do not establish an outage, failed test, rejected transfer, invalid abuse contact, AS-SET collision or RPKI routing effect. They do not identify a member who suffered from the shared dependency.

Those absences are not editorial inconveniences. They define the proper object of scrutiny. The subject is not a presumed failure. It is whether the reporting architecture can distinguish success when it arrives — and can identify which success arrived.

AFRINIC has already supplied the beginnings of that architecture by separating Awaiting Implementation, internal testing, partly implemented, procedure mapping, prioritisation after the portal and Last Call. The next step is to join those words to policy-specific acceptance evidence. If it does so, MyAFRINIC v2 can remain a shared platform without becoming a shared alibi.

Sources