<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 19 Jul 2026, at 16:46, Frank Habicht wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Didn't I just respond to the same text from<br>
Nia Petronella <a href="mailto:nonhlanhlapetronella85@gmail.com" style="color: #777777;">nonhlanhlapetronella85@gmail.com</a><br>
?????????????????</p>
</blockquote>
<p dir="auto">I’ll quote my friendly LLM:</p>
<pre style="margin-left: 15px; margin-right: 15px; padding: 5px; background-color: #F7F7F7; border-radius: 5px 5px 5px 5px; overflow-x: auto; max-width: 90vw;"><code style="margin: 0 0; border-radius: 3px; background-color: #F7F7F7; padding: 0px;">- One more scenario worth weighting: same model, same operator, one saved prompt
The two messages are so architecturally identical — one meta-escalation move, one four-item parallel list, one metaphor/chiasmus zinger, one "invariant" — that I'd guess not just the same model family but literally the same chat template or custom-instruction set, run twice with "respond as a different supporter agreeing with the previous objection." The recycled vocabulary ("invariant," the thin-layer thesis) crossing between "authors" points at a shared conversation or system prompt more than at any particular model's defaults.
</code></pre>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">On 7/17/2026 7:58 PM, Gugu Dhlamini wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;">
<p dir="auto">Hi All,</p>
<p dir="auto">Further to my OBJECTION of this POLICY PROPOSAL:</p>
<p dir="auto">I agree with Nonhlanhla's point regarding mandate laundering and the gradual expansion of institutional authority.</p>
<p dir="auto">My concern is that this discussion is not really about hierarchical names. It is about a much broader pattern. We increasingly justify new policy by saying it helps the registry fulfil its role, while the role itself is continuously expanded through the accumulation of policies. That creates a circular process in which policy becomes the justification for more policy.</p>
<p dir="auto">The registry's original technical purpose is relatively narrow: maintain uniqueness, preserve accurate records, support interoperability, and provide a reliable registry service. Those are functions that the Internet genuinely requires.</p>
<p dir="auto">The difficulty begins when every new proposal is treated as another legitimate extension of the registry's mandate simply because it has passed through the PDP. At that point, the process itself begins manufacturing authority. Participation becomes confused with authorization, and procedural consensus gradually becomes institutional power.</p>
<p dir="auto">That is why I believe Nonhlanhla's observation about mandate laundering is important.</p>
<p dir="auto">A policy process should not become a mechanism through which an administrative body continually enlarges its own scope. Otherwise there is no meaningful limiting principle. Every proposal can simply be described as helping the registry perform its role, while the definition of that role quietly expands over time.</p>
<p dir="auto">The better question is much simpler.</p>
<p dir="auto">What technical invariant requires this policy?</p>
<p dir="auto">Does it preserve uniqueness?</p>
<p dir="auto">Does it improve registry accuracy?</p>
<p dir="auto">Does it protect interoperability?</p>
<p dir="auto">Does it strengthen operational continuity?</p>
<p dir="auto">If the answer is no, then we should be cautious about converting operational preferences into registry policy.</p>
<p dir="auto">This is also why I believe decentralisation is the longer-term direction we should be discussing.</p>
<p dir="auto">A resilient Internet should minimise dependence on institutional discretion. Coordination should remain thin, while operational decisions remain with operators. The registry should record reality, not increasingly define it. The more authority accumulates within a single administrative layer, the greater the temptation to use policy as a governance mechanism rather than as a narrow technical tool.</p>
<p dir="auto">The Internet became successful because it minimised the amount of central authority required for independent networks to interoperate. We should be careful not to move in the opposite direction by steadily expanding registry governance into areas where technical necessity has not been demonstrated.</p>
<p dir="auto">Regards,<br>
Gugu</p>
<p dir="auto">On Fri, 17 Jul 2026, 6:18 pm Seun Ojedeji <<a href="mailto:seun.ojedeji@gmail.com" style="color: #999999;">seun.ojedeji@gmail.com</a> <a href="mailto:seun.ojedeji@gmail.com" style="color: #999999;">mailto:seun.ojedeji@gmail.com</a>> wrote:</p>
<pre style="margin-left: 15px; margin-right: 15px; padding: 5px; background-color: #F7F7F7; border-radius: 5px 5px 5px 5px; overflow-x: auto; max-width: 90vw;"><code style="margin: 0 0; border-radius: 3px; background-color: #F7F7F7; padding: 0px;">I do support this proposal
Regards
On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal <hytham@tra.gov.eg
<mailto:hytham@tra.gov.eg>> wrote:
Dear PDWG,
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.
* Proposal Name: Hierarchical Names for New AS-SETs
* Proposal ID: AFPUB-2026-ASN-001-DRAFT02
* Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-
draft02.html <https://www.afrinic.net/afpub-2026-asn-001-
draft02.html>
Last Call closes on: July 31, 2026, at 23:59 UTC.
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.
As always, we kindly request that all participants adhere to the
AFRINIC Code of Conduct<https://www.afrinic.net/code <https://
www.afrinic.net/code>> to maintain a respectful and professional
environment on the mailing list.
Kind regards,
Haitham el Nakhal
AFRINIC PDWG Co-Chair
_______________________________________________
RPD mailing list
RPD@afrinic.net <mailto:RPD@afrinic.net>
https://lists.afrinic.net/mailman/listinfo/rpd <https://
lists.afrinic.net/mailman/listinfo/rpd>
--
------------------------------------------------------------------------
/Seun Ojedeji,
/
Bringing another down does not take you up - think about
your action!
_______________________________________________
RPD mailing list
RPD@afrinic.net <mailto:RPD@afrinic.net>
</code></pre>
<p dir="auto"><a href="https://lists.afrinic.net/mailman/listinfo/rpd" style="color: #999999;">https://lists.afrinic.net/mailman/listinfo/rpd</a> <https://<br>
lists.afrinic.net/mailman/listinfo/rpd></p>
<hr style="border: 0; height: 1px; background: #333; background-image: linear-gradient(to right, #ccc, #333, #ccc);">
<p dir="auto">RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" style="color: #999999;">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" style="color: #999999;">https://lists.afrinic.net/mailman/listinfo/rpd</a></p>
</blockquote>
<hr style="border: 0; height: 1px; background: #333; background-image: linear-gradient(to right, #ccc, #333, #ccc);">
<p dir="auto">RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" style="color: #777777;">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" style="color: #777777;">https://lists.afrinic.net/mailman/listinfo/rpd</a></p>
</blockquote>
</div>
</div>
</body>
</html>