[rpd] Updated Proposal - AfriNIC Policy Compliance Dashboard AFPUB-2026-GEN-002-DRAFT02

[jordi.palet at theipv6company.com]

Hi Nonjabulo,

The point is to implement each feature or test at once. For example to test if the reverse delegation is done, or to test if the relevant whois data is there, are two different processes. The implementation can tackle one first, then the other one, and so on.

At the same time, the proposal mentions in section 3 “history”, together with “periodically” in section 2. You will be able to see when every testing has been done and the result. If you updated something after a testing you will see the date when it was tested and you should know that you corrected it, right? I think this is a very normal way to measure periodically and state status at the measured time.

In other RIRs, this worked very well leaving the operational implementation details to the staff. They can adjust available human resources to develop each feature, and announce to the members once a new features is available (and even if needed in “beta”). Again, something very normal in terms of development. Exactly the same as bugs, they happen all the time in all kind of software, and fixing them can’t be pre-determined in a policy.

The waiver for the implementation is handled by the staff. This has been announced already several times for many other policies. Probably the staff will prepare a draft implementation plan for the board ratification, and it may depend on the boards decisions about staff priorities. Once more, this is very normal and nothing new in policy implementation.

Regards,
Jordi

@jordipalet

> El 2 oct 2026, a las 8:22, Nonjabulo Sphilile <nonjabulosphilile at gmail.com> escribió:
> 
> Dear colleagues,
> 
> A separate concern is where implementing an existing policy ends and creating a new compliance requirement begins. Paragraph 2 acknowledges that compliance cannot always be objectively measured, while requiring the dashboard’s automation to evolve alongside the CPM. However, the proposed text does not specify how changes to the meaning of a compliance test will be distinguished from ordinary software updates. 
> 
> The appendix includes outdated Whois information among the possible dashboard checks. Consider a hypothetical implementation that flags a record because it has not been edited for twelve months. That measures the record’s age, not whether its contents are wrong. Information may remain unchanged precisely because it remains accurate. Unless the applicable policy requires periodic reconfirmation, turning that age threshold into a compliance requirement would introduce an additional obligation through software configuration.
> 
> This distinction matters because the proposal anticipates incorporating different parts of the RSA and CPM progressively, according to Board and staff decisions, without a predefined completion timetable. Phased development can be practical, but members need to know whether a later phase merely introduces another way to check an existing obligation or introduces a stricter interpretation that was never established in the policy itself.
> 
> There is also an implementation question to resolve. CPM section 3.4.5 states that the implementation date should be less than six months after Last Call unless a waiver is requested. The authors should explain what would constitute implementation of this proposal, which checks would be included initially, and how subsequent phases would be governed. Open-ended development should not leave the substantive boundaries of the policy open-ended as well. 
> 
> A clearer specification would make each check independently reproducible, disclose its assumptions and thresholds, and publish a version history explaining changes. This reflects the principle that shared technical rules should be narrowly defined and independently verifiable, rather than depend on continuing institutional interpretation. 
> 
> Routine bug fixes would not need a new policy debate. But a change that introduces a new duty, stricter compliance condition or wider applicability should be identified and considered as a substantive policy change, not treated as routine dashboard maintenance. The software should implement the agreed rule, not become the place where additional rules are made.
> 
> Regards,
> Nonjabulo
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20261002/060c7996/attachment-0001.html>