<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
Dear Jaco,</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
Thank you, but your answer introduces a further problem.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
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.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
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.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
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.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
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.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
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.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
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.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
For that reason, my concern has not been addressed, and I remain opposed to the proposal as written.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
Regards,</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
Tshepo</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<div dir="auto" id="mail-editor-reference-message-container"><br>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg" style="font-size: 11pt;" dir="auto"><b>From:</b> Jaco Kroon <jaco@uls.co.za><br>
<b>Sent:</b> Monday, July 27, 2026 11:23:30 am<br>
<b>To:</b> Tshepo Masuku <TshepoMasuku26@hotmail.com>; rpd@afrinic.net <rpd@afrinic.net>; pdwg-chairs@afrinic.net <pdwg-chairs@afrinic.net><br>
<b>Subject:</b> Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
</div>
<br>
<p>Hi,</p>
<div class="moz-cite-prefix" dir="auto">On 2026/07/27 08:30, Tshepo Masuku wrote:</div>
<blockquote>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Dear PDWG,</span></p>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I have a separate concern arising from the Impact Assessment.</span></p>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">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.</span></p>
</blockquote>
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.
<blockquote>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">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 <code>AS12345:AS-CUSTOMERS</code>, 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.</span></p>
</blockquote>
<p>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.</p>
<blockquote>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">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.</span></p>
</blockquote>
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.
<blockquote>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">These are not questions about whether AS-SET membership is correct. They concern whether the proposal’s claimed
attribution remains technically true after creation.</span></p>
</blockquote>
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.
<blockquote>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">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.</span></p>
</blockquote>
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.
<blockquote>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">A creation-time check is not enough for a claim of continuing authorisation.</span></p>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">For that reason, I object to the proposal as presently written.</span></p>
</blockquote>
<p>Please refer above and advise if that addresses your concerns - I believe it should.<br>
<br>
Kind regards,<br>
Jaco</p>
<p><br>
</p>
<blockquote>
<p><span style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Regards,<br>
Tshepo</span></p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre><div class="moz-quote-pre" dir="auto">_______________________________________________
RPD mailing list
<a href="mailto:RPD@afrinic.net" class="moz-txt-link-abbreviated">RPD@afrinic.net</a>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="moz-txt-link-freetext">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</div></pre>
</blockquote>
<br>
</div>
</body>
</html>