[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 7:51 PM, Nia Petronella wrote:
> Hello Seun,
> 
> That response illustrates precisely the concern.
> 
> Saying that a proposal “helps the RIR fulfil its role” does not answer 
> whether the proposal expands that role. It merely assumes the scope of 
> the role in advance and then uses policy adoption to validate the 
> assumption.
> 
> That is circular.
> 
> The registry’s original technical function is narrow: preserve 
> uniqueness, maintain accurate records, support contactability, record 
> changes of control, and protect operational continuity. Those functions 
> justify a registry. They do not create a general mandate to regulate 
> every practice that can be attached to a registry object.

So, until 2013 (Lusaka) there was a discussion and (by 2013) conclusion, 
that AfriNIC should operate an Internet Routing REGISTRY (IRR). You 
might have missed this.

Since then, AfriNIC is not only dealing out IPv4, IPv6, ASNs, but also 
allowing members with those resources to create route[6] objects, and 
also (anyone) to create as-set objects.

The rules / policies for the latter is what we're discussing. And 
unfortunately it took quite a long while till most people understood 
that just like IPs and ASNs, it would be a good thing if AS-SETs were 
also unique, assuredly.

That's what we're trying to fix. Unfortunately some people haven't 
understood that yet. But we'll get there. Maybe it's just their 
incentives that make them not understand.

> A policy does not become legitimate merely because the registry can 
> administer it. Nor does ratification transform an administrative 
> preference into a technical necessity.

Please note: we are having a case where we started with the 'technical 
necessity'.

> That is mandate laundering.

As mentioned: 2013 [1] was the mandate to operate an IRR. Now we are 
trying to improve it from an IRR that allows dangerous garbage [say: 
toxic waste] to an IRR that doesn't allow dangerous garbage.

Hope that explanation helps.

> A narrow coordination function is passed through the language of policy, 
> consensus, and community until it re-emerges as institutional authority. 
> The process then points to its own output as proof that the authority 
> existed all along.

the authority is and was with this WG. With the above you are trying to 
make it more complicated, right?


[snip]

> Rough consensus does not give a registry an unlimited governance surface 
> over operators, routing practice, commercial arrangements, naming 
> conventions, or future implementation choices.

You know what gives AfriNIC 'an unlimited governance surface over 
operators, routing practice, commercial arrangements, naming 
conventions, or future implementation choices' ???
Nothing.

We (the humans and AIs) in this WG are talking about what can be in that 
IRR Database.

Maybe the ones using that DB should have a say about what should be in 
there. Have you ever used it?


> The proper question is: what technical invariant requires this rule to 
> be mandatory?

The operational problems in the problem statement. Which were well put.


> Does it protect uniqueness?

of AS-SETs, for future creations of same. Yes.

> Does it prevent duplicate registration?

of AS-SETs. Yes.

> Does it preserve registry accuracy?

Not if the Iv4,IPv6,ASN registry, which i guess you're referring to...

> Does it protect security integrity?

Indirectly. It improves a tool that network operators can use (if they 
so wish) to prevent incorrect routing announcements. In the operators 
responsibility.

> Does it preserve operational continuity?

Not by itself. But it can support a tool (software) that does this.

> If it does not, then it is not a necessary registry function. It is 
> institutional preference being converted into enforceable policy.

You must have noticed the prference of network operators by now. This is 
not (AfriNIC) 'institutional preference' !

The proposal originated from a network operator.


> There is also an important distinction between recording a practice and 
> governing it. A registry may accurately record AS-SET information.

are you aware that AfriNIC members and also everyone else is generating 
this IRR content?

> It 
> may provide technical formats and interoperable publication mechanisms. 
> It should not assume that maintaining the database gives it authority to 
> prescribe every naming structure used by operators.

not *every*. But some. As decided by this here WG.


> The registry should describe operational reality, not manufacture it 
> through policy and then enforce obedience through control of the 
> registry layer.

And this WG should mandate the IRR operator (AfriNIC) to restrict 
naming, since it is of operational benefit.


> So yes, this proposal does expand the governance surface. It does so by 
> converting a naming convention into a policy obligation and then placing 
> the registry in the position of interpreting, administering, and 
> enforcing that obligation.

so when governments made rulings such as "you should always drive on the 
left-hand side of the road" or "you should always drive on the 
right-hand side of the road" that was also "converting a naming 
convention into a policy obligation" - right?


> Calling that “fulfilling the RIR’s role” does not resolve the objection.

Hey, it's improving the IRR's functionality, as per users of the IRR. 
Are you a user of any IRR?

Regards,
Frank

[1] Madhvi is allowed to correct me.