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

[Nonjabulo Sphilile]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20261002/3c92c347/attachment.html>