<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);">
Dear Hendrik,</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. I will respond directly to your three points.</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);">
First, Question 7 is a test you introduced. It is not a requirement that every objector demonstrate personal damage to their own production network before a policy concern may be considered. A mandatory rule may be challenged because its state model, implementation
assumptions, or enforcement boundaries are incomplete.</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);">
Making personal operational harm the admission price for an objection would turn an open PDP into an operator-credential test. Experience is relevant evidence; it is not exclusive authority.</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);">
Second, the delegated statistics file does not provide the guarantee you claim. It maps an ASN to its current registry. It does not identify which AS-SET object a resolver actually used, invalidate an old copy, update every mirror or cache simultaneously, or
confirm the present maintainer chain of a delegated descendant.</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 file published daily is not a globally atomic authority mechanism.</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 claim is that running tools already use that map to reject historical or conflicting AS-SET objects, please identify the relevant resolver behaviour, code path, or test case. Otherwise, this remains an architectural assumption rather than running-code
evidence.</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 can reasonably claim that a new name is unique and authenticated inside the AFRINIC database at creation time. It should not be credited with continuous, globally deterministic source resolution unless that behaviour is demonstrated across the
actual tooling that consumes the 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);">
Third, you asked for effects on current or future operations, but then excluded the future scenario because AFRINIC does not currently support inter-RIR ASN transfers. Those positions cannot both stand.</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 policy intended to remain in force cannot use the present absence of another policy as proof that its own assumptions will remain valid indefinitely. If a future transfer policy must define the object transition, then that confirms the present proposal does
not define 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 am not asking this proposal to solve every transfer problem. I am asking that its text and Impact Assessment claim only what the mechanism actually guarantees.</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 unresolved issue is therefore specific: the proposal creates local, creation-time naming and authentication rules, while its supporters attribute to it a global and continuing authority property that has not been demonstrated in running tools.</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 record is not made complete merely by declaring it complete. Until the claims are narrowed to the property actually proved, I remain opposed.</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> Hendrik Visage <hvisage@hevis.co.za><br>
<b>Sent:</b> Wednesday, 29 July 2026 20:21:10<br>
<b>To:</b> Tshepo Masuku <TshepoMasuku26@hotmail.com>; rpd@afrinic.net <rpd@afrinic.net><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 class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Good day Tshepo,<br>
<br>
Three short points, and then I'll leave the record to the Co-Chairs.<br>
<br>
First: your scenario requires an inter-RIR ASN transfer. AFRINIC does<br>
not perform inter-RIR transfers - not for ASNs, not for anything.<br>
There is no policy for it in the CPM, and the other registries list<br>
AFRINIC as not approved for transfers in either direction. So the<br>
event your whole scenario depends on cannot occur in this region<br>
under any rule that exists - and a NAMING proposal can neither create<br>
that capability nor govern it. If our community one day adopts an<br>
inter-RIR transfer policy, THAT policy is where object handling on<br>
transfer gets defined - which is exactly where the deployed<br>
registries define it today (APNIC's transfer conditions, for example,<br>
spell out which dependent objects get deleted when a resource<br>
moves). You are asking the wrong document to answer, before the<br>
right document exists.<br>
<br>
Second: the "how do tools distinguish the current authoritative<br>
object from the historical one" question has a running answer<br>
already: the delegated statistics files every RIR publishes daily,<br>
which record each ASN's current registry - transfers included,<br>
single-valued at every instant. That is the map the whole IRR<br>
tooling world uses today. And notice: under flat names your<br>
succession scenario is strictly worse, because then there is no map<br>
at all.<br>
<br>
Third, on Question 7: I asked for the technical issues and real-world<br>
examples where this policy would negatively affect YOUR current or<br>
future operations. A hypothetical relying operator, in a transfer<br>
type that is not available in this region, is not that. So I note,<br>
with appreciation for the attempt, that Question 7 still stands<br>
unanswered. And to be fair on the record: of the six questions of<br>
(015344), yours in (015348) remain the only point-by-point answers<br>
given - answers I credited in (015404) - the rest of the opposition<br>
has answered none.<br>
<br>
The record is now complete enough for the Co-Chairs to do their work,<br>
and I am content to leave it to them.<br>
<br>
Regards,<br>
Hendrik Visage (AS329532; also AS213481)<br>
<br>
</div>
</span></font></div>
</body>
</html>