<div dir="auto">Good day,<div dir="auto"><div dir="auto"><br></div><div dir="auto">Building on the concerns already raised about obligations not established in the CPM, I have a specific wording question about section 1, “Summary of the problem being addressed by this proposal”.</div><div dir="auto"><br></div><div dir="auto">What does “even if not clearly stated” refer to?</div><div dir="auto"><br></div><div dir="auto">There is a difference between a CPM provision clearly establishing a requirement without expressly saying that failure to meet it constitutes non-compliance, and the CPM not clearly establishing the requirement itself. The current sentence does not distinguish those situations.</div><div dir="auto"><br></div><div dir="auto">Could the authors clarify which meaning is intended? If the intended meaning is the former, the sentence could read:</div><div dir="auto"><br></div><div dir="auto">“Failure to meet a clearly established, applicable CPM requirement constitutes non-compliance, whether or not the provision expressly describes that failure as non-compliance.”</div><div dir="auto"><br></div><div dir="auto">Please also clarify that ambiguity or silence in the CPM does not, by itself, establish a member’s non-compliance.</div><div dir="auto"><br></div><div dir="auto">Regards</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 02 Oct 2026, 15:53 , <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send RPD mailing list submissions to<br>
<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of RPD digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Updated Proposal - AfriNIC Policy Compliance Dashboard<br>
AFPUB-2026-GEN-002-DRAFT02 (Nonjabulo Sphilile)<br>
2. Re: Updated Proposal - AfriNIC Policy Compliance Dashboard<br>
AFPUB-2026-GEN-002-DRAFT02 (NP Petronella)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 2 Oct 2026 15:36:16 +0200<br>
From: Nonjabulo Sphilile <<a href="mailto:nonjabulosphilile@gmail.com" target="_blank" rel="noreferrer">nonjabulosphilile@gmail.com</a>><br>
To: <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
Subject: [rpd] Updated Proposal - AfriNIC Policy Compliance Dashboard<br>
AFPUB-2026-GEN-002-DRAFT02<br>
Message-ID:<br>
<<a href="mailto:CAJwHbZNPSFses3_oYMmcAF96JNow-qVBJKkODjVe1cvPEwVu1A@mail.gmail.com" target="_blank" rel="noreferrer">CAJwHbZNPSFses3_oYMmcAF96JNow-qVBJKkODjVe1cvPEwVu1A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Mark,<br>
<br>
Thank you ? your DNSSEC example is genuinely useful, and I think it<br>
strengthens the point rather than answering it.<br>
<br>
You show that the registry surfaces are uneven: a zone object can indicate<br>
whether the zone is DNSSEC-signed, while the corresponding IP object<br>
carries no indication of reverse DNSSEC. So an automated check that reads<br>
"no DNSSEC indication" on the IP object is not observing a fact about your<br>
reverse zones; it is observing a gap in the data model. Once that gap is<br>
recorded as a dashboard item and pushed out under paragraph 3 as a<br>
"possible non-compliance", it becomes a finding about the holder. That is<br>
the core risk of building the dashboard on the signals that happen to be<br>
available rather than on the compliance obligations the policy actually<br>
imposes.<br>
<br>
On the "I was here" button: as a member-facing convenience it is fine, and<br>
I would support it. But it does not measure accuracy ? it records that<br>
someone logged in and clicked. It cannot distinguish a record that is<br>
correct but old from one that is wrong. And if a record without a recent<br>
confirmation is treated as suspect, we have created a periodic<br>
reconfirmation duty that no policy requires: the additional obligation<br>
through software configuration I raised earlier. A confirmation button can<br>
be a comfort feature; it must not be the compliance test.<br>
<br>
Your second point makes the same case: much number-resource data is static<br>
precisely because it is correct. Age is not a proxy for accuracy in either<br>
direction. So the appendix item "unavailable or outdated Whois<br>
information", and any edit-recency threshold behind it, should either be<br>
removed or rewritten so that an absent or old timestamp is not itself a<br>
finding.<br>
<br>
That is why I think the fix has to be structural rather than cosmetic. As<br>
drafted: paragraph 3 notifies members *and staff* as soon as a **possible**<br>
non-compliance is detected; paragraph 4 has staff verify the output of the<br>
same automated testing that produced it, and then investigate and act; and<br>
paragraph 7 then runs on its own calendar ? publication of resources<br>
proposed for recovery for up to three months, removal of the authoritative<br>
NS records at two months, recovery of the resources and removal of the<br>
holder records at three months ? independently of the RSA/Bylaws notice,<br>
response and appeal steps. A data gap can therefore start an enforcement<br>
sequence, and the later steps act on the registry records themselves, which<br>
affects third parties who rely on them and not only the member.<br>
<br>
I would therefore ask the authors to: (1) drop age/edit-recency thresholds<br>
and any check that treats an absent signal as non-compliance; (2) limit the<br>
section to visibility and member-facing reporting, with no automatic<br>
notification-to-staff or enforcement consequence; (3) require each check to<br>
be defined in the policy text, versioned and independently reproducible;<br>
and (4) state expressly that nothing in the section displaces the existing<br>
notice, response and appeal process.<br>
<br>
Until that is in the text, I have to oppose the proposal as drafted, and I<br>
would ask that it not proceed to Last Call.<br>
<br>
Regards,<br>
Nonjabulo<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20261002/f89dfb7f/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20261002/f89dfb7f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 2 Oct 2026 13:53:05 +0000<br>
From: NP Petronella <<a href="mailto:NPertuniaPetronella@outlook.com" target="_blank" rel="noreferrer">NPertuniaPetronella@outlook.com</a>><br>
To: "<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>" <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>>, "<a href="mailto:pdwg-chairs@afrinic.net" target="_blank" rel="noreferrer">pdwg-chairs@afrinic.net</a>"<br>
<<a href="mailto:pdwg-chairs@afrinic.net" target="_blank" rel="noreferrer">pdwg-chairs@afrinic.net</a>><br>
Subject: Re: [rpd] Updated Proposal - AfriNIC Policy Compliance<br>
Dashboard AFPUB-2026-GEN-002-DRAFT02<br>
Message-ID:<br>
<<a href="mailto:VI3PR09MB653902CE3B3EF29A15FB6DBD58A4892@VI3PR09MB653902.eurprd09.prod.outlook.com" target="_blank" rel="noreferrer">VI3PR09MB653902CE3B3EF29A15FB6DBD58A4892@VI3PR09MB653902.eurprd09.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Dear PDWG,<br>
<br>
My comment is on one provision: the history requirement in the Notifications item of the proposed new CPM section.<br>
<br>
What the text says. Item 3 provides that the dashboard "Will automatically send notifications to members and staff as soon as a possible non-compliance is detected, showing previous history if available."<br>
<br>
Why that is a defect. The test for including history is availability ("if available"), not relevance. Available history and relevant history are not the same thing. The notification is also triggered by a 'possible' non-compliance ? before the staff verification contemplated by item 4 ? and the same bullet sends the material to staff, not only to the member. The proposal's own description of its design says staff warnings are for "a continued and repeated lack of compliance, or severe violation"; the operative wording is wider than that.<br>
<br>
Why the other safeguards do not answer this. Item 2, third paragraph, says the automation "will be made without the need to capture personal data or intrusion in the members' networks". That limits new collection. It does not say which existing information is to accompany a notification, which is precisely what item 3 requires. Existing data-protection law and AFRINIC's Privacy Policy govern how AFRINIC holds information; they do not determine what this policy puts into a notification. Because item 3 is the provision that specifies the content, the policy is the instrument that must state the test.<br>
<br>
It may be said that this belongs in implementation and that existing privacy rules already apply. If the notification's content were only an implementation choice, item 3 would not need to specify it. Because it specifies it, the rule needs a relevance test rather than an availability test. A general assurance cannot substitute for the rule when the rule is what the paragraph contains.<br>
<br>
Proposed amendment ? replace the first bullet of item 3 with:<br>
<br>
"Will automatically send notifications to the member as soon as a possible non-compliance is detected. The notification shall state that no determination has been made. Historical information shall be included only where it is necessary and relevant to understand or correct the possible non-compliance identified, and shall identify its source, date and current disposition. Automated findings that have not been confirmed under item 4 shall not form part of the history shown. Staff notification shall follow a determination under item 4, or the continued and repeated non-compliance described in the proposal's summary of how it addresses the problem."<br>
<br>
Questions for the authors and colleagues, for the record. (a) What does "previous history" include? (b) Is relevance or availability the test? (c) Does unconfirmed automated output enter that history? (d) Which published procedure governs its reuse?<br>
<br>
I ask that this be recorded as a distinct issue from the earlier dashboard-visibility/privacy exchange and from the scope question about item 4 raised by another commenter. I am not alleging unlawful processing, and I am not claiming that no safeguards exist. I am identifying a test the policy should state, and offering wording that achieves it.<br>
<br>
Kind regards,<br>
Nia<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20261002/5183b535/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20261002/5183b535/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 225, Issue 7<br>
***********************************<br>
</blockquote></div>