Zusammenfassung

  • AFRINICs öffentliches Service Level Commitment trägt die Kennzeichnung Version 1, November 2015. Es verspricht für alle an das Operations-Team gerichteten Anfragen eine wirksame Antwort binnen zwei Arbeitstagen und führt zwölf benannte Queues auf.
  • Das Support-Verzeichnis nennt sechzehn spezialisierte E-Mail-Kategorien. Die Hauptkontaktseite beschränkt die sichtbare Wahl auf Registry Queries, Technical Support und Media & Press sowie ein allgemeines Formular ohne sichtbare Dienstkategorie.
  • Daraus folgt weder ein verlorenes Ticket noch eine Fristverletzung. Öffentlich ungeklärt bleibt jedoch, welcher Eingang zu welcher SLC-Queue führt, wann die Uhr startet und ob bei einer Weiterleitung der erste Eingangszeitpunkt erhalten bleibt.
  • Eine versionierte Zuordnungstabelle kann allgemeine und spezialisierte Zugänge zugleich erhalten. Sie braucht Diensttyp, aktuelle Adresse, verantwortliche Queue, Empfangsereignis, Übergaberegel, Ersatzweg und Eskalation.

Drei richtige Adressen können eine unklare Uhr ergeben

Ein Mitglied möchte einen Reverse-DNS-Eintrag ändern. Im Leistungsversprechen liest es, Service support sei für Reverse DNS, BPKI, MyAFRINIC und Whois zuständig. Im E-Mail-Verzeichnis findet es Account Info & Services, DNS and DNSSEC und DB-help. Auf der zentralen Kontaktseite bleiben Technical Support oder ein freies Formular.

Das ist nicht automatisch ein schlechter Serviceaufbau. Erfahrene Betreiber profitieren von einem direkten Fachzugang. Wer die interne Terminologie nicht kennt, benötigt einen breiten Eingang. Entscheidend ist, ob beide Wege denselben, nach außen erkennbaren Zeitpunkt für das Leistungsversprechen erzeugen.

AFRINICs Service Level Commitment sagt, das Operations-Team werde alle an es gerichteten Anfragen innerhalb von zwei Arbeitstagen wirksam beantworten. Im Anhang werden Antwortzeit und Lösungszeit unterschieden. Die erste beschreibt, wie schnell AFRINIC auf ein gemeldetes Anliegen reagiert; die zweite reicht von der Erfassung bis zur vollständigen Lösung.

Diese Trennung ist sachgerecht. Ein Ressourcenantrag kann Unterlagen erfordern, eine Rechnungsfrage eine Prüfung und ein Sicherheitsfall technische Arbeit. Die erste Antwort kann trotzdem Empfang, Zuständigkeit und nächste Schritte klären. Sie ist aber nur messbar, wenn Absender und Register denselben Eingang anerkennen.

Zwölf Queues im eigentlichen Versprechen

Das SLC bezeichnet sich als „Version 1 | November 2015“. Es umfasst Registrierungs- und Kundendienst, öffentliche Datenbanken und Onlinedienste, Reverse DNS, Abrechnung und Dienstinfrastruktur. Direkt unter der Zwei-Tage-Aussage steht eine Tabelle mit zwölf ausgefüllten Zeilen.

Genannt werden 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 und Complaint escalation.

Die Beschreibungen geben der Liste Substanz. Hostmaster behandelt zusätzliche Ressourcen und allgemeine Fragen zur Verwaltung von IP-Ressourcen. Service support umfasst Reverse DNS, BPKI-Zertifikate, MyAFRINIC, Whois und Fehler beim Anlegen oder Ändern von Whois-Objekten. RPKI, DNS und IRR stehen jeweils gesondert da.

Damit ist die Tabelle mehr als ein Kontaktblock. Ihre Begriffe bilden die öffentliche Taxonomie des Leistungsversprechens. Wer das Dokument liest, darf erwarten, dass eine aktuelle Kontaktmöglichkeit in eine dieser Kategorien führt oder ausdrücklich außerhalb des Versprechens liegt.

Für Beschwerden wird der Ablauf noch genauer. Auf eine telefonisch oder per E-Mail eingegangene Beschwerde soll das Management binnen zwei Arbeitstagen antworten; gesetzliche Feiertage in Mauritius zählen nicht mit. Bleibt die Lösung unbefriedigend, kann der Vorgang unter Angabe nützlicher Informationen einschließlich der Ticketnummer eskaliert werden. Auch dafür nennt AFRINIC zwei Arbeitstage bis zur Antwort.

Das garantiert weder einen Erfolg der Beschwerde noch eine vollständige Lösung in zwei Tagen. Es schafft aber eine Folge von Zuständen, die durch die Ticketnummer verbunden werden soll. Ein aktueller Zugang zur ersten Beschwerde ist deshalb Teil der Nachweisbarkeit.

Sechzehn Fachadressen im Support-Verzeichnis

Das Verzeichnis der Support-E-Mails folgt dem Prinzip der Spezialisierung. AFRINIC erklärt, unterschiedliche Anliegen benötigten besondere Fachkenntnis; getrennte Adressen sollten dazu beitragen, dass keine Anfrage unbeachtet bleibt.

Die Seite listet sechzehn Kategorien: Hostmaster/IP Resources, Billing, Account Info & Services, Routing Registry, DB-help, Prospective Members, Training, Outage, Fellowship, Fellowship Alumni, General, Escalation, RPKI, DNS and DNSSEC, Data Protection und IT security/Responsible disclosure.

Mehrere Zuordnungen erscheinen plausibel. Account Info & Services dürfte dem älteren Service support nahekommen. Outage kann auf Service Infrastructure Maintenance verweisen. Prospective Members könnte die beiden Mitgliedschaftsphasen zusammenfassen. RPKI, DNS und Routing Registry sind nahezu gleich benannt.

Plausibilität ist jedoch keine veröffentlichte Regel. Das SLC hat eine Zeile Complaint report, während das Verzeichnis nur Escalation ausdrücklich nennt. Website information fehlt dort unter diesem Namen. Umgekehrt erhalten Training, Fellowship, Datenschutz und verantwortliche Schwachstellenmeldung erst im Verzeichnis eigene Kategorien.

Diese Abweichungen beweisen keine getrennten technischen Systeme. Adressen können Aliasse sein. Mehrere Anzeigen können dieselbe Queue beliefern. Mitarbeitende können umklassifizieren, ohne den ersten Zeitstempel zu verändern. Untersucht wurden weder Mailregeln noch Tickets.

Gerade deshalb wäre eine öffentliche Zuordnung nützlich. Sie würde zeigen, ob Begriffe Synonyme, Sammelzugänge, Untergruppen oder Überreste verschiedener Veröffentlichungsstände sind.

Drei breite Eingänge auf der Kontaktseite

Die Kontaktseite reduziert die Auswahl stark. Unter Support Emails stehen drei benannte Ziele: Registry Queries, Technical Support und Media & Press. Fragen zu Mitgliedschaft, IP-Adressvergabe oder BGP-Routing-Registry sollen auch über ein Formular gestellt werden können.

Diese Vereinfachung hat einen guten Grund. Ein Interessent kennt den Unterschied zwischen Informationen zur Mitgliedschaft und der Bewertung eines laufenden Antrags möglicherweise nicht. Eine BGP-bezogene Frage kann Whois, IRR oder RPKI betreffen. Ein breiter Zugang verhindert, dass ein Nutzer zuerst die Organisation des Registers studieren muss.

Das verlinkte allgemeine Kontaktformular fragt Name, E-Mail-Adresse, Betreff und Nachricht ab. Eine sichtbare Auswahl der zwölf SLC-Queues oder sechzehn Fachkategorien gibt es nicht. Ein aussagekräftiger Betreff kann intern vollkommen genügen; das Formular kann außerdem verborgene Zuordnungsdaten übermitteln.

Für diese Untersuchung wurde keine Nachricht verschickt und kein internes System geöffnet. Die Qualität der Weiterleitung lässt sich daher nicht bewerten. Sichtbar ist nur, dass der Absender keine Regel erhält, welche Queue das Formular bedient und welcher Zeitpunkt bei einer späteren Zuweisung gilt.

Bei der Übergabe trennt sich interne von öffentlicher Zeit

Eine Anfrage, die sofort beim richtigen Spezialisten landet, verdeckt den Unterschied. Relevant wird er bei einer Weiterleitung.

Nehmen wir eine Abrechnungsfrage an Technical Support. Das allgemeine Team bestätigt den Eingang und leitet sie an Billing weiter. Der erste Bereich kann ab dem ursprünglichen Empfang messen, Billing ab der internen Zuweisung. Das Mitglied misst ab dem Versand an die veröffentlichte Adresse. Alle drei Zeitangaben können korrekt sein, aber nicht dasselbe Versprechen darstellen.

Bei Beschwerden kommt die Identität des Vorgangs hinzu. Das SLC verlangt bei der Eskalation eine Ticketnummer. Die Hauptkontaktseite zeigt jedoch keinen Zugang mit der Bezeichnung Complaint report. Beginnt der Vorgang im Formular und geht später an Escalation, ist öffentlich nicht erklärt, ob Nummer und Ausgangszeit automatisch mitgeführt werden.

Aus dem Schweigen darf man keinen Neustart der Uhr ableiten. Ebenso wenig lässt sich ihr Fortlauf überprüfen. Der Befund lautet daher nicht „AFRINIC setzt die Frist zurück“, sondern: Die Regel für den Übergang ist nicht öffentlich nachvollziehbar.

Eine Zuordnungstabelle reicht aus

Die Lösung erfordert weder ein neues Portal noch weniger Adressen. Sie erfordert eine kleine, versionierte Tabelle.

Jede Zeile sollte ein Anliegen in verständlicher Sprache benennen: Mitglied werden, Ressourcen beantragen, Kontaktdaten pflegen, Rechnung klären, Whois ändern, Reverse DNS verwalten, IRR oder RPKI nutzen, einen Ausfall melden, Beschwerde einlegen, eskalieren, Datenschutzrechte ausüben oder eine Sicherheitslücke melden.

Daneben gehören die aktuell veröffentlichte Adresse beziehungsweise das Formular und die zuständige SLC-Queue. Bei einem allgemeinen Eingang kann die Zeile mögliche Fachziele und Beispiele nennen. Für sicherheitskritische Meldungen genügt die Bestätigung des richtigen Spezialkanals; interne Prüfschritte müssen nicht veröffentlicht werden.

Die Zeitspalten bilden den Kern. Welches Ereignis gilt als Empfang? Bestätigt eine automatische Nachricht diesen Zeitpunkt? Welcher Arbeitstagskalender gilt? Behält eine Umklassifizierung den ersten Zeitstempel? Welches Ziel gilt für die erste Antwort, und wie wird die spätere Lösung getrennt dargestellt?

Dann folgen Ersatzweg, Beschwerde und Eskalation. Wenn eine Fachadresse eine Nachricht ablehnt oder das Formular nicht verfügbar ist, braucht der Absender einen gleichwertigen Weg. Der Vorgang sollte über die Ticketnummer verbunden bleiben.

Version, Wirksamkeitsdatum, verantwortliche Funktion und Änderungshistorie vervollständigen die Tabelle. Einzelne Mitarbeitende müssen nicht genannt werden. AFRINIC kann eine Adresse weiterhin ändern; es dokumentiert lediglich, wann und mit welcher Wirkung der Übergang erfolgte.

Mitgliedertexte, Ressourcendaten, Rechnungen, Mailfilter und Sicherheitsverfahren bleiben vertraulich. Veröffentlicht wird allein der Kontrollpunkt zwischen einer empfohlenen Kontaktaufnahme und einer messbaren Dienstverantwortung.

Aggregate ohne Preisgabe einzelner Fälle

Auf dieser Grundlage ließen sich monatlich Eingänge, Weiterleitungen, erste Antworten innerhalb des Ziels, offene Bestände und Altersklassen nach Diensttyp berichten. Beschwerden und Eskalationen könnten als Anzahl und Zeitverteilung erscheinen.

Kleine oder sensible Kategorien sollten zusammengefasst oder ausgelassen werden, wenn sonst ein Einzelfall erkennbar würde. Das Ziel ist nicht der Einblick in Tickets, sondern die Bestätigung, dass öffentlicher Eingang und gemessene Einheit zusammenpassen.

Ein Durchschnitt allein genügt nicht. Viele schnelle Antworten können wenige alte Fälle verdecken. Eine Quote kann gut aussehen, wenn jede Weiterleitung eine neue Uhr erzeugt. Der unveränderte Eingangsstempel und Altersbänder machen die Zahlen belastbarer.

Auch für AFRINIC entsteht Nutzen. Hohe Weiterleitungszahlen weisen auf missverständliche Bezeichnungen hin. Ein alter Bestand in einer Kategorie verlangt eine andere Maßnahme. Beschwerden nach Übergaben können eher ein Kommunikations- als ein Fachproblem anzeigen.

Grenzen des Befunds

Keine der vier Seiten belegt eine verlorene, ignorierte, falsch zugewiesene oder verspätet beantwortete Anfrage. Es wurde kein Formular getestet, kein Mitgliedskonto benutzt und kein internes Ticket gelesen. Die breiten Eingänge können alle Fachanliegen zuverlässig verteilen.

Die Jahresangabe 2015 macht das SLC nicht ungültig. Die Seite war zum Untersuchungszeitpunkt öffentlich erreichbar. Technische Änderungsangaben eines Servers belegen außerdem nicht, wann die Inhalte zuletzt fachlich überprüft wurden.

Schließlich sind zwei Arbeitstage eine Antwort-, keine Lösungsfrist. Die vorgeschlagene Tabelle soll diese Grenze schärfen: Sie fixiert den ersten Empfang und zeigt einen offenen Vorgang getrennt von der ersten Reaktion.

Quellen