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

[Hendrik Visage]

Well said both Seun & Nishal.

  Being a very young operator, actually running a multi-homed network, I 
quickly realized that hierarchical AS-SETS should be mandatory, not just 
“optional”, Not only from  technical and operational reasons, but 
also for AfriNIC to be a good Netizen in the global Internet

---
Hendrik Visage
Director/Owner
HeViS.Co Systems t/a Envisage Cloud Solutions
hvisage at hevis.co.za
GSM/SMS/Signal: +27-84-612-5345
InstantMessenger: https://t.me/hvisage

On 18 Jul 2026, at 22:10, Seun Ojedeji wrote:

> Well said Nishal and since it seem Nia, Asamkele, Gugu, and Tshepo, 
> agree
> on the same philosophy and infact they share similar content, perhaps 
> they
> can form co authors to propose what they feel is a better policy.
>
> However for now I support AFPUB-2026-ASN-001-DRAFT02 to move pass the 
> last
> call.
>
> Regards
>
> ----
> Sent from my mobile
> kindly excuse typos
>
>
>
> On Sat, 18 Jul 2026, 2:59 pm Nishal Goburdhan, 
> <nishal at controlfreak.co.za>
> wrote:
>
>>
>>
>> On 18 Jul 2026, at 21:05, Asamkele Menzeleli wrote:
>>
>>> My objection therefore remains. The proposal has not shown that
>> compulsory
>>> hierarchical naming is necessary to protect number-resource 
>>> uniqueness,
>> nor
>>> that the registry should extend its mandatory policy authority into 
>>> this
>>> area.
>>
>>
>> what you meant to say is that it hasn’t shown this “to you”.
>> and that’s ok;  policy proposals are never about appeasing 
>> everyone.  they
>> are about making incremental benefit.
>> what you are not seeing, is that this solution, has already been
>> demonstrated elsewhere in the world, has actually solved
>> Real-World-Operational problems.
>> you’re forgiven if you don’t see these problems - again - not 
>> everyone
>> lives and speaks bgp.
>>
>> but maybe i’m wrong - and maybe you *have* found a better sauce to 
>> solving
>> these problems;  problems which, real world network operators, have 
>> already
>> shown can be exploited, to significant detriment.  in which case, 
>> please
>> share that, because we’d love to benefit from your operational 
>> prowess.
>> but, f you haven’t - either found that sauce, or, are unwilling to 
>> share,
>> then appreciate that those of us that operate real networks, want the
>> better protections that this proposal brings.  even if you don’t.  
>> here’s
>> the thing;  the threat that “flat” names creates has already done 
>> this -
>> ie. they *have* been exploited, for no good, in the wild.  this is 
>> already
>> well documented, and discussed in operator forums.  and the 
>> objections as i
>> read them - and however strongly you may feel about them - haven’t 
>> failed
>> to address any kind of solution, or provided a technical alternate, 
>> or,
>> actually done anything except say:   “well, i don’t agree”
>>
>> also, as a tip, the last call part of the proposal is where you 
>> address
>> concerns that the _particular policy_ might have.  you haven’t 
>> really done
>> any of that.  so please, try to focus your the discussion on 
>> _technical
>> merit solely_.  here’s what would help:
>> - show an alternate solution by a vendor / from a technical list
>> - show real world problems that this creates, as documented on a 
>> technical
>> forum (eg. afnog, sidr, secops, ..)
>>
>> no-one here has all the answers;  and, if we discover in 10years, 
>> that
>> “flat” names were better, no penguins would have been harmed.  
>> but, we
>> would have enabled protections for african operators.
>>
>> —n.
>>
>> _______________________________________________
>> 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/083072ff/attachment-0001.html>