Summary

  • Resolution 202002.552 efficiently ratified Multihoming Not Required for ASN Draft 4 and Adjusting IPv6 PI in one corporate act, but it compressed only the act of ratification, not the evidence needed to understand either instrument.
  • The ASN proposal and the IPv6 PI adjustment had different problem statements, review histories, applicant risks and operational changes. Evidence from one lane cannot establish scrutiny or implementation in the other.
  • A sound public record would pair the shared resolution and 29 May 2020 release boundary with two separate instrument records: exact final text, review history, remaining caveat, responsible implementation work, changed service materials and post-release verification.
  • AFRINIC could administer both rules as a private technical bookkeeper and coordinator. Neither Board ratification nor community consensus gave it sovereign, regulatory, police, prosecutorial, punitive, confiscatory or adjudicative power.

L3 — One resolution, two technical records

A network in a remote market may need a globally unique public routing identity while having only one physical connection today. An exchange may use provider-independent IPv6 space on a peering LAN that is never intended for global announcement. Those situations do not ask the same question of a number registry. The first asks what evidence shows a genuine need for a public ASN when physical multihoming is not an absolute precondition. The second asks whether absence from the global routing table can fairly be treated as absence of use.

In February 2020, a single line in AFRINIC's Board record changed the administrative status of both questions.

The line records Resolution 202002.552 and names Multihoming Not Required for ASN Draft 4 alongside Adjusting IPv6 PI. That is firm evidence of one corporate ratification act. It is not evidence that the instruments travelled through the same scrutiny, answered the same objections or required the same changes to the service manual. Nor does the record establish the precise day on which the resolution passed, a tally, the reasons of individual directors or what any Board papers contained. The responsible reading is therefore narrow but consequential: AFRINIC's Board acted once, in February 2020, on two distinct proposals.

That distinction matters because a short decision record invites an easy mistake. A reader may see one resolution number, one later implementation date and the word “implemented” on a policy lifecycle page, then mentally turn the pair into a single policy change. Yet the ASN instrument dealt with a test for public routing identity, whereas the IPv6 instrument repaired the relationship between non-announcement and continued legitimate use. The former could affect an applicant deciding whether it had to procure a second upstream before seeking an ASN.

The latter could affect an end user whose IPv6 PI resource served an exchange or private network without appearing globally. One could not inherit the other's evidence.

The ASN lane begins before the ratified draft

The ASN history demonstrates why version discipline is essential. Version 1 of Multihoming Not Required for ASN was submitted on 27 February 2019 and separately announced on 7 March. Its central challenge was to the use of physical multihoming as an absolute eligibility proxy. A network might have a legitimate operational need for a globally unique public ASN even when its present topology did not include two physical upstreams. Conversely, a registry still needed to distinguish that need from purely local uses for which private ASNs remained available. The proposal did not abolish eligibility review, and it did not abolish private ASNs.

AFRINIC staff assessed Draft 1 on 8 April 2019. That assessment is unusually useful because it exposes the kinds of questions that a compressed ratification line cannot show. Staff identified a conflict involving a single-interconnection route and section 5.1 of RFC 1930. They tested four one-peer or prospective cases, asked for terminology changes, considered namespace consumption in light of the large 32-bit ASN pool and listed operational work in forms, checklists and documentation. The assessment also recorded no comment from the legal adviser. Each point belongs to the ASN proposal's review history.

But none of those points can simply be pasted onto the final decision object. Draft 2 followed on 10 April, Draft 3 on 3 November and Draft 4 on 25 November. Resolution 202002.552 ratified Draft 4, not Draft 1. The April assessment proves that an early version received detailed staff attention; it does not, on its own, prove how every recommendation was resolved in later text or what complete final scrutiny looked like. A proper account therefore keeps three propositions separate: Draft 1 raised and received a documented assessment; the proposal changed through three later versions; and the Board ultimately ratified Draft 4.

This is more than bibliographic neatness. If a reader attributes Draft 1 language to Draft 4, the reader may believe a concern remained when it had been revised, or believe a revision occurred when it did not. If a staff test for an early draft is described as though it were a final implementation test, an applicant cannot tell which evidence AFRINIC would actually request after the rule took effect. Version identity is part of the service promise. It tells operators which wording controls an application and tells staff which checklist is legitimate to use.

The later policy lifecycle and CPM 1.5 place implementation on 29 May 2020. That gives the ASN lane a visible end point, but a date alone is not a receipt. To close the lane, the public record must connect Draft 4's final eligibility rule to the affected ASN manual text, request form, checklist, internal guidance and applicant-facing explanation. The April assessment anticipated categories of such work, but its existence cannot demonstrate that every final change was made. A reader needs the final text and the corresponding service materials side by side.

The substantive boundary is equally important. The revised approach could ask whether global coordination genuinely required a unique public ASN, while leaving local-only uses to private ASNs. It could remove the purchase of a second physical upstream as an absolute gate. It could not transform AFRINIC into an authority over network architecture. A technical registry may ask for evidence necessary to preserve uniqueness and accurate records; it may not make redundancy, supplier choice or topology into a moral test.

The IPv6 lane begins with a different defect

The IPv6 PI adjustment grew from a separate history. AFRINIC published V6-004, the IPv6 PI Update, on 28 March 2018. That proposal created an end-user route to provider-independent IPv6 resources, with consequences for portability and dependence on a provider's addressing. At AFRINIC-28 on 6 June, participants discussed the twelve-month announcement condition, routing monitoring and other technical language. Resolution 201808.449 ratified V6-004 on 8 August and directed staff implementation. On 29 November, AFRINIC reported partial implementation while specified automation remained pending.

Those 2018 records establish the predecessor rule and the setting in which the later problem arose. They do not establish that the 2019 adjustment had already been ratified or implemented. The chronology matters: first came an end-user IPv6 PI route with retained announcement-related wording; only later did Adjusting IPv6 PI identify why that wording could be too broad.

The later proposal focused on legitimate uses that may never be globally announced. An IXP peering LAN is an obvious example: its usefulness may depend precisely on serving participants locally rather than becoming a destination carried across the public Internet. A private network may likewise use assigned space operationally without advertising it worldwide. In those cases, non-announcement does not establish non-use. A sentence capable of connecting twelve months without announcement to a reclamation implication therefore risked treating a routing-table observation as a complete account of operational reality.

The selected register identifies the ratified IPv6 instrument as Draft 1, while the cited substantive lifecycle page is Adjusting IPv6 PI Draft 2. Draft 2 supports the existence of the distinct clarification problem, examples of legitimate non-announcing use and the later lifecycle. It must not be used to claim that every word shown there appeared in ratified Draft 1. That is the IPv6 version boundary corresponding to the ASN warning, but it operates differently: the ASN record clearly identifies Draft 4 as the ratification object, while the later IPv6 Draft 2 page supplies bounded evidence about the clarification and its evolution.

A careful analysis names that limit rather than silently backdating the later wording.

Nor can the ASN staff assessment fill the gap. The four ASN scenarios, the RFC 1930 conflict and the large 32-bit namespace concern say nothing about whether an IXP peering LAN is a legitimate non-announcing use of IPv6 PI space. Likewise, the 2018 meeting discussion about announcement and monitoring cannot demonstrate that ASN Draft 4 received final review. The records are adjacent in time and later adjacent in the Board register, but adjacency is not evidentiary substitution.

The policy lifecycle and CPM 1.5 place the IPv6 change at the 29 May 2020 implementation boundary as well. Again, the shared date is useful but incomplete. Closing this lane requires a direct mapping from the ratified IPv6 adjustment to the corrected sentence in the relevant IPv6 PI manual section, along with an operational test showing that a legitimate non-announcing use would no longer trigger the defective implication. The ASN form and checklist cannot perform that task. The IPv6 lane needs its own receipt.

What one register line can and cannot tell us

The Board register answers a corporate-status question: were the two proposals ratified? It says yes, together, through Resolution 202002.552. It does not answer the technical questions that preceded ratification or the operational questions that followed. A public record becomes intelligible only when those three levels remain connected without being collapsed.

At the first level is the shared corporate act: resolution number, month and the identity of both instruments. At the second are the separate scrutiny histories: which draft was considered, which technical conflict or defect was examined, what objections remained and what text emerged. At the third are separate implementation records: which manual sentences, forms, checklists and staff instructions changed, when they became effective and what later evidence confirmed that staff applied the new rule as intended.

This structure does not presume that either proposal lacked scrutiny. The available record shows meaningful work in both lineages, although it does not contain complete last-call records, Board papers or proposal-specific votes. The point is not to turn missing material into an accusation. It is to recognise that a compressed Board line cannot carry all the information an operator needs. Where supporting records exist elsewhere, the decision record should point to them with enough specificity that no one has to borrow proof from the neighbouring policy.

BTW's earlier research on the first ASN draft helps establish the early chronology and the practical problem with compulsory multihoming, but the February 2020 commission begins later: it asks what happened when Draft 4 and the IPv6 adjustment were ratified together. BTW's earlier IPv6 PI analysis likewise establishes the predecessor portability mechanism and announcement ambiguity without proving Resolution 202002.552. Treating those articles as first-class analytical sources means respecting their boundaries as well as using their insights.

The result is a simple but demanding proposition. One decision can contain two approvals. It cannot contain one blended proof burden. The resolution compressed the ceremony of corporate action; it did not erase the need to identify two final texts, two technical questions, two review trails and two implementation closures.