Summary

  • AFPUB-2026-ASN-001-DRAFT02 would require every newly created AFRINIC AS-SET to have an ASN-rooted hierarchical name and would authenticate creation against the ASN in the first component. That is a narrow, locally verifiable bookkeeping rule. It can improve the truthfulness of AFRINIC's record at the moment of creation; it does not create ownership, validate AS-SET members, decide routing policy, authorise BGP announcements, change RPKI or place AFRINIC above the networks it records.
  • The proposal is prospective. Existing flat AS-SETs would remain valid and editable, while a mistakenly deleted flat object could return through a mandatory case-by-case exception. Continuity is necessary because the registry describes an already-running world and must not break it. But restoration has no published test, decision-maker, timetable, review path or audit design in the material examined, so the exception is the point where objective correction could slide into permission.
  • On 9 August 2026, AFRINIC's proposal index said Under Discussion while the proposal page said Last Call and recorded an AF37 presentation on 24 June. Those are claims about AFRINIC's own procedure, not sources of sovereignty. No official material reviewed by the cutoff established ratification, production implementation or uniform rejection across WHOIS, MyAFRINIC and relevant APIs. Text becomes an operational fact only when running systems apply it; even then, AFRINIC remains the bookkeeper, not the ruler of the network.

One useful act, and no more

The entire proposal can be understood through a single submission. Someone asks AFRINIC to create a name with the pattern AS15169:AS-GOOGLE. The example shows the permitted form; it does not assert that this object exists in AFRINIC. The first component is an ASN. The second is an AS-SET label. Under the proposal, AFRINIC's system would ask whether the creator can satisfy the authentication details attached to the root ASN. If the answer is no, the system would reject the creation.

That is a proper task for a registry because it concerns the integrity of the registry's own record. A shared namespace is useful only if independent operators can distinguish conflicting claims and trace a new record to proof of control. The proposed check would make one state transition locally verifiable: a first hierarchical child may enter the AFRINIC database only through authentication tied to its ASN root. The rule is deterministic enough to be expressed in server validation, tested through each creation path and audited after the event.

Nothing in that task makes AFRINIC sovereign. The registry does not cause AS15169 to operate. It does not create the routers, links, customers, contracts, engineers or BGP decisions associated with the network. It does not own the operational reality described by the number. It cannot use its ability to accept or reject a database object as a general licence to decide whether the network deserves to operate, whether its commercial relationships are proper, which peers should accept its routes or how its routing policy should be written.

The record must follow the fact. It must not pretend to author the fact. AFRINIC may record that an authenticated controller created a name beneath an ASN. It may preserve the uniqueness and auditability of that record. It may correct a false or conflicting entry by applying an objective rule. It may not turn the administrative check into punishment, policy judgment, morality, commercial permission or authority over a running network. This distinction is not a rhetorical reservation added after the proposal. It is the condition that makes the proposal defensible at all.

The existing draft manuscript approached the change as a transfer of naming authority. That phrasing needs precision. AFRINIC would not grant the ASN holder sovereignty over a slice of routing reality. It would recognise proof already supplied through control of the authentication material and then keep its own namespace consistent with that proof. The holder's ability to create the root does not originate in AFRINIC's grace. The registry is verifying a control relationship for the purpose of its own ledger.

This is why the colon matters without becoming mystical. It can encode a chain that a flat label does not express. It cannot turn a label into title. It can reduce ambiguity in one registry. It cannot make a routing decision for anyone. It can support coordination. It cannot rule.

What DRAFT02 says the bookkeeper would check

James Bensley of Inter.link GmbH submitted DRAFT02 on 8 June 2026. The text proposes a new section 7.8 of the AFRINIC Consolidated Policy Manual. For each newly created AS-SET, the first name component would be AS followed by an ASN controlled by the authenticated creator. The second component would be an AS-SET name beginning AS-. Later components could be ASNs or AS-SET names, separated by colons.

The first child is tied to the authentication details of the ASN in the first component. For a deeper descendant, RFC 2622's hierarchy places child creation under the maintainer of the immediate parent set. A name can therefore express a control chain: the root is tested against an ASN, and a deeper branch is tested against its parent. The chain is useful because it replaces an arbitrary first-come label at creation with a relationship the receiving registry can verify.

The proposed restriction expressly concerns AS-SET objects. It does not extend to route-sets or other RPSL set types. It does not inspect the truth of every member placed inside a set. It does not select which IRR database a consumer should trust. It does not alter a Route Origin Authorisation, validate a BGP route, repair old objects or impose its rule on an external IRR. The proposed CPM text is a create-time naming rule, not a general routing-security constitution.

Three layers must remain separate. RFC 2622 provides a grammar and semantics for hierarchical set names, including the parent-maintainer model. It also leaves registration processes outside the document. DRAFT02 asks AFRINIC to use part of that grammar as an admission condition for new AS-SETs. AFRINIC software would then have to implement the condition in working systems. A technical specification does not make an AFRINIC database rule. A procedural document does not make running code. Running code does not make AFRINIC the owner of the reality it records.

The proposed rule belongs in the ledger only because any truthful ledger must reject an entry that fails its stated integrity test. It is not a policy verdict on the creator. Rejection would mean only that the proposed database state does not satisfy the new-name predicate used by that system. It would not mean that the creator is unlawful, that its network is invalid, that its routes should be withdrawn, that its existing resources may be revoked or that counterparties must refuse to interoperate.

That boundary also governs the deeper hierarchy. A parent maintainer's ability to create a descendant is a namespace operation under the RFC model, not jurisdiction over the child network's business or routing decisions. Every use of the word control in this article concerns a defined authentication or record-creation surface. It does not mean ownership of routing reality.

A procedural label cannot make the rule real

The official AFRINIC material did not present one settled procedural state at the evidence cutoff. The current-proposals index listed AFPUB-2026-ASN-001-DRAFT02 as Under Discussion. The proposal page separately displayed Last Call and said the draft had been presented at AF37 on 24 June 2026. Neither surface explained the mismatch.

The correct response is not to choose the more advanced label and infer completion. Nor is it to imagine that either label changes the source of truth. Under Discussion and Last Call describe stages claimed by AFRINIC's process. A proposal author, mailing list, meeting, declared consensus, Board, staff assessment or Registration Service Agreement cannot manufacture sovereignty over networks. Even a procedurally completed text would remain a coordination artifact until implemented and used. Even a fully deployed check would remain a ledger rule, not a law of the Internet.

No ratification notice, final CPM text, release note or production acceptance result reviewed by 9 August established that DRAFT02 had become an operative AFRINIC rule. The proposal can therefore be analysed as text and planned behaviour. It cannot be reported as a deployed fact. AFRINIC staff's assessment can establish what staff said would change, what risks staff identified and how staff described sequencing. It cannot establish adoption by existing merely as an assessment, and it cannot make a deployed result exist before the systems show it.

This is Running-Code Primacy applied without ambiguity. A document may guide implementation. It may help operators prepare. It may define a test. But publication is not operational reality, meeting approval is not operational reality and registry recognition is not operational reality. The material fact would be consistent acceptance and rejection by the relevant production paths. Until those paths enforce the same predicate, the proposed control remains proposed.

Nor would implementation create a universal obligation. Operators remain responsible for the compatibility sets and routing decisions they choose. A consumer may use an AFRINIC hierarchical name as evidence that AFRINIC tested its root at creation. The consumer is not compelled to use the set, accept its members or install any derived filter. Another IRR remains responsible for its own database. AFRINIC cannot declare an independently running system invalid because it does not adopt AFRINIC's rule.

The gap between a credential and a truthful name

AFRINIC's published MyAFRINIC instructions describe creating flat AS-SET names beginning AS- and authorising the operation with maintainer credentials. The current operation is therefore not simply anonymous. It tests whether a submitter can use a maintainer. But a credential attached to an object operation and a name rooted in an ASN answer different questions.

The credential says that the submitter is authorised for the operation represented by that maintainer. A flat name such as AS-GOOGLE does not, from its syntax, establish a relation to a particular ASN. Because IRR databases are autonomous, the same human-readable label can appear in more than one source. A resolver or operator then needs additional information—source qualification, source ordering, bilateral confirmation or another local rule—to know which object was intended.

DRAFT02 would add the missing relation for new AFRINIC roots. It would ask not merely whether the submission has some accepted authentication but whether the authenticated party controls the ASN named at the start of the proposed hierarchy. The name would become more informative because the ledger would refuse a root that lacked that proof.

The proposer says flat labels across RIR-operated IRRs can collide and can yield wrong or empty expansions when consumers aggregate or select sources. The mechanism is plausible and supported by operational examples, but its measured scale is unknown. No AFRINIC flat-name inventory, cross-registry collision denominator, incident series or loss calculation appeared in the controlling proposal and assessment. The argument must not inflate one demonstrated mechanism into a frequency claim.

A MANRS explainer documented an unrelated maintainer's ability to create a flat AS-SET name while an ASN-rooted creation failed without the necessary authorisation. It also documented the same AS-AMAZON label across RADB and RIPE. That is evidence that the namespace mechanism can produce collisions and that root authentication changes the admission condition. It is not evidence that either registrant acted maliciously. It is not a count of AFRINIC incidents. Official and operational material is evidence of what its publisher claimed, tested or did; it is never a substitute for the missing denominator.

The gain can therefore be stated without exaggeration. If AFRINIC deploys the rule uniformly, a party could no longer create a new AFRINIC AS-SET root beneath an ASN whose authentication it cannot satisfy. The database would avoid admitting that class of unsupported relationship. Future readers of the name would have a locally verifiable trail back to the root check.

That is worthwhile bookkeeping. It is not an award of property, a certification of virtue or a verdict on routes. The registry would be doing the same kind of limited work expected of an accurate ledger: refuse to describe a control relation for which the required proof is absent.

Registry accuracy is not routing truth

The sharpest risk in explaining hierarchical names is semantic expansion. Once a new name contains an ASN and has passed an authentication check, readers may begin treating the name as a general trust mark. That inference would be false.

An AS-SET contains routing-policy data supplied for operational use. Root authentication says who was entitled to create the name under the registry's rule. It does not establish that every member is current, complete or correct. It does not prove that a member consents to every downstream use. It does not determine which source a resolver should consult when similar objects exist elsewhere. It does not tell a transit provider which filters to generate or whether a peering relationship should continue.

RPKI operates on a separate control layer. The reviewed NRS material distinguishes the IRR's routing-policy context from cryptographic route-origin authorisation. AFRINIC staff assessed RPKI as requiring no change for this proposal. An ASN-rooted AS-SET neither replaces a ROA nor inherits the properties of one. Conversely, a valid ROA does not authenticate an AS-SET name or its membership.

The operator remains the decision-maker. Each peer, transit provider, route-policy generator and network chooses its sources, expansion rules, cache behaviour, empty-set handling and filter construction. Those local choices can turn ambiguous input into harmless rejection, a missing route or an unsafe policy; the exact mechanism depends on configuration. No source reviewed supplied an end-to-end AFRINIC incident trace that would justify pretending the outcome is automatic.

This separation protects both the registry and the operator. AFRINIC can improve its record without claiming command over routing. Operators can use the improved signal without surrendering their own judgment. The common layer stays thin: syntax, conflict prevention, proof of root control, accuracy and audit. Routing strategy, commercial choice and counterparty acceptance stay where they belong—with the networks that run them.

The registry record describes that an authenticated event occurred in the registry. It does not create the network reality beyond the record. If the record later diverges from running reality, accuracy requires correction; it does not permit the registry to punish reality for refusing to conform to a database fiction.

Continuity is a right, not a favour

DRAFT02 would not force existing flat AS-SETs to be renamed. It states that existing objects may remain in flat form, continue to be used and continue to be edited without a rename trigger. Those protections matter because live dependencies do not reside only in AFRINIC's database.

A flat name may be present in peering records, operational documentation, internal templates, customer instructions, scripts or generated policy. AFRINIC cannot see or rewrite every dependency. A compulsory migration could therefore damage coordination while claiming to improve it. The registry must not make a running network hostage to its preference for a new label.

Non-retroactivity is not merely a compromise granted by administrators. It follows from the ledger's subordinate role. The bookkeeper encounters an existing operational reality with reliance already built around it. The registry may introduce a more accurate form for future records. It may not treat its new preference as authority to erase the old fact or break external references. Operational continuity outranks the aesthetics of a uniform database.

The proposal provides three explicit continuity protections: no mandatory rename, continued use of existing flat names and no rename triggered by ordinary editing. These rules avoid a fleet-wide conversion. AFRINIC staff characterised the expected member burden as a minor learning curve plus possible updates to automation or tooling. That is staff's expectation, not a measured survey, monetary estimate or proof that the burden will be equal for every operator.

The price of continuity is a dual population. New hierarchical names would carry a root-authentication trail. Legacy flat names would remain valid through their existing registration and maintainer arrangements. The old ambiguity would not disappear. Consumers would still need to understand which kind of object they were using.

That is not a defect that authorises coercive cleanup. It is the honest cost of protecting running dependencies. A ledger can improve prospectively while recording that its installed history remains mixed. Uniformity purchased by breaking networks would invert the registry's purpose.

Deletion reveals the boundary between correction and permission

The draft's hardest case begins when a valid legacy object is deleted by mistake. The ordinary new-object rule would reject recreation of the same flat name. External references might still point to it. DRAFT02 therefore requires case-by-case exceptions and uses restoration after mistaken deletion as its example.

There is a narrow form of restoration consistent with the registry's proper role. If objective evidence proves that the same previously recorded object was accidentally removed and that the applicant represents the previously authenticated control, restoring the truthful ledger state can protect continuity. Such an act would correct the record. It would not grant a new entitlement or reward a preferred applicant.

The published material did not define that closed test. It did not name the decision-maker, specify evidence, set a time limit, explain treatment of the former maintainer and history, establish a review route or describe an auditable public record. AFRINIC staff warned that recall or restoration could become an operational loophole and undermine the objective. Staff suggested documenting the reason for each exception.

A reason is necessary but not sufficient. Without a deterministic rule, an administrator would decide who receives an outcome unavailable through the ordinary path. The ledger would stop applying a fact test and begin dispensing permission. That is precisely the kind of expansion a bookkeeper must resist.

The danger is not only inconsistent customer service. Once new flat creation is closed, a surviving flat name has a characteristic no new applicant can obtain ordinarily. A restoration decision can preserve a genuine dependency, but it can also recreate a scarce exception. If the decision rests on unstated preference, the registry has created discretionary power at the boundary of a deterministic rule.

RIPE's documented implementation supplies a bounded contrast. Existing flat names could remain and be updated, but an old flat name could not be recreated after deletion. That line is predictable and moves risk onto the maintainer who deletes. AFRINIC's draft would preserve a recovery path and move risk into exception administration. Neither comparison grants RIPE authority over AFRINIC, and the contrast is not a policy command. It simply makes the allocation of risk visible.

The correct doctrinal question is not whether AFRINIC should exercise restoration power fairly. It is whether the registry can reduce the event to an objective correction rule so that discretionary power is unnecessary. A bookkeeper may repair a proven clerical break. It may not turn continuity into a favour, denial into punishment or a support desk into a tribunal over networks.

Running code is the only evidence of implementation

AFRINIC staff identified six systems in its impact table. WHOIS software and the MyAFRINIC IRR interface would require direct changes. RDAP would reflect WHOIS data. NetSuite, NMRP and RPKI were assessed as requiring no change. This map distinguishes enforcement points, a presentation layer and systems outside the proposal.

The assessment referred to server-side validation, forms and APIs. Uniformity across those paths is essential. A web form that refuses a flat name while an API accepts it would not establish the proposed invariant. A user-interface warning without a root-authentication check would teach the syntax while leaving the authority gap open. An accurate server rejection paired with obsolete documentation could preserve the rule while imposing avoidable operator confusion.

AFRINIC announced MyAFRINIC IRR integration in production on 14 April 2020, with password and optional PGP authentication for maintainers. DRAFT02 would therefore bind an existing authentication capability to a new name-semantic check; it would not invent authentication from nothing.

Staff said the required skills were available, assessed no legal or financial issue on that assumption and sequenced policy work after MyAFRINIC v2, then expected on 15 November 2026. From the evidence cutoff, that date was 98 calendar days away. The date was an expectation in a June assessment, not a verified commitment. Implementation was described as following the platform work.

The earlier chronology similarly shows activity rather than completion. DRAFT01 was submitted on 15 May. DRAFT02 followed 24 days later. Staff dated its assessment seven days after DRAFT02. The AF37 presentation followed nine days later. These intervals establish revision, assessment and presentation. They do not establish that a database predicate was running.

The decisive evidence would be ordinary acceptance tests: an authorised first child succeeds; an unauthorised first child fails; a valid deeper child succeeds; the wrong parent maintainer fails; a new flat name fails; an existing flat object remains editable; deletion behaves as specified; restoration follows a published rule. The outcomes must match across WHOIS, MyAFRINIC and relevant APIs. No such end-to-end deployed matrix appeared in the evidence reviewed.

This order matters. A policy room cannot declare software into existence. A Board cannot vote a validation result into a server. Staff cannot turn an impact estimate into production. An RSA cannot make operators subject to a network reality they do not run. The only sound chain is proposed predicate, implemented code, testable behaviour, actual deployment and operator use. The record should then describe that adopted reality.

What the regional evidence can and cannot establish

APNIC's official prop-151 page records its hierarchy restriction as implemented while preserving existing AS-SET objects. RIPE NCC's release and work-item records show a new-object restriction deployed in release 1.105, also with continuity for existing flat objects. These are bounded implementation facts reported by the respective registries. They demonstrate that a prospective rule can be encoded in an RIR database without forced migration. They do not give those institutions sovereignty, and they do not prove AFRINIC has deployed anything.

LACNIC's official technical writing shows ASN-rooted hierarchical examples in use. The checked LACNIC pages did not independently document rejection of every non-hierarchical creation path. The AFRINIC proposal makes a stronger statement about LACNIC's implementation, but that remains the proposer's claim unless supported by LACNIC's own complete operational record. It would be equally unsupported to infer that LACNIC lacks enforcement.

ARIN's official record shows a different path. Its Advisory Council rejected ARIN-prop-342 as outside number-resource policy scope and redirected the subject to a service-suggestion process. ARIN consulted on a feature that excluded existing records and third-party IRRs, then placed hierarchical enforcement on a future-feature list for prioritisation. The closeout did not announce deployment or a date.

The verified comparator count at the cutoff is therefore two: APNIC and RIPE NCC had direct official evidence of deployed restrictions. LACNIC had verified usage examples but incomplete enforcement evidence in the checked material. ARIN had future work. This count measures the evidence collected; it is not a political ranking and not proof that one registry's rule governs another.

The proposer's claim that AFRINIC implementation would end AS-SET squatting across all five major RIRs is therefore overbroad. Legacy flat names survive. ARIN had not announced production. Complete LACNIC enforcement was not independently established in the checked sources. Third-party IRRs remain outside the proposal. Consumers remain free to choose sources and construct policy. A useful local invariant should not be inflated into a global monopoly claim.

The strongest case against requiring hierarchy

The strongest contrary case accepts that hierarchy can encode creation authority and asks whether a registry mandate is necessary for the benefit claimed. Operators already possess narrower tools. A source-qualified identifier can identify both database and object. PeeringDB presents Google's ASN as 15169 and its routing-set reference as RADB::AS-GOOGLE. A resolver can use an explicit source policy. Peers can confirm intended sets bilaterally. RPKI can separately provide cryptographic origin authorisation.

The proposal does not fix incorrect members, stale objects, unsafe source order, external IRRs or route-origin validity. It leaves every existing flat name in place and creates a restoration exception. It would require new naming patterns and tooling changes without providing an AFRINIC incident denominator or quantified savings. From this view, careful consumers can manage ambiguity locally while a mandatory hierarchy adds another registry constraint whose measured operational return is unknown.

That is a strong case against describing DRAFT02 as a routing-security cure or a globally necessary regime. It is less strong against the precise create-time check. Source qualification works downstream and only when each consumer carries and honours it. Root authentication can prevent a class of unsupported new records from entering AFRINIC's namespace in the first place. Bilateral verification is useful but uneven. RPKI answers another question. Voluntary hierarchy works only where a creator chooses it and a registry honours the parent chain.

The doctrine does not require rejection of all common rules. It requires a minimum common rule that is deterministic, locally verifiable and tied to a genuine invariant. Proof that a creator controls the ASN named at the root meets that test. It protects the truthfulness of a shared record without deciding the operator's business, routes or counterparties. The case for DRAFT02 survives only at that narrow scale.

Nor does the doctrine turn the registry into the sole arbiter of uniqueness. Each database can protect its own ledger. Consumers can qualify sources. Operators can reject incompatible or untrusted state locally. The proposal is one coordination check among autonomous systems, not a charter for a central authority.

The operator still owns every operational decision

For a network creating a new AFRINIC AS-SET, implementation would require a hierarchical form and access to authentication for the root ASN or the relevant immediate parent. A provisioning script, naming template, internal guide or peering record might need an update. A failed submission would have to distinguish bad syntax, failed root authentication and a broken parent chain.

For an existing maintainer, the flat object would remain usable and editable. Deletion would become the critical change. External references might continue after the object disappeared, and the published proposal does not specify what proof would cause restoration. A prudent operator can map dependencies, preserve historical state and require deliberate deletion approval, but those steps are operational choices. They do not concede that AFRINIC owns the name or network.

For a consumer, a new hierarchical AFRINIC root would provide evidence about create-time control inside AFRINIC. The consumer would still choose sources, interpret legacy objects, assess members, decide how to handle external data and build filters. The registry cannot order the consumer to accept the signal. Its value will be demonstrated by operators relying on it voluntarily because it reduces ambiguity.

Costs and benefits will not fall evenly. New creators absorb workflow changes. Existing operators avoid forced conversion. Consumers continue carrying the legacy ambiguity. AFRINIC bears software and support work. A larger network may update automation readily; a smaller network may value a predictable rule while spending a larger share of limited engineering time on adoption. The evidence supports those mechanisms but not a monetary total.

None of these burdens authorises punishment. A creator whose proposed name fails the predicate should receive an intelligible rejection of that database transition, not a broader compliance stigma. An operator that does not use a hierarchical object should not be declared invalid. A consumer that chooses another source should not face registry retaliation. The common check must not acquire an enforcement tail.

The verdict: a narrow ledger improvement with a hard constitutional limit

AFPUB-2026-ASN-001-DRAFT02 contains a sound technical-administrative core. A new ASN-rooted AS-SET can be admitted only after proof tied to the root ASN. That check can protect uniqueness within AFRINIC's database, improve registry accuracy, reduce a class of ambiguous future registrations and provide a clearer starting point for routing coordination.

Its soundness ends at the edge of that check. The name does not become property created by AFRINIC. The record does not determine whether a network exists, who its customers are, which routes it announces or which peers accept them. The AS-SET members do not become true merely because the root is authenticated. RPKI does not change. Other registries do not become subordinate. Operators do not surrender local choice.

The prospective design properly protects existing dependencies, because a bookkeeper must not make running networks hostage to a newly preferred form. That continuity leaves historical ambiguity in place. The restoration clause then becomes the proposal's dangerous hinge. A closed proof-based correction can serve registry accuracy and continuity. An undefined case-by-case permission can give administrators a power that the ordinary deterministic rule denies everyone else.

The procedural record was unresolved at the cutoff, and no production evidence established implementation. That uncertainty must remain. The official documents are evidence of proposals, claims, assessments and recorded steps. They do not create the operational fact they discuss. Community consensus, Board action, staff planning and an RSA cannot manufacture authority over routing reality.

The proper conclusion is therefore firm, not relativistic. AFRINIC is a bookkeeper. It may check the colon. It may authenticate the root. It may maintain an accurate, auditable record and protect uniqueness. It may not convert the useful act of record validation into ownership, policy judgment, punishment, discretionary enforcement or rule over networks. The registry record must describe reality. It must never claim to create it.

Sources