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

[Jaco Kroon]

Hi,

On 2026/07/27 12:23, Nonjabulo Sphilile wrote:
> Dear Jaco,
>
> Thank you for engaging with the concern. Your reply brings up a 
> different problem that the Impact Assessment does not address.
>
> The policy has a future implementation date, while every flat AS-SET 
> created before that date will remain valid and editable. This creates 
> a race-to-grandfather risk. A database user could register desirable 
> or confusing flat names during the transition, leave them empty or 
> harmless, and populate or alter them after enforcement begins.

If you want to pre-emptively aim a shotgun at your own foot there is 
nothing I or anyone else can do to stop you.  That shotgun would 
however, now be aimed at YOUR foot, not mine.  Good luck.

>
> The registry would then reject new flat names, but those 
> pre-positioned objects would remain active indefinitely. In other 
> words, the proposal does not necessarily stop new harmful cases going 
> forward. It stops only one method of creating them after the cut-off 
> date. New risk could still be introduced through later changes to 
> grandfathered objects.
No one said it does stop all of them, but it will over time close the 
gap further as those objects are no longer used and (ideally) gets deleted.
>
> The source-qualified membership restriction you suggest is not part of 
> this proposal. A possible future policy cannot be counted as 
> protection delivered by the current text.
As per my previously email, this policy is still a step (building block) 
in the right direction.  We build sky scrapers floor by floor and brick 
by brick.  This is but one small brick.
>
> At minimum, the proposal would need an immediate reservation or 
> cut-off mechanism, an audit of flat objects created during the 
> implementation period, and clear rules governing material changes to 
> grandfathered objects. The operational impact of those measures has 
> not been assessed.

No, because existing object may still be valid for a very long time to 
come.  For now we're just aiming to stop creation of new ones.  All 
concerns that has been raised is part of the bigger sky-scraper picture 
and needs to be addressed, but by separate bricks.

>
> Grandfathered does not mean frozen. Until the active legacy surface 
> and the transition-period incentive are addressed, I do not believe 
> the claim that the policy prevents new problem cases has been established.

The problem is what does grandfathered mean?  We ourselves have 
AFRINIC::AS-ULS - which we no longer advertise - but I've found at least 
one peer still uses that, it simply references AS3287767:AS-ULS it's 
only member now, which is the best we can do for now.  We can but HOPE 
that the relevant peer restricts to AFRINIC::AS-ULS rather than AS-ULS.  
Does it mean it's a definite attack vector?  No, as per all things, it 
depends on the specific USE CASE.  Can someone collide with the flat 
name from another RIR?  Absolutely, but this may or may not be a problem 
depending on the use-case.

Who's allowed to reference my object, or include my AS into their own 
sets is a discussion for a different policy which does need to be 
addressed, but that's separate from this specific brick.

Kind regards,
Jaco