<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Phetulo,<div><br></div><div>Responses below, in-line.</div><div><br id="lineBreakAtBeginningOfMessage"><div>
<div>Regards,<br>Jordi<br><br>@jordipalet<br></div>

</div>
<div><br><blockquote type="cite"><div>El 5 oct 2026, a las 11:56, Phetulo Dhlamini <phetulodhlamini@gmail.com> escribió:</div><br class="Apple-interchange-newline"><div><div dir="auto"><div dir="auto">Hi Jordi,</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">However, “implement, evaluate and improve” leaves a separate question: **what happens to existing outputs when a check is found to be unreliable?**</div></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="auto"><div dir="auto"><br></div><div dir="auto">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.</div></div></div></blockquote><div><br></div><div>If there is a "massive bug”, as part of the implementation process I’m sure the staff will also correct unreliable records.</div><br><blockquote type="cite"><div><div dir="auto"><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto"><br></div><div dir="auto">> 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.</div><div dir="auto"><br></div><div dir="auto">This would not prevent investigation based on independent, valid evidence.</div><div dir="auto"><br></div><div dir="auto">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.</div></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="auto"><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Phetulo</div></div>
</div></blockquote></div><br></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
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.<br>
<br>
</body></html>