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

[Tshepo Masuku]

Dear PDWG,

I have a separate concern arising from the Impact Assessment.

The proposal validates an AS-SET only when it is created, but the assessment presents the hierarchical name as a continuing link to the responsible ASN operator. That link may not remain accurate throughout the object’s lifetime.

For example, what happens if the leading ASN changes holder, is returned, is reassigned, or receives a new maintainer? Does the former operator retain control of AS12345:AS-CUSTOMERS, does the new holder inherit it, or is the object suspended? The policy also permits existing objects to be edited, but does not say whether changes to maintainers or parent objects trigger renewed authorisation checks.

Deletion and recreation create a similar problem. If a hierarchical name is deleted and later recreated, existing filters or references may silently resolve to a different object using the same name. The proposal provides no tombstone, reservation, restoration period, or conflict-state mechanism.

These are not questions about whether AS-SET membership is correct. They concern whether the proposal’s claimed attribution remains technically true after creation.

Before adoption, the policy should define deterministic rules for changes of ASN control, parent-child delegation, maintainer replacement, deletion, restoration, and name reuse. Otherwise, AFRINIC may enforce a hierarchical label while the label no longer identifies the operator actually controlling the object.

A creation-time check is not enough for a claim of continuing authorisation.

For that reason, I object to the proposal as presently written.

Regards,
Tshepo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260727/3daca504/attachment-0001.html>