Summary

  • AFRINIC’s live Service Level Commitment is labelled Version 1, November 2015. It promises an effective response to all queries addressed to the Operations Team within two working days and names twelve populated queues.
  • A separate support directory publishes sixteen specialist email classes, while the main Contact Us page presents three broad addresses and a general form. The terms overlap, but they do not form a published one-to-one map.
  • This is not evidence that a request was lost or that AFRINIC missed its commitment. The missing control is a versioned intake crosswalk showing which entry point reaches which queue, when the response clock begins, and whether a transfer preserves the original receipt time.
  • AFRINIC can keep both specialist channels and a simple front door. What it should add is a public receipt joining service class, destination, clock, fallback and escalation without revealing ticket contents or internal security details.

A request with three browser tabs

Imagine the routine case before the difficult one. A network operator needs help with a reverse-DNS change. There is no outage, no dispute and no reason to escalate. The operator simply wants to place the request in the channel to which AFRINIC’s service commitment applies.

One public page offers a table headed “Queue.” Its rows include Service support, DNS & DNSSEC support and Routing Registry. Another page, “Support Emails and Mailing Lists,” offers Account Info & Services, DNS and DNSSEC, Routing Registry and DB-help, each with a specialist address. The main Contact Us page instead offers Registry Queries and Technical Support, then invites the visitor to open a general form.

Each page is understandable on its own. Together they create a small institutional puzzle: which public label is the one the clock recognizes?

The question matters because AFRINIC has made a measurable promise. Its Service Level Commitment identifies itself as Version 1, November 2015. Section 3.2 says the Operations Team is committed to providing an effective response to all queries addressed to it within two working days. The annex distinguishes response time—how quickly AFRINIC responds to an issue—from resolution time, which runs until the issue is fully resolved.

That is a useful distinction. A technically hard request may not be solved in two days. A credible first response can still acknowledge receipt, identify what evidence is missing and tell the member which team now owns the matter. But the distinction works only if the sender and the registry can agree on when the request entered the governed queue.

Twelve queues in the commitment

The SLC’s own map is granular. It contains twelve populated queue rows: How to Become a Member; Membership application Evaluation; Hostmaster; Billing; Service support; Service Infrastructure Maintenance; RPKI Support; DNS & DNSSEC support; Routing Registry; Website information; Complaint report; and Complaint escalation.

The descriptions make several boundaries reasonably clear. Hostmaster covers requests for additional resources and general queries about IP-resource management. Service support covers reverse DNS, BPKI certificates, MyAFRINIC and the Whois database, including errors involving Whois objects. The RPKI and routing-registry rows identify their respective specialist functions. Complaint report and Complaint escalation are separate states.

This is more than a directory. It is the vocabulary placed directly under the two-working-day commitment. A reader can therefore reasonably treat those labels as the service classes against which the promise is understood.

The same document gives complaints a more explicit sequence. A complaint received by telephone or email is to receive a response within two working days, excluding public holidays observed in Mauritius. If the matter is not resolved to the correspondent’s satisfaction, the page invites escalation, asks for useful information including the service ticket number and gives the escalated complaint another two-working-day response statement.

Nothing in that wording guarantees a result favourable to the complainant. Nor does it convert a first response into final resolution. It does, however, create a traceable transition: request, ticket, complaint, escalation. For that transition to be practical, the current public entrance for each state must be easy to identify.

Sixteen specialist addresses in the directory

AFRINIC’s support email directory presents a second map. Its rationale is strong: different requests require particular expertise, so the organisation publishes different addresses with the stated aim that no query goes unnoticed.

This directory contains sixteen service labels. Some resemble the SLC closely. Hostmaster/IP Resources sits beside Hostmaster. Account Info & Services resembles Service support. Outage is a natural neighbour of Service Infrastructure Maintenance. RPKI, DNS and DNSSEC, Routing Registry and Escalation all have recognisable counterparts.

But resemblance is not a crosswalk. The directory adds DB-help, Training, two Fellowship contacts, General, Data Protection and IT security/Responsible disclosure. It uses Prospective Members where the SLC separates becoming a member from evaluating a membership application. It publishes Escalation but no row carrying the exact label Complaint report. The SLC names Website information; the email directory has no row with that name.

There may be excellent internal mappings behind these labels. The directory’s Account Info & Services destination may feed the same work queue as the SLC’s Service support. Its Outage destination may be the correct modern entrance for Service Infrastructure Maintenance. A message to General may be classified by staff and retain its original timestamp. None of those possibilities is evidence of failure.

They are precisely why a public mapping would help. Without one, an outsider cannot tell whether two labels are synonyms, whether one is a broader front end to several queues, or whether the SLC table and the live directory describe different generations of the service design.

Three broad contacts and a form

The Contact Us page creates a third map by doing something reasonable: it simplifies. Under Support Emails, it lists three named destinations: Registry Queries, Technical Support, and Media & Press. For questions about membership, IP-address allocation or the BGP routing registry, it also points visitors to a form.

The linked general contact form asks for a name, email address, subject and message. It does not display a service-class dropdown or a reference to one of the SLC queue labels. The subject line may be entirely sufficient for skilled staff to route the message. The form may attach internal metadata invisible to the sender. This review did not submit a test request and did not inspect AFRINIC’s ticket system.

The public question is narrower. If a member uses the Technical Support route for a routing-registry problem, is the request considered addressed to the Operations Team at first receipt, or only once it reaches the Routing Registry queue? If the general form is reclassified as Billing, does the original timestamp travel with it? If a request begins at Registry Queries but belongs to Hostmaster, which public promise governs the handoff?

The pages do not answer those questions in one place. That absence does not show that a clock restarts. It shows that the correspondent cannot verify whether it does.

Simplicity and specialization are both defensible

It would be a mistake to turn the three maps into a design scandal. A visitor who does not know the difference between Whois, IRR and RPKI should not be forced to pass a registry terminology exam before asking for help. A broad Technical Support address and a free-text subject can reduce abandonment and misclassification.

Specialist addresses serve the opposite but equally valid need. An experienced operator reporting a routing-registry issue can avoid a general queue. A responsible-disclosure address should remain separated from ordinary support. Billing and data-protection questions may require handling rules that do not belong in a technical inbox.

The conflict arises only if simplification and specialization are left without a published join. A good public service design can offer both. It can let the sender choose the narrow route when confident, use the broad route when not, and preserve the same service clock through triage.

That last clause is the control. Otherwise the institution can measure response from arrival in the specialist queue while the correspondent measures from submission at the advertised front door. Both records can be internally consistent and still disagree about the same experience.

The missing object is an intake crosswalk

AFRINIC does not need to publish staff names, ticket text, internal mail rules or sensitive routing logic. It needs a small versioned table.

Each row should begin with a plain-language request type and a few examples: new membership, additional IPv4 or IPv6 resources, account details, reverse DNS, Whois object, IRR, RPKI, billing, outage, complaint, escalation, privacy and responsible disclosure. It should then name the currently advertised entrance and the SLC queue to which that entrance maps.

The next fields should make time auditable. What event counts as receipt? Does an automated acknowledgement establish it? Which working-day calendar applies? Does transfer or reclassification preserve the first timestamp? What is the first-response objective, and which separate indicator describes resolution?

Finally, the row should state fallback and escalation. If a specialist address rejects a message, where should it be resent? If the form fails, which public address is equivalent? When does an unanswered service request become a complaint, and when does a complaint become an escalation? The SLC already asks for a service ticket number at the escalation stage; the crosswalk should show how the sender obtains and carries that identifier forward.

The table should have an effective date, version, responsible role and change notice. The SLC says amendments may be made after thirty days’ notice. A corresponding change record for intake would let readers distinguish a deliberate redesign from a stale page without assuming either.

Measurement can remain privacy-safe

A public crosswalk becomes more credible when paired with modest aggregate evidence. AFRINIC could report monthly arrivals by public service class, the share transferred after receipt, first responses within the stated objective, unresolved stock and age bands. Complaints and escalations could be reported as counts and timing distributions.

None of this requires publication of member identities, IP resources, invoice details or security reports. Responsible disclosure should be aggregated carefully or omitted where a small count could reveal a case. The point is not to expose the queue. It is to show that the public entrance and the public commitment describe the same accountable process.

Nor should a single average substitute for the record. An average can improve while a small set of old requests remains unresolved. A compliance percentage can hide transfers whose clocks were reset. The crosswalk defines the unit first; the aggregate then says how that unit behaved.

What the evidence does not establish

No source reviewed for this article identifies a lost message, a wrong routing decision or a missed two-day response. No member ticket was opened. No internal queue, automation rule or staff procedure was inspected. The broad addresses may work exceptionally well, and the form may route every subject correctly.

The SLC’s date also requires discipline. “Version 1 | November 2015” does not make the commitment invalid. The three main AFRINIC pages were live when captured, but a web server’s modification header does not prove the date of a substantive policy review. The proper finding is not that one page is old and another is new. It is that their public taxonomies are not joined by a versioned map.

Finally, the two-working-day statement is a response commitment, not a resolution promise. A crosswalk would make that boundary more visible, not erase it. The goal is to locate the clock accurately and preserve its timestamp through intake, not to promise that every resource, billing or security question can be completed within the same interval.

Sources