<div dir="ltr"><div dir="ltr"><div dir="ltr"><p>Hi Jordi, all,</p><p>I oppose AFPUB-2026-GEN-002-DRAFT02 because my concern is not with any single provision, but with the proposal as a whole.</p><p>The standard is simple. A registry's role is administrative, not punitive. It keeps records accurate and can say what a record is; it does not judge an operator's utilisation, deployment or commercial choices, and it must not use control of registration as economic force. A rule that people have to obey must be fixed and verifiable at the moment it is adopted, not settled later in implementation.</p><p>The coordination layer should remain limited to what is necessary: uniqueness, proof of control, registry accuracy, security assertions, transfer records, auditability and replacement paths. Everything else belongs closer to the operator. No running network should be held hostage to registry discretion or lose its resources because of decisions that extend beyond the registry's legitimate administrative responsibilities.</p><p>DRAFT02 fails that standard as a whole. It creates a monitoring duty, a notification duty to staff on a possible finding, and a record attached to the member. It links these to investigation, service withholding, revocation or closure, while the checks, the content of notifications, the meaning of the automated record and the threshold for "evidence suggesting a lack of compliance" are all left to be decided afterwards.</p><p>Amending individual provisions would not resolve the underlying concern. It would simply make the broader compliance framework more workable without questioning whether such authority should exist in the first place. A rule whose content is decided after it is adopted should not be adopted at all.</p><p>For these reasons, I am not asking for amendments. I ask the working group and the co-chairs to abandon AFPUB-2026-GEN-002-DRAFT02, withdraw it and not advance it to Last Call.</p><p>If members need visibility into their own registration records and a practical way to correct inaccuracies, that can be provided as a service within the registry's administrative role, without attaching an additional compliance mandate. That would be a proposal worth supporting.</p><p>Kind regards,</p><p>Zenalo</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Oct 2026 at 10:25, <<a href="mailto:rpd-request@afrinic.net" target="_blank">rpd-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send RPD mailing list submissions to<br>
<a href="mailto:rpd@afrinic.net" target="_blank">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" 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">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">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. Re: AFPUB-2026-GEN-002-DRAFT02 Policy Compliance Dashboard<br>
(Nonjabulo Sphilile)<br>
2. Re: Forum for policy discussions? (Owen DeLong)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 12 Oct 2026 10:13:17 +0200<br>
From: Nonjabulo Sphilile <<a href="mailto:nonjabulosphilile@gmail.com" target="_blank">nonjabulosphilile@gmail.com</a>><br>
To: <a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a><br>
Subject: Re: [rpd] AFPUB-2026-GEN-002-DRAFT02 Policy Compliance<br>
Dashboard<br>
Message-ID:<br>
<<a href="mailto:CAJwHbZNVdEtXhUMUyNN8Sha38J2%2BRXTXbPE%2BcWQK480TqhSPcg@mail.gmail.com" target="_blank">CAJwHbZNVdEtXhUMUyNN8Sha38J2+RXTXbPE+cWQK480TqhSPcg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Jordi,<br>
<br>
I do not accept DRAFT02, and I oppose its ratification. My objection is<br>
about the supervisory mandate the text creates, not about notification<br>
formatting or software development, and I am not going to argue about the<br>
appendix.<br>
<br>
On the text as I read it, item 4 keeps the consequence inside the proposal:<br>
on evidence suggesting a lack of compliance, AFRINIC may investigate and<br>
take further action, including service withholding, revocation or member<br>
closure. At the same time, the set of checks, the content of the<br>
notification and the meaning of the automated record are left to<br>
implementation which, on your answers, need not be published before the<br>
text takes effect. That is what I cannot accept. What would be adopted is<br>
not a rule that decides whether a member is compliant, but permission to be<br>
bound by decisions taken afterwards.<br>
<br>
The standard this text has to meet is not technical, and it is not about<br>
the dashboard.<br>
<br>
A registry's role is administrative, not punitive. Confirming that a<br>
registration record is accurate does not make the registry the judge of an<br>
operator's utilisation, deployment or commercial choices; a registration<br>
system must not turn registration into punishment, must not police leasing,<br>
customer location, commercial structure or morality, and must not use<br>
control of the database as economic force. Where coordination needs a rule,<br>
the rule must be fixed and verifiable at the moment it is adopted, so that<br>
it does not have to be invented case by case afterwards. Leaving "what<br>
counts as non-compliance" to be settled later, in implementation, does not<br>
avoid discretion ? it keeps the discretion and postpones the decision. And<br>
the common layer should stay thin: uniqueness, proof of control, registry<br>
accuracy, security assertions, transfer records, auditability and<br>
replacement paths belong in it; everything else belongs closer to the<br>
operator. No running network should be made hostage to registry discretion,<br>
and every network should be able to leave a failing, captured, conflicted<br>
or abusive registry without losing its number resources.<br>
<br>
I read the registry's own record and transfer auditability as inside that<br>
thin layer ? which is what a dashboard can legitimately be ? and not as<br>
authority to audit a member's deployment or commercial decisions.<br>
<br>
My remaining objection is short and specific. I am not asking for a<br>
template, a format or a development schedule, and I am not asking your<br>
implementation work to come back through the PDP. I am asking the adopted<br>
text to state six things, none of which depends on any implementation<br>
timetable:<br>
<br>
1. An automated indication is not a determination. It creates no finding,<br>
no change of a member's status, no obligation and no permission for any<br>
consequence, until a finding is made under the applicable CPM or RSA<br>
provision.<br>
2. A notification under item 3 states that no determination has been made.<br>
Where historical information is included, it states its source, its date<br>
and its current disposition.<br>
3. Information produced by an automated check that is not confirmed under<br>
item 4 is not entered into the member's history and is not counted for any<br>
purpose under this policy, regardless of how or by whom the check is<br>
operated.<br>
4. Before a check is relied on in connection with a member, the checks in<br>
operation and the record produced for that member are visible to that<br>
member.<br>
5. The dashboard is limited to objectively verifiable registry facts:<br>
uniqueness, proof of control, record accuracy, and shared technical<br>
security. This policy does not authorise general audits of an operator's<br>
deployment, utilisation or commercial decisions, including documentary<br>
audits.<br>
6. A new or widened check takes effect only as policy text, not by<br>
implementation update.<br>
<br>
On section 4, your explanation of the order of the work does not resolve my<br>
objection ? and that is exactly why the text cannot be settled first. If<br>
the neutrality of section 4 depends on what the impact assessment says, the<br>
re-check is a condition of the text, not a promise made about it.<br>
<br>
My earlier requests for safeguards are not an acceptance of an audit<br>
mandate, and I am not reopening the points already made on the list.<br>
<br>
I oppose DRAFT02 as drafted until this is in the text.<br>
<br>
Kind regards,<br>
Nonjabulo Sphilile<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20261012/ef60fd0c/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20261012/ef60fd0c/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 12 Oct 2026 01:23:03 -0700<br>
From: Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>><br>
To: "<a href="mailto:ben.roberts@frinic.net" target="_blank">ben.roberts@frinic.net</a>" <<a href="mailto:ben.roberts@afrinic.net" target="_blank">ben.roberts@afrinic.net</a>>,<br>
"ben.roberts--- via RPD" <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] Forum for policy discussions?<br>
Message-ID: <<a href="mailto:0D7A722D-6D5B-4961-9BE1-7C53F8B224B4@delong.com" target="_blank">0D7A722D-6D5B-4961-9BE1-7C53F8B224B4@delong.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Digests in general cause more problems than they solve and I would favor AFRINIC discontinuing support for digests on RPD, personally.<br>
<br>
I don?t favor migrating away from email. I, and I suspect many other users have built various forms of automation over the years to handle and help manage list discussions. All of that effort would go out the window if we migrated away from email and it would, IMHO, make participation significantly less convenient. (I realize there are those in the community that would view that as a feature in my case, but nonetheless, I suspect I would not be the only person negatively impacted.)<br>
<br>
Owen<br>
<br>
<br>
> On Oct 8, 2026, at 08:57, ben.roberts--- via RPD <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>> wrote:<br>
> <br>
> And dont reply to digests<br>
> <br>
> <br>
> Get Outlook for Mac <<a href="https://aka.ms/GetOutlookForMac" rel="noreferrer" target="_blank">https://aka.ms/GetOutlookForMac</a>><br>
> From: jordi.palet--- via RPD <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>
> Date: Thursday, 8 October 2026 at 14:58<br>
> To: <a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a> <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>
> Subject: Re: [rpd] Forum for policy discussions?<br>
> <br>
> And I will add:<br>
> <br>
> Keep the thread in the message, not start a new ?empty? email.<br>
> <br>
> The emails I responded to today took much more time, and may have even had misunderstandings, because the original message/thread was not there.<br>
> <br>
> Regards,<br>
> Jordi<br>
> <br>
> @jordipalet<br>
> <br>
> El 8 oct 2026, a las 13:49, Jaco Kroon via RPD <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>> escribi?:<br>
> <br>
> Hi,<br>
> <br>
> If people stop using digests the problem would sort itself out on the spot.<br>
> <br>
> Kind regards,<br>
> Jaco<br>
> <br>
> On 2026/10/08 07:11, Benson Muite wrote:<br>
> Policy discussions have so far been done on a mailing list. This has<br>
> worked well, but occasionally, the norm of keeping threads intact is not<br>
> followed and norms/policies for the AFRINIC RPD mailing list have not<br>
> been explicitly written down. This can make it difficult to follow<br>
> discussions and for people new to mailing lists to make contributions.<br>
> <br>
> Would using a tool like Loomio:<br>
> <a href="https://www.loomio.com/" rel="noreferrer" target="_blank">https://www.loomio.com/</a><br>
> be considered for managing discussions? It could be hosted by AFRINIC<br>
> or by another service provider in Africa, or even elsewhere - ip address<br>
> log data would be the only thing that is not typically public. As the<br>
> software is open source, it could be modified to better suite Afrinic<br>
> policy discussions. It does have an API:<br>
> <a href="https://www.loomio.com/docs/en/user_manual/integrations/api" rel="noreferrer" target="_blank">https://www.loomio.com/docs/en/user_manual/integrations/api</a><br>
> so creating a mobile application for those that do not want to use the<br>
> web interface is possible. One can also setup chat integrations for<br>
> those who may prefer not to get notifications by email.<br>
> <br>
> AFRINIC is still running Mailman2, probably this will be updated to<br>
> Mailman3 or some other mailing list software, so some migration of<br>
> communication infrastructure will occur and it maybe a good change to<br>
> evaluate what will work best for policy and other discussions.<br>
> <br>
> Regards,<br>
> Benson<br>
> <br>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
> <br>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
> <br>
> <br>
> **********************************************<br>
> IPv4 is over<br>
> Are you ready for the new Internet ?<br>
> <a href="http://www.theipv6company.com" rel="noreferrer" target="_blank">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>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20261012/67a5a11f/attachment.html" rel="noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20261012/67a5a11f/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">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 225, Issue 32<br>
************************************<br>
</blockquote></div></div>
</div>