[rpd] RPD Digest, Vol 222, Issue 45

[Gugu Dhlamini]

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/5a582fb9/attachment-0001.html>