[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)

[Tshepo Masuku]

Dear Hendrik,

Thank you for consolidating the discussion. I will not repeat the earlier objections. I will answer Question 7 with one specific operational concern arising from your own response.

You rely on the AFRINIC transfer record to conclude that an ASN and its related AS-SET objects move together. However, a transfer log proves only that control of an ASN changed. It does not prove that every hierarchical AS-SET beneath that ASN is atomically transferred, re-authenticated, frozen, deleted, or moved to another IRR.

Consider this case:

AS65000:AS-CUSTOMERS exists in the AFRINIC database and is maintained by the previous holder or a delegated maintainer. AS65000 later changes holder or authoritative registry. The proposal does not define what happens to that AS-SET.

If the old object remains while the new holder creates the same hierarchical name in the new authoritative source, two objects with the same supposedly unique name may coexist. Both may have been validly authorised when created, but they represent different holders and different points in time.

That creates a practical risk: filter-generation tools, mirrors, caches, and source-specific configurations may resolve different objects without the relying operator changing its configuration. The ambiguity has moved from flat-name collision to authority succession, but it has not disappeared.

This is not an adjacent question about membership accuracy. It concerns the proposal’s central claims of name uniqueness, source determinism, and proof of control.

The transfer JSON does not demonstrate the required database behaviour. What is needed is a documented and tested state transition explaining:

whether dependent AS-SETs move with the ASN;

whether they remain under delegated maintainers;

whether the old source publishes a tombstone or transfer status;

whether the new holder may recreate the same name elsewhere; and

how tools distinguish the current authoritative object from the historical one.


Without that, the statement that the ASN-to-registry map always provides a deterministic authoritative source is not established by running implementation.

I am not asking the proposal to build the entire IRR “skyscraper.” I am asking whether its claimed foundation remains sound when control of the anchor ASN changes. A creation-time authorisation rule that does not define subsequent authority transitions is incomplete within its own stated purpose.

This is a concrete future operational problem that could produce divergent filters and stale authority after an ASN transfer. Until the transfer behaviour is specified and tested, I remain opposed to the proposal as written.

Regards,
Tshepo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260729/d8deab1c/attachment-0001.html>