[rpd] Updated Proposal - AfriNIC Policy Compliance Dashboard AFPUB-2026-GEN-002-DRAFT02

Thu Oct 8 17:13:54 UTC 2026

Good evening,

I do not support AFPUB-2026-GEN-002-DRAFT02 in its current form and
therefore oppose its ratification.

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.

The policy should clearly distinguish between an alert or prompt for
further review and evidence that establishes an actual breach.

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.

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.

At a minimum, the policy should make it clear that:

- an unverified alert does not, by itself, constitute an adverse finding;
- a dashboard entry alone does not establish a resource-status dispute or
prevent an otherwise eligible transfer; and
- pending transfers and access to the necessary registry records are
expressly addressed before any recovery, revocation or closure action is
taken.

These are important safeguards, and I do not believe mailing-list
assurances should be relied upon in place of clear policy text.

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.

Regards,
Fundiswa

On Thu, 08 Oct 2026, 16:42 , <rpd-request at afrinic.net> wrote:

> Send RPD mailing list submissions to
>         rpd at afrinic.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.afrinic.net/mailman/listinfo/rpd
> or, via email, send a message with subject or body 'help' to
>         rpd-request at afrinic.net
>
> You can reach the person managing the list at
>         rpd-owner at afrinic.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of RPD digest..."
>
>
> Today's Topics:
>
>    1. Re: Forum for policy discussions? (Benson Muite)
>    2. Re: Updated Proposal - AfriNIC Policy Compliance Dashboard
>       AFPUB-2026-GEN-002-DRAFT02 (Tshepo Masuku)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 08 Oct 2026 17:17:56 +0300
> From: Benson Muite <benson_muite at emailplus.org>
> To: "jordi.palet at theipv6company.com" <jordi.palet at theipv6company.com>,
>         rpd at afrinic.net
> Subject: Re: [rpd] Forum for policy discussions?
> Message-ID: <87fqygwa23.fsf at emailplus.org>
> Content-Type: text/plain; charset=utf-8
>
> "jordi.palet--- via RPD" <rpd at afrinic.net> writes:
>
> Hi Jordi,
>
> > Hi Benson,
> >
> > 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.
>
> AFRINIC is a bit different than other RIRs, so it maybe worth trying to
> make things work well for AFRINIC not just doing exactly the same as
> other RIRs.
>
> >
> > You will also need to keep the email exploder working and reflect
> bidirectionally every message.
> >
> > 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.
> >
>
> Yes, it is possible to use an email based workflow rather than the web
> interface for most things, though one would need to configure this:
> https://www.loomio.com/docs/en/user_manual/users/email_settings
>
> It is structured for decision making:
> https://www.loomio.com/docs/en/guides/making_decisions
>
> At present, in addition to discussion, public polls are often used to
> get a sense of opinions, though one could replace these with a machine
> learning sentiment analysis tool to analyse written respones or not use
> either of these.
>
> > 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).
> >
>
> If the primary concern is replies to digests, then upgrading will help.
> More extensive changes to improve the efficiency of the consensus
> process would probably require using other tools as well or instead.
>
> > Regards,
> > Jordi
>
> Regards,
> Benson
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 8 Oct 2026 14:42:00 +0000
> From: Tshepo Masuku <TshepoMasuku26 at hotmail.com>
> To: "rpd at afrinic.net" <rpd at afrinic.net>,
>         "jordi.palet at theipv6company.com" <jordi.palet at theipv6company.com>
> Subject: Re: [rpd] Updated Proposal - AfriNIC Policy Compliance
>         Dashboard AFPUB-2026-GEN-002-DRAFT02
> Message-ID:
>         <
> DB7PR04MB5993DCA29233F2D8DD00C529CA932 at DB7PR04MB5993.eurprd04.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> Jordi,
>
> I won?t argue this inside your frame, because the frame is the problem.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> DRAFT02 should expressly state:
> 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.
>
> Limiting an audit to documents changes the method, not the mandate. The
> mandate itself is what we do not accept.
>
> Regards,
> Tshepo
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.afrinic.net/pipermail/rpd/attachments/20261008/644f2571/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> ------------------------------
>
> End of RPD Digest, Vol 225, Issue 29
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20261008/bb1b64cd/attachment.html>