<div dir="auto">Dear All,<div dir="auto"><br><div dir="auto">I OBJECT THIS POLICY. </div><div dir="auto"><br></div><div dir="auto">I would like to express my concerns regarding the proposal to introduce hierarchical naming for new AS-SETs (AFPUB-2026-ASN-001-DRAFT02).</div><div dir="auto"><br></div><div dir="auto">I agree with the concerns raised by Fundiswa, Thandeka, and Nonhlanhla during the discussion.</div><div dir="auto"><br></div><div dir="auto">At first glance, this proposal appears to be a minor technical enhancement. However, policy changes should be evaluated not only on their immediate operational benefits, but also on whether they expand institutional complexity or shift the role of the registry beyond its core function.</div><div dir="auto"><br></div><div dir="auto">The primary role of the registry is to maintain an accurate, neutral, and reliable resource registry and associated data infrastructure. Policy should focus on preserving the integrity of the ledger and enabling operational continuity, rather than continuously introducing new structures that may increase dependence on registry-defined conventions.</div><div dir="auto"><br></div><div dir="auto">One concern is that proposals of this nature, while well-intentioned, can contribute to what has been described as “mandate laundering”: the gradual expansion of institutional influence through incremental policy changes that appear administrative or technical in isolation, but collectively increase the scope of centralized governance over network operations and coordination practices.</div><div dir="auto"><br></div><div dir="auto">The Internet’s resilience comes from minimizing unnecessary dependencies and preserving operator autonomy. If hierarchical AS-SET naming is genuinely required for operational efficiency, the proposal should clearly demonstrate that existing mechanisms are insufficient and that the benefits outweigh the costs of additional policy complexity. Convenience alone is not a sufficient basis for expanding registry-managed structures.</div><div dir="auto"><br></div><div dir="auto">This also relates to the broader “stability fallacy”: the assumption that more structure, more policy, or more institutional mechanisms necessarily create more stability. In many cases, long-term stability is better served by simplicity, interoperability, and clear separation between registry administration and operator decision-making.</div><div dir="auto"><br></div><div dir="auto">The burden of proof should therefore rest with proponents to demonstrate that this proposal addresses a concrete operational problem that cannot be solved through existing practices, voluntary coordination, or tooling improvements outside the policy framework.</div><div dir="auto"><br></div><div dir="auto">For these reasons, I do not support the proposal in its current form and encourage the Working Group to prioritise minimalism, operational continuity, and the protection of the registry’s core mandate.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto">Gugu</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 17 Jul 2026, 5:44 pm Musa Stephen Honlue <<a href="mailto:honlue@gmail.com">honlue@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
I support adoption and implementation of this policy.<br>
<br>
Sent from my iPhone<br>
<br>
> On 17 Jul 2026, at 09:19, Frank Habicht <<a href="mailto:geier@geier.ne.tz" target="_blank" rel="noreferrer">geier@geier.ne.tz</a>> wrote:<br>
> <br>
> Dear all,<br>
> <br>
> I support adoption and implementation of this proposal.<br>
> <br>
> Regards,<br>
> Frank Habicht<br>
> AS37084<br>
> <br>
>> On 7/17/2026 1:09 AM, Hytham El-Nakhal wrote:<br>
>> Dear PDWG,<br>
>> The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026.<br>
>>   *   Proposal Name: Hierarchical Names for New AS-SETs<br>
>>   *   Proposal ID: AFPUB-2026-ASN-001-DRAFT02<br>
>>   *   Proposal URL: <a href="https://www.afrinic.net/afpub-2026-asn-001-draft02.html" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/afpub-2026-asn-001-draft02.html</a><br>
>> Last Call closes on: July 31, 2026, at 23:59 UTC.<br>
>> Please note the staff observation regarding implementation constraints: due to the current prioritization of the MyAFRINIC v2 deployment, physical database implementation of this policy will be scheduled once the MyAFRINIC v2 deployment is concluded.<br>
>> As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct<<a href="https://www.afrinic.net/code" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/code</a>> to maintain a respectful and professional environment on the mailing list.<br>
>> Kind regards,<br>
>> Haitham el Nakhal<br>
>> AFRINIC PDWG Co-Chair<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>
> 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>
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>
</blockquote></div>