<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hello Jordi,</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;" dir="auto">
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you for coming back on this. I want to test one thing you said, because it seems to decide the whole question.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
You wrote that the thresholds for manual investigation are unchanged, that the procedure already exists because staff must have one today, and that the proposal deliberately does not describe the recovery details. On that account, the only thing this proposal
 adds is that AFRINIC will monitor periodically, show each member a status, and send notifications — to members and to staff — when something looks possibly non-compliant, with previous history attached.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
If that is right, one of two things follows.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
If the proposal genuinely changes nothing about obligations, thresholds, procedures or consequences, then it is a description of an internal project rather than a policy, and the CPM does not look like the right instrument for it. Members would be bound by
 nothing new, and the document would mainly authorise the dashboard.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
If instead it does change something — and I think it does, because "will automatically send notifications to members and staff", "as soon as a possible non-compliance is detected" and "showing previous history" are new duties that did not exist before — then
 that change is the part that needs to be written down. What is a member expected to do on receiving such a notice? Is the notice a finding? Does it remain on a record? Does it count for anything later? You have said staff decide the text and can change it
 over time, and that no procedure is created because that is a staff/board matter. That is a fair position about how the dashboard is run; it leaves what the member is now subject to undefined.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
There is also a practical side to the efficiency argument. The saving you describe depends on the notices being accurate and actionable. Nothing in the proposal says what happens when a signal is wrong — which will happen, especially where a check reflects
 a gap in the registry's own data rather than a fault in the member's network. If a wrong signal still reaches the member and the staff record, the saving is real for AFRINIC and the cost is carried by the member.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
So my question is short: if the thresholds, the procedure and the consequences are all unchanged, what is the community being asked to approve? If the answer is "the monitoring and the notifications", then those need to be specified in the text — including
 what a notice means and what happens when a check is wrong. If the answer is "nothing that needs to be in a policy", I don't see why this should reach Last Call.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Finally, you mention that the section 4 wording was rejected by the impact assessment three years ago and that you will check back against the new assessment. That assessment is the document that is supposed to answer this, so I would prefer to see it published
 before the community is asked to take a position.</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards,</div>
<div dir="auto" style="font-family: Aptos, Aptos_MSFontService, -apple-system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Tshepo</div>
</div>
<div dir="auto" id="mail-editor-reference-message-container" class="">
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg" style="font-size: 11pt;" dir="auto"><b>From:</b> rpd-request@afrinic.net <rpd-request@afrinic.net><br>
<b>Sent:</b> Friday, October 2, 2026 6:10:26 PM<br>
<b>To:</b> rpd@afrinic.net <rpd@afrinic.net><br>
<b>Subject:</b> RPD Digest, Vol 225, Issue 9<br>
</div>
<br>
<meta name="Generator" content="Microsoft Exchange Server">
<div dir="auto" class="PlainText" 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 17:54:49 +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: <38B08F6A-2403-4B4D-9FDD-FA874D4D5E20@theipv6company.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Mphoentle,<br>
<br>
The transfers can only be made if the resources (and the holder) are ?in good standing?. Remember also that the transfers section is being replaced by the newer transfers policy, once implemented. You will notice that the actual version of the proposal doesn?t
 have text for enforcing the recovery or closure, an appendix provides some ideas, but this is not part of the policy text, and it depends on staff or board decisions already currently taken and *not changed* by this proposal.<br>
<br>
Regards,<br>
Jordi<br>
<br>
@jordipalet<br>
<br>
> El 2 oct 2026, a las 9:15, Mphoentle Mokheseng via RPD <rpd@afrinic.net> escribi?:<br>
><br>
> Dear Co-Chairs and colleagues,<br>
><br>
> A further concern is how a member can complete an orderly transfer before membership closure or resource recovery. DRAFT02?s illustrative recovery sequence provides an opportunity to regularise the situation but does not explain how an otherwise permissible
 transfer to an eligible recipient would be handled during that period. This leaves an important alternative to recovery unaddressed.<br>
><br>
> There is a specific interaction with the published CPM that needs clarification. Section 5.7.3.1 requires the transfer source to be the recognised rights holder and not be involved in a dispute concerning the status of the resources. That makes the distinction
 between a disagreement about an administrative obligation and a dispute about entitlement to the resources particularly important.<br>
><br>
> DRAFT02 does not explain whether a dashboard compliance case could affect that transfer eligibility. My concern is that, without an explicit distinction, an administrative disagreement could be treated as a resource-status dispute and prevent a transfer even
 where nobody contests the holder?s control. This is a potential interaction requiring clarification, not a claim that the draft expressly prohibits transfers.<br>
><br>
> Consider a member winding down its business and arranging an otherwise eligible transfer to another network. The relevant question should be whether that transfer can be authenticated and accurately recorded, rather than whether the outgoing organisation
 must continue its existing membership indefinitely. Ending a service relationship and surrendering resources should not be treated as the same event. This reflects the principle that portability and the ability to export registry records should support operator
 independence.<br>
><br>
> The proposal should therefore explain how pending transfers are handled before recovery, preserve access to the records needed to complete them, and establish a defined transition period for an otherwise eligible transfer. A dashboard case should not, by
 itself, become an additional transfer restriction. Any broader right to move registry administration elsewhere would require its own clearly specified arrangements; it should not be assumed to exist already.<br>
><br>
> This would not excuse fraud, override a binding legal restriction, or remove outstanding obligations owed by the outgoing member. It would distinguish those obligations from the separate question of whether a verified change of holder can proceed. That separation
 is consistent with a registry function centred on recording legitimate changes of control rather than making exit dependent on continued institutional approval.<br>
><br>
> An orderly transfer should be an expressly addressed outcome, not an option left uncertain until a member is already facing recovery.<br>
><br>
> BR,<br>
> Mphoentle<br>
> Disclaimer This email and the information contained herein are Advtech Ltd confidential and are protected by law. Please navigate to our website for more information
<a href="https://www.groupadvtech.com">https://www.groupadvtech.com</a>. Use of this information or this email by any person for any purposes other than that for which it is intended is prohibited and may result in civil and/or criminal liability. This email
 is not to be shared with any 3rd parties not included within this email, without the written consent of its Author. If you have received this message in error, please notify Advtech immediately, telephone number +27 11 676 8000. Advtech leads the private sector
 in the fields of education and resourcing, contributing meaningfully towards the sustainable development of human capacity in South Africa.<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/bc210c12/attachment-0001.html">https://lists.afrinic.net/pipermail/rpd/attachments/20261002/bc210c12/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 2 Oct 2026 18:09:06 +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: <9449546D-82A4-4EB1-9011-56844B06EEFA@theipv6company.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Tshepo,<br>
<br>
Even if the proposal requires staff verification, automatic possible lack of compliance detection will in the end, release human resources for initial verification and simplify the process.<br>
<br>
We decided to not describe the details of the recovery decisions, because it was one of the concerns in the previous version. So the proposal is now more a simpler ?framework?. We want:<br>
As automated as possible monitoring.<br>
Display the status of each monitored item.<br>
Notifications.<br>
<br>
The thresholds for manual investigation aren?t changed from what today is already doing the staff. Policy should not change that to avoid being considered to intrusive in the legal aspects for the bylaws/RSA. This version avoids precisely the complains from
 the analysis impact in the previous version. This is also the reason we don?t create a procedure, because it is staff/board decision, which they already must have today, even if this policy would not exist.<br>
<br>
While I agree with the changes that you are proposing for section 4, most of them were (not exact same wording but same meaning) in the original proposal 3 years ago (as we have them in a policy proposal in LACNIC that reached consensus and was implemented
 several years ago) ?. and they were rejected by the impacts assesement. Anyway, we will check back depending on the inputs from the new impacts assessment.<br>
<br>
Regards,<br>
Jordi<br>
<br>
@jordipalet<br>
<br>
> El 2 oct 2026, a las 14:29, Tshepo Masuku <TshepoMasuku26@hotmail.com> escribi?:<br>
><br>
> Dear PDWG,<br>
><br>
> Thank you for the revised proposal. DRAFT02 acknowledges the limitations of automated assessment, requires staff verification and removes the former Board-exception clause. Those changes address parts of the earlier discussion. My comment therefore does not
 assume that the proposal requires automatic revocation or retains the deleted exception.<br>
><br>
> The remaining question is what paragraph 4 of section 3 actually changes: does it merely describe existing authority, or establish an additional policy basis for exercising enforcement powers?<br>
><br>
> This distinction was already raised in the DRAFT01 legal assessment, which asked whether the proposal operationalised existing contractual rights or created additional remedies. The June meeting also recorded the contrary interpretation that the proposal
 operated entirely within the existing framework. Neither interpretation should simply be assumed to settle the meaning of the revised text.<br>
><br>
> Paragraph 4 combines investigation and potential service withholding, revocation or membership closure in a sentence linked to evidence indicating possible non-compliance. It refers to the RSA/bylaws, but does not expressly distinguish the threshold for investigating
 a concern from the conditions necessary for an adverse decision.<br>
><br>
> There are two separate questions here. Staff verification asks whether the information is reliable. It does not, by itself, answer whether a particular obligation applies, whether a breach has been established, or which remedy is authorised. For example,
 confirming that a record is incorrect does not alone determine which consequences may follow from that error.<br>
><br>
> The scope question also needs an explicit answer. CPM section 3.1 distinguishes number-resource policy from general business practices and procedures, which fall outside the PDP. This does not establish that every provision affecting enforcement is outside
 scope. It does mean that the authors should identify which new resource-policy obligation paragraph 4 creates and which matters remain governed by separate contractual procedures.<br>
><br>
> There is a related change between versions. DRAFT01 expressly required staff to define and publish a procedure; that requirement is not retained in DRAFT02?s operative wording. However, CPM section 3.2.2 already requires implementation procedures to be documented
 and publicly available. I am therefore not claiming that publication obligations disappear. The unanswered question is which procedure will govern dashboard-derived findings, and when members will be able to inspect it.<br>
><br>
> The response that ?existing instruments continue to apply? is relevant, but it should lead to an identifiable provision and procedure. Where no additional enforcement authority is intended, an explicit non-expansion clause would clarify that intention without
 prescribing staff workflows.<br>
><br>
> I propose replacing paragraph 4 with the following:<br>
><br>
> > 4. Verification and use of dashboard information<br>
><br>
> The dashboard provides information for member assistance and staff verification. This section does not introduce additional substantive obligations, create new sanctions, or alter the conditions for exercising an existing remedy.<br>
><br>
> An unverified dashboard indication shall not itself establish a breach. Any adverse decision relying on dashboard information shall identify the applicable obligation, the facts established, the authority for the decision and the procedure followed.<br>
><br>
> Before dashboard information is used to support adverse decisions, AFRINIC shall publish the applicable notification, evidence-disclosure, response, correction and review arrangements. Existing contractual and legal protections remain applicable.<br>
><br>
><br>
><br>
> This wording separates useful monitoring from the authority to impose consequences. It does not prevent legitimate investigation or excuse an established breach.<br>
><br>
> Please could the authors explain whether this reflects their intended scope? Where it does not, please identify precisely which additional obligation, authority or consequence the current wording is intended to establish. A DRAFT02-specific staff explanation
 of that interaction would also help the community assess the revised text, rather than treating the earlier impact assessment as a determination on this version.<br>
><br>
> I ask that the discussion record distinguish this question from the automation concerns already addressed, and document the response and any resulting amendment. The issue is not whether a dashboard can be useful. It is whether members and the community can
 determine, from the text, what legal or operational consequence the new section adds.<br>
><br>
> Kind regards,<br>
> Tshepo<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/0acc4ed6/attachment.html">https://lists.afrinic.net/pipermail/rpd/attachments/20261002/0acc4ed6/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 9<br>
***********************************<br>
</div>
<br>
</div>
</body>
</html>