Summary

  • AFRINIC’s captured DBWG overview reports 83 work items: 46 Open and 37 Resolved. The figures are a dated public stock snapshot, not a performance finding.
  • The DBWG process describes six stages from Raised through Recorded and defines Open as no recorded resolution, decision or deployment.
  • The public tracker gives each row a status, request, outcome, dates and thread link, but not a structured history through every lifecycle stage.
  • A small, versioned state path could make the existing process more intelligible without demanding private triage, named assignments or sensitive implementation detail.

A public register is already doing useful work

The case for AFRINIC begins with the purpose of the DBWG, not with a demand for theatre. The group is a channel for technical discussion of WHOIS and the underlying database. Comments and suggestions are welcome, while final implementation decisions remain with AFRINIC staff. The public process also says that operational incidents and urgent bugs belong in the relevant operational channels, not merely on a discussion list. That is a sensible division. A working-group register is neither a ticketing system nor a public promise that every question has the same urgency.

The register is useful precisely because it does not pretend otherwise. Its work-items page says it gathers requests, bug reports and proposals raised on the mailing list and classifies them Open or Resolved. The accompanying tracker provides a request, a latest-status narrative where present, the person who raised it, a raised date, a last-activity date and a link back to the relevant thread. The pages also qualify their own provenance: the register is compiled from the public mailing-list archive and reconciled with the official issue tracker or WHOIS changelog where those confirm a decision or deployment.

That is a serious public record. It lets a reader locate a question rather than confuse an unsearched archive with an answer. It preserves a route back to the discussion. It distinguishes a recorded outcome from an item that has no recorded outcome. None of this proves that staff have no additional record, no private review, no security constraint, no test work or no reason to defer a public explanation. The public register should be read as the public register.

The gap is between a total and a transition

The difficulty appears when the six-stage process is placed beside the two-status tracker. The process gives a reader a vocabulary: raised, discussed, consensus, decision, implementation and recorded. The tracker gives a useful snapshot and often a narrative outcome. Yet its visible row model does not provide a versioned sequence that tells the reader which public transition occurred, when it occurred and which source confirms it.

This is not an argument that every item must advance. Some requests may remain under discussion. Some may not reach consensus. Some decisions may properly be to do nothing, to defer, or to handle a matter through another channel. A recorded non-decision is not a failure, and an implementation may require work that cannot safely be described in detail. The point is not to abolish discretion. It is to stop asking a bare total to stand in for all those distinct states.

The practical consequence is interpretive rather than accusatory. A last-activity date is not a decision date. A thread is not proof of deployment. A consensus label is not an implementation. A row marked Open, under AFRINIC’s own definition, means that no resolution, decision or deployment is recorded. It does not tell a reader why. Treating it as a verdict would create precisely the false certainty that a public record ought to resist.

A thin state path would be enough

AFRINIC does not need to publish a confidential engineering board to make the existing lifecycle readable. Each work-item page could retain the current request and thread link, then add a compact, versioned series of public state events. The events could use the process vocabulary: raised; under discussion; consensus recorded; staff decision recorded; implementation or testing announced; deployed and linked to a changelog; or no public disposition recorded as of a stated date.

The important fields are modest: the lifecycle state, the date on which that public state was recorded, the source that supports it, and a change history when a state changes. Where a dependency can be described safely, a broad class is enough: external standard, security review, implementation sequencing or another operational channel. Where it cannot be described safely, the record can say no public detail. Neither form requires a named employee, private correspondence, internal estimates or a service-level promise.

The benefit is not that the register becomes a tribunal. AFRINIC staff would still make implementation decisions, as the public page says. The benefit is that the public artifact would describe the difference between a question that has been raised, a decision that has been made and a change that has been deployed. That is a narrow form of accountability: not power over the decision, but a durable account of the decision’s public state.

Preserve the distinction for the next reader

Registry records are often used after the people who first read them have moved on. A future operator, researcher or member may find an item number, a date and a label without knowing whether the record describes a live technical question, a completed deployment, an explicit decision not to proceed or simply the end of a public thread. A count cannot solve that interpretive problem. A state path can.

The irreversible risk is not that AFRINIC has 46 open items on one dated page. It is that a public record designed to make work discoverable becomes too compressed to explain its own states. A thin, source-linked transition record would preserve the usefulness of the register without claiming that public visibility is command, that every item deserves the same treatment or that private operational work should be exposed.

Sources

  1. AFRINIC Database Working Group overview
  2. AFRINIC DBWG process
  3. AFRINIC DBWG work items
  4. AFRINIC DBWG work-item data
  5. AFRINIC DBWG work-item renderer