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

Thu Jul 30 04:59:36 UTC 2026

Dear colleagues,

I think we've now narrowed the discussion down to the main technical issue.

I agree that this proposal is about naming and not about defining how a
future inter-RIR transfer policy should work. If AFRINIC ever adopts such a
policy, those details would naturally belong there.

That said, I also think it's important that we don't claim more for this
proposal than what it can actually guarantee.

>From my reading, the proposal clearly provides benefits such as unique
naming at creation, a more structured namespace, and improved
administrative clarity within the AFRINIC IRR. Those are meaningful
improvements.

Where I still have reservations is the suggestion that these naming rules,
by themselves, provide a continuous, globally authoritative identity for
AS-SET objects across all routing tools and IRR consumers. If that is part
of the proposal's intended benefit, it would be helpful to see the
implementation evidence or operational examples that demonstrate this
behaviour in practice.

If that evidence does not exist, then I believe the proposal and its Impact
Assessment would be stronger if they simply described the guarantees the
mechanism actually provides, without extending those claims further.

I believe that kind of clarity would benefit everyone, regardless of
whether they support or oppose the proposal.

Kind regards,

Fundiswa Nadia Maseko

On Wed, 29 Jul 2026, 20:29 , <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) (Tshepo Masuku)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 29 Jul 2026 20:21:10 +0200
> From: Hendrik Visage <hvisage at hevis.co.za>
> To: Tshepo Masuku <TshepoMasuku26 at hotmail.com>, 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: <32BB6C1F-18CF-44AC-ACDF-979D0BE9E81D at hevis.co.za>
> Content-Type: text/plain; markup=markdown
>
> Good day Tshepo,
>
> Three short points, and then I'll leave the record to the Co-Chairs.
>
> First: your scenario requires an inter-RIR ASN transfer. AFRINIC does
> not perform inter-RIR transfers - not for ASNs, not for anything.
> There is no policy for it in the CPM, and the other registries list
> AFRINIC as not approved for transfers in either direction. So the
> event your whole scenario depends on cannot occur in this region
> under any rule that exists - and a NAMING proposal can neither create
> that capability nor govern it. If our community one day adopts an
> inter-RIR transfer policy, THAT policy is where object handling on
> transfer gets defined - which is exactly where the deployed
> registries define it today (APNIC's transfer conditions, for example,
> spell out which dependent objects get deleted when a resource
> moves). You are asking the wrong document to answer, before the
> right document exists.
>
> Second: the "how do tools distinguish the current authoritative
> object from the historical one" question has a running answer
> already: the delegated statistics files every RIR publishes daily,
> which record each ASN's current registry - transfers included,
> single-valued at every instant. That is the map the whole IRR
> tooling world uses today. And notice: under flat names your
> succession scenario is strictly worse, because then there is no map
> at all.
>
> Third, on Question 7: I asked for the technical issues and real-world
> examples where this policy would negatively affect YOUR current or
> future operations. A hypothetical relying operator, in a transfer
> type that is not available in this region, is not that. So I note,
> with appreciation for the attempt, that Question 7 still stands
> unanswered. And to be fair on the record: of the six questions of
> (015344), yours in (015348) remain the only point-by-point answers
> given - answers I credited in (015404) - the rest of the opposition
> has answered none.
>
> The record is now complete enough for the Co-Chairs to do their work,
> and I am content to leave it to them.
>
> Regards,
> Hendrik Visage (AS329532; also AS213481)
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 29 Jul 2026 18:28:45 +0000
> From: Tshepo Masuku <TshepoMasuku26 at hotmail.com>
> To: Hendrik Visage <hvisage at hevis.co.za>, "rpd 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:
>         <
> AM6PR04MB59921D9A6819806346BA1927CACA2 at AM6PR04MB5992.eurprd04.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear Hendrik,
>
> Thank you. I will respond directly to your three points.
>
> First, Question 7 is a test you introduced. It is not a requirement that
> every objector demonstrate personal damage to their own production network
> before a policy concern may be considered. A mandatory rule may be
> challenged because its state model, implementation assumptions, or
> enforcement boundaries are incomplete.
>
> Making personal operational harm the admission price for an objection
> would turn an open PDP into an operator-credential test. Experience is
> relevant evidence; it is not exclusive authority.
>
> Second, the delegated statistics file does not provide the guarantee you
> claim. It maps an ASN to its current registry. It does not identify which
> AS-SET object a resolver actually used, invalidate an old copy, update
> every mirror or cache simultaneously, or confirm the present maintainer
> chain of a delegated descendant.
>
> A file published daily is not a globally atomic authority mechanism.
>
> If the claim is that running tools already use that map to reject
> historical or conflicting AS-SET objects, please identify the relevant
> resolver behaviour, code path, or test case. Otherwise, this remains an
> architectural assumption rather than running-code evidence.
>
> The proposal can reasonably claim that a new name is unique and
> authenticated inside the AFRINIC database at creation time. It should not
> be credited with continuous, globally deterministic source resolution
> unless that behaviour is demonstrated across the actual tooling that
> consumes the data.
>
> Third, you asked for effects on current or future operations, but then
> excluded the future scenario because AFRINIC does not currently support
> inter-RIR ASN transfers. Those positions cannot both stand.
>
> A policy intended to remain in force cannot use the present absence of
> another policy as proof that its own assumptions will remain valid
> indefinitely. If a future transfer policy must define the object
> transition, then that confirms the present proposal does not define it.
>
> I am not asking this proposal to solve every transfer problem. I am asking
> that its text and Impact Assessment claim only what the mechanism actually
> guarantees.
>
> The unresolved issue is therefore specific: the proposal creates local,
> creation-time naming and authentication rules, while its supporters
> attribute to it a global and continuing authority property that has not
> been demonstrated in running tools.
>
> The record is not made complete merely by declaring it complete. Until the
> claims are narrowed to the property actually proved, I remain opposed.
>
> Regards,
> Tshepo
>
>
> ________________________________
> From: Hendrik Visage <hvisage at hevis.co.za>
> Sent: Wednesday, 29 July 2026 20:21:10
> To: Tshepo Masuku <TshepoMasuku26 at hotmail.com>; rpd 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)
>
> Good day Tshepo,
>
> Three short points, and then I'll leave the record to the Co-Chairs.
>
> First: your scenario requires an inter-RIR ASN transfer. AFRINIC does
> not perform inter-RIR transfers - not for ASNs, not for anything.
> There is no policy for it in the CPM, and the other registries list
> AFRINIC as not approved for transfers in either direction. So the
> event your whole scenario depends on cannot occur in this region
> under any rule that exists - and a NAMING proposal can neither create
> that capability nor govern it. If our community one day adopts an
> inter-RIR transfer policy, THAT policy is where object handling on
> transfer gets defined - which is exactly where the deployed
> registries define it today (APNIC's transfer conditions, for example,
> spell out which dependent objects get deleted when a resource
> moves). You are asking the wrong document to answer, before the
> right document exists.
>
> Second: the "how do tools distinguish the current authoritative
> object from the historical one" question has a running answer
> already: the delegated statistics files every RIR publishes daily,
> which record each ASN's current registry - transfers included,
> single-valued at every instant. That is the map the whole IRR
> tooling world uses today. And notice: under flat names your
> succession scenario is strictly worse, because then there is no map
> at all.
>
> Third, on Question 7: I asked for the technical issues and real-world
> examples where this policy would negatively affect YOUR current or
> future operations. A hypothetical relying operator, in a transfer
> type that is not available in this region, is not that. So I note,
> with appreciation for the attempt, that Question 7 still stands
> unanswered. And to be fair on the record: of the six questions of
> (015344), yours in (015348) remain the only point-by-point answers
> given - answers I credited in (015404) - the rest of the opposition
> has answered none.
>
> The record is now complete enough for the Co-Chairs to do their work,
> and I am content to leave it to them.
>
> Regards,
> Hendrik Visage (AS329532; also AS213481)
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.afrinic.net/pipermail/rpd/attachments/20260729/60d10620/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 223
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260730/7978fb15/attachment-0001.html>