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

[Jaco Kroon]

Hi,

I believe it does, since the ASxxx:: "namespace" belongs to the AS, the 
owner of the AS should be perfectly able to clean it up, or at a minimum 
be "plainly able to request AFRINIC" to perform same.

Since it's in the hierarchy of ASxxx any cleanup will plainly affect 
ASxxx either directly or indirectly, providing them incentive to fix it.

As things stand currently, arbitrary parties are permitted to include 
any AS or AS-SET into their own anyway, so your concern is valid, but 
not directly related to the ongoing policy proposal. You're now starting 
to understand the bigger picture (I think) towards which this proposal 
is but a small step towards resolving.  We cannot, and should not aim 
to, build a castle reaching the sky without first building the 
foundations.  This is foundation building.

AS transfer as I understand tranfers te AS object, along with all 
related objects, thus ownership gets moved to the new AS that has 
operational authority over the AS.

In the case of deletion (return to the RIR) the objects would currently 
dangle, this would allow them to be deleted - which would definitely 
create a dangling reference, but prevent that object from being 
high-jacked by another party, thus already improving even that 
scenario.  Given the prevalence of AS numbers I highly doubt returned AS 
numbers would be re-used any time soon.  And if they are, the new owner 
should receive ownership of any undeleted but related objects, allowing 
them to clean things up.

Remember:  NOTHING currently stops anyone from referencing any one 
else's AS-SET objects already - so recreating an object that's 
referenced, or having someone point to your existing object is thus from 
an operational perspective the same issue.

That said - whilst I'm sure AS transfers and deletions happen, I do not 
think they're a frequent occurrence.

Also, none of this is the object of the policy change.  Should policies 
be put into place to deal with that?  Most definitely, but we cannot 
build that sky-scraper in one step, we build it in multiple smaller 
steps, so that we can break down and retract/take steps back if we've 
found to have made a mistake, rather than building everything in one go 
and then having it crash down on us.  Floor by floor.  Brick by brick.  
Small steps in the right direction, not leaps and bounds.

Kind regards,
Jaco

On 2026/07/27 11:55, Tshepo Masuku wrote:
> Dear Jaco,
>
> Thank you, but your answer introduces a further problem.
>
> You say the policy will allow AFRINIC or a future ASN holder to “clean 
> up” hierarchical objects. That mechanism does not appear in the 
> policy. The text controls the name only when an object is created. It 
> does not define what happens to child AS-SETs when the leading ASN is 
> returned, transferred, reassigned, suspended, or deleted.
>
> This matters because cleanup can itself affect running networks. If 
> AS12345:AS-FOO is referenced by other objects or operator 
> configurations, deleting it creates a dangling reference. If a later 
> holder of AS12345 recreates the same name, an unchanged reference may 
> suddenly resolve to completely different data.
>
> The new holder’s ability to “clean up” the previous holder’s namespace 
> is therefore not automatically a protection. It is a transfer of 
> control whose consequences the proposal does not define.
>
> Before adoption, the policy should state whether child names remain 
> permanently reserved, whether they transfer with the ASN, whether 
> existing objects are frozen pending re-authentication, how relying 
> operators are notified, and what conditions apply to restoration or reuse.
>
> The undefined exception in section 7.8.7 makes this more serious. If 
> AFRINIC may grant exceptions “where necessary,” the supposedly closed 
> namespace is not deterministic. The proposal does not say what 
> qualifies as necessary, who decides, or whether an exception may 
> permit another non-hierarchical object.
>
> A mandatory rule should define valid state transitions rather than 
> leave them to future registry discretion. The proposal currently 
> promises attribution at creation while leaving later control and name 
> reuse unresolved.
>
> For that reason, my concern has not been addressed, and I remain 
> opposed to the proposal as written.
>
> Regards,
> Tshepo
>
>
> ------------------------------------------------------------------------
> *From:* Jaco Kroon <jaco at uls.co.za>
> *Sent:* Monday, July 27, 2026 11:23:30 am
> *To:* Tshepo Masuku <TshepoMasuku26 at hotmail.com>; rpd at afrinic.net 
> <rpd at afrinic.net>; pdwg-chairs at afrinic.net <pdwg-chairs at afrinic.net>
> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical 
> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>
> 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/ae836acd/attachment-0001.html>