<div dir="auto"><p>Hello Seun,</p>
<p>That response illustrates precisely the concern.</p>
<p>Saying that a proposal “helps the RIR fulfil its role” does not answer whether the proposal expands that role. It merely assumes the scope of the role in advance and then uses policy adoption to validate the assumption.</p>
<p>That is circular.</p>
<p>The registry’s original technical function is narrow: preserve uniqueness, maintain accurate records, support contactability, record changes of control, and protect operational continuity. Those functions justify a registry. They do not create a general mandate to regulate every practice that can be attached to a registry object.</p>
<p>A policy does not become legitimate merely because the registry can administer it. Nor does ratification transform an administrative preference into a technical necessity. Otherwise, there is no limiting principle. Any proposal can be said to “help the RIR fulfil its role,” provided the role is continuously redefined by the policies the RIR later enforces.</p>
<p>That is mandate laundering.</p>
<p>A narrow coordination function is passed through the language of policy, consensus, and community until it re-emerges as institutional authority. The process then points to its own output as proof that the authority existed all along.</p>
<p>But policy procedure cannot manufacture mandate.</p>
<p>A meeting is not a legislature. Participation is not authorization. Rough consensus does not give a registry an unlimited governance surface over operators, routing practice, commercial arrangements, naming conventions, or future implementation choices.</p>
<p>The proper question is not whether the proposal can be administered by the RIR. Almost anything can be administered once enough procedure is created around it.</p>
<p>The proper question is: what technical invariant requires this rule to be mandatory?</p>
<p>Does it protect uniqueness?</p>
<p>Does it prevent duplicate registration?</p>
<p>Does it preserve registry accuracy?</p>
<p>Does it protect security integrity?</p>
<p>Does it preserve operational continuity?</p>
<p>If it does not, then it is not a necessary registry function. It is institutional preference being converted into enforceable policy.</p>
<p>There is also an important distinction between recording a practice and governing it. A registry may accurately record AS-SET information. It may provide technical formats and interoperable publication mechanisms. It should not assume that maintaining the database gives it authority to prescribe every naming structure used by operators.</p>
<p>The registry should describe operational reality, not manufacture it through policy and then enforce obedience through control of the registry layer.</p>
<p>So yes, this proposal does expand the governance surface. It does so by converting a naming convention into a policy obligation and then placing the registry in the position of interpreting, administering, and enforcing that obligation.</p>
<p>Calling that “fulfilling the RIR’s role” does not resolve the objection.</p>
<p>It proves it.</p>
<p>Regards, </p><p>Nonhlanhla </p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 17 Jul 2026, 6:24 pm Seun Ojedeji <<a href="mailto:seun.ojedeji@gmail.com">seun.ojedeji@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Nia,<div><br></div><div>The registry administers number resources through policies that govern it. To your question<strong style="background-color:transparent"> "...does it expand the registry's governance surface?" </strong><span style="background-color:transparent">no it doesn't, the proposal once ratified will serve as one of the policies that helps the RIR fulfil its role.</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">Regards</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 17 Jul 2026 at 10:40, Nia Petronella <<a href="mailto:nonhlanhlapetronella85@gmail.com" target="_blank" rel="noreferrer">nonhlanhlapetronella85@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><p>Dear Colleagues, </p><p>I do <strong>not</strong> support adoption of this proposal.</p>
<p>The proposal appears technically modest, but it reflects a broader pattern that AFRINIC should be moving away from, not reinforcing. Every new policy that expands registry-defined objects, procedures, or institutional scope should first answer a simple question: <strong>does this protect uniqueness, or does it expand the registry's governance surface?</strong></p>
<p>A registry exists to maintain accurate records and protect uniqueness. It may record. It may coordinate. It may protect uniqueness. It may not rule. Once policy begins creating additional administrative structures that are not strictly required for interoperability, we should ask whether we are solving an Internet problem or an institutional one.</p>
<p>This proposal also illustrates what Lu Heng describes as the <strong>Policy Mirror</strong>. The issue is not hierarchical AS-SET names themselves, but the continuing assumption that every operational practice should be standardized through registry policy rather than left to voluntary operator adoption. Running networks—not policy manuals—should determine what survives. If hierarchical naming provides sufficient operational value, operators will naturally deploy it without requiring another layer of institutional governance.</p>
<p>Furthermore, AFRINIC should be reducing policy complexity rather than increasing it. <strong>Running-Code Primacy</strong> requires that policy remain the minimum necessary to preserve interoperability and operational continuity. Every additional policy object increases long-term maintenance, interpretation, and enforcement costs while offering limited benefit to the stability of the Internet itself. The common layer should remain thin.</p>
<p>Finally, rough consensus should not be mistaken for proof that additional governance is desirable. A mailing list is not a legislature, and community discussion should not automatically become permanent policy. Before adopting any proposal, we should first ask whether failure to adopt would actually threaten uniqueness, interoperability, or operational continuity. If the answer is no, then the proposal belongs in operational best practice, not in mandatory registry policy.</p>
<p>For these reasons, I oppose adoption.</p><p><br></p><p>BR, </p><p>Nonhlanhla </p></div>
_______________________________________________<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><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">------------------------------------------------------------------------<br><font color="#888888"><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;font-family:garamond,serif">
<i><span style="color:rgb(0,102,0)">Seun Ojedeji,<br style="color:rgb(0,102,0)"></span></i><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bringing another down does not take you up - think about your action!<br></blockquote></blockquote></font><br></div></div></div></div></div></div></div></div>
</blockquote></div>