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

[Phetulo Dhlamini]

Dear Jaco,

As I have been following the discussions very closely, thank you for taking
the time to explain your position. I accept that hierarchical naming can
strengthen creation authorisation within the AFRINIC database.

I have a different concern, however. The proposal binds an AS-SET name to
an ASN, but it does not bind that name to a particular IRR source.

For example, AS12345:AS-CUSTOMERS identifies the ASN namespace, but it does
not tell a resolver whether the intended object is from AFRINIC, RADB,
RIPE, or another source. IRR software already recognises that sets with the
same primary key may exist in different sources and may return them
separately.

This is not merely hypothetical architecture. An active IETF GROW
working-group draft, still a work in progress, states that object primary
keys are not guaranteed to be unique among IRR registries and proposes
registry-scoped references precisely because multi-source resolution
remains ambiguous.

That creates a gap in the proposal’s central claim. It is presented as
protection against inter-RIR collisions, yet the Impact Assessment
expressly places mirroring and resolver behaviour outside scope. If the
source is not part of the object’s identity, a hierarchical name may be
properly authorised in AFRINIC while an identically named object remains
visible through another source.

Before mandatory enforcement is introduced, the design should specify how
the authoritative source is selected, what tooling must do when the same
hierarchical primary key appears in multiple sources, and whether
source-qualified references or an equivalent deterministic rule are
required.

Otherwise, the policy gives operators a stronger-looking name without
providing a complete answer to the multi-source lookup problem it is meant
to address.

This concern is fixable, but it should be resolved and tested before the
proposal advances. I therefore remain opposed to the policy as presently
written.

Regards,
Phetulo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260727/8ee56125/attachment.html>