<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p><br>
</p>
<p>Sorry for top-posting, but it seems exactly me cares about most
of that anyway.</p>
<p><br>
</p>
<p>It's a risk. We're aware of it. If you want an object restored
and your not happy with the outcome, escalate the matter.</p>
<p><br>
</p>
<p>If you're unhappy with the wording, propose alternative wording
or live with it. It's that simple.</p>
<p><br>
</p>
<p>The inter-RIR risk is currently also there, so irrelevant, plus,
I think Afrinic is the only RIR that still allows new "flat"
AS-SET objects to be created. And someone pointed out to be today
RADB, but I haven't confirmed that.</p>
<p><br>
</p>
<p>That also reduces your risk of creating exactly the collision
that we intend to prevent because those collisions would exist
currently (as in before the effective date where no more flat
AS-SET objects can be created)!</p>
<p><br>
</p>
<p>If you can propose better wording, and with enough foresight to
deal with all possible future restore situations in a sensible way
I'm sure James would happily reconsider again. But I doubt that's
possible bringing us back to even with an extremely lenient, and
specifically vague motivation for restore we're still
significantly better of than what we are today.</p>
<p><br>
</p>
<p>Kind regards,<br>
Jaco</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2026/07/29 17:11, Tshepo Masuku
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR04MB5993CCA0CDBE8B92F146F0A7CACA2@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);">
<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);">
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 for explaining your view. However, your concession
identifies the problem: if one staff member may approve a
restoration and another may reject the same request, the rule is
not deterministic. Whether we call that vague or ambiguous, an
operator cannot know the outcome from the policy text.</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 is also a specific inter-RIR risk. A flat AS-SET may be
deleted from AFRINIC and the same name may then be created in
another authoritative IRR before restoration. Restoring the
AFRINIC object “exactly as it was” could recreate the very
cross-registry collision this proposal is intended to prevent.
Confirming that the key remains free inside AFRINIC would not be
sufficient.</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 restoration is retained, the policy should require verified
prior control, restoration from the archived object rather than
creation of a different object under the old name, and a
conflict check at the time of restoration. It should also define
how a refusal is reviewed.</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);">
I do not doubt that AFRINIC staff may act reasonably. But policy
must survive staff changes and cannot depend on assumptions
about how generously discretion will be exercised. Trust is not
a substitute for an objective rule.</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);">
My concern is therefore not that the proposal fails to solve
every IRR problem. It is that its exception can potentially
recreate the precise problem the mandatory rule claims to close.</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>
<div id="ms-outlook-mobile-body-separator-line"
data-applydefaultfontstyles="true" dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<div
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
</div>
<div id="ms-outlook-mobile-signature" dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
<span
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">Get
</span><a href="https://aka.ms/AAb9ysg"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;"
moz-do-not-send="true">Outlook for Android</a></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> Wednesday, 29 July 2026 16:48:37<br>
<b>To:</b> Tshepo Masuku <a class="moz-txt-link-rfc2396E" href="mailto:TshepoMasuku26@hotmail.com"><TshepoMasuku26@hotmail.com></a>;
James Bensley <a class="moz-txt-link-rfc2396E" href="mailto:james@inter.link"><james@inter.link></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 Tshepo,<br>
<br>
</p>
<div class="x_moz-cite-prefix">On 2026/07/29 15:48, 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 James,</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 for considering the concern carefully and
explaining your decision openly. I genuinely appreciate that
you engaged with the substance rather than simply dismissing
it.</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)">
I understand the case for incremental improvement and agree
that no policy can anticipate every future scenario. My
concern, however, is not that the draft must be perfect. It
is that the exception clause sits at the boundary of what
AFRINIC will be required, or permitted, to enforce.</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 absence of data cuts both ways. If we do not know how
frequently restoration will be needed, that uncertainty does
not necessarily justify leaving the criteria undefined. It
may instead support beginning with a narrow, objective
restoration rule and expanding it later if operational
evidence shows that broader exceptions are necessary.</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)">
I also do not think restarting Last Call is, by itself, a
sufficient reason to retain ambiguous wording. Once adopted,
the policy will be binding until another proposal completes
the PDP. During that period, AFRINIC will have to interpret
“where necessary” without agreed criteria. That is not quite
the same as a temporary implementation experiment.</div>
</blockquote>
I don't think it's ambiguous, it may be vague, but not
ambiguous. I will concede it leaves the jay or nay decision to
operational discretion, and one person may decide yes, another
may decide no, but IMHO *any* reason to restore an object would
be operational of nature, something like "Hi, we've deleted
object X, but it has come to light it's still being referenced
by {insert another object|operational peer name|AS} and we're
having trouble getting the relevant party to update, could you
please restore".<br>
<br>
I don't foresee any other case of restoration case that I would
consider to be valid. But precisely that "cannot foresee" is
why I believe it's best to leave it to Afrinic staff to
determine the validity of any motivation for *restoration* of an
object. At that point it becomes a debate. And I've not yet
encountered Afrinic staff to be unreasonable and they'll most
likely err on the side of restoring (exactly as it was, without
modification) rather than not.
<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)">
<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 narrowly drafted restoration safeguard would not be an
attempt to build the whole castle at once. It would simply
make the first brick clear enough that operators and staff
know what it permits. The common layer should be minimal,
but what it contains should also be deterministic and
auditable.</div>
</blockquote>
<p>Without knowing what will or may be required in the future
this is exceptionally difficult, as per James, to narrow
down. I agree with James that it's best to intentionally
leave it vague.</p>
<p><br>
</p>
<p>Bottom line is: no new "flat" objects, and restore only on
motivation to Afrinic staff (which will likely be in the lines
above).<br>
<br>
At some point we would likely want to get a list of all "flat"
objects and see if they're still *referenced*, confirming
actual *use* is harder since we have no way of knowing whether
any implementation references that object. At least, none I'm
aware of. If there is a way it would likely involve Afrinic
having to check some query log and if the object name hasn't
been queried in some time. But that's not to say there aren't
gateway systems (such as rr.ntt.net - default queried server
by at least bgpq4) running some form of irrd, that doesn't
pull the entire database and then references "offline", so
without looking into exactly how that infrastructure works,
there's no way to identify completely unused objects I don't
think.</p>
<p><br>
</p>
<p>I trust this answers your concern.</p>
<p><br>
</p>
<p>Kind regards,<br>
Jaco</p>
<p><br>
</p>
<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)">
<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)">
I respect your decision not to revise the draft, and I
appreciate your constructive approach. However, because the
difference between a guaranteed restoration right and
discretionary case-by-case approval remains unresolved, I
cannot support the proposal as currently written and
therefore maintain my objection.</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)">
kind 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 tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font
face="Calibri, sans-serif" color="#000000"
style="font-size:11pt"><b>From:</b> James Bensley
<a class="x_moz-txt-link-rfc2396E"
href="mailto:james@inter.link" moz-do-not-send="true"><james@inter.link></a><br>
<b>Sent:</b> Wednesday, 29 July 2026 14:26:30<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: [Last Call] Draft Policy Proposal -
Hierarchical Names for New AS-SETs
(AFPUB-2026-ASN-001-DRAFT02)</font>
<div> </div>
</div>
<style type="text/css" style="display:none">p
{margin-top:0;
margin-bottom:0}</style>
<div dir="ltr">
<div class="x_x_elementToProof"
style="margin-top:0px; margin-bottom:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Dear Tshepo,</div>
<div class="x_x_elementToProof"
style="margin-top:0px; margin-bottom:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_x_elementToProof"
style="margin-top:0px; margin-bottom:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
After careful consideration I have decided not to revise
the draft. There are a couple of reasons for this:</div>
<div class="x_x_elementToProof"
style="margin-top:0px; margin-bottom:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<ul
data-editing-info="{"applyListStyleFromLevel":false,"unorderedStyleType":1}"
style="margin-top:0px; margin-bottom:0px; list-style-type:disc">
<li
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); margin-top:0px; margin-bottom:0px">
<div class="x_x_elementToProof" role="presentation"
style="margin-top:0px; margin-bottom:0px">
I think this is becoming too prescriptive. If we try
to define a time period for restoration for example,
for some people it will be too long, for others too
short. We have no data to make an informed decision
here. Similarly the point about having a public log.
That requires us to define what that looks like and
how it works. We have no idea how often this process
would be enacted so we can't described what that needs
to look like. We have no data. I think trying to make
a perfect policy that covers all cases is the wrong
approach. I think we should be aiming to get
"something" implemented, let it run for a while,
gather feedback, and then if it needs adjusting, we
can raise another policy change proposal. Nothing is
set in stone here. There's no need to get his perfect
first time, we can iterate over time.</div>
<div class="x_x_elementToProof" role="presentation"
style="margin-top:0px; margin-bottom:0px">
<br>
</div>
</li>
<li
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); margin-top:0px; margin-bottom:0px">
<div class="x_x_elementToProof" role="presentation"
style="margin-top:0px; margin-bottom:0px">
Any changes to the draft will restart the Last Call
and potentially also require the staff to re-review
the draft. The changes you proposed, whilst valid, are
optimising for a corner case (how often to people
delete their AS-SET by mistake? I would say, rarely).
Why delay getting "something" deployed, which we can
continue to iterate on, just to optimise for a corner
case (restores aren't blocked by this policy)?</div>
</li>
</ul>
<div
style="margin-top:0px; margin-bottom:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_x_elementToProof"
style="margin-top:0px; margin-bottom:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
For these reasons I have decided not to modify the draft.</div>
<div class="x_x_elementToProof"
style="margin-top:0px; margin-bottom:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_x_elementToProof"
style="margin-top:0px; margin-bottom:0px; font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
With kind regards,</div>
<div id="x_x_Signature" class="x_x_elementToProof">
<div class="x_x_elementToProof"
style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
James Bensley (he/him)</div>
</div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg">
<div
style="direction:ltr; font-family:Calibri,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<b>From:</b> Tshepo Masuku <a
class="x_moz-txt-link-rfc2396E"
href="mailto:TshepoMasuku26@hotmail.com"
moz-do-not-send="true">
<TshepoMasuku26@hotmail.com></a><br>
<b>Sent:</b> 28 July 2026 15:28<br>
<b>To:</b> James Bensley <a
class="x_moz-txt-link-rfc2396E"
href="mailto:james@inter.link" moz-do-not-send="true">
<james@inter.link></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: [Last Call] Draft Policy Proposal -
Hierarchical Names for New AS-SETs
(AFPUB-2026-ASN-001-DRAFT02)</div>
<div style="direction:ltr"> </div>
</div>
<p style="margin-top:0px; margin-bottom:0px"><span
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Dear
James,</span></p>
<p style="margin-top:0px; margin-bottom:0px"><span
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Thank
you for engaging with the concern constructively. Your
proposed wording is a meaningful improvement because it
begins replacing an open-ended exception with objective
conditions.</span></p>
<p style="margin-top:0px; margin-bottom:0px"><span
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">I
think a few points still need tightening before the rule
is ready:</span></p>
<ul>
<li
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Restoration should return the object to its last valid
archived state, not merely reuse the same key.
Otherwise, an old flat name could be restored with
entirely different contents and become a new object in
substance.</li>
<li
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
The text should define whether the restoration right is
permanent or subject to a recovery period.</li>
<li
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
“Another maintainer within the same organisation” and an
organisation “responsible for the assets” require
objective evidence, such as registry history or
documented legal succession. Those terms should not be
left entirely to staff interpretation.</li>
<li
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
The residual case-by-case provision should expressly
prohibit creating a flat name that did not exist before
implementation.</li>
<li
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Every exceptional decision should record the evidence
relied upon and provide a review or appeal path, not
merely an audit entry.</li>
</ul>
<p style="margin-top:0px; margin-bottom:0px"><span
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">I
would also suggest wording along these lines:</span></p>
<blockquote>
<p style="margin-top:0px; margin-bottom:0px"><span
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">A
restored object shall initially reflect its last valid
archived state, except that maintainer and contact
attributes may be updated where necessary to establish
control by the verified original holder or lawful
successor.</span></p>
</blockquote>
<p style="margin-top:0px; margin-bottom:0px"><span
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Because
this changes the normative enforcement boundary, I
believe v3 should be published with an updated Impact
Assessment and receive proper review. It should not be
treated as a minor editorial correction during the final
days of Last Call.</span></p>
<p style="margin-top:0px; margin-bottom:0px"><span
style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">I
remain opposed to DRAFT02 as written, but I appreciate
your willingness to address the defect directly. This is
the kind of concrete engagement that adds value to the
process.</span></p>
<p style="margin-top:0px; margin-bottom:0px"><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>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div id="x_x_x_ms-outlook-mobile-body-separator-line">
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt">
<br>
</div>
</div>
<div id="x_x_x_ms-outlook-mobile-signature">
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
</div>
<hr style="display:inline-block; width:98%">
<div id="x_x_x_divRplyFwdMsg">
<div
style="direction:ltr; font-family:Calibri,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<b>From:</b> James Bensley <a
class="x_moz-txt-link-rfc2396E"
href="mailto:james@inter.link" moz-do-not-send="true">
<james@inter.link></a><br>
<b>Sent:</b> Tuesday, 28 July 2026 13:39:50<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: [Last Call] Draft Policy Proposal -
Hierarchical Names for New AS-SETs
(AFPUB-2026-ASN-001-DRAFT02)</div>
<div style="direction:ltr"> </div>
</div>
<div style="direction:ltr">Dear <span
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Tshepo,</span></div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thank you for providing your feedback. I am in agreement
with your statement.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I am the original author of this draft change, and I wrote
in my last update (version 2):</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
"Exceptions MUST be allowed on a case-by-case basis. For
example, a non-hierarchically named AS-SET was deleted by
mistake, so it should be possible to restore this AS-SET
without having to rename it."</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
The staff assessment was to go with the following "7.8.7
Exceptions for the creation of hierarchical names may be
granted where necessary. AFRINIC shall document the reason
for any exception.".</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
The staff asked me to review their assessment and I
initially agreed, because it was loser than my definition.
There may be other scenarios where restoration is required
which I/we haven't thought of, so why limit it to
accidental deletion only. Opening it up to allow any case
to be reviewed has benefits. But as you say, it could also
go the other way, it could simply mean that every case is
rejected.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I am going to submit another version (v3) of the document,
only replacing the text I quoted above, with the text
below, to fix the problem you raised of the text having
gone from being too strict before to now being too lose (I
will try to propose something in the middle which
guarantees delete/restoration is protected, anything else
needs a review).</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I am proposing the following text, what do you think?</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
------</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
A non-hierarchical AS-SET existing before implementation
of this policy change, which has since been deleted, must
be restorable when the following conditions are met:</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
- The same object key is requested for restoration (no
AS-SET name changes allowed)</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
- No object with a conflicting name has been created
between the date of deletion and the date the restore is
made</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
- The restore request is coming from either a maintainer
that was present on the deleted object, or another
maintainer within the same organisation (in the case the
maintainer was also deleted), or a maintainer in an
organisation responsible for the assets of the original
organisation (in the case of a merger or acquisition).</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
- The restoration is recorded in an auditable log.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Any other request for restoring a deleted AS-SET created
before the implementation date of this policy change will
need to be reviewed by AFRINIC on a case by case basis.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
-------</div>
<div id="x_x_x_x_Signature">
<div
style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div
style="direction:ltr; font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
With kind regards,</div>
<div
style="direction:ltr; font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
James Bensley (he/him)</div>
</div>
<hr style="direction:ltr; display:inline-block; width:98%">
<div id="x_x_x_x_divRplyFwdMsg">
<div
style="direction:ltr; font-family:Calibri,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<b>From:</b> Tshepo Masuku <a
class="x_moz-txt-link-rfc2396E"
href="mailto:TshepoMasuku26@hotmail.com"
moz-do-not-send="true">
<TshepoMasuku26@hotmail.com></a><br>
<b>Sent:</b> 27 July 2026 15:29<br>
<b>To:</b> <a
class="x_moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:hvisage@hevis.co.za"
moz-do-not-send="true">
hvisage@hevis.co.za</a> <a
class="x_moz-txt-link-rfc2396E"
href="mailto:hvisage@hevis.co.za"
moz-do-not-send="true">
<hvisage@hevis.co.za></a>; Nonjabulo Sphilile <a
class="x_moz-txt-link-rfc2396E"
href="mailto:nonjabulosphilile@gmail.com"
moz-do-not-send="true">
<nonjabulosphilile@gmail.com></a>; Phetulo
Dhlamini <a class="x_moz-txt-link-rfc2396E"
href="mailto:phetulodhlamini@gmail.com"
moz-do-not-send="true">
<phetulodhlamini@gmail.com></a>; Taye Medoye <a
class="x_moz-txt-link-rfc2396E"
href="mailto:daniel.medoye@gmail.com"
moz-do-not-send="true">
<daniel.medoye@gmail.com></a>; Thulisile Mazomba
<a class="x_moz-txt-link-rfc2396E"
href="mailto:thulisile.mazomba@gmail.com"
moz-do-not-send="true">
<thulisile.mazomba@gmail.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><br>
<b>Subject:</b> Re: [rpd] [Last Call] Draft Policy
Proposal - Hierarchical Names for New AS-SETs
(AFPUB-2026-ASN-001-DRAFT02)</div>
<div style="direction:ltr"> </div>
</div>
<div
style="direction:ltr; background-color:rgb(255,243,205); margin-bottom:10px; padding:12px; border-width:1px; border-style:solid; border-color:rgb(255,238,186); font-family:Arial,sans-serif; font-size:14px; color:rgb(133,100,4)">
<b>⚠️ Caution:</b> This email originated from outside of
your organization. Do not click on links or open
attachments unless you recognize the sender and know the
content is safe.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Dear Hendrik and colleagues,</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Thank you for consolidating the discussion. I will not
repeat the earlier lifecycle, resolver, delegation, or
membership arguments.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
There is, however, a separate defect in the actual text
being considered.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
The proposal says that exceptions MUST be allowed on a
case-by-case basis and gives restoration of an
accidentally deleted flat AS-SET as the example. The
staff-recommended wording instead says exceptions may be
granted “where necessary.” These are materially different
rules. </div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Under the first version, an eligible operator has a right
to restoration. Under the second, restoration depends on
AFRINIC’s discretion. The wording also changes a narrow
restoration example into an undefined general exception.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
That produces a concrete operational difference. If a
grandfathered flat AS-SET is accidentally deleted after
implementation, one version requires a restoration path
while the other allows AFRINIC to refuse it. Operators and
peers referencing that object cannot know which outcome
the adopted policy guarantees.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
This is not an adjacent lifecycle problem. It is the
enforcement boundary of the present proposal.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
The text should therefore be amended to provide one
deterministic rule. For example:</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
> A non-hierarchical AS-SET existing before
commencement may be restored only where the same object
key is requested within a defined recovery period, the
request is authenticated by the maintainer authorised
immediately before deletion, no conflicting object has
intervened, and the restoration is recorded in an
auditable log. No other exception may authorise creation
of a new non-hierarchical AS-SET.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
That would preserve accidental-deletion recovery without
leaving the supposedly closed namespace subject to
undefined staff judgment.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Documenting the reason after an exception is granted is
not the same as defining the conditions under which the
exception is valid. Implementation guidance also cannot
resolve a conflict between “MUST” and “may” after
ratification.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Before Last Call closes, the authors and co-chairs should
identify which wording is actually under consideration and
resolve the difference in normative force.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Until then, I remain opposed to the proposal as written.</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Regards,</div>
<div
style="direction:ltr; font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Tshepo </div>
<hr style="direction:ltr; display:inline-block; width:98%">
<div id="x_x_x_x_x_divRplyFwdMsg">
<div
style="direction:ltr; font-family:Calibri,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<b>From:</b> <a
class="x_moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:hvisage@hevis.co.za"
moz-do-not-send="true">
hvisage@hevis.co.za</a> <a
class="x_moz-txt-link-rfc2396E"
href="mailto:hvisage@hevis.co.za"
moz-do-not-send="true">
<hvisage@hevis.co.za></a><br>
<b>Sent:</b> Monday, 27 July 2026 15:11:31<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>; Nonjabulo
Sphilile <a class="x_moz-txt-link-rfc2396E"
href="mailto:nonjabulosphilile@gmail.com"
moz-do-not-send="true">
<nonjabulosphilile@gmail.com></a>; Phetulo
Dhlamini <a class="x_moz-txt-link-rfc2396E"
href="mailto:phetulodhlamini@gmail.com"
moz-do-not-send="true">
<phetulodhlamini@gmail.com></a>; Taye Medoye <a
class="x_moz-txt-link-rfc2396E"
href="mailto:daniel.medoye@gmail.com"
moz-do-not-send="true">
<daniel.medoye@gmail.com></a>; Thulisile Mazomba
<a class="x_moz-txt-link-rfc2396E"
href="mailto:thulisile.mazomba@gmail.com"
moz-do-not-send="true">
<thulisile.mazomba@gmail.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><br>
<b>Subject:</b> [Last Call] Draft Policy Proposal -
Hierarchical Names for New AS-SETs
(AFPUB-2026-ASN-001-DRAFT02)</div>
<div style="direction:ltr"> </div>
</div>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Good day Tshepo,
Nonjabulo, Phetulo, Taye, Thulisile, colleagues,</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Apologies to the human
readers for this voluminous post, but I’d<br>
rather address as much in one email than to flood the
mailing list<br>
With even more messages as I’d rather do a digest type
response for<br>
all the similar objections at once.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">For nearly two weeks we
have been asking for technical substance;<br>
today, in the week Last Call closes, technical reasons
have at last<br>
been presented. Before I respond to them, let me add a
seventh<br>
question to the six of 23 July (015344):</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Question 7: could you
please provide the technical issues,<br>
difficulties, and real-world examples where
implementation of this<br>
draft policy - as three RIRs have already implemented
it, and the<br>
fourth is formally proposing - would negatively affect
your current<br>
or future operations? We would like to understand those
too.<br>
Operational evidence of that kind would genuinely add to
the body<br>
of knowledge on this proposal.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Note: numbers like
(015344) are message IDs in the RPD archive -<br>
prepend </span><span
style="font-family:sans-serif; color:rgb(57,131,196)"><a
href="https://lists.afrinic.net/pipermail/rpd/2026/"
id="OWAe288f940-a422-34b1-b13b-62d89dd1e2e2"
class="x_x_OWAAutoLink x_moz-txt-link-freetext moz-txt-link-freetext"
data-auth="NotApplicable"
style="color:rgb(57,131,196); margin-top:0px; margin-bottom:0px"
moz-do-not-send="true">https://lists.afrinic.net/pipermail/rpd/2026/</a></span><span
style="font-family:sans-serif"> and append<br>
.html to read any of them.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">So let's get to the
objections we have been waiting two weeks for:</span></p>
<ol start="1" style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">object
lifecycle under changes of ASN control (015387,<br>
escalated in 015391 and 015400) - answered by Jaco in
(015388)<br>
and (015394)</li>
</ol>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">1b) its
delegated-maintainer extension (015398, pressed again in<br>
015400) - Jaco deferred to the RFC in (015399); the
deferral is<br>
completed in section 1 below<br>
2) recursive expansion of members: references (015389) -
answered<br>
in (015390)<br>
3) grandfathered flat objects (015392) - answered in
(015395)<br>
4) multi-source name resolution (015393) - answered in
(015396,<br>
015397)<br>
5) anchor-ASN eligibility and authentication (015401) -
addressed<br>
in section 5 below<br>
6) implementation rollout process (015402) - addressed
in section 6<br>
below; its delegation and 7.8.7 points are answered in
section 1<br>
(the delegation question is 015398/015400 returning),
and its<br>
benefit-scope point in the common ground just below</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">I refer to and endorse
Jaco's answers rather than repeat them. It<br>
was asked earlier in this Last Call that objections be
addressed as<br>
grouped issues rather than piecemeal, and in that spirit
I have<br>
collated the responses in a single email, adding what
has not yet<br>
been shared: a precise statement of the authorisation
model, the<br>
published data, and the cross-registry record.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">First, the common ground,
because it is substantial. In today's own<br>
words:</span></p>
<ul style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">hierarchical
naming "can strengthen creation authorisation" (015393)</li>
<li style="font-family:sans-serif; direction:ltr">the
proposal "secures the first object name" (015389)</li>
<li style="font-family:sans-serif; direction:ltr">the
concerns are "not questions about whether AS-SET
membership<br>
is correct" (015387)</li>
<li style="font-family:sans-serif; direction:ltr">ASN-anchored
naming "can reduce future flat-name collisions"<br>
(015402)</li>
</ul>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">None of today's messages
disputes what the proposal does. Each of<br>
today's objections asks it to also solve an adjacent
problem -</span></p>
<ul style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">lifecycle</li>
<li style="font-family:sans-serif; direction:ltr">delegation
semantics</li>
<li style="font-family:sans-serif; direction:ltr">expansion
semantics</li>
<li style="font-family:sans-serif; direction:ltr">legacy
objects</li>
<li style="font-family:sans-serif; direction:ltr">mirror
copies</li>
<li style="font-family:sans-serif; direction:ltr">anchor
eligibility</li>
<li style="font-family:sans-serif; direction:ltr">and
every one of those problems exists today, everywhere,
with or</li>
</ul>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">without this policy. That
is not the discovery of a defect. It is<br>
the discovery that the proposal has a scope, which it
states and<br>
which was put on this record weeks ago (015119, 015120,
015123; and<br>
the draft's own sections 7.8.3-7.8.6).</span></p>
<ol start="1" style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">The
authorisation model, changes of ASN control, and
delegation<br>
(015387, 015391, 015398, 015400, 015402)</li>
</ol>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Jaco deferred to the RFC
on the depth mechanics (015399). Rightly<br>
so - the RFC, followed to the top of the chain,
completes his<br>
answer. (015398) states the rule correctly: a
first-level object,<br>
AS12345:AS-CUSTOMERS, is created under the authorisation
of the<br>
aut-num AS12345 as it stands at that moment - its
maintainer chain,<br>
which follows the current registered holder. A deeper
object,<br>
AS12345:AS-CUSTOMERS:AS-EU, is created under the
authorisation of<br>
the maintainer of its immediate parent. Now ask where
that parent<br>
came from: its own creation was authorised by the level
above it,<br>
and so on, terminating at the aut-num itself. Every
object in the<br>
tree exists because the level above authorised its
creation.<br>
Delegation, where it exists, exists because the chain
authorised<br>
it. And who controls each level is answerable, level by
level, from<br>
the database as it stands - which is what verifiable
control looks<br>
like in RPSL.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">The emphatic difference
at the current state is that a flat name<br>
offers just a maintainer but no chain: no root, and no
way to ask<br>
whether the name was ever anyone's to create - beyond
that it must<br>
not already exist in THIS one database.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">(015400) concludes that
because deeper control can be delegated,<br>
the "control model remains unspecified". The opposite is
the case:<br>
the control model is fully specified - in the very RFC
that<br>
(015398) cited, which is why deferring to it was the
right answer.<br>
That deeper authority is delegated, and that delegated
authority<br>
does not automatically follow the ASN, is not a gap in
the model;<br>
it is the model, working as designed for twenty-seven
years, for<br>
every hierarchical object family, at every RPSL-based
registry. A<br>
policy does not "leave AFRINIC to interpret" what the
RFC and the<br>
production database already define - any more than this
proposal<br>
needs to restate what mnt-by means. What
deterministically follows<br>
the ASN is the root of every chain: authority over
creation and<br>
recreation at the first level of the namespace. That is
precisely</span></p>
<ul style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">and only
- what the proposal's attribution claim covers. The same</li>
</ul>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">depth question returns in
(015402); the answer above stands.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">These semantics are not
invented by this proposal. They are RFC<br>
2622 (1999), operated by RPSL-based registries -
AFRINIC's included</span></p>
<ul style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">for
twenty-seven years. The proposal does not modify them;
it</li>
</ul>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">gates which names may
come into existence, nothing else. The two<br>
outcomes (015398) poses are therefore both answered by
the<br>
semantics already in production: descendants do not move<br>
automatically, so no delegated maintainer is overridden
- exactly<br>
as for every delegated object today. And the new holder
gains<br>
precisely what the name anchors: authority over creation
and<br>
recreation at the first level of its namespace. What the
new holder<br>
does not get - control over objects a previous holder's
delegates<br>
still maintain - is what nobody has today under flat
names, for any<br>
object, ever. A stale delegated descendant is today's
universal<br>
condition; the proposal neither creates nor worsens it,
and no<br>
registry in those twenty-seven years has defined the
demanded<br>
delegation-and-revocation regime for set objects in
policy.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">How ASN control actually
changes in this region is likewise not a<br>
matter for speculation. AFRINIC publishes it:</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif; color:rgb(57,131,196)"><a
href="https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json"
id="OWAe08156bb-9a61-a99c-74ff-99749c6c5545"
class="x_x_OWAAutoLink x_moz-txt-link-freetext moz-txt-link-freetext"
data-auth="NotApplicable"
style="color:rgb(57,131,196); margin-top:0px; margin-bottom:0px"
moz-do-not-send="true">https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json</a></span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">A full read of that file
today: 75 ASN-carrying transfer events (91<br>
ASNs) from 2018 through 2026 - about nine such events a
year - and<br>
every single one is a merger/acquisition succession, in
which the<br>
organisation and its maintainer control pass together,
so parent<br>
ASN and child objects move as one unit. That is the
published<br>
record behind Jaco's description in (015394), with the
frequency<br>
question answered exactly: none open-market, all
successions that<br>
preserve the attribution chain by construction. Anyone
can verify<br>
this from the file. So the concern of (015391) has been
addressed -<br>
with our registry's own data.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">The cross-registry record
answers the rest. I checked this week,<br>
across the policy, procedural and database-documentation
layers of<br>
the other four RIRs. RIPE has required hierarchical
names for new<br>
as-sets since December 2022 and operates full ASN
transfers,<br>
including inter-RIR; APNIC likewise since July 2023
(prop-151);<br>
LACNIC's IRR has been structurally hierarchical since it
launched<br>
in 2020; at ARIN hierarchical naming is available today
and a<br>
mandate for new objects is formally proposed
(ARIN-prop-342,<br>
pending) - the same direction. All four are silent on
child as-set<br>
lifecycle at every layer. Across the deployed
implementations that<br>
is roughly three and a half years of exactly the
coexistence<br>
(015387) warns about - hierarchical mandates running
over live ASN<br>
transfer markets - and I could not find one documented
incident of<br>
the failure mode described. In every deployed
implementation,<br>
lifecycle lives where it belongs: in standard RPSL
authorisation<br>
and registry operations, not in naming-policy text.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">On 7.8.7 (015391,
015402): today the namespace has no rule at all -<br>
every creation, by anyone, of any name, is the
exception. A closed<br>
default with documented-reason exceptions cannot be less<br>
deterministic than no default whatsoever. And credit
where due:<br>
(015402) makes one point that verifies - the staff
assessment's<br>
prose cites "7.8.6" for the
restoration-of-deleted-objects<br>
exception, where 7.8.6 concerns editing and the
exception clause is<br>
in fact 7.8.7. That is a cross-reference slip in the
assessment's<br>
commentary, worth an erratum, and it changes nothing in
the policy<br>
text: the clauses say what they say, and staff's own
recorded<br>
caution about recall loopholes shows the right mechanism
was<br>
analysed. As for the demanded exception criteria: 7.8.7
requires<br>
every exception to be documented with its reason - a
discipline<br>
stricter than today, where no creation needs any reason
at all.</span></p>
<ol start="2" style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">Recursive
expansion of members: references (015389)</li>
</ol>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Correct as far as it goes
- and it concedes the top level is<br>
secured. What members: may contain is a content
question, expressly<br>
outside this proposal's scope, and outside the naming
policies of<br>
every registry that already runs this rule: none coupled
naming to<br>
expansion semantics, because that coupling is a
different and<br>
larger policy. Jaco has already named the constructive
path<br>
(015390): a members-qualification rule would be a
coherent separate<br>
proposal, and wording was invited. Meanwhile every new
hierarchical<br>
set is one fewer ambiguous reference for the next
expansion to fear</span></p>
<ul style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">the gap
this concern describes narrows with adoption and stays</li>
</ul>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">open without it.</span></p>
<ol start="3" style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">Grandfathered
flat objects and the transition window (015392)</li>
</ol>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">The capability described
- register flat names now, populate them<br>
later - exists today, permanently, with or without this
proposal.<br>
Anyone may do it this afternoon. The proposal is the
only mechanism<br>
before this Working Group that ever closes that window;
declining<br>
it preserves the window forever. If gaming of the
implementation<br>
gap is the genuine worry, the remedy is a short
implementation<br>
period - a staff scheduling matter - not an indefinitely
open<br>
namespace. And, respectfully: (015392) describes with
precision the<br>
squatting behaviour whose future possibility this policy
exists to<br>
end. An objection that demonstrates the attack is an
argument for<br>
closing the door.</span></p>
<ol start="4" style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">Multi-source
resolution (015393)</li>
</ol>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Jaco's answer (015396,
015397) is complete: an ASN is delegated by<br>
exactly one registry, so a hierarchical name carries its<br>
authoritative source in its own first element. The
question "which<br>
source is authoritative for this set?" has a
deterministic answer<br>
precisely and only when the name is hierarchical; under
a flat name<br>
that answer does not exist anywhere. The working-group
draft cited<br>
in (015393) pursues the same determinism through
source-qualified<br>
references - the two mechanisms are complements, not
conflicts, and<br>
that draft's problem statement describes the flat-name
condition<br>
this proposal removes for new AFRINIC sets. What a
third-party<br>
mirror carries is today's condition for every object in
every IRR<br>
database and is governed by no naming policy at any
registry.</span></p>
<ol start="5" style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">Anchor-ASN
eligibility and authentication (015401)</li>
</ol>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Taye, this is the kind of
message Last Call is for: specific,<br>
technical, and naming the exact requirements it wants.
Three<br>
responses.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">First, on substance: the
properties you list - the leading ASN<br>
globally assigned, an authoritative aut-num present,
creation<br>
authenticated against that object's maintainer,
private-use and<br>
reserved ranges (RFC 6996) excluded, canonical ASPLAIN
form (RFC<br>
5396) - are, I would argue, what the Impact Assessment's
own<br>
authorisation claim already entails. An anchor with no
holder can<br>
authorise no one; a check that can pass in the absence
of the<br>
aut-num it authenticates against would not be the check
the<br>
assessment describes. So I read your list not as a new
mechanism<br>
but as the strict, and correct, reading of the mechanism
the<br>
proposal already claims.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Second, on where it
belongs: those are implementation semantics -<br>
the authentication mode of the database software and the
eligible<br>
ASN ranges - and I would support AFRINIC staff recording
exactly<br>
your list in the implementation guidance for this
policy, alongside<br>
the failure behaviour per creation path. That is the
normal home of<br>
such requirements at every registry, and section 7.8.7's<br>
documented-exception mechanism gives staff the
instrument for any<br>
edge the guidance must handle. It is worth adding: even
in the<br>
weakest imaginable configuration, an unattributable<br>
hierarchical-form name is no worse than today, where
every name of<br>
any form requires no authorisation from anyone.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Third, on form: yours is
the closest any message in this Last Call<br>
has come to proposed text. If you formalise that list as
wording -<br>
whether as implementation guidance or as a clarification
for a<br>
future revision - I have no doubt this Working Group
will engage it<br>
on its merits, exactly as was invited days ago (015390).
It is the<br>
constructive instrument the process recognises.</span></p>
<ol start="6" style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">Implementation
rollout process (015402)</li>
</ol>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Warning-only phases, test
vectors, baselines, rollback plans and<br>
scheduled reviews are implementation artifacts. They are
produced<br>
by registry staff during implementation - at every RIR -
and they<br>
appear in no naming policy anywhere: RIPE shipped its
hierarchical<br>
requirement through the database release process, with
release<br>
notes and a release-candidate test environment, on the
strength of<br>
a policy text that contains none of those artifacts.
Nothing in<br>
this proposal forbids a staged, warning-first
deployment; that is<br>
exactly the kind of detail the implementation phase
exists to<br>
define, and 7.8.7's documented-exception mechanism gives
staff the<br>
instrument for edge handling during it. Taken at face
value,<br>
(015402)'s final section is an argument about deployment<br>
scheduling, which follows ratification - not a reason to
withhold<br>
it.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Stepping back, twice.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Each of the demands in
messages (015387), (015389), (015391),<br>
(015392), (015393), (015398), (015400) and (015402)
carries the same<br>
condition: "before adoption" (015387, 015389, 015391),
"before<br>
mandatory enforcement" (015393), "before this proceeds"
(015398),<br>
"until ... addressed" (015392), "until that is
clarified" (015400),<br>
"until ... clearly resolved" (015402).<br>
As Seun reminded the list (015386), this PDP has no
conditional<br>
adoption: a proposal cannot pass Last Call subject to
future<br>
homework. At day eleven of Last Call, "resolve and test
before<br>
advancing" therefore spells "do not adopt". The process
has exactly<br>
one instrument for a genuine, fixable concern: proposed
text. Jaco<br>
invited it (015390).</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Let me emphasise the
arithmetic: seven distinct technical concerns<br>
in a single day, after eleven days without one - and,
section 5's requirements<br>
list aside, still zero proposed amendments. Of the six
questions of<br>
23 July (015344), exactly one account engaged them point
by point -<br>
Tshepo, in (015348) - and the record should credit those
answers.<br>
In short:</span></p>
<ol start="1" style="direction:ltr">
<li style="font-family:sans-serif; direction:ltr">Two-object
case: tooling should bind to an explicitly selected<br>
source or stop and report - the fail-closed behaviour
supporters<br>
had proposed; the live case itself stays unresolved
either way,<br>
the rule being prospective.</li>
<li style="font-family:sans-serif; direction:ltr">Squatting
remedy: none - the victim is left to another<br>
database's dispute or abuse process.</li>
<li style="font-family:sans-serif; direction:ltr">Is it an
improvement? "Yes, narrowly."</li>
<li style="font-family:sans-serif; direction:ltr">Evidence
bar: a four-part test - whose second criterion, that<br>
the proposal "would have prevented" the incident,
excludes by<br>
construction every incident that already exists; a
creation-time<br>
rule is prospective by definition.</li>
<li style="font-family:sans-serif; direction:ltr">Impact
Assessment: "I do not dispute the findings"; the<br>
objection shifts to what the IA does not cover.</li>
<li style="font-family:sans-serif; direction:ltr">Capacity:
individual, representing no organisation or resource<br>
member.</li>
</ol>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">No other opposing account
has answered any of the six. Today the<br>
bar has moved with nearly every message, and a seventh
question now<br>
joins the list. My assessment, for the record:<br>
none of today's objections identifies a defect in what
the proposal<br>
claims; and their cumulative effect, whatever the
intent, has been<br>
to consume the finite attention of this Working Group -
a cost<br>
long-standing participants have already described in
their own<br>
words (015154, 015179).</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">One further observation,
offered for the record and without<br>
attributing it to any individual: this Last Call's
objections began<br>
from the principle that the registry "may record... It
may not<br>
rule" (015011). Today's objections ask the registry to
pre-define<br>
delegation graphs, revocation processes, state machines,
permanent<br>
reservations, transition audits and source-selection
rules, in<br>
advance (015391, 015392, 015393, 015398, 015400,
015402). Those two<br>
standards pull in opposite directions, and the same
seven-clause<br>
creation-time rule cannot be faulted under both at once.
Which<br>
standard the Working Group actually holds is exactly
what the<br>
Co-Chairs will weigh - against what the proposal
actually claims: a<br>
creation-time naming rule, whose every stated boundary
today's<br>
objection messages ask it to exceed.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">The community is entitled
to expect Last Call to close on schedule<br>
and to be assessed on the record as it stands.</span></p>
<p style="direction:ltr; margin-top:0px; margin-bottom:0px"><span
style="font-family:sans-serif">Regards,<br>
Hendrik Visage (AS329532; also AS213481)</span></p>
<div style="direction:ltr; display:none">[CompanySignature]</div>
<div
style="direction:ltr; font-family:"Calibri",sans-serif; font-size:8pt">Inter<span
style="font-size:0px">.</span>.link GmbH
<b>|</b> Boxhagener Straße 80, 10245 Berlin, Germany <b>|</b>
Managing Directors: Marc Korthaus, Theo Voss
<b>|</b> Commercial Register: Amtsgericht Charlottenburg,
HRB 138876 <b>|</b> VAT ID: DE281288887
<b>|</b> Email: <a href="mailto:hello@inter.link"
id="OWA02ff23ec-3d1e-7759-6597-38c0b37631c4"
class="x_x_OWAAutoLink x_moz-txt-link-freetext moz-txt-link-freetext"
moz-do-not-send="true">
hello@inter.link</a> <b>|</b> Web: <a
href="https://inter.link"
id="OWAf8d7f1f5-4be0-1f7a-4593-690df3987cb8"
class="x_x_OWAAutoLink" data-auth="NotApplicable"
moz-do-not-send="true">
inter.link</a></div>
</div>
<br>
<fieldset class="x_moz-mime-attachment-header"></fieldset>
<pre class="x_moz-quote-pre">_______________________________________________
RPD mailing list
<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-freetext moz-txt-link-freetext"
href="https://lists.afrinic.net/mailman/listinfo/rpd"
moz-do-not-send="true">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
</div>
</blockquote>
</body>
</html>