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

[Nonjabulo Sphilile]

Mark,

Thank you — your DNSSEC example is genuinely useful, and I think it
strengthens the point rather than answering it.

You show that the registry surfaces are uneven: a zone object can indicate
whether the zone is DNSSEC-signed, while the corresponding IP object
carries no indication of reverse DNSSEC. So an automated check that reads
"no DNSSEC indication" on the IP object is not observing a fact about your
reverse zones; it is observing a gap in the data model. Once that gap is
recorded as a dashboard item and pushed out under paragraph 3 as a
"possible non-compliance", it becomes a finding about the holder. That is
the core risk of building the dashboard on the signals that happen to be
available rather than on the compliance obligations the policy actually
imposes.

On the "I was here" button: as a member-facing convenience it is fine, and
I would support it. But it does not measure accuracy — it records that
someone logged in and clicked. It cannot distinguish a record that is
correct but old from one that is wrong. And if a record without a recent
confirmation is treated as suspect, we have created a periodic
reconfirmation duty that no policy requires: the additional obligation
through software configuration I raised earlier. A confirmation button can
be a comfort feature; it must not be the compliance test.

Your second point makes the same case: much number-resource data is static
precisely because it is correct. Age is not a proxy for accuracy in either
direction. So the appendix item "unavailable or outdated Whois
information", and any edit-recency threshold behind it, should either be
removed or rewritten so that an absent or old timestamp is not itself a
finding.

That is why I think the fix has to be structural rather than cosmetic. As
drafted: paragraph 3 notifies members *and staff* as soon as a **possible**
non-compliance is detected; paragraph 4 has staff verify the output of the
same automated testing that produced it, and then investigate and act; and
paragraph 7 then runs on its own calendar — publication of resources
proposed for recovery for up to three months, removal of the authoritative
NS records at two months, recovery of the resources and removal of the
holder records at three months — independently of the RSA/Bylaws notice,
response and appeal steps. A data gap can therefore start an enforcement
sequence, and the later steps act on the registry records themselves, which
affects third parties who rely on them and not only the member.

I would therefore ask the authors to: (1) drop age/edit-recency thresholds
and any check that treats an absent signal as non-compliance; (2) limit the
section to visibility and member-facing reporting, with no automatic
notification-to-staff or enforcement consequence; (3) require each check to
be defined in the policy text, versioned and independently reproducible;
and (4) state expressly that nothing in the section displaces the existing
notice, response and appeal process.

Until that is in the text, I have to oppose the proposal as drafted, and I
would ask that it not proceed to Last Call.

Regards,
Nonjabulo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20261002/f89dfb7f/attachment.html>