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

[Hendrik Visage]

Good day Tshepo, colleagues,

Tshepo, first: thank you! Your AS-FOO restoration example (015415) is
honestly the best illustration this whole Last Call has produced of
the exact disease we are busy fixing here - you clearly understand
the cross-registry collision problem, you've described its anatomy
better than most of the supporters did. Where I want to help is to
show you WHERE that collision actually lives: it lives in the flat
names, and only in the flat names - and this proposal is precisely
the instrument that stops making them. Let me walk through it.

Executive Summary: An ASN belongs to exactly one registry, that's how 
IANA delegates the blocks, and a hierarchical AS-SET can only be
created in that one registry, by that ASN's holder, because the
creation is authorised against the LOCAL aut-num object in that
database. I can prove it with my own two ASNs: my AS213481 (RIPE)
cannot anchor a set in the AfriNIC database - there is simply no
aut-num there to authorise it - and my AS329532 (AfriNIC) cannot
anchor one at RIPE, APNIC or ARIN, same reason mirror-imaged. So the
authoritative hierarchical namespaces are disjoint BY CONSTRUCTION,
and the cross-registry collision in your AS-FOO restoration example
(015415) is unconstructible with any name this policy produces - it
only works with the flat legacy names, the exact class this policy
stops minting. Your example demonstrates the disease we are treating
- and I mean that as a genuine compliment, it takes understanding the
problem to construct it.

Now the longer version, for those that want to check my work.

There is two facts this all rests on:

Fact 1: every ASN have exactly one registry, always. IANA delegates
the ASN blocks to one RIR each - my AS329532 sits in AfriNIC's
327680-330751 block, my AS213481 sits in RIPE's 196608-219547 block.
The map ASN => registry is total and single-valued, and it even stays
single-valued under inter-RIR ASN transfers where those are allowed
(the authoritative home moves WITH the ASN, it never has two homes -
and AfriNIC is not even part of the inter-RIR transfer system today,
but that's a different discussion).

Fact 2: hierarchical creation is authorised against the LOCAL aut-num
object. In every authoritative RIR database, to create
ASxxx:AS-SOMETHING you must pass authorisation via the aut-num for
ASxxx in that SAME database (mnt-lower, else mnt-by - per the RIPE
and AfriNIC documentation; APNIC prop-151 says created only by "the
maintainer of the ASN" in the name; ARIN does it via the Org
linkage). And an RIR's authoritative database only carries aut-num
objects for the ASNs that registry itself issued. AfriNIC's DB has
no aut-num AS213481. RIPE's DB has no aut-num AS329532.

So the demonstration, with my own two ASNs:

=> I cannot create AS213481:AS-ANYTHING in the AfriNIC database. The
authorisation check needs aut-num AS213481 in AfriNIC's DB, no such
object exists or can exist there, since it's RIPE-issued. There is no
maintainer chain to authorise against. Creation fails for me - and
for everybody else on earth too.
=> I cannot create AS329532:AS-ANYTHING in the RIPE database, exact
mirror image reason. Same at APNIC, same at ARIN.

Which means: under hierarchical naming the five authoritative
namespaces is disjoint by construction. A hierarchical name can
exist, as an authoritative object, in exactly ONE registry - the one
that issued its leading ASN - and can be created there by exactly ONE
party - that ASN's current holder chain. A cross-registry collision
between two authoritative hierarchical objects with the same name is
not "unlikely", it is impossible. Nobody have to go check anybody
else's namespace, the name itself IS the check. (This is also Jaco's
point in (015396) about source selection - the tooling maps the
leading ASN to its registry and queries only there.)

Now apply that to your (015415) example. Look carefully what carries
that scenario: EVERY step of it requires the name to be flat.

1) The colliding class is the flat class. A hierarchical name cannot
be created in the "other" registry at your step 2 - see above. The
scenario is unconstructible with any name this policy produces, it is
only constructible with the legacy names the policy stops minting.

2) The restored object is grandfathered surface. Clauses 7.8.4/7.8.5
expressly tolerate the existing flat inventory and its exposure,
restoration un-deletes a member of that tolerated class. Its
cross-registry exposure existed every single day that object was
live - the delete/restore round-trip neither creates nor enlarges
it.

3) And your example is anyway a subset of today's standing condition:
without this policy, AS-FOO collisions require no
deletion-and-restoration choreography at all - anyone can create
AS-FOO in any IRR, today, right now, this afternoon. The restoration
edge is a strict subset of the permanent flat-name exposure, and the
only mechanism on the table that ever SHRINKS that exposure is this
proposal, under which the flat class ages out and your scenario's raw
material disappears with it.

So your example does not show the exception "recreating the very
collision this proposal is intended to prevent". It shows, in full
working detail, the problem that exists exactly as long as flat names
can exist. You have, maybe without intending to, written the
strongest argument FOR the proposal this list has seen in two weeks -
it just runs in reverse.

To be complete and honest about the edges: yes, the open registries
and mirrors (RADB and friends) accept objects on their own terms,
including names rooted in ASNs the submitter doesn't hold - that is
true today, unaffected by any RIR's policy, governed by those
operators, and it's a tooling source-selection matter which the ASN
=> registry map above makes deterministic for the authoritative data.
And yes, AfriNIC-side enforcement of the local-aut-num check is
exactly the implementation semantics Taye asked to have pinned in
(015401), which I've already supported recording as staff
implementation guidance in (015404).

So Tshepo - you see the problem, that much is clear from how well you
described it. The flat namespace is the only place your scenario can
happen, and every day the flat class shrinks, your scenario shrinks
with it. That shrinking only starts when this policy is adopted. I'd
genuinely welcome you on the side of fixing the disease you've just
diagnosed so well.

Regards,
Hendrik Visage (AS329532; also AS213481)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260729/79f3c671/attachment.html>