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

[Nonjabulo Sphilile]

Hi Jordi,

Thank you for the detailed answers. I accept the phasing point —
implementing one check at a time is normal — and I am not asking the policy
to schedule development or to pre-determine bug fixes. I also accept that
the appendix is not intended as policy text.

That last point is why I am following up, because it changes what is left.

If sections 6 and 7 and the appendix are not policy text, the operative
proposal is items 1–4. The only enforcement sentence is item 4: on
"evidence suggesting that there is lack of compliance", AFRINIC "is able to
initiate a more exhaustive investigation and take further actions (such as
service withholding, revocation or even member closure)", following the
RSA/bylaws prerogatives. You have also confirmed that the thresholds for
manual investigation are unchanged and that the proposal deliberately
creates no procedure, because that is a staff/board decision.

In the notifications item the operative rule is that notifications go to
members and staff "as soon as a possible non-compliance is detected,
showing previous history if available". You have added that the exact
notification text is left to staff so that they are not "mandated to that
text", and that the "continued" qualifier was removed from the normative
text.

So the operative effect is: a member is recorded and staff are alerted on
an automated possibility, with history included on an availability test,
while the procedure that determines what follows is outside the policy.
That reverses the structure you describe — the obligations are inside the
text and the safeguards are outside it. The earlier version required staff
to define and publish a procedure to ensure fair treatment of all members;
DRAFT02 does not, and you have confirmed no procedure is created.

Three questions:

1. Which text is normative? If 6 and 7 are examples, they should be moved
out of the block labelled "Proposed", or expressly marked non-normative,
before Last Call. If they are normative, then the publication step, the
NS-record removal, the holder-record deletion, the "more than 3 confirmed
violations happen in a 12 months timeframe" trigger and the staff-set
"severity graduation" still need the objections raised on 2 October
answered. As it stands, the community cannot tell which document it is
being asked to adopt.

2. What governs the notification content, including "previous history"? You
have said staff decide the text and can change it over time. Then the only
test the policy itself contains for including history is "if available" —
availability, not relevance. A record kept for audit and re-displayed in an
unrelated notification serves a different purpose from the one it was kept
for. Will the published procedure required by CPM 3.2.2 state the relevance
test, and will it be published before Last Call?

3. Does an unconfirmed automated finding — including one from a feature
still in "beta" — enter "previous history", and the count? You mentioned
beta features. Nothing in the text excludes unfinished check output from
the notification or from the record.

Changes I would support:

- In item 3: notification to the member on a possible finding; the notice
states that no determination has been made; historical information included
only where necessary and relevant to understand or correct the finding,
identified by source, date and current disposition; automated findings not
confirmed under item 4 excluded from the history.
- In item 4, or a new item: no adverse decision may rely on dashboard
information unless the applicable CPM or RSA provision is identified, the
facts established are stated, and the notice, response and appeal
provisions of the RSA and Bylaws have been observed; the published
implementation procedure exists before any adverse decision relies on
dashboard information.
- In item 2: state the position under CPM 3.4.5, and list the initial set
of checks in the policy. Any later check, or any change of a criterion or
threshold that creates or widens an obligation, should come back through
the PDP.

I am not asking the policy to describe your development process, and I am
not asking it to fix bugs. I am asking it to state the rules that decide
whether a member is compliant, because those rules are what the community
is being asked to approve. I oppose the proposal as drafted until that is
resolved.

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