<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>I'll happily defer to the RFC. This doesn't in my mind really
change anything.<br>
<br>
Kind regards,<br>
Jaco</p>
<div class="moz-cite-prefix">On 2026/07/27 13:11, Tshepo Masuku
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR04MB5993BFD5443B6A876BA6072BCACC2@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);">
Based on your explanation, I think this raises a separate
concern about the actual authorisation chain.</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 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. </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);">
That means control can be delegated through the hierarchy.</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);">
Consider:</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);">
AS12345:AS-CUSTOMERS:AS-EU</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);">
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.</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);">
There are two possible outcomes, and both require policy
clarity:</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);">
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.</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);">
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.</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 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.</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 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.</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 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.</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 common rule should define those state transitions in
advance. It should not leave AFRINIC to invent them later.</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 objection remains.</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"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"
style="font-size:11pt" color="#000000"><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, 27 July 2026 12:46:55<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)</font>
<div> </div>
</div>
<div>
<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="x_moz-cite-prefix">On 2026/07/27 11:55, Tshepo
Masuku wrote:<br>
</div>
<blockquote type="cite">
<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="x_mail-editor-reference-message-container"><br>
<hr style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="auto" style="font-size:11pt"><b>From:</b>
Jaco Kroon
<a class="x_moz-txt-link-rfc2396E"
href="mailto:jaco@uls.co.za" moz-do-not-send="true"><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="x_moz-txt-link-rfc2396E"
href="mailto:TshepoMasuku26@hotmail.com"
moz-do-not-send="true">
<TshepoMasuku26@hotmail.com></a>; <a
class="x_moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:rpd@afrinic.net" moz-do-not-send="true">
rpd@afrinic.net</a> <a class="x_moz-txt-link-rfc2396E"
href="mailto:rpd@afrinic.net" moz-do-not-send="true">
<rpd@afrinic.net></a>; <a
class="x_moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:pdwg-chairs@afrinic.net"
moz-do-not-send="true">
pdwg-chairs@afrinic.net</a> <a
class="x_moz-txt-link-rfc2396E"
href="mailto:pdwg-chairs@afrinic.net"
moz-do-not-send="true">
<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="x_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="x_moz-mime-attachment-header"></fieldset>
<pre><div class="x_moz-quote-pre" dir="auto">_______________________________________________
RPD mailing list
<a href="mailto:RPD@afrinic.net"
class="x_moz-txt-link-abbreviated x_moz-txt-link-freetext moz-txt-link-freetext"
moz-do-not-send="true">RPD@afrinic.net</a>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd"
class="x_moz-txt-link-freetext moz-txt-link-freetext"
moz-do-not-send="true">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</div></pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>