[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:30, Tshepo Masuku wrote:
>
> Dear PDWG,
>
> I have a separate concern arising from the Impact Assessment.
>
> The proposal validates an AS-SET only when it is created, but the 
> assessment presents the hierarchical name as a continuing link to the 
> responsible ASN operator. That link may not remain accurate throughout 
> the object’s lifetime.
>
We've established that the policy is about avoiding inter-RIR collisions 
and attesting to who (which AS) published the object. The validity of 
the data is a whole different ballgame and must be addressed 
separately.  I have had some ideas on this but my mindset was mostly 
around how tooling can use current IRR data to validate the correctness 
of AS-SET data - nothing that remotely worked has popped up, but as 
mentioned that's independent of this policy.
>
> For example, what happens if the leading ASN changes holder, is 
> returned, is reassigned, or receives a new maintainer? Does the former 
> operator retain control of |AS12345:AS-CUSTOMERS|, does the new holder 
> inherit it, or is the object suspended? The policy also permits 
> existing objects to be edited, but does not say whether changes to 
> maintainers or parent objects trigger renewed authorisation checks.
>
The AS remains, unless the AS gets shut, in which case the objects can 
either remain for some time (currently they linger indefinitely, since 
we have no way to clean them up now either anyway).  The policy is thus 
still a move in the right direction as it will enable us to clean up in 
case an AS gets cleaned up. Stale data again IMHO is a different 
independent problem that should be addressed as such.

> Deletion and recreation create a similar problem. If a hierarchical 
> name is deleted and later recreated, existing filters or references 
> may silently resolve to a different object using the same name. The 
> proposal provides no tombstone, reservation, restoration period, or 
> conflict-state mechanism.
>
I don't think this is relevant any more, in part due to the same AS that 
would need to recreate, we're already much better off here too, in that 
for example if some entity references AS-FOO, then that gets deleted, an 
attacker can now currently create AS-FOO.  With this policy that would 
be prohibited, and if it was ASxxx:AS-FOO then the attacker would need 
to be authoritive for ASxxx to recreate the object, so again we gain 
some level of protection.
>
> These are not questions about whether AS-SET membership is correct. 
> They concern whether the proposal’s claimed attribution remains 
> technically true after creation.
>
Any new owner of the same ASxxx would be in a position now to clean that 
up, compared to previous non-hierarchical objects which would (and 
continue to) linger indefinitely.  So this is still an improvement over 
current situation even in those cases.
>
> Before adoption, the policy should define deterministic rules for 
> changes of ASN control, parent-child delegation, maintainer 
> replacement, deletion, restoration, and name reuse. Otherwise, AFRINIC 
> may enforce a hierarchical label while the label no longer identifies 
> the operator actually controlling the object.
>
Whomever manages the parent ASxxx (first ASxxx in the sequence) in the 
set is the responsible party, so I don't see how this is relevant.
>
> A creation-time check is not enough for a claim of continuing 
> authorisation.
>
> For that reason, I object to the proposal as presently written.
>
Please refer above and advise if that addresses your concerns - I 
believe it should.

Kind regards,
Jaco


> Regards,
> Tshepo
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260727/70adcc55/attachment.html>