[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02)

[Frank Habicht]

Hi,

inline...

On 7/17/2026 6:39 PM, Nia Petronella wrote:
> Dear Colleagues,
> 
> I do *not* support adoption of this proposal.
> 

> A registry exists to maintain accurate records and protect uniqueness. 
> It may record. It may coordinate. It may protect uniqueness. It may not 
> rule. Once policy begins creating additional administrative structures 
> that are not strictly required for interoperability, we should ask 
> whether we are solving an Internet problem or an institutional one.

AfriNIC does (for many years) operate an Internet Routing Registry 
(IRR). Along the one for IP addresses and aut-num's.

RIRs are in a unique position to operate IRRs as they have a direct 
knowledge of which entities hold IP address resources. And only those 
holding IP resources can then create associated route[6] objects. This 
makes the RIR-operated IRRs authoritative, while the others (RADB, 
Level3, ...) are *not*.

I just helped this past week to clean up incorrect information in the 
"Level3" IRR - my national communications regulator can confirm.

You said above "It may protect uniqueness."
I agree with you that the Internet Routing *REGISTRY* should protect 
uniqueness. Globally.

It was a mistake to not do this from the beginning, this is now being 
corrected.

We have this way to avoid future creation of these collisions of AS-SET 
names that we have shown to exist.

Anyone opposing this solution can show a better one, as has been 
mentioned by others. [before last call would also be nice]

Otherwise, opposing means effectively that you want me to have the 
ability to create
AS-AKAMAI
AS-FACEBOOK
AS-SEACOM

That would mean you want to enable the IRR system to become more 
unpredictable.

As someone who has created policies/filter rules from IRR data, I would 
like to say that this is not good.


We unfortunately have not seen what the level of experience is that the 
opponents of this policy have with using Internet Routing Registries.

I gave an example on June 1st in 
https://lists.afrinic.net/pipermail/rpd/2026/014850.html how a collision 
was avoided.

It is in-scope for any operator of an IRR to make the rules for their 
IRR. It is good for AfriNIC to not allow names like the examples give above.


> This proposal also illustrates what Lu Heng describes as the *Policy 
> Mirror*. The issue is not hierarchical AS-SET names themselves, but the 
> continuing assumption that every operational practice should be 
> standardized through registry policy rather than left to voluntary 
> operator adoption. Running networks—not policy manuals—should determine 
> what survives.

How many networks do the opponents of this policy run?
How many networks does Lu Heng run?
Do we agree that there are 8533 route objects with maintainer 
LARUS-SERVICE-MNT in the AfriNIC DB? [1]
Referencing 557 origin networks? [2]

Are these origin networks listed in AS-SET's in different IRRs?
Can I create one with the same name in AfriNIC?
Can I omit some members from that AS-SET?
Will someone generating filters from that suddenly not allow certain IP 
resources?

> If hierarchical naming provides sufficient operational 
> value, operators will naturally deploy it without requiring another 
> layer of institutional governance.

I sincerely hope that my above questions pointed (anyone not 
artificially thinking) to the operational value.

If not, I will conclude:
It is difficult to get a man to understand something, when his salary 
depends on his not understanding it.
[Upton Sinclair]

> Furthermore, AFRINIC should be reducing policy complexity rather than 
> increasing it. *Running-Code Primacy* requires that policy remain the 
> minimum necessary to preserve interoperability and operational 
> continuity.

I wonder what's the source for this statement?

> Every additional policy object increases long-term 
> maintenance, interpretation, and enforcement costs while offering 
> limited benefit to the stability of the Internet itself. The common 
> layer should remain thin.

Many have concluded that in this case the benefit outweighs the cost.
Thank you.

> Finally, rough consensus should not be mistaken for proof that 
> additional governance is desirable.

I believe this is universally agreed. Nothing new.
Otherwise the rough consensus that a certain AfriNIC member in 
Seychelles doesn't really need 6 million Pv4 addresses would have let to 
some action already - right?

> A mailing list is not a legislature, 
> and community discussion should not automatically become permanent 
> policy. Before adopting any proposal, we should first ask whether 
> failure to adopt would actually threaten uniqueness, interoperability, 
> or operational continuity.

Yes, it would. Hence the proposal exists, has a good problem statement, 
with actual example cases, and was adopted.

> If the answer is no, then the proposal 
> belongs in operational best practice, not in mandatory registry policy.

Answer is not no.

Regards,
Frank Habicht
has created AS-SETs, eBGP policies, prefix filters, advised colleagues 
against colliding AS-SET names


[1]
$ whois -h whois.afrinic.net "LARUS-SERVICE-MNT -i mnt-by -T route" | 
grep -E '^route:' | wc -l
     8533
$

[2]
$  whois -h whois.afrinic.net "LARUS-SERVICE-MNT -i mnt-by -T route" | 
grep -E '^origin:' | awk '{print $2}' | sort | uniq | wc -l
      557
$


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