<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
Hi Hendrik, Jordi</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
<br>
</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
I used the 'Reply all' option to respond to Jordi’s reply to my earlier email, rather than composing a new email because it's more efficient.</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
<br>
</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
For clarity, my response concerns the AFRINIC Policy Compliance Dashboard, AFPUB-2026-GEN-002-DRAFT02, specifically Jordi’s comments on my earlier message. I was continuing that exchange, not introducing a new discussion.</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
<br>
</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
I understand your concern about how the message appeared in the digest. The above identifies the exchange I was addressing so that readers can follow the substantive points.</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
<br>
</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
Regards,</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" dir="auto">
Nia</div>
<div id="ms-outlook-mobile-body-separator-line" data-applydefaultfontstyles="true" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
</div>
<div style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" id="ms-outlook-mobile-signature">
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Hendrik Visage <hvisage@hevis.co.za><br>
<b>Sent:</b> Thursday, 08 October 2026 14:21:52<br>
<b>To:</b> NP Petronella <NPertuniaPetronella@outlook.com><br>
<b>Cc:</b> rpd@afrinic.net <rpd@afrinic.net>; jordi.palet@consulintel.es <jordi.palet@consulintel.es><br>
<b>Subject:</b> Re: [rpd] RPD Digest, Vol 225, Issue 10</font>
<div> </div>
</div>
<div style="font-family:sans-serif">
<div class="x_plaintext" style="white-space:normal">
<p dir="auto">Nia, please respond with the actual email thread, as responding on the digest breaks the thread for other humans that tries to follow the threads, and not have the time to figure out which thread your digest response is refering to</p>
<br>
<p dir="auto">On 5 Oct 2026, at 9:03, NP Petronella wrote:</p>
</div>
<blockquote class="x_embedded" style="margin:0 0 5px; padding-left:5px; border-left:2px solid #777777; color:#777777">
<div id="x_D8674C0C-60AC-4E78-A6E2-D14AF492D1D2">
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Hi Jordi,</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Thank you for clarifying. Your explanation raises a separate issue: 'where does non-intrusive dashboard monitoring end, and a separately authorised audit begin?'</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
You explain that monitoring does not require personal-data collection or entry into a member’s network, but that checks requiring access “inside” the network could be implemented through audits.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
I accept that AFRINIC may already possess relevant audit powers. I am not suggesting that an investigation must wait until a breach has been proved. However, the existence of audit powers does not, by itself, explain their permissible scope or the conditions
for exercising them.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
There are three distinct questions:</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
1. What can the dashboard observe?</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
2. What grounds justify opening an audit?</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
3. What information or access may AFRINIC require during that audit?</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Calling a finding “possible” addresses uncertainty about compliance. It does not answer the second and third questions.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
For example, where an external observation cannot establish a fact inside a member’s network, that is an evidential limitation. It may justify further review under existing procedures, but should not itself create a new obligation to provide internal access
or disclose otherwise non-public information.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Could you identify the applicable provisions governing that transition, including the relevant authority, initiation criteria and limits on information gathering? References to other RIRs’ practices cannot establish what AFRINIC’s own instruments authorise.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
A narrow clarification could read:</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
> This policy does not create or expand powers to access members’ networks or require disclosure of non-public information. Any audit informed by dashboard findings remains subject to the applicable existing authority, initiation criteria and safeguards. Dashboard
findings do not waive or lower those requirements.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
This would preserve legitimate audits and staff implementation flexibility. It would simply make clear that a notification mechanism is not an additional source of investigative authority.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
A registry should exercise defined functions under explicit rules. Operational flexibility should not obscure the boundary of those powers.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
If the existing text already establishes this boundary unambiguously, please identify the provision. Otherwise, I would ask that it be clarified before ratification. Until that question is resolved, I do not support ratification of the present draft.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Regards, </div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(33,33,33)">
Nia</div>
<div id="x_ms-outlook-mobile-body-separator-line" data-applydefaultfontstyles="true" dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt">
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif; font-size:12pt">
<br>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> rpd-request@afrinic.net <rpd-request@afrinic.net><br>
<b>Sent:</b> Friday, 02 October 2026 18:32:37<br>
<b>To:</b> rpd@afrinic.net <rpd@afrinic.net><br>
<b>Subject:</b> RPD Digest, Vol 225, Issue 10</font>
<div> </div>
</div>
<div class="x_BodyFragment">
<div class="x_PlainText"><font size="2"><span style="font-size:11pt">Send RPD mailing list submissions to<br>
rpd@afrinic.net<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
rpd-request@afrinic.net<br>
<br>
You can reach the person managing the list at<br>
rpd-owner@afrinic.net<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. Re: Updated Proposal - AfriNIC Policy Compliance Dashboard<br>
AFPUB-2026-GEN-002-DRAFT02 (jordi.palet@theipv6company.com)<br>
2. Re: Updated Proposal - AfriNIC Policy Compliance Dashboard<br>
AFPUB-2026-GEN-002-DRAFT02 (jordi.palet@theipv6company.com)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 2 Oct 2026 18:16:44 +0200<br>
From: "jordi.palet@theipv6company.com"<br>
<jordi.palet@theipv6company.com><br>
To: rpd@afrinic.net<br>
Subject: Re: [rpd] Updated Proposal - AfriNIC Policy Compliance<br>
Dashboard AFPUB-2026-GEN-002-DRAFT02<br>
Message-ID: <54D46AC7-9CEC-4DAE-A513-832869F07906@theipv6company.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Nonjabulo,<br>
<br>
I think you?re missing the point that appendix, examples, etc., are only that: examples.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Jordi<br>
<br>
@jordipalet<br>
<br>
> El 2 oct 2026, a las 15:36, Nonjabulo Sphilile <nonjabulosphilile@gmail.com> escribi?:<br>
><br>
> Mark,<br>
><br>
> Thank you ? your DNSSEC example is genuinely useful, and I think it strengthens the point rather than answering it.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Regards,<br>
> Nonjabulo<br>
> _______________________________________________<br>
> RPD mailing list<br>
> RPD@afrinic.net<br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com">http://www.theipv6company.com</a><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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20261002/fef9d9cb/attachment-0001.html">https://lists.afrinic.net/pipermail/rpd/attachments/20261002/fef9d9cb/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 2 Oct 2026 18:32:10 +0200<br>
From: "jordi.palet@theipv6company.com"<br>
<jordi.palet@theipv6company.com><br>
To: "rpd@afrinic.net" <rpd@afrinic.net><br>
Subject: Re: [rpd] Updated Proposal - AfriNIC Policy Compliance<br>
Dashboard AFPUB-2026-GEN-002-DRAFT02<br>
Message-ID: <77661056-6164-4F9F-989F-EF184CFB3C31@theipv6company.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Nia,<br>
<br>
The way we introduced ?possible? is to allow the staff impact assessment to withdraw some of the ?cons? against the proposal. The overall goal of the proposal works the same if instead of defining all the details (which are now as examples in non-normative
text), we just ensure that there is a notification in ?possible? cases and them the staff can take their own steps and decisions.<br>
<br>
We don?t have anymore in the normative text the ?continued? part, we leave it now to the staff - again, as explained in previous emails, so they can follow their already existing procedures.<br>
<br>
The collection of personal data is not needed in our opinion for the monitoring, but we wanted to make it explicit to responde to one of the impact assessment points. Same for ?not intruding? the network. Was never expected to be done. If monitoring some aspect
needs going ?inside? the network, then it can be implemented, and only can be done in case of ?audits? which can be done by AFRINIC, as they are done by any other RIRs in case of suspicius signals.<br>
<br>
We could use your text for section 3, however, I think is superfluous, because the exact text to send should be determined by the staff. If we include it in the proposal, they are mandated to that text, which over the time could be easily improved, changed,
etc.<br>
<br>
Regarding the history, it needs to be used as explained already in a previous email.<br>
<br>
Note that the dashboard has only visibility for the resource holder, not others. As explained in a previous email, I would agree that once a recovery process is started, it should be made public for some time. This was in the LACNIC proposal that was adopted,
but a previous version 3 years ago in AFRINIC, reached consensus and was not ratified by the staff/board, because it was considered encroaching them - strange that 2 RIRs doing the same functions have so much different view but this is what we have!<br>
<br>
Regards,<br>
Jordi<br>
<br>
@jordipalet<br>
<br>
> El 2 oct 2026, a las 15:53, NP Petronella <NPertuniaPetronella@outlook.com> escribi?:<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>
> _______________________________________________<br>
> RPD mailing list<br>
> RPD@afrinic.net<br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com">http://www.theipv6company.com</a><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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20261002/edd20f5c/attachment.html">https://lists.afrinic.net/pipermail/rpd/attachments/20261002/edd20f5c/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
RPD@afrinic.net<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 225, Issue 10<br>
************************************<br>
</span></font></div>
</div>
</div>
</blockquote>
<div class="x_plaintext" style="white-space:normal">
<blockquote style="margin:0 0 5px; padding-left:5px; border-left:2px solid #777777; color:#777777">
<p dir="auto">_______________________________________________ <br>
RPD mailing list <br>
RPD@afrinic.net <br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" style="color:#777777">https://lists.afrinic.net/mailman/listinfo/rpd</a></p>
</blockquote>
</div>
</div>
</body>
</html>