Search RPD Archives
[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
Jaco Kroon
jaco at uls.co.za
Mon Jul 27 11:31:54 UTC 2026
Hi,
I'll happily defer to the RFC. This doesn't in my mind really change
anything.
Kind regards,
Jaco
On 2026/07/27 13:11, Tshepo Masuku wrote:
> Dear Jaco,
>
> Based on your explanation, I think this raises a separate concern
> about the actual authorisation chain.
>
> The statement that the entire ASxxx: namespace simply belongs to the
> current ASN holder is incomplete. Under RFC 2622, the holder of the
> ASN controls creation of the first-level set, but deeper objects are
> created by the maintainer of the immediate parent. For example, the
> maintainer of AS12345:AS-CUSTOMERS, rather than necessarily the ASN
> maintainer, controls creation beneath that object.
>
> That means control can be delegated through the hierarchy.
>
> Consider:
>
> AS12345:AS-CUSTOMERS:AS-EU
>
> If the parent set is maintained by a customer, contractor, subsidiary,
> or another operational team, the proposal does not explain whether the
> current ASN holder may override that maintainer, delete the
> descendant, or automatically recover control after an ASN transfer.
>
> There are two possible outcomes, and both require policy clarity:
>
> If all descendants automatically move to the new ASN holder, AFRINIC
> may be overriding valid delegated maintainers and changing control of
> routing-policy objects without their approval.
>
> If descendants do not move automatically, then the new ASN holder is
> not necessarily “plainly able” to clean them up, contrary to the
> benefit you describe.
>
> The proposal defines naming syntax at creation, but it does not define
> the authorisation graph, delegation rules, revocation process, or how
> control of nested objects changes. Saying that an operator could
> simply ask AFRINIC to intervene replaces a deterministic rule with
> staff discretion.
>
> This is not about whether the data are stale or whether the proposal
> fixes every problem. It is about whether the claimed proof of control
> remains verifiable at every level of the hierarchy.
>
> Before this proceeds, the policy should clearly state who controls
> each descendant, whether delegation is permitted, how it is withdrawn,
> and what happens to delegated objects when the leading ASN changes holder.
>
> A mandatory common rule should define those state transitions in
> advance. It should not leave AFRINIC to invent them later.
>
> For that reason, my objection remains.
>
> Regards,
> Tshepo
>
>
> ------------------------------------------------------------------------
> *From:* Jaco Kroon <jaco at uls.co.za>
> *Sent:* Monday, 27 July 2026 12:46:55
> *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,
>
> 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> <mailto:jaco at uls.co.za>
>> *Sent:* Monday, July 27, 2026 11:23:30 am
>> *To:* Tshepo Masuku <TshepoMasuku26 at hotmail.com>
>> <mailto:TshepoMasuku26 at hotmail.com>; rpd at afrinic.net
>> <mailto:rpd at afrinic.net> <rpd at afrinic.net> <mailto:rpd at afrinic.net>;
>> pdwg-chairs at afrinic.net <mailto:pdwg-chairs at afrinic.net>
>> <pdwg-chairs at afrinic.net> <mailto: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 <mailto:RPD at afrinic.net>
>> https://lists.afrinic.net/mailman/listinfo/rpd
>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260727/f9b99d8e/attachment-0001.html>
More information about the RPD
mailing list