Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Thulisile Mazomba 219280444 at mycput.ac.za
Sun Jul 19 08:10:14 UTC 2026


Dear Nishal and Seun,

I agree with Asamkele, Gugu, Tshepo, and Nonhlanhla, and I remain opposed to AFPUB-2026-ASN-001-DRAFT02.

Nishal describes the proposal as an incremental improvement. But mandatory policy should not be justified merely by the possibility of improvement. It should define what success means, how that success will be measured, and what happens if the promised benefit does not materialise.

The proposal appears to contain no meaningful operational baseline. How many harmful collisions currently originate from the AFRINIC database? How many incorrect filters have resulted? What measurable reduction should hierarchical naming produce? How will the community distinguish an actual security improvement from simple compliance with a new naming format?

Without those answers, the policy risks creating a false assurance. Operators may see a hierarchical name and assume the object is trustworthy even though the accuracy of its members remains unverified. A rule that improves appearance while leaving substantive data risk intact can make unsafe reliance more likely, not less.

There is also no serious treatment of reversibility. Nishal says that if the policy proves mistaken in ten years, no harm will have occurred. That is an assumption, not an analysis. Mandatory formats create implementation dependencies, documentation burdens, tooling expectations, and institutional precedent. Once the registry becomes the enforcement point, reversal is rarely costless.

This is why the common coordination layer must remain minimal. A rule should enter that layer only when the protected invariant is clearly identified, the remedy is technically sufficient, and the consequences of centralising enforcement are understood. Policy should not be used as an experiment whose costs are carried by operators while its supporters declare success by adoption alone.

Seun’s suggestion that participants with similar objections should write another proposal also misunderstands the role of objection. The absence of a competing policy does not validate the current one. A proposal must stand on its own evidence, scope, and implementation design.

Nor does agreement among several participants weaken the objection. A shared concern may indicate that the proposal’s assumptions have not been answered. It should not be treated as a reason to advance the proposal despite those concerns.

The policy process should record and test operational reality. It should not manufacture obligation first and wait for running networks to prove the institution wrong later.

Until the proposal defines measurable harm, measurable benefit, residual risk, review criteria, and a credible rollback path, it should not proceed beyond last call.

I therefore maintain my objection.

Regards,
Thulisile Mazomba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/ba492115/attachment.html>


More information about the RPD mailing list