<div dir="ltr"><div dir="ltr">Dear PDWG,<br>I have reviewed the Impact Assessment. I accept the narrow point that ASN-anchored naming can reduce future flat-name collisions for newly created AFRINIC AS-SETs.<br>My objection remains because the assessment exposes several unresolved implementation issues.<br>First, section 7.8.7 permits exceptions “where necessary” but defines no criteria, decision-maker, review mechanism, or limit on what may be excepted. Staff then refers to an exception in 7.8.6 involving restoration of deleted objects, although the supplied 7.8.6 concerns editing existing objects. The assessment nevertheless records no ambiguity.<br>This needs clarification before implementation. If exceptions allow future flat-name creation, the namespace is not prospectively closed. If the intention is only to restore accidentally deleted legacy objects, the text should define the recovery period, proof of prior control, eligible maintainer, audit record, and whether the old name remains reserved after deletion.<br>Second, the assessment says that only the leading ASN operator can create names beginning with that ASN. RFC 2622 appears more specific: deeper namespace control follows the immediate parent object. The policy should therefore state whether nested objects are authorised by the leading ASN maintainer or the parent AS-SET maintainer, whether the parent must already exist, and whether that authority may be delegated.<br>Third, the claimed benefit should be stated accurately. Existing flat objects remain untouched, and mirroring and resolver behaviour are expressly outside scope. The proposal may reduce future AFRINIC-originated collisions, but it does not resolve existing cross-IRR ambiguity or establish global uniqueness across all resolver contexts.<br>Finally, the assessment provides no operational baseline, warning phase, test vectors, measurable success criteria, rollback plan, or scheduled review. Before mandatory rejection is enabled, AFRINIC should run the validation in warning-only mode, publish the number of affected creation attempts and automation failures, and provide a complete implementation and recovery plan.<br>These are not demands for a perfect solution. They are necessary questions about the precise rule AFRINIC will enforce and the scope of the result it claims.<br>Until the exception, authorisation chain, implementation method, and review criteria are clearly resolved, I remain opposed to advancing the proposal as written.<br><br>Regards,<br>Thulisile</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2026 at 1:51 PM <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send RPD mailing list submissions to<br>
<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rpd-request@afrinic.net" target="_blank">rpd-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rpd-owner@afrinic.net" target="_blank">rpd-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of RPD digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 27 Jul 2026 11:50:00 +0000<br>
From: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank">TshepoMasuku26@hotmail.com</a>><br>
To: Jaco Kroon <<a href="mailto:jaco@uls.co.za" target="_blank">jaco@uls.co.za</a>>, "<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>" <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>>,<br>
"<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>" <<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>><br>
Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
Message-ID:<br>
<<a href="mailto:DB7PR04MB5993E4EA2B38B28EDF0F96BACACC2@DB7PR04MB5993.eurprd04.prod.outlook.com" target="_blank">DB7PR04MB5993E4EA2B38B28EDF0F96BACACC2@DB7PR04MB5993.eurprd04.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
<br>
Dear Jaco,<br>
<br>
It changes the issue materially.<br>
<br>
Your earlier argument depended on the current ASN holder controlling the entire ASxxx: namespace. If RFC 2622 gives control of deeper names to the immediate parent maintainer, then authority may be delegated and may not automatically follow the ASN during transfer or reassignment.<br>
<br>
The policy text and Impact Assessment should therefore define the actual authorisation chain, rather than leave AFRINIC to interpret it after adoption. A mandatory rule cannot claim deterministic proof of control while its control model remains unspecified.<br>
<br>
Until that is clarified, my concern remains and I continue to object.<br>
<br>
Regards,<br>
Tshepo<br>
<br>
________________________________<br>
From: Jaco Kroon <<a href="mailto:jaco@uls.co.za" target="_blank">jaco@uls.co.za</a>><br>
Sent: Monday, 27 July 2026 13:31:54<br>
To: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank">TshepoMasuku26@hotmail.com</a>>; <a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a> <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>>; <a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a> <<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>><br>
Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
<br>
<br>
Hi,<br>
<br>
I'll happily defer to the RFC. This doesn't in my mind really change anything.<br>
<br>
Kind regards,<br>
Jaco<br>
<br>
On 2026/07/27 13:11, Tshepo Masuku wrote:<br>
Dear Jaco,<br>
<br>
Based on your explanation, I think this raises a separate concern about the actual authorisation chain.<br>
<br>
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.<br>
<br>
That means control can be delegated through the hierarchy.<br>
<br>
Consider:<br>
<br>
AS12345:AS-CUSTOMERS:AS-EU<br>
<br>
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.<br>
<br>
There are two possible outcomes, and both require policy clarity:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
A mandatory common rule should define those state transitions in advance. It should not leave AFRINIC to invent them later.<br>
<br>
For that reason, my objection remains.<br>
<br>
Regards,<br>
Tshepo<br>
<br>
<br>
________________________________<br>
From: Jaco Kroon <<a href="mailto:jaco@uls.co.za" target="_blank">jaco@uls.co.za</a>><mailto:<a href="mailto:jaco@uls.co.za" target="_blank">jaco@uls.co.za</a>><br>
Sent: Monday, 27 July 2026 12:46:55<br>
To: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank">TshepoMasuku26@hotmail.com</a>><mailto:<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank">TshepoMasuku26@hotmail.com</a>>; <a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a><mailto:<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>> <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><mailto:<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>>; <a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a><mailto:<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>> <<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>><mailto:<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>><br>
Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
<br>
<br>
Hi,<br>
<br>
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.<br>
<br>
Since it's in the hierarchy of ASxxx any cleanup will plainly affect ASxxx either directly or indirectly, providing them incentive to fix it.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
That said - whilst I'm sure AS transfers and deletions happen, I do not think they're a frequent occurrence.<br>
<br>
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.<br>
<br>
Kind regards,<br>
Jaco<br>
<br>
On 2026/07/27 11:55, Tshepo Masuku wrote:<br>
Dear Jaco,<br>
<br>
Thank you, but your answer introduces a further problem.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
For that reason, my concern has not been addressed, and I remain opposed to the proposal as written.<br>
<br>
Regards,<br>
Tshepo<br>
<br>
<br>
________________________________<br>
From: Jaco Kroon <<a href="mailto:jaco@uls.co.za" target="_blank">jaco@uls.co.za</a>><mailto:<a href="mailto:jaco@uls.co.za" target="_blank">jaco@uls.co.za</a>><br>
Sent: Monday, July 27, 2026 11:23:30 am<br>
To: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank">TshepoMasuku26@hotmail.com</a>><mailto:<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank">TshepoMasuku26@hotmail.com</a>>; <a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a><mailto:<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>> <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><mailto:<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>>; <a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a><mailto:<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>> <<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>><mailto:<a href="mailto:pdwg-chairs@afrinic.net" target="_blank">pdwg-chairs@afrinic.net</a>><br>
Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
<br>
<br>
Hi,<br>
<br>
On 2026/07/27 08:30, Tshepo Masuku wrote:<br>
<br>
Dear PDWG,<br>
<br>
I have a separate concern arising from the Impact Assessment.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
These are not questions about whether AS-SET membership is correct. They concern whether the proposal?s claimed attribution remains technically true after creation.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
A creation-time check is not enough for a claim of continuing authorisation.<br>
<br>
For that reason, I object to the proposal as presently written.<br>
<br>
Please refer above and advise if that addresses your concerns - I believe it should.<br>
<br>
Kind regards,<br>
Jaco<br>
<br>
<br>
Regards,<br>
Tshepo<br>
<br>
<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><mailto:<a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a>><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260727/cb12d92b/attachment.html" rel="noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260727/cb12d92b/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 222, Issue 212<br>
*************************************<br>
</blockquote></div></div>