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

[Jaco Kroon]

Hi,

On 2026/07/27 08:50, Nonjabulo Sphilile wrote:
> Dear PDWG,
>
> Kindly allow me to raise a technical concern on my side that further 
> supports my objection to the proposed policy.
>
> The proposal controls the name of a newly created AS-SET, but not the 
> AS-SET names referenced inside it. RPSL allows the members: attribute 
> of an AS-SET to contain other AS-SET names. Those referenced sets are 
> then included when the object is expanded, with nested inclusion 
> operating recursively.
>
> A new object such as:
>
> AS65000:AS-CUSTOMERS
>
> could therefore still contain:
>
> members: AS-EXAMPLE
>
> If AS-EXAMPLE exists with different contents in multiple IRR sources, 
> the top-level object may be hierarchical while its dependency chain 
> remains ambiguous. The same filter-generation problem can therefore 
> reappear during recursive expansion.

Correct.  But this will stop new such top-level cases from creating 
dangere, and hopefully AS65000 will deploy as RIR::AS-EXAMPLE, locking 
it down to the specific instance.  This policy will stop re-creation of 
RIR::AS-EXAMPLE once it's deleted, thus eliminating the re-use risk as 
well.  As such, whilst it does not close all possible attack vectors 
from day one, it stops them from being created going forward.  Getting 
existing parties to migrate is an operational matter and migration 
should be encouraged.  It should not stop us from blocking the problem 
going forward.

>
> This is not the earlier argument about whether individual members are 
> factually correct. It is a narrower issue of resolution integrity: the 
> proposal secures the first object name but does not secure every 
> referenced name that tooling must resolve.
Agreed - but it stops targets from being created going forward.
>
> The Impact Assessment expressly places resolver behaviour outside 
> scope, yet the operational justification depends on the results 
> produced by resolvers and filter-generation tools. That gap needs to 
> be addressed.
So narrowing a gap that already exist, and which will be closed over 
time with this policy without creating operational issues right now is 
not sufficient?

What would you propose?  The only possible improvement I can imagine to 
this policy here it to prevent plain AS-NAMES from being added as 
members, and that they need to be at least RIR::AS-NAME - which is 
something I can consider getting behind, but I believe adjusting the 
content restriction, rather than naming thereof, could be considered a 
separate policy?  If you'd like to propose wording to add this I'm sure 
it would be considered positively but I'm not sure this is sufficient 
reason to not progress on the existing proposal since it's already 
creating a huge improvement over existing status quo. Further, I suspect 
implementing such a restriction would be considerably harder on the 
whois side compared to this policy, and as such I for one would at least 
see *some improvement* soonest possible, compared to having to wait for 
a perfect policy that would take longer to deploy - I assume we can 
agree on that much at least?
>
> Before adoption, the proposal should clarify whether newly created 
> hierarchical AS-SETs may reference grandfathered flat AS-SETs. If they 
> may, the policy should define how ambiguity is detected and handled 
> throughout the dependency chain. If they may not, the operational 
> impact and migration requirements should be assessed and documented.
I think this applies not only to newly created hierarchical AS-SET 
objects, but to ALL AS-SET objects as they get updated, or newly 
created, and for this reason alone I would suggest that we've got 
concensus that restricting newly created objects to be hierarchical is a 
step in the right direction, and that we can address the membership 
status separately such that all objects going forward, whether updated 
or newly created may no longer reference other AS-SET objects by name 
only and must be of the format RIR::AS-NAME or ASxxx::AS-NAME, and I 
believe that's a separate change that deserves it's own operational 
assessment.
>
> A creation-time naming restriction should not be credited with 
> protecting filter generation until the complete expansion path has 
> been tested.
It does avoid creating further problem cases, it does not stop existing 
problems, or existing objects that creates problems, no one has claimed 
it does.  It does stop people from creating new objects that can be 
targeted.  Kinda like deprecating older ciphers in encryption protocols 
prior to banning them.

Kind regards,
Jaco