<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>Please allow me to be blatantly blunt:</p>
<p>The only possible reason I can imagine to resist this proposal is
because you don't want people to use Hierarchical Names, leaving
them vulnerable to IRR collision attacks, in order to enable
yourself or a related party to execute such a collision attack
against them. Either that or you're resisting change for the sake
of resisting change.<br>
<br>
The problem is, it's usually not the vulnerable party that suffers
the damages, it's their peers, service providers and customers.</p>
<p>I beg you Mphoentle, as well as Tshepo, Paulo, Nthabiesng,
Thandeka, Thulisile, Nia, Asamkele, Nonhlanhla and probably others
I've missed now please stop this. Others call this astroturfing.
Just because a bunch of you repeat the same rhetoric, not grounded
in actual technical fact or sound reasoning, does not make it
true, reasonable or sensible. If you want to object, please
clarify to us from a technical and operational perspective how
this policy causes harm (ie, as Nishal said - creates operational
problems - so that we can address that).</p>
<p>It has been shown, and is well know, that Hierarchical Names
helps avoid inter-RIR naming collissions, this preventing a set of
known attacks (at least one of our upstreams was collided
previously, causing measurable harm to us - this policy, if
implemented from day one, would have prevented that). This does
not in any way add additional centralised control - you can choose
to use these objects to help protect you, your customers, as well
as your providers, or not. But I highly recommend you do. This
policy, does in fact, not actually change anything other than
force those that choose to use the mechanism to not make
themselves vulnerable to known naming collision attacks. In other
words - this policy solves actual real-world problem for real
network operators. If that can be done in a better way - please
speak up and show us how, rather than just merely objecting.<br>
<br>
Better tooling as some have implied does not stop the problem.
One can (for bgpq* at least) say to specifically look at say
AFRINIC::ULS - but fixing the root cause of the problem should be
preferred over requiring all tooling to work around the problem.
Which is what this policy does.</p>
<p>The same goes for every other objection to this proposal. It
feels like the whole AS0 situation all over again. Those of us
who operated actual networks has existing operational problems
which this, and policies such as others being resisted currently,
as well as the previously mentioned AS0 policy, helps address.
This isn't about centralising control. This is about protecting
resources and making the Internet a better and safer place for
all.</p>
<p>These policies helps to make the internet a safer place for all.</p>
<div class="moz-signature">
<div style="padding: 0px; margin: 0px; font-family: 'Open Sans';">
<p
style="font-size: large; color: black; padding-left: 10px; padding-top: 3px;">Kind
regards,<br>
Jaco Kroon<br>
<br>
On 2026/07/17 21:36, Mphoentle Mokheseng via RPD wrote:</p>
</div>
</div>
<blockquote type="cite"
cite="mid:JNAP275MB0669F5711941528487AEF1ACF0C62@JNAP275MB0669.ZAFP275.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;">
Dear PDWG Chairs,</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
I object to AFPUB-2026-ASN-001-DRAFT02.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
The Internet has always succeeded by minimizing the amount of
centralized authority required for independent networks to
interoperate. Coordination is necessary. Governance beyond what
coordination requires is not.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
This proposal may appear modest, but it reflects a broader trend
that deserves scrutiny. We increasingly treat every operational
preference as something that must be standardized through policy
simply because the registry is capable of administering it. That
reverses the proper relationship between operations and policy.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
Policy should emerge from established operational reality. It
should not be used to manufacture it.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
The burden is on the proposer to demonstrate that an existing
technical deficiency cannot be addressed without creating a new
policy obligation. I do not believe that burden has been met. No
compelling evidence has been presented that current AS-SET
naming practices threaten uniqueness, registry integrity,
interoperability, or the stable operation of the Internet.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
The fact that a naming convention may be desirable does not make
it an appropriate subject for mandatory registry policy.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
Every additional policy expands the registry's sphere of
interpretation and administration. Individually these expansions
appear harmless. Collectively they normalize the idea that the
registry should increasingly prescribe operational behaviour
rather than simply coordinate shared technical resources.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
That is a direction we should resist.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
The registry's legitimacy comes from performing a narrowly
defined technical function exceptionally well, not from
continuously enlarging its policy surface. We should preserve
that distinction. Institutions are strongest when they exercise
only the authority that is demonstrably necessary, and no more.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
For these reasons, I object to AFPUB-2026-ASN-001-DRAFT02.</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
Kind regards,</div>
<div dir="auto"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
Mphoentle </div>
<div id="ms-outlook-mobile-signature"
style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;"
dir="auto">
</div>
Disclaimer This email and the information contained herein are
Advtech Ltd confidential and are protected by law. Please navigate
to our website for more information <a class="moz-txt-link-freetext" href="https://www.groupadvtech.com">https://www.groupadvtech.com</a>.
Use of this information or this email by any person for any
purposes other than that for which it is intended is prohibited
and may result in civil and/or criminal liability. This email is
not to be shared with any 3rd parties not included within this
email, without the written consent of its Author. If you have
received this message in error, please notify Advtech immediately,
telephone number +27 11 676 8000. Advtech leads the private sector
in the fields of education and resourcing, contributing
meaningfully towards the sustainable development of human capacity
in South Africa.
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
</body>
</html>