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

[Hendrik Visage]

Dear Asamkele,
The distinction you draw doesn't survive contact with how the objects 
actually work: an AS-SET name is not merely a label, it is the 
authorization anchor for the object. Under RFC 2622 hierarchical naming, 
the leading AS number binds the set to a resource the registry has 
already uniquely assigned, so only the maintainer of that ASN can create 
or modify it — proof of control, which you agree is core registry 
function, is derived directly from the name. A flat name has no such 
binding, which means the registry is accepting objects it cannot 
attribute to any resource holder; that is not a data-quality preference, 
it is an authorization gap in the registry's own database. This is also 
why voluntary naming cannot solve it: hierarchy protects you only if the 
flat namespace is closed, because as long as anyone can create 
AS-EXAMPLE, your careful use of AS65000:AS-EXAMPLE does nothing to stop 
a third party from registering a colliding or shadowing set that expands 
into your customer cone. The harm is concrete and regional in effect 
regardless of where the query originates — bgpq4, IRRToolSet and 
similar expand AS-SET names, so an ambiguous name yields a prefix-list 
that either admits prefixes the operator never authorized or omits ones 
it did, and the resulting leak or blackhole lands on AFRINIC networks. 
Better tooling and warnings cannot close this, because the ambiguity 
exists in the data the tooling consumes, not in the tooling itself. As 
for scope: rejecting the creation of unauthorizable objects is the same 
function the registry already performs when it refuses an 
unauthenticated route object — it is the existing mandate applied 
consistently, not a new one, and applying it prospectively to a single 
object type is the least restrictive form in which it can achieve the 
outcome at all.
Regards

---
Hendrik Visage
Director/Owner
HeViS.Co Systems t/a Envisage Cloud Solutions
hvisage at hevis.co.za
GSM/SMS/Signal: +27-84-612-5345
InstantMessenger: https://t.me/hvisage

On 18 Jul 2026, at 21:05, Asamkele Menzeleli wrote:

> Dear Hendrik,
>
> I disagree with your characterization.
>
> A collision between two AS-SET names is not the same as a failure of
> Internet number-resource uniqueness. The uniqueness function of the
> registry concerns ASNs, prefixes, proof of control and accurate
> registration of those resources. An AS-SET is an operational 
> routing-policy
> object. Confusing the naming convention of that object with the 
> uniqueness
> of the underlying number resource expands the meaning of 
> “uniqueness” far
> beyond its proper technical scope.
>
> The fact that two operators may choose the same flat label may justify
> better tooling, clearer warnings, stronger validation or voluntary
> hierarchical naming. It does not automatically justify a mandatory 
> policy
> rule.
>
> That distinction is precisely the concern I raised. Institutional 
> authority
> often expands by redefining a useful administrative preference as a
> technical necessity. Once every data-quality issue is described as a
> uniqueness failure, there is effectively no limit to what may be 
> brought
> into mandatory registry policy.
>
> The proposal’s limited scope does not answer that concern. A new
> enforcement power does not cease to be enforcement merely because it
> applies prospectively or begins with one object type. The correct test 
> is
> whether the rule is indispensable to preserving the operation of 
> running
> networks, and whether a less restrictive mechanism cannot achieve the 
> same
> outcome.
>
> You also repeat that the other four RIRs have implemented hierarchical
> naming. That demonstrates institutional adoption elsewhere. It does 
> not
> demonstrate that AFRINIC operators have authorized the same rule, that
> actual routing failures in this region require it, or that voluntary 
> and
> technical alternatives are inadequate. Four registries making the same
> choice is not a substitute for evidence.
>
> A registry should record operational reality accurately and provide
> operators with tools to manage routing information safely. It should 
> not
> turn every preferred convention into mandatory governance merely 
> because
> uniformity looks tidy from the registry side.
>
> My objection therefore remains. The proposal has not shown that 
> compulsory
> hierarchical naming is necessary to protect number-resource 
> uniqueness, nor
> that the registry should extend its mandatory policy authority into 
> this
> area.
>
> Regards,
> Asamkele Menzeleli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/6b7c005c/attachment.html>