<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>Since it's in the hierarchy of ASxxx any cleanup will plainly
affect ASxxx either directly or indirectly, providing them
incentive to fix it.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>That said - whilst I'm sure AS transfers and deletions happen, I
do not think they're a frequent occurrence.</p>
<p>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.</p>
<p>Kind regards,<br>
Jaco</p>
<div class="moz-cite-prefix">On 2026/07/27 11:55, Tshepo Masuku
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR04MB5993BB2544C57D696C134B26CACC2@DB7PR04MB5993.eurprd04.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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 <a class="moz-txt-link-rfc2396E" href="mailto:jaco@uls.co.za"><jaco@uls.co.za></a><br>
<b>Sent:</b> Monday, July 27, 2026 11:23:30 am<br>
<b>To:</b> Tshepo Masuku <a class="moz-txt-link-rfc2396E" href="mailto:TshepoMasuku26@hotmail.com"><TshepoMasuku26@hotmail.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:rpd@afrinic.net">rpd@afrinic.net</a> <a class="moz-txt-link-rfc2396E" href="mailto:rpd@afrinic.net"><rpd@afrinic.net></a>;
<a class="moz-txt-link-abbreviated" href="mailto:pdwg-chairs@afrinic.net">pdwg-chairs@afrinic.net</a> <a class="moz-txt-link-rfc2396E" href="mailto:pdwg-chairs@afrinic.net"><pdwg-chairs@afrinic.net></a><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 moz-txt-link-freetext"
moz-do-not-send="true">RPD@afrinic.net</a>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd"
class="moz-txt-link-freetext" moz-do-not-send="true">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</div></pre>
</blockquote>
<br>
</div>
</blockquote>
</body>
</html>