<div dir="auto">Good evening,<div dir="auto"><br></div><div dir="auto">I do not support AFPUB-2026-GEN-002-DRAFT02 in its current form and therefore oppose its ratification.</div><div dir="auto"><br></div><div dir="auto">My concern is that stating that the existing enforcement thresholds remain unchanged does not fully address what the proposal introduces. Items 2-4 appear to place possible findings and previous history before staff during their assessment, and a new input can potentially influence a decision even where the formal enforcement threshold itself has not changed.</div><div dir="auto"><br></div><div dir="auto">The policy should clearly distinguish between an alert or prompt for further review and evidence that establishes an actual breach.</div><div dir="auto"><br></div><div dir="auto">I am also concerned about the references to investigation, service withholding, revocation and membership closure. The proposal does not clearly explain what happens to an otherwise eligible transfer before any recovery or closure action is taken. It is also unclear whether a dashboard finding, whether possible or confirmed, could itself be treated as a resource-status dispute or have an impact on transfer eligibility.</div><div dir="auto"><br></div><div dir="auto">Simply stating that existing procedures will apply does not resolve these concerns. The specific procedure should be identified, and the proposal should demonstrate how it addresses these situations. If the proposal is not intended to change transfer eligibility or the recovery process, this should be stated clearly in the operative text.</div><div dir="auto"><br></div><div dir="auto">At a minimum, the policy should make it clear that:</div><div dir="auto"><br></div><div dir="auto">- an unverified alert does not, by itself, constitute an adverse finding;</div><div dir="auto">- a dashboard entry alone does not establish a resource-status dispute or prevent an otherwise eligible transfer; and</div><div dir="auto">- pending transfers and access to the necessary registry records are expressly addressed before any recovery, revocation or closure action is taken.</div><div dir="auto"><br></div><div dir="auto">These are important safeguards, and I do not believe mailing-list assurances should be relied upon in place of clear policy text.</div><div dir="auto"><br></div><div dir="auto">For these reasons, I oppose advancing this draft towards ratification in its current form until the status of dashboard findings and the applicable transfer process are clearly addressed in the proposal itself.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Fundiswa</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 08 Oct 2026, 16:42 , <<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. Re: Forum for policy discussions? (Benson Muite)<br>
2. Re: Updated Proposal - AfriNIC Policy Compliance Dashboard<br>
AFPUB-2026-GEN-002-DRAFT02 (Tshepo Masuku)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 08 Oct 2026 17:17:56 +0300<br>
From: Benson Muite <<a href="mailto:benson_muite@emailplus.org" target="_blank" rel="noreferrer">benson_muite@emailplus.org</a>><br>
To: "<a href="mailto:jordi.palet@theipv6company.com" target="_blank" rel="noreferrer">jordi.palet@theipv6company.com</a>" <<a href="mailto:jordi.palet@theipv6company.com" target="_blank" rel="noreferrer">jordi.palet@theipv6company.com</a>>,<br>
<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
Subject: Re: [rpd] Forum for policy discussions?<br>
Message-ID: <<a href="mailto:87fqygwa23.fsf@emailplus.org" target="_blank" rel="noreferrer">87fqygwa23.fsf@emailplus.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
"jordi.palet--- via RPD" <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>> writes:<br>
<br>
Hi Jordi,<br>
<br>
> Hi Benson,<br>
><br>
> Note that I don?t know that specific tool, however, in general I don?t think this will be useful. Several other RIRs (and similar communities) have used those ?forum? tools and I can?t see them being used in reality.<br>
<br>
AFRINIC is a bit different than other RIRs, so it maybe worth trying to<br>
make things work well for AFRINIC not just doing exactly the same as<br>
other RIRs.<br>
<br>
><br>
> You will also need to keep the email exploder working and reflect bidirectionally every message.<br>
><br>
> I assume that this tool means you need to be on-line to work on that. Email has the advantage, that you can be off-line (when you travel, have no connectivity, etc.), and respond to messages that will be sent when you?re back on-line.<br>
><br>
<br>
Yes, it is possible to use an email based workflow rather than the web<br>
interface for most things, though one would need to configure this:<br>
<a href="https://www.loomio.com/docs/en/user_manual/users/email_settings" rel="noreferrer noreferrer" target="_blank">https://www.loomio.com/docs/en/user_manual/users/email_settings</a><br>
<br>
It is structured for decision making:<br>
<a href="https://www.loomio.com/docs/en/guides/making_decisions" rel="noreferrer noreferrer" target="_blank">https://www.loomio.com/docs/en/guides/making_decisions</a><br>
<br>
At present, in addition to discussion, public polls are often used to<br>
get a sense of opinions, though one could replace these with a machine<br>
learning sentiment analysis tool to analyse written respones or not use<br>
either of these.<br>
<br>
> Migration to mailman3, yes, of course, I guess it will be done at some point (IETF and a couple of other RIRs, NOGs, etc., already did some time ago).<br>
><br>
<br>
If the primary concern is replies to digests, then upgrading will help.<br>
More extensive changes to improve the efficiency of the consensus<br>
process would probably require using other tools as well or instead.<br>
<br>
> Regards,<br>
> Jordi<br>
<br>
Regards,<br>
Benson<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 8 Oct 2026 14:42:00 +0000<br>
From: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank" rel="noreferrer">TshepoMasuku26@hotmail.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>>,<br>
"<a href="mailto:jordi.palet@theipv6company.com" target="_blank" rel="noreferrer">jordi.palet@theipv6company.com</a>" <<a href="mailto:jordi.palet@theipv6company.com" target="_blank" rel="noreferrer">jordi.palet@theipv6company.com</a>><br>
Subject: Re: [rpd] Updated Proposal - AfriNIC Policy Compliance<br>
Dashboard AFPUB-2026-GEN-002-DRAFT02<br>
Message-ID:<br>
<<a href="mailto:DB7PR04MB5993DCA29233F2D8DD00C529CA932@DB7PR04MB5993.eurprd04.prod.outlook.com" target="_blank" rel="noreferrer">DB7PR04MB5993DCA29233F2D8DD00C529CA932@DB7PR04MB5993.eurprd04.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Jordi,<br>
<br>
I won?t argue this inside your frame, because the frame is the problem.<br>
<br>
I do not accept policy-making by a self-selected group as a mandate to govern a continent or supervise operators? businesses. Calling something ?community policy? does not establish the legitimacy of the authority it claims. The distinction between participation in an administrative process and representation of everyone affected by it is important.<br>
<br>
A registry records; it does not enforce. AFRINIC?s proper function is administrative: it keeps accurate records of who holds which number resources and executes transfers under defined procedures. That is an address book. Examining how a holder runs its network, imposing penalties, or withholding an address to punish conduct is enforcement. In fact, that function is placed with the appropriate sovereign authorities, not with a voluntary registry acting as police, prosecutor and judge. A registry that attempts this undermines its legitimacy rather than strengthening it.<br>
<br>
Nothing you have cited resolves that objection. The Assisted Review page describes both routine registry-data checks and extended reviews that may request utilisation details and evidence of network operations. It also reproduces RSA language concerning reviews of already-assigned resources. That establishes what AFRINIC claims to do; it does not establish why we should accept that supervisory mandate or endorse it through DRAFT02. The extension from maintaining records to examining resource use is precisely what we reject.<br>
<br>
Nor does community consensus confer sovereignty. AFRINIC?s PDP uses consensus, but agreement among participants is not a mandate from every operator, every member or every person across the service region. A self-selected policy forum is not a continent. A service region is not a sovereign people; a mailing list is not a legislature. Community participation does not convert an administrative function into authority over how address holders run their businesses.<br>
<br>
So the position stands: I do not accept a general audit or enforcement mandate over how holders use their number resources, and we oppose DRAFT02 being used to create, expand or endorse one. Describing supervision as ?policy compliance? does not change its nature.<br>
<br>
The dashboard is not presented solely as recordkeeping. Paragraph 4 connects findings to investigation, service withholding, revocation and membership closure. Its appendix illustrates public listing, NS-record removal, recovery and deletion of holder records. Although those appendix provisions are examples rather than automatic operative deadlines, they show the enforcement model being contemplated. The authority for that model must be justified, not assumed.<br>
<br>
To converge, put it on the table: the exact instrument relied upon for resource-use audits, the grounds for initiating them, and the limits on information or access demanded. Identifying a clause that asserts a power is not the same as establishing why that power should be endorsed.<br>
<br>
DRAFT02 should expressly state:<br>
This section shall neither create, expand nor endorse a general power to audit operators? use of already-held number resources, whether through network access or documentary demands. Dashboard checks shall be limited to objectively verifiable registry facts necessary for uniqueness, accurate records and recognised control.<br>
<br>
Limiting an audit to documents changes the method, not the mandate. The mandate itself is what we do not accept.<br>
<br>
Regards,<br>
Tshepo<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20261008/644f2571/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20261008/644f2571/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 29<br>
************************************<br>
</blockquote></div>