<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<div class="moz-cite-prefix">On 2026/07/27 08:30, Tshepo Masuku
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR04MB59937236E9ADBEE9F910D247CACC2@DB7PR04MB5993.eurprd04.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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 type="cite"
cite="mid:DB7PR04MB59937236E9ADBEE9F910D247CACC2@DB7PR04MB5993.eurprd04.prod.outlook.com">
<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 type="cite"
cite="mid:DB7PR04MB59937236E9ADBEE9F910D247CACC2@DB7PR04MB5993.eurprd04.prod.outlook.com">
<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 type="cite"
cite="mid:DB7PR04MB59937236E9ADBEE9F910D247CACC2@DB7PR04MB5993.eurprd04.prod.outlook.com">
<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 type="cite"
cite="mid:DB7PR04MB59937236E9ADBEE9F910D247CACC2@DB7PR04MB5993.eurprd04.prod.outlook.com">
<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 type="cite"
cite="mid:DB7PR04MB59937236E9ADBEE9F910D247CACC2@DB7PR04MB5993.eurprd04.prod.outlook.com">
<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 type="cite"
cite="mid:DB7PR04MB59937236E9ADBEE9F910D247CACC2@DB7PR04MB5993.eurprd04.prod.outlook.com">
<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 wrap="" class="moz-quote-pre">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
</body>
</html>