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

[Paul Hjul]

I've reverted to the original thread name because this is squarely within
addressing the objections and possibly getting to a basis to move past last
call.

Dear Paul,

Thank you for your detailed response.

I must admit that I am struggling to understand the direction of your
> argument. While you raise several points about policy and operational
> matters, it is not clear to me how they demonstrate that this proposal
> requires a policy solution rather than an operational one.



> Could you clarify which specific concern cannot be addressed operationally and
> why a policy obligation is the only appropriate approach?



> I believe that distinction is central to the discussion.



> *BR,*



> *Thandeka Mseleku*


That is probably because there are a couple of arguments in the post - and
a lot of the argument is adopting a synthesis approach (it is also why I
didn't use the subject line of the proposal)

The word policy here needs to be unpacked. Because in all instances we are
dealing with a policy. You can have unwritten policies, informal policies
etc ... So whatever comes up there is a "policy" involved. So the question,
even if you are objecting to the proposal, is not whether there should be a
policy (because there is one of some form) but rather whether a policy
adopted by the RPD list and PDP processes as a community policy on AFRINIC.
If the operational objective here is achieved through a software change
then the policy underlying that software is where the policy is found. A
comment appearing in some rust code (or is it rusty c code) is just as much
a policy statement as anything else. What is being debated is about a
formal "Policy" - big P policy. In this instance the big P policy is a
formal community policy appearing in the CPM.
So in the case of AFRINIC there is a Consolidated Policy Manual. This
Manual binds AFRINIC and informs implementation. Therefore if the community
wishes to impose something onto an implementation and wants text to appear
in the CPM then this is the means to do it.
The CPM in chapter 7 deals with ASN (
https://afrinic.net/consolidated-policy-manual.html#ASN) and this chapter
certainly has implications for resource holders etc ... 7.7 potentially can
allow for the scope creep for which concern has been expressed but that
isn't at issue here.

So the question then is would CPM chapter 7 be better or worse with the
addition of 7.8. I fear that the objectors to the policy are erroneously
concluding the 7.8 will impose something that is better handled as an
operational matter. This is wrong because what 7.8 will do is dictate to
AFRINIC something that would otherwise be handled within 7.7. The outcome
is to reduce discretion rather than create it.

In fact, thinking about it, my only disagreement with the proposal as
written is that it doesn't slot in as 7.7 and renumber 7.7 to 7.8 -
although I think most people would prefer to avoid renumbering here.

The specific concern which is addressed by inclusion in the CPM is that it
directs the development of AFRINIC tools. More importantly the proposal
correctly locates the "policy obligation" onto the right point - AFRINIC
(in tool development). You'll notice that I indicate my concern that the
explanation on implementation can be improved - discussed further below.

It is not necessary (I think Andrew and Jordi have properly addressed this
aspect) that the proposal be "the only appropriate approach". The threshold
is that the approach is not inappropriate.

Dear Paul,



> Your own framing points to the central issue.



> RFC 2622 provides the specification, and AFRINIC’s database provides the implementation. The disputed extra layer is policy. If this is a service-side change that creates no obligation, sanction, or operational burden for resource holders, then a transparent implementation plan should be sufficient.



> A technical specification does not automatically require an institutional mandate. Policy creates permanence, interpretation risk, and precedent beyond the immediate database change. “It affects AFRINIC, not resource holders” is therefore not a complete safeguard, because AFRINIC remains the institution interpreting and enforcing the resulting rule.



> I support your request for the exact text and implementation plan. They should also state plainly that the change: is implemented only on the service side; creates no compliance duty or sanction for resource holders; cannot be extended to existing objects without a new review; and will be measured and reconsidered if the expected operational benefit does not appear.



> ...  The registry should implement what the system technically requires. It should not turn implementation convenience into permanent policy authority.



> Regards, Nonhlanhla



I don't see any point of disagreement except that, for the reason I've
given, there is a benefit in a "big P policy" - a formal inclusion in
the CPM. The concerns you appear to be relying upon arise in the
existing text in 7.7. I don't see any reason the co-chairs can't give
us 3 things:
[1] the wording of the policy
[2] the implementation plan
[3] what the CPM chapter 7 will look like in its entirety.

Saying that they should do so is not an expression that they are
obligated to - that's an entirely different debate - but rather is a
proposition that doing so will align with the intent and objective of
this process.

Because of the existing CPM paragraph 7 (I think they called sections
but I am actually not sure) the text does in fact safeguard. An
implementation plan speaks to how a given policy (whether formal or
otherwise) is brought into effect. The argument that you can implement
directly presupposes that there isn't a reason to put the text into
the manual.

Therefore in addition to the fact that there is rough consensus at the
PPM I think there is an adequate basis to infer that the proposal
addresses the concerns raised when properly unpacked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260721/d9b1ca67/attachment.html>