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

[jordi.palet at theipv6company.com]

Hi Nonjabulo,

I think you’re missing the point that appendix, examples, etc., are only that: examples.

They are not part of the policy text. The staff can use those examples to actually build on their own way. They can consult openly with the community what we think and in the end, if something is not good or not working well, the staff may address it, or even suggest to the community to work on a more detailed proposal.

We decided to drop the text in sections 6 and 7 because the previous proposal, 3 years ago, was not ratified because it was including all those details and they were considered encroaching the staff and the board. I don’t agree on that, as explained previously all that comes from a previous proposal in LACNIC that reached consensus and was implemented with all that detail, but I’m happy to let the staff and board to decide their own way.

If it doesn’t work, the community can always come back with more explicit text, but I think is fair give them an opportunity to decide on their own all those operational details and see how it works.

Regards,
Jordi

@jordipalet

> El 2 oct 2026, a las 15:36, Nonjabulo Sphilile <nonjabulosphilile at gmail.com> escribió:
> 
> 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
> _______________________________________________
> 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/fef9d9cb/attachment.html>