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

[Nonjabulo Sphilile]

Hi Jordi,

I do not accept DRAFT02, and I oppose its ratification. My objection is
about the supervisory mandate the text creates, not about notification
formatting or software development, and I am not going to argue about the
appendix.

On the text as I read it, item 4 keeps the consequence inside the proposal:
on evidence suggesting a lack of compliance, AFRINIC may investigate and
take further action, including service withholding, revocation or member
closure. At the same time, the set of checks, the content of the
notification and the meaning of the automated record are left to
implementation which, on your answers, need not be published before the
text takes effect. That is what I cannot accept. What would be adopted is
not a rule that decides whether a member is compliant, but permission to be
bound by decisions taken afterwards.

The standard this text has to meet is not technical, and it is not about
the dashboard.

A registry's role is administrative, not punitive. Confirming that a
registration record is accurate does not make the registry the judge of an
operator's utilisation, deployment or commercial choices; a registration
system must not turn registration into punishment, must not police leasing,
customer location, commercial structure or morality, and must not use
control of the database as economic force. Where coordination needs a rule,
the rule must be fixed and verifiable at the moment it is adopted, so that
it does not have to be invented case by case afterwards. Leaving "what
counts as non-compliance" to be settled later, in implementation, does not
avoid discretion — it keeps the discretion and postpones the decision. And
the common layer should stay thin: uniqueness, proof of control, registry
accuracy, security assertions, transfer records, auditability and
replacement paths belong in it; everything else belongs closer to the
operator. No running network should be made hostage to registry discretion,
and every network should be able to leave a failing, captured, conflicted
or abusive registry without losing its number resources.

I read the registry's own record and transfer auditability as inside that
thin layer — which is what a dashboard can legitimately be — and not as
authority to audit a member's deployment or commercial decisions.

My remaining objection is short and specific. I am not asking for a
template, a format or a development schedule, and I am not asking your
implementation work to come back through the PDP. I am asking the adopted
text to state six things, none of which depends on any implementation
timetable:

1. An automated indication is not a determination. It creates no finding,
no change of a member's status, no obligation and no permission for any
consequence, until a finding is made under the applicable CPM or RSA
provision.
2. A notification under item 3 states that no determination has been made.
Where historical information is included, it states its source, its date
and its current disposition.
3. Information produced by an automated check that is not confirmed under
item 4 is not entered into the member's history and is not counted for any
purpose under this policy, regardless of how or by whom the check is
operated.
4. Before a check is relied on in connection with a member, the checks in
operation and the record produced for that member are visible to that
member.
5. The dashboard is limited to objectively verifiable registry facts:
uniqueness, proof of control, record accuracy, and shared technical
security. This policy does not authorise general audits of an operator's
deployment, utilisation or commercial decisions, including documentary
audits.
6. A new or widened check takes effect only as policy text, not by
implementation update.

On section 4, your explanation of the order of the work does not resolve my
objection — and that is exactly why the text cannot be settled first. If
the neutrality of section 4 depends on what the impact assessment says, the
re-check is a condition of the text, not a promise made about it.

My earlier requests for safeguards are not an acceptance of an audit
mandate, and I am not reopening the points already made on the list.

I oppose DRAFT02 as drafted until this is in the text.

Kind regards,
Nonjabulo Sphilile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20261012/ef60fd0c/attachment.html>