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

[jordi.palet at theipv6company.com]

Hi Phetulo,

Responses below, in-line.

Regards,
Jordi

@jordipalet

> El 5 oct 2026, a las 11:56, Phetulo Dhlamini <phetulodhlamini at gmail.com> escribió:
> 
> Hi Jordi,
> 
> Thank you for clarifying that the appendix is illustrative rather than normative. I accept that distinction, and agree that staff should be able to improve software without another policy-development process.
> 
> However, “implement, evaluate and improve” leaves a separate question: **what happens to existing outputs when a check is found to be unreliable?**

I will say, all of us have found a bug in software before, right? In this case if it happens, the staff will review the implementation, but this is not any consequence on that, because the proposal is not implementing measures, just displaying the status and sending notifications.

> 
> Section 3, item 3 requires automatic notifications and allows previous history to be shown. Item 4 provides for staff verification. Verification of individual findings is useful, but discovering a defective check could affect a whole class of earlier notifications and historical entries. Fixing the check prospectively would not, by itself, correct those records.

If there is a "massive bug”, as part of the implementation process I’m sure the staff will also correct unreliable records.

> 
> Could you identify the applicable arrangements for suspending affected notifications, correcting earlier results, informing affected members and preventing invalidated findings from being reused as evidence of non-compliance?
> 
> I am not suggesting that staff lack these capabilities, or that existing procedures contain no safeguards. My concern is whether these outcomes are assured. A minimum requirement could leave the technical implementation entirely to staff:
> 
> > Where AFRINIC establishes that a monitoring check produces materially erroneous results, it shall suspend affected automated notifications, identify and correct affected records, notify affected members, and validate the correction before resuming that check. Invalidated findings shall not be relied upon as evidence of non-compliance, while an audit trail of the correction shall be retained.
> 
> This would not prevent investigation based on independent, valid evidence.
> 
> If existing procedures already ensure these outcomes, identifying them would answer the concern. Otherwise, I would support adding this safeguard before adoption rather than relying on a future policy proposal after problems emerge.

I don’t think this is needed. If there is a bug in some monitoring, as part of the implementation/operational part, notifications may be put in hold. Of course, happy to add it if the impact analysis considers that it is needed to be explicit about that.

> 
> Regards,
> Phetulo



**********************************************
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/20261008/1167b293/attachment.html>