[rpd] RPD Digest, Vol 222, Issue 45

Sun Jul 19 04:14:10 UTC 2026

Dear colleagues,
The point about voluntary naming is where the argument breaks down. Hierarchical naming only protects you if the namespace is closed — if flat names remain creatable, any third party can still register a name that collides with or shadows yours, and your voluntary good behaviour does nothing to stop it. That is why every other RIR made it mandatory rather than advisory: the protection is only real when it's universal. On measurable harm: tools like bgpq4 expand AS-SET names, not ASNs, so when a name is ambiguous the generated prefix-filter can silently include the wrong prefixes or drop the right ones. That is a routing outcome, not a labelling aesthetic — and it is precisely the "accurate routing information" you say the registry should support. On least-restrictive: this proposal already is the minimum — new objects only, no renaming, no other set types, no ongoing registry discretion. It is hard to describe a narrower intervention that still closes the namespace. And the point about other RIRs isn't an appeal to conformity; IRR data is consumed globally as a single namespace by operators who query multiple sources, so AFRINIC remaining the one registry that permits flat names doesn't preserve our independence — it just makes our data the weak link in everyone else's filters. Finally, responding to objections individually is engaging with them on their merits; that is what the process asks for.
Regards

On 18 Jul 2026, at 21:49, Nia Petronella wrote:

> Dear PDWG,
>
> I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this
> proposal.
>
> Responding to objectors one by one does not resolve the common concern they
> have raised. A collision between AS-SET labels is not a failure of ASN or
> prefix uniqueness, and repeating that characterization does not make it
> technically correct.
>
> The proposal still has not demonstrated measurable operational harm, why
> voluntary hierarchical naming is insufficient, or why mandatory registry
> intervention is the least restrictive solution. Adoption by other RIRs is
> relevant, but institutional uniformity is not proof of technical necessity.
>
> A policy process should examine objections on their merits, not treat
> repeated disagreement as something to be individually overcome. The
> registry should support accurate routing information without converting
> every preferred convention into compulsory policy.
>
> I therefore support the objections already raised and maintain my
> opposition.
>
> Regards,
> Nonhlanhla
>
> On Sat, 18 Jul 2026, 9:46 pm <rpd-request at afrinic.net> wrote:
>
>> Send RPD mailing list submissions to
>>         rpd at afrinic.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        https://lists.afrinic.net/mailman/listinfo/rpd
>> or, via email, send a message with subject or body 'help' to
>>         rpd-request at afrinic.net
>>
>> You can reach the person managing the list at
>>         rpd-owner at afrinic.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of RPD digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names
>>       for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage)
>>    2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names
>>       for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli)
>>    3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names
>>       for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 18 Jul 2026 20:28:16 +0200
>> From: Hendrik Visage <hvisage at hevis.co.za>
>> To: Asamkele Menzeleli <asamkele.menzeleli18 at maharishinstitute.org>
>> Cc: rpd-owner at afrinic.net, rpd at afrinic.net
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical
>>         Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>> Message-ID: <6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66 at hevis.co.za>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Hello Asamkele,
>> Respectfully, this proposal does exactly what you're asking for ? it
>> maintains uniqueness. Flat AS-SET names can be registered by anyone, so
>> two operators can create the same name and there is no way to tell
>> afterwards which ASN it belongs to. That is a uniqueness failure in the
>> registry's own data, and fixing it is squarely within the mandate you
>> describe, not an expansion of it. The proposal adds no governance layer:
>> it applies only to newly created AS-SETs, leaves existing objects
>> untouched, and doesn't extend to route-sets or anything else. And the
>> operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and
>> LACNIC have all implemented hierarchical AS-SET naming, which would
>> leave AFRINIC as the only registry whose IRR data still permits name
>> collisions.
>> Regards
>>
>> ---
>> 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 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote:
>>
>>> Hello everyone,
>>>
>>> I object to this proposal.
>>>
>>> I also agree with Nonhlanhla's point regarding mandate laundering. We
>>> should be careful not to confuse policy development with expanding
>>> institutional authority.
>>>
>>> Policies should reflect demonstrated operational realities and
>>> technical
>>> necessity. They should not become governance mechanisms that gradually
>>> enlarge the registry's role beyond maintaining uniqueness, accurate
>>> records, and operational coordination.
>>>
>>> A registry should record reality, not create new layers of governance
>>> through policy.
>>>
>>> Regards,
>>> Asamkele Menzeleli
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html
>>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 18 Jul 2026 21:05:38 +0200
>> From: Asamkele Menzeleli <asamkele.menzeleli18 at maharishinstitute.org>
>> To: rpd at afrinic.net
>> Cc: rpd-owner at afrinic.net
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical
>>         Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>> Message-ID:
>>         <CAP3o3_aaSmMp7onNPHESjeoAScNZCZbg_FFjed=
>> Yxp+MhGJFpQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Dear Hendrik,
>>
>> I disagree with your characterization.
>>
>> A collision between two AS-SET names is not the same as a failure of
>> Internet number-resource uniqueness. The uniqueness function of the
>> registry concerns ASNs, prefixes, proof of control and accurate
>> registration of those resources. An AS-SET is an operational routing-policy
>> object. Confusing the naming convention of that object with the uniqueness
>> of the underlying number resource expands the meaning of ?uniqueness? far
>> beyond its proper technical scope.
>>
>> The fact that two operators may choose the same flat label may justify
>> better tooling, clearer warnings, stronger validation or voluntary
>> hierarchical naming. It does not automatically justify a mandatory policy
>> rule.
>>
>> That distinction is precisely the concern I raised. Institutional authority
>> often expands by redefining a useful administrative preference as a
>> technical necessity. Once every data-quality issue is described as a
>> uniqueness failure, there is effectively no limit to what may be brought
>> into mandatory registry policy.
>>
>> The proposal?s limited scope does not answer that concern. A new
>> enforcement power does not cease to be enforcement merely because it
>> applies prospectively or begins with one object type. The correct test is
>> whether the rule is indispensable to preserving the operation of running
>> networks, and whether a less restrictive mechanism cannot achieve the same
>> outcome.
>>
>> You also repeat that the other four RIRs have implemented hierarchical
>> naming. That demonstrates institutional adoption elsewhere. It does not
>> demonstrate that AFRINIC operators have authorized the same rule, that
>> actual routing failures in this region require it, or that voluntary and
>> technical alternatives are inadequate. Four registries making the same
>> choice is not a substitute for evidence.
>>
>> A registry should record operational reality accurately and provide
>> operators with tools to manage routing information safely. It should not
>> turn every preferred convention into mandatory governance merely because
>> uniformity looks tidy from the registry side.
>>
>> 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.
>>
>> Regards,
>> Asamkele Menzeleli
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html
>>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 18 Jul 2026 21:45:03 +0200
>> From: Gugu Dhlamini <gugudhlamini343 at gmail.com>
>> To: "asamkele.menzeleli18 at maharishinstitute.org"
>>         <asamkele.menzeleli18 at maharishinstitute.org>,  "
>> hvisage at hevis.co.za"
>>         <hvisage at hevis.co.za>, rpd at afrinic.net, rpd-owner at afrinic.net
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical
>>         Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>> Message-ID:
>>         <
>> CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Dear PDWG,
>>
>> I agree with Asamkele and disagree with Hendrik?s perspective.
>>
>> This is substantially the same argument Hendrik made in response to Tshepo:
>> that because a naming collision can occur, the issue must therefore be
>> treated as a failure of registry uniqueness and made subject to mandatory
>> policy. That conclusion does not follow.
>>
>> A collision between AS-SET labels is not the same as duplicate allocation
>> of an ASN or IP prefix. The underlying number resources remain unique. What
>> is being discussed is the naming and interpretation of an operational
>> routing object. That may justify better tools, warnings, validation,
>> documentation, or voluntary hierarchical naming, but it does not
>> automatically justify expanding mandatory registry authority.
>>
>> There is also an important ethical question here. Policy power should not
>> be enlarged merely because the proposed requirement appears useful, tidy,
>> or widely adopted elsewhere. The burden lies with those seeking compulsion
>> to show actual harm, necessity, proportionality, and the failure of less
>> restrictive alternatives. Operators should not be forced to surrender
>> discretion simply because an institution prefers uniformity.
>>
>> The fact that four other RIRs adopted a similar convention is not proof
>> that AFRINIC must do the same. Institutional repetition is not technical
>> necessity, and participation in the PDWG should not become a ritual for
>> ratifying choices already made elsewhere.
>>
>> The registry should preserve number-resource uniqueness, registry accuracy,
>> and operational continuity. It should not stretch those concepts until
>> every preferred operational convention becomes mandatory policy.
>>
>> For these reasons, I support Asamkele?s objection and remain opposed to the
>> proposal.
>>
>> Regards,
>> Nonhlanhla
>> On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli <
>> asamkele.menzeleli18 at maharishinstitute.org> wrote:
>>
>>> Dear Hendrik,
>>>
>>> I disagree with your characterization.
>>>
>>> A collision between two AS-SET names is not the same as a failure of
>>> Internet number-resource uniqueness. The uniqueness function of the
>>> registry concerns ASNs, prefixes, proof of control and accurate
>>> registration of those resources. An AS-SET is an operational
>> routing-policy
>>> object. Confusing the naming convention of that object with the
>> uniqueness
>>> of the underlying number resource expands the meaning of ?uniqueness? far
>>> beyond its proper technical scope.
>>>
>>> The fact that two operators may choose the same flat label may justify
>>> better tooling, clearer warnings, stronger validation or voluntary
>>> hierarchical naming. It does not automatically justify a mandatory policy
>>> rule.
>>>
>>> That distinction is precisely the concern I raised. Institutional
>>> authority often expands by redefining a useful administrative preference
>> as
>>> a technical necessity. Once every data-quality issue is described as a
>>> uniqueness failure, there is effectively no limit to what may be brought
>>> into mandatory registry policy.
>>>
>>> The proposal?s limited scope does not answer that concern. A new
>>> enforcement power does not cease to be enforcement merely because it
>>> applies prospectively or begins with one object type. The correct test is
>>> whether the rule is indispensable to preserving the operation of running
>>> networks, and whether a less restrictive mechanism cannot achieve the
>> same
>>> outcome.
>>>
>>> You also repeat that the other four RIRs have implemented hierarchical
>>> naming. That demonstrates institutional adoption elsewhere. It does not
>>> demonstrate that AFRINIC operators have authorized the same rule, that
>>> actual routing failures in this region require it, or that voluntary and
>>> technical alternatives are inadequate. Four registries making the same
>>> choice is not a substitute for evidence.
>>>
>>> A registry should record operational reality accurately and provide
>>> operators with tools to manage routing information safely. It should not
>>> turn every preferred convention into mandatory governance merely because
>>> uniformity looks tidy from the registry side.
>>>
>>> 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.
>>>
>>> Regards,
>>> Asamkele Menzeleli
>>> _______________________________________________
>>> 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/20260718/7d3628bc/attachment.html
>>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>>
>>
>> ------------------------------
>>
>> End of RPD Digest, Vol 222, Issue 45
>> ************************************
>>

> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd