Summary

  • AFRINIC’s 25 September 2026 DRAFT02 says automated checks can suggest possible signs of non-compliance; staff must verify the information before any further investigation or action under the RSA/bylaws.
  • Compared with DRAFT01, the revised text changes the meaning of an automated result. A test output is now described as a lead for review, not a compliance finding.
  • A versioned policy-to-test map would show which rule, effective date, data source, member/resource scope and test version produced each alert—and what the result cannot establish.
  • The proposal remains Under Discussion. The public record does not show an operating dashboard, member notification, compliance finding or sanction.

A dashboard can observe a field. It cannot choose the rule by itself.

Imagine a resource holder receives an alert that a registry record does not match an expected condition. The software may have read a contact field, compared a route object or checked a resource record against a rule. That comparison can be repeatable. It does not, on its own, establish that the correct policy applies to this member, that the source record is current, or that the member has breached an obligation.

That difference sits at the centre of AFRINIC’s revised Policy Compliance Dashboard proposal, AFPUB-2026-GEN-002-DRAFT02. The version submitted on 25 September says automation should concentrate on conditions that can be measured as objectively as possible and should suggest possible signs of non-compliance. It says the dashboard is not the final judge of the result: staff must verify information obtained by automated testing. Only when evidence suggests non-compliance does the text describe a more exhaustive investigation and possible further action under the RSA or bylaws.

Those clauses do not describe a working product. The current proposal index still marks DRAFT02 as Under Discussion. The article is about the design boundary in the draft and the evidence needed if AFRINIC later builds it.

DRAFT02 changes what an automated result is allowed to mean

The archived DRAFT01 used firmer language. It called for notices when non-compliance was detected, then separately described reminders, staff-defined periods for persistent non-compliance, staff procedures and later-defined rules for withholding services, revoking resources or closing a member. It also proposed a Board exception for certain critical-infrastructure or exceptional cases.

DRAFT02 is not simply the same text with a shorter timetable. It removes the standalone clauses that assigned persistence periods and sanction rules to future staff procedures. In their place, it makes two qualifications explicit: compliance cannot be measured with complete objectivity, and automated checks can only suggest possible signs. Staff verification now appears in the proposed policy text itself. The draft still refers to further RSA/bylaws action, including withholding, revocation or closure; the revision does not erase that possibility.

This is a meaningful change in the role assigned to software. The older wording began with a machine-detected state called non-compliance. The new wording begins with an indicator that may be wrong, incomplete or out of scope. A staff review is the bridge between the two. Whether that bridge is reliable depends on what the reviewer can see and what the member can reproduce.

The policy version belongs beside the test result

The proposal says the dashboard’s automation will need to evolve as the Consolidated Policy Manual changes. That is not a minor maintenance point. A test that accurately reflects yesterday’s rule may misclassify a resource after the policy changes, or may apply a new criterion before its effective date. A green or red status without a rule version hides that distinction.

The archived DRAFT01 staff impact assessment listed examples such as contact accuracy, abuse-contact validity, route-object consistency, RPKI coverage where relevant and reverse-DNS requirements. These are examples from the predecessor’s assessment, not a final DRAFT02 test catalogue and not proof that those checks are deployed. They show why “automated” does not mean “self-explanatory.” A missing contact field may be directly observable; whether that field is required for this resource under the applicable policy is a separate question. A route or RPKI comparison likewise needs an identified source, observation time and scope.

A useful check therefore needs two linked records. The first is the rule map: policy identifier, version, effective date, affected resource class and applicability conditions. The second is the test receipt: data source, collection time, transformation, test version, result and known limits. A staff member should be able to follow the receipt back to the source and say why the rule applies—or why the alert should be cleared. The member should be able to see the same basis without receiving private operational data about anyone else.

This is a recommendation, not a feature AFRINIC has announced. DRAFT02 specifies no complete test catalogue, versioning method, accuracy measure or staff disposition record. The proposal’s own distinction between possible signal and verified information makes those omissions consequential: the reviewer cannot meaningfully verify a result if its input and governing rule are invisible.

The path from data to action has separate steps

A defensible chain has at least four states: a recorded network or registry state; an automated comparison that raises a possible signal; a staff verification that tests the source and the applicable rule; and, separately, any action authorized under the RSA or bylaws. These are different claims. A dashboard label should not silently turn the first into the fourth.

That separation protects both sides. A member can correct an inaccurate record or explain why a rule does not apply. Staff can distinguish a data-quality issue from a policy question. AFRINIC can explain which evidence supports any later investigation. If the check is wrong, the alert can be corrected without leaving an unexplained compliance status attached to the member’s record.

The economic channel is prospective but straightforward. The proposal itself says that future requests, services and membership may be affected under the RSA. A misleading status could consume an operator’s time or influence a later review; an accurate warning could help a member fix a problem before it grows. The public sources show neither outcome today. They support a design question: how would anyone tell a useful warning from a stale or misapplied test?

The version history sets a boundary, not a verdict

AFRINIC-37 considered DRAFT01 on 24 June. The minutes say the co-chairs found no rough consensus and returned that version to the mailing list; an August notice records the same result. DRAFT02 followed on 25 September, and its own revision history says it reflects RPD discussion and an impact assessment. The earlier meeting outcome belongs to DRAFT01; it is not a decision on the current version.

The revision narrows what automation is supposed to decide and adds human verification. That is a stronger evidentiary boundary, but not a demonstrated safeguard in operation. The next policy step should make the test catalogue reviewable alongside the policy it implements: version, effective date, scope, source, test logic, result limits and the record of staff verification. That would let members and operators check the mechanism before any alert is treated as more than a lead.

Sources and scope. AFRINIC’s DRAFT02 proposal and current proposal index establish the current wording and status. The archived DRAFT01 and its impact assessment supply the predecessor wording and illustrative checks. The AFRINIC-37 minutes and 12 August co-chairs’ notice document DRAFT01’s return to the mailing list. None establishes deployment or a member-level result.