<div dir="auto">Dear colleagues,<div dir="auto"><br></div><div dir="auto">I think we've now narrowed the discussion down to the main technical issue.</div><div dir="auto"><br></div><div dir="auto">I agree that this proposal is about naming and not about defining how a future inter-RIR transfer policy should work. If AFRINIC ever adopts such a policy, those details would naturally belong there.</div><div dir="auto"><br></div><div dir="auto">That said, I also think it's important that we don't claim more for this proposal than what it can actually guarantee.</div><div dir="auto"><br></div><div dir="auto">From my reading, the proposal clearly provides benefits such as unique naming at creation, a more structured namespace, and improved administrative clarity within the AFRINIC IRR. Those are meaningful improvements.</div><div dir="auto"><br></div><div dir="auto">Where I still have reservations is the suggestion that these naming rules, by themselves, provide a continuous, globally authoritative identity for AS-SET objects across all routing tools and IRR consumers. If that is part of the proposal's intended benefit, it would be helpful to see the implementation evidence or operational examples that demonstrate this behaviour in practice.</div><div dir="auto"><br></div><div dir="auto">If that evidence does not exist, then I believe the proposal and its Impact Assessment would be stronger if they simply described the guarantees the mechanism actually provides, without extending those claims further.</div><div dir="auto"><br></div><div dir="auto">I believe that kind of clarity would benefit everyone, regardless of whether they support or oppose the proposal.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto"><br></div><div dir="auto">Fundiswa Nadia Maseko</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 29 Jul 2026, 20:29 , <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send RPD mailing list submissions to<br>
<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of RPD digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage)<br>
2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 29 Jul 2026 20:21:10 +0200<br>
From: Hendrik Visage <<a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>><br>
To: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank" rel="noreferrer">TshepoMasuku26@hotmail.com</a>>, <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
Message-ID: <<a href="mailto:32BB6C1F-18CF-44AC-ACDF-979D0BE9E81D@hevis.co.za" target="_blank" rel="noreferrer">32BB6C1F-18CF-44AC-ACDF-979D0BE9E81D@hevis.co.za</a>><br>
Content-Type: text/plain; markup=markdown<br>
<br>
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>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 29 Jul 2026 18:28:45 +0000<br>
From: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank" rel="noreferrer">TshepoMasuku26@hotmail.com</a>><br>
To: Hendrik Visage <<a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>>, "<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>"<br>
<<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
Message-ID:<br>
<<a href="mailto:AM6PR04MB59921D9A6819806346BA1927CACA2@AM6PR04MB5992.eurprd04.prod.outlook.com" target="_blank" rel="noreferrer">AM6PR04MB59921D9A6819806346BA1927CACA2@AM6PR04MB5992.eurprd04.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Dear Hendrik,<br>
<br>
Thank you. I will respond directly to your three points.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
A file published daily is not a globally atomic authority mechanism.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The record is not made complete merely by declaring it complete. Until the claims are narrowed to the property actually proved, I remain opposed.<br>
<br>
Regards,<br>
Tshepo<br>
<br>
<br>
________________________________<br>
From: Hendrik Visage <<a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>><br>
Sent: Wednesday, 29 July 2026 20:21:10<br>
To: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank" rel="noreferrer">TshepoMasuku26@hotmail.com</a>>; <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a> <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
<br>
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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260729/60d10620/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260729/60d10620/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 222, Issue 223<br>
*************************************<br>
</blockquote></div>