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

[Simphiwe Ngubane]

Dear PDWG,

Good day colleagues, I would like to take the opportunity to vouchsafe the remarks made by Asamkele’s objection in accordance with remaining firmly opposed to AFPUB-2026-ASN-001-DRAFT02.

Noah, Nishal, and Seun, from the discursive propositions they have made and that I have seen, seem (and I say this with some hesitation but with profound respect for each of them) to treat the existence of an operational concern as if it automatically proves the necessity of this particular mandatory policy: in my humble opinion it does not.

Hierarchical naming may improve attribution by binding the creator of an AS-SET to an ASN maintainer. It does not verify that the membership of the set is accurate, current, complete, or authorised by every network represented within it. Automated filtering tools consume the contents of the object. They do not become safe merely because the object has a hierarchical name.

The proposal, from my perspective, addresses attribution, not the expansive full routing-authorisation problem being used in justifying the said proposal. That difference cannot be dismissed as philosophical or non-technical, to whit; it goes directly to whether the proposed rule actually prevents the claimed harm.

Nishal (whose discursive writing on this platform I have been consuming with rapacious intent) made a  suggestion that objectors do not “live and speak BGP”, this has a hue of questionability. Operational experience is valuable, but it is evidence, not exclusive authority. Technical expertise should explain the threat model, quantify the harm, and test whether the remedy works. It can be argued that it should not be used as a credential to exclude participants who question policy scope, proportionality, or institutional power.

Noah has also made claim that the community is “empowered” to impose such rules also requires limits. A policy process may coordinate around genuine technical invariants. It does not receive unlimited authority to make every preferred operational convention compulsory. Participation does not manufacture mandate. A mailing list is not a legislature, and support from regular participants is not a substitute for proof that compulsion is indispensable.

Seun, whom I have respectfully addressed directly before regarding a comment directed at myself, made the suggestion that those sharing similar objections should write another policy reverses the burden of proof. Objectors do not have to design a replacement enforcement regime before opposing this one. The authors and supporters of a mandatory proposal must demonstrate:


  *
that the harm is clearly evidenced;


  *
that the proposed rule materially prevents it;


  *
that less restrictive mechanisms have failed;


  *
and that registry enforcement is the minimum proportionate response.

The continued creation of flat AS-SETs does not prove that voluntary adoption has failed. It proves only that operators continue to use a format currently permitted by the system. Non-adoption of a preferred convention is not itself a technical failure.

Alternatives such as explicit provenance, source-qualified references, collision warnings, deterministic validation, tooling improvements, local rejection, and voluntary hierarchical naming have not been shown to be incapable of addressing the risk. They have largely been brushed aside because compulsion is administratively simpler.

Administrative simplicity is not a technical necessity. Nor does adoption by other RIRs settle the issue. Institutional convergence may be relevant experience, but it is not authority over AFRINIC. Other registries choosing the same rule does not remove AFRINIC’s obligation to test necessity, proportionality, residual risk, and operator impact for itself.

Ultimately, it should be given that the proper common layer should remain thin. It should protect uniqueness, proof of control, registry accuracy, security integrity, and operational continuity. It should not grow each time a useful practice can be converted into a mandatory database rule.

For these reasons, and unequivocally, I lend my support to Asamkele and maintain my strong opposition to this proposal.

Regards,
Simphiwe Ngubane






Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260720/7d46c031/attachment-0001.html>