[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)

Sun Jul 19 15:07:34 UTC 2026

On 19 Jul 2026, at 16:46, Frank Habicht wrote:

> Didn't I just respond to the same text from
> Nia Petronella <nonhlanhlapetronella85 at gmail.com>
> ?????????????????
>

I’ll quote my friendly LLM:

```
- 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.
```

> On 7/17/2026 7:58 PM, Gugu Dhlamini wrote:
>> Hi All,
>>
>> Further to my OBJECTION of this POLICY PROPOSAL:
>>
>> I agree with Nonhlanhla's point regarding mandate laundering and the 
>> gradual expansion of institutional authority.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> That is why I believe Nonhlanhla's observation about mandate 
>> laundering is important.
>>
>> 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.
>>
>> The better question is much simpler.
>>
>> What technical invariant requires this policy?
>>
>> Does it preserve uniqueness?
>>
>> Does it improve registry accuracy?
>>
>> Does it protect interoperability?
>>
>> Does it strengthen operational continuity?
>>
>> If the answer is no, then we should be cautious about converting 
>> operational preferences into registry policy.
>>
>> This is also why I believe decentralisation is the longer-term 
>> direction we should be discussing.
>>
>> 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.
>>
>> 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.
>>
>> Regards,
>> Gugu
>>
>> On Fri, 17 Jul 2026, 6:18 pm Seun Ojedeji <seun.ojedeji at gmail.com 
>> <mailto:seun.ojedeji at gmail.com>> wrote:
>>
>>     I do support this proposal
>>
>>     Regards
>>
>>     On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal <hytham at tra.gov.eg
>>     <mailto:hytham at 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 at afrinic.net <mailto:RPD at 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 at afrinic.net <mailto:RPD at afrinic.net>
>>    https://lists.afrinic.net/mailman/listinfo/rpd <https://
>>     lists.afrinic.net/mailman/listinfo/rpd>
>>
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/cb63debb/attachment.html>