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

[Phetulo Dhlamini]

Hi Frank,

Your examples are useful, but they do not establish the global guarantee
you suggest.

On your first question, the answer is not automatically “no.” Current RIPE
Database documentation states that anyone may create an aut-num copy for an
ASN administered by another RIR. The same documentation says that creation
of a hierarchical AS-SET is authorised through the maintainer of the parent
object in that local database. This means, at least in principle, that a
locally created, non-authoritative copy of an out-of-region aut-num could
become the authorisation anchor for the same hierarchical AS-SET name.

This is not an imaginary threshold. A current IETF GROW Internet-Draft
expressly states that RFC 2622 hierarchical authorisation works only within
a single IRR and does not identify the correct external IRR. The proposal
therefore improves local authorisation, but local authorisation should not
be presented as global authority.

On whether AS3320:AS-DTAG could be created in AFRINIC, the normative text
does not provide a complete answer. It requires an ASN as the first
element, but does not expressly require that ASN to be currently
administered by AFRINIC and authenticated against an authoritative AFRINIC
aut-num.

That requirement should be stated directly, for example:

> The first ASN element MUST be currently administered by AFRINIC and MUST
be authenticated against the authoritative AFRINIC aut-num object. A
locally copied or otherwise non-authoritative aut-num object MUST NOT
satisfy this requirement.



The proposal should also state precisely what assurance the name provides:

> A compliant hierarchical name proves authorisation to create the object
in the AFRINIC authoritative IRR at that time. It does not, by itself,
establish the authority of copies in other IRRs or determine how
multi-source tools must select an object.



As for the possibility that suitable tooling may be written later,
possibility is not an operational guarantee. A mandatory policy should not
be credited today with a security property that software might implement in
future. If tools are expected to rely on the hierarchical name as an
authority signal, the meaning of that signal and the relevant test cases
should be specified first.

I accept that the proposal can improve creation control inside AFRINIC. I
do not accept that this proves global uniqueness or deterministic source
authority.

Until the authoritative-anchor requirement and the scope of the resulting
assurance are made explicit, I remain opposed to the proposal as written.

Regards,
Phetulo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260730/7696f7ee/attachment-0001.html>