[rpd] RPD Digest, Vol 222, Issue 45

[Hendrik Visage]

Hi Gugu & Nia

 Just to be clear, I’m the operator of AS329532 & AS213481, Which ASNs are you representing that have issues with this AS-SET proposal?


---
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 19 Jul 2026, at 8:54, Gugu Dhlamini wrote:

> Dear Hendrik,
>
> I remain firmly opposed to your viewpoint, and I agree with Nonhlanhla.
>
> Your argument establishes that a closed hierarchical namespace can prevent
> future creation of flat-name collisions. It does not establish that this
> proposal solves the broader routing-authorisation problem being used to
> justify mandatory policy.
>
> The distinction remains important. Hierarchical naming can bind the creator
> of an AS-SET to the maintainer of an ASN. It does not verify that the
> contents of the set are accurate, current, complete, or authorised by every
> network represented within it. A hierarchically named object can still
> contain stale, excessive, or incorrect members. Tools such as bgpq4 will
> still expand those contents.
>
> The proposal therefore reduces one source of ambiguity. It does not make
> generated prefix filters inherently trustworthy.
>
> That matters because the policy is being defended not merely as a naming
> improvement, but as a necessary routing-security protection. The claimed
> benefit should be described honestly and proportionately. Attribution is
> improved. Semantic correctness is not guaranteed. The remaining failure
> modes do not disappear because the namespace has been closed.
>
> You also describe the proposal as the minimum intervention because it
> applies only to new AS-SETs. Narrow scope is relevant, but it does not by
> itself prove necessity. A rule may be small and still place an optional
> operational convention into the mandatory registry layer without first
> demonstrating that other technical controls are inadequate.
>
> The alternatives are not limited to voluntary good behaviour. They include
> explicit IRR source qualification, provenance display, collision detection,
> deterministic validation, tooling that refuses ambiguous references,
> stronger object-level authorization signals, and local rejection of
> untrusted data. The relevant question is whether those mechanisms can
> prevent silent ambiguity without making the registry the universal
> enforcement point.
>
> If a tool silently consumes an ambiguous name across multiple IRRs, that is
> also a tooling and validation failure. A coordination system should not
> answer every unsafe consumer assumption by expanding central compulsion at
> the producer layer.
>
> You further say that the namespace must be universal because IRR data is
> consumed globally. Global consumption does not automatically create global
> authority for one preferred implementation. It creates a need for clear
> source semantics, local validation, and explicit compatibility rules. The
> Internet has always depended on operators deciding which data sources they
> trust and how they validate them. That responsibility should not be quietly
> transferred upward each time a tool can be misconfigured or over-trusting.
>
> The fact that other RIRs closed their namespaces remains relevant
> experience. It is still not proof that AFRINIC must do the same through
> mandatory policy, nor that their adoption eliminated the underlying problem
> rather than only one visible symptom.
>
> A registry should maintain a truthful ledger and support safe coordination.
> It should not claim more than the proposed mechanism can actually deliver.
>
> This proposal prevents future flat-name creation. It does not validate
> AS-SET membership, guarantee accurate prefix filters, or establish that
> registry compulsion is the only technically sound response.
>
> For those reasons, my objection remains.
>
> Regards,
> Gugu
>
> On Sun, 19 Jul 2026, 6:17 am Hendrik Visage via RPD <rpd at afrinic.net> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> 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/bce95dbd/attachment-0001.html>