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

Thu Oct 8 11:33:02 UTC 2026

Hi Nonjabulo,

Clarifications below, in-line.

Regards,
Jordi

@jordipalet

> El 5 oct 2026, a las 8:49, Nonjabulo Sphilile <nonjabulosphilile at gmail.com> escribió:
> 
> 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.
> 

All the proposals have the same structure, this is defined by the CPM/PDP. The normative part is section 3. 

> 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.2.2. doesn’t state that the implementation procedures should be published before, and I don’t think this will be right, because, part of the implementation work is precisely to define how you will address it.

> 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.

What I said regarding “beta” is just a possibility, a suggestion. I think we all know that it is quite normal since many years ago, to develop things (like the automation and the dashboard) and try it internally, then ask users interested to test it as well.

> 
> 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.

I’m not sure to understand if you mean that this info should be part of the policy text to ensure that the automated message has some specific format. In my opinion this is a very low level operational/implementation decision and it can be improved over the time, so I don’t think it will be appropriate to provide so much details.

> - 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.

I don’t think it is needed and the way the section 4 has been written, is to ensure that it is very neutral and avoids negative implications from the impact assessment. I think we need to wait to have it to do a re-check.

> - 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 completely disagree with that. It defeats the most important part of the proposal: when new changes are done in the PDP, if they can be somehow automated, when possible, be incorporated into the dashboard. The implementation will decide what is possible to be done and in what timeframe.

> 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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20261008/2a60ed16/attachment.html>