[rpd] RPD Digest, Vol 222, Issue 45

[Nia Petronella]

Dear Hendrik,

I agree with Gugu, Tshepo, and Asamkele, and I remain firmly opposed to
this proposal.

Your argument proves that mandatory hierarchical naming can close one path
to future flat-name collisions. It does not prove that the proposal secures
the routing information consumed by operators.

That difference is fundamental.

A hierarchical name authenticates the maintainer permitted to create the
object under an ASN. It does not authenticate every member placed inside
that object. It does not prove that the represented customer cone is
complete, current, or authorised. It does not prevent an authorised
maintainer from publishing stale, excessive, mistaken, or misleading
membership.

The tools you cite expand the contents of an AS-SET. They do not merely
validate the parent ASN in its name. Closing the namespace may improve
provenance, but it does not make the expanded data true.

The proposal is therefore being credited with a security outcome it cannot
deliver. It reduces one ambiguity while leaving the central semantic risk
intact. A partial control should be described as a partial control, not
elevated into a universal protection merely because it is easy to enforce
at object creation.

You also argue that AFRINIC would become the weak link because other RIRs
have adopted the rule. That is still institutional convergence being used
as a substitute for proving necessity. A globally consumed system requires
explicit source identity, deterministic validation, trustworthy provenance,
and local rejection of unsafe data. It does not follow that every source
must impose the same mandatory naming convention through registry policy.

A consumer that merges multiple IRR sources and silently treats an
ambiguous name as authoritative has made a validation decision. That design
choice cannot simply be transferred upward and converted into a new power
for the registry. Unsafe consumption is not cured only by restricting
production.

Nor is “new objects only” proof that this is the least restrictive
solution. It describes the proposal’s temporal scope. It does not
demonstrate that source-qualified queries, collision detection,
provenance-aware tooling, ambiguity rejection, or stronger object-content
validation are technically inadequate.

The minimum intervention is not automatically the smallest rule the
registry can enforce. It is the least coercive mechanism that protects the
actual invariant. That analysis has not been completed.

The broader concern is precisely this pattern: a technical inconvenience is
identified, one centralised remedy is proposed, and then the existence of
the inconvenience is treated as authority for compulsion. The registry’s
role expands one apparently narrow rule at a time. No one announces
enforcement creep. It arrives dressed as data hygiene.

A registry may maintain accurate records, expose provenance, warn about
collisions, and support safer tooling. It should not pretend that
controlling the name of a container guarantees the accuracy of what the
container says.

Responding to objections individually is not itself the problem. The
problem is that the same institutional answer is being repeated without
resolving the same substantive objection: the proposal authenticates object
creation but does not validate object content, and its supporters have not
shown why registry compulsion is the minimum necessary response.

The common layer must remain thin. It should protect what running networks
objectively require, not every convention that an institution can enforce.

For these reasons, I support Gugu, Tshepo, and Asamkele, and I maintain my
strong opposition to AFPUB-2026-ASN-001-DRAFT02.

Regards,
Nonhlanhla

On Sun, 19 Jul 2026, 6:14 am Hendrik Visage <hvisage at hevis.co.za> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/98fcd380/attachment-0001.html>