Summary

  • Policy Compliance Dashboard Draft 1 proposed a private MyAFRINIC view that would periodically show each member several indicators, send notices and reminders, and expose repeated or continuing discrepancies to staff.
  • The useful part of that design was informational: name the exact difference, disclose the evidence and rule version, record when the check ran, let the member respond, and preserve the correction history.
  • Payment, document, WHOIS, reverse-DNS, announcement, sub-assignment and transfer evidence are not interchangeable. Compressing them into one status could turn uncertainty into an apparent finding.
  • Automation, repetition, staff review, community consensus, an appeal path or a Board exception can improve or constrain procedure. None can create authority to punish, revoke, recover resources or close membership.
  • AFRINIC-32 recorded no consensus in September 2020, and the official proposal page records Draft 1 as expired. The record proves an attempted design, not an operative system or an action against any member.

L3 — One screen, several kinds of evidence

Imagine opening MyAFRINIC and finding a single page assembled from records that normally live in separate operational worlds. One line says whether an invoice appears paid. Another says whether a requested document is present. A third records whether the member replied to a message. Elsewhere, the page considers whether a number resource is announced, whether WHOIS information is current, whether reverse DNS is configured, whether a PI assignment appears to have been sub-assigned, whether a transfer was authorised, and whether a possible discrepancy has appeared before.

That was the practical attraction of Policy Compliance Dashboard Draft 1: not a new abstract principle, but one place where a member might see what the registry believed required attention.

AFRINIC's official record identifies the instrument as AFPUB-2020-GEN-001-DRAFT01, version 1.0, submitted on 17 February 2020 by Jordi Palet Martinez, Frank Habicht, Mark Elkins and Haitham El Nakhal. The draft proposed periodic reviews of members' status, automated as far as possible, with the result displayed to each member through MyAFRINIC. It contemplated notifications after a review or update, reminders when an indicated problem persisted, and warnings visible to staff. Those elements describe a recognisable service improvement. A member who has missed a change, allowed a contact record to go stale or failed to notice a reverse-DNS problem gains a chance to correct the record before confusion spreads.

The screen's apparent simplicity, however, concealed a difficult classification problem. An unpaid invoice is not the same kind of thing as an old WHOIS field. A missing document is not the same kind of thing as the absence of a route announcement. A route can be absent for legitimate operational reasons; reverse DNS can depend on delegation and customer arrangements; a transfer question can turn on evidence of authority; a response record says only that a communication was or was not received or answered within some period. PI sub-assignment may require context about the arrangement and the applicable rule.

Even the apparently cleanest fields depend on identity, timing and version. The fact that all of them can be represented in software does not make them one legal, contractual or technical object.

That non-equivalence matters before any consequence is considered. A colour, percentage or composite status has rhetorical force. It invites the eye to treat every underlying item as already resolved: green means good; red means bad. But a dashboard is often most useful precisely where the underlying situation is not yet resolved. It should draw attention to a difference between a record and an expected condition, not conceal the steps needed to decide what that difference means.

If the system labels a member “non-compliant” before identifying the exact field, governing text, measurement time and contrary evidence, the display has moved from observation to accusation without doing the work that accusation requires.

The strongest design would therefore resist the temptation to produce one master answer. It would display separate cards or rows for distinct kinds of evidence. Each row would name the data source, the exact version of the policy or contract term used for comparison, the time of measurement, the raw or intelligibly summarised evidence, and the degree of uncertainty. It would explain whether the difference is objective—such as a field being empty at a stated time—or interpretive, such as whether a particular operational arrangement fits a rule.

It would also distinguish data owned by the registry from information supplied by a member or a third party. The point would be to make the path from observation to correction legible.

This precision has an immediate economic value. A member that can see the actual mismatch does not need to open a broad support case merely to discover what AFRINIC means. Registry staff do not need to reconstruct an opaque status from several systems. An operator can assign the issue to the right team: finance for payment, an authorised contact for documents, network operations for routing or reverse DNS, and legal or commercial staff for a transfer question. The correction can be confirmed against the same evidence and timestamp that generated the notice.

Even where the member disagrees, the disagreement becomes specific enough for a bounded human review.

Private visibility is important here. Draft 1 proposed that each member see its own status, not a public member-by-member display. That boundary protects more than reputation. A status assembled from incomplete or stale operational information could reveal where an organisation is experiencing administrative delay, contact failure or uncertainty about a resource. Public exposure could affect counterparties and create security or commercial pressure before the underlying facts had been tested. A private view can support correction without turning an unverified registry signal into a market allegation.

The proposal did not stop at visibility. It separately contemplated more exhaustive investigation and further action under the Registration Services Agreement when evidence appeared to suggest non-compliance. Its proposed ladder reached far beyond contact and rectification: it referred to publication, deletion of relevant name-server records, resource recovery, withholding of services, revocation and closure of membership. It also contemplated a Board extension of a revocation period for essential strategic infrastructure or exceptional circumstances following staff assessment. Those provisions exposed the design's central fault line.

A tool that begins by gathering indicators can easily acquire the appearance of an enforcement mechanism if its output is placed next to a list of grave consequences.

The official material proves that those consequences were proposed in Draft 1. It does not prove that the proposal was adopted, that the stated consequences were authorised, that the dashboard was built, that any automated result was correct, or that any member faced any action. That distinction must be maintained throughout the record. An ambitious consequence clause inside a proposal is evidence of what its authors wanted the instrument to say. It is not evidence that the power existed.

AFRINIC's August 2020 impact assessment made some of the hidden complexity visible. Staff distinguished policy non-compliance from contractual non-compliance and noted that payment and reverse-DNS tools already existed without being consolidated into the proposed dashboard. That distinction should have driven the design, because it acknowledges that the source, meaning and response path for an item vary. The assessment also anticipated significant MyAFRINIC development, work for Member Services and possibly additional staffing. In other words, the screen was not merely a neat presentation layer.

It would have required decisions about data ownership, refresh intervals, thresholds, case handling and responsibility for errors.

Staff questions about repeated or continued violations were especially revealing. A recurrence counter sounds objective, but it is only as meaningful as its reset rule. If a member corrects a stale field and the same field becomes stale two years later, is that a second violation, a fresh service issue or simply the normal decay of administrative data? If the first signal was wrong, does it remain in the count? If two systems report the same underlying event, are they one occurrence or two? Without a threshold and reset rule, “repeated” can become a durable mark that survives correction.

The impact assessment also sought clarification about publication, deletion of domain objects and quarantine mechanics, showing that the steps with the greatest operational consequences were not self-executing technical details.

The AFRINIC-32 minutes add the September 2020 meeting record. Participants expressed both support for visibility and concern about redundancy, cost, staff burden and whether automatic notifications would be effective. The co-chairs recorded no consensus and returned the proposal to mailing-list discussion. The official page now records Draft 1 as expired. That chronology sets the outer limit of what may be said: publication in February, staff interpretation in August, discussion and no consensus in September, and an expired status on the official page.

There is no evidence in this record of adoption, ratification, implementation, an actual member status, a sanction, a revocation, a closure, resource recovery or a quantified loss.

The value of examining the draft is therefore not that it tells a story of harm already done. It shows where an apparently helpful information product needs constitutional restraint before software gives uncertain signals the visual grammar of judgment. The control surface is concrete: which data are selected, which rule and contract versions are used, how often checks run, what labels appear, when counters reset, who receives notices, what staff can see, how human reasons are recorded, how corrections are preserved, and whether any indicator is connected to a consequential act.

Each choice can either keep the dashboard in its proper role or let it imply more authority than the registry possesses.

For readers, members and operators, the first watchpoint is explainability at the level of each indicator. A member should be able to answer five questions without opening a general dispute: What exact fact did the system observe? Against which exact text and version was it compared? When did the comparison occur? How certain is the result? What can the member submit or change to correct it? If the dashboard cannot answer those questions, the status is less an operational aid than a compressed institutional assertion.

The second watchpoint is separation. Objective registry mismatches should not share an undifferentiated label with questions that require context or judgment. A missing required field can be displayed as missing. A disputed transfer authority cannot responsibly be reduced to the same kind of red mark. The third is reversibility: correction should update the current state while retaining a clear, non-punitive revision history. The fourth is privacy: member-level indicators should remain within the relevant account and authorised staff channels.

The fifth is linkage: no dashboard flag, count or notification should automatically trigger a consequential registry action.

Handled this way, the proposed screen could have become a useful difference engine. It could have reduced surprise and support cost while strengthening the accuracy of a shared ledger. Handled otherwise, it could have turned unlike records into one allegation and made a display look like proof. The difference lies not in the colour scheme but in whether the system exposes its reasoning and remains subordinate to correction.