Zusammenfassung

  • Der vorgeschlagene SLA gilt für Systemleistung und Verfügbarkeit. Die Leistung des Tools Team sowie Terminierung und Planung seiner Arbeit sind ausdrücklich nicht erfasst.
  • Die UX-Konsultation behandelt Oberflächen, Barrierefreiheit, Zugriffskontrolle, Client-Anforderungen und Web-, CLI-, Plugin-, API-, MCP- und Offline-Nutzung; Systemleistung bleibt dem parallelen SLA-Verfahren vorbehalten.
  • Ein öffentlicher, versionierter Beleg kann Rückmeldung, Dienst, Messpunkt, Ausnahmen, Entscheidungsbefugnis, Umsetzungseigentümer, Priorität, Zeitstatus und Prüfung verbinden, ohne die beiden Entscheidungsstände zusammenzulegen.

Gleicher Start, unterschiedliche Entscheidung

Am 17. September 2026 bat die IETF LLC um Stellungnahmen zu zwei Aspekten der IETF-Tools. Beide Verfahren enden am 12. Oktober. Antworten können vertraulich an Board und Executive Director oder öffentlich an tools-discuss gehen. Gleiche Frist und Kanäle schaffen jedoch keine einheitliche Zuständigkeit.

Das SLA-Papier entwirft beobachtbare Systemziele: Verfügbarkeit, Web-Antwortzeit, Mail-Verzögerung und Reaktion auf Vorfälle. Es ordnet Dienste Stufen zu, gewichtet Teilausfälle, benennt Ausnahmen und sieht Monatsberichte sowie eine jährliche Überprüfung vor. Damit soll aus „best efforts“ eine überprüfbare Diensterwartung werden.

Das UX-Papier fragt dagegen, wie Menschen mit den Werkzeugen arbeiten sollen. Es betrachtet Web, Kommandozeile, Plugins, APIs, Model Context Protocol und Offline-Betrieb. Hinzu kommen Barrierefreiheit, Authentisierung, Client-Voraussetzungen, dauerhafte URLs und Personalisierung. Systemleistung ist ausgenommen, weil sie in der anderen Konsultation behandelt wird.

Damit ist auch die Aussagekraft getrennt. Ein Verfügbarkeitswert kann zeigen, wie sich ein Dienst an einem definierten Messpunkt verhielt. Er bewertet nicht automatisch die Arbeit eines Teams und legt keine Entwicklungsreihenfolge fest. Eine angenommene UX-Anforderung kann einen Bedarf bestätigen, beweist aber keine erfüllte Dienstgüte.

Was die Dienstuhr misst

Der Entwurf zieht die Grenze ausdrücklich: Teamleistung sowie Terminierung und Planung der Arbeit gehören nicht in den SLA. Diese Fragen mögen berechtigt sein; ein Systemwert beantwortet sie nicht.

Innerhalb des Bereichs ist das Modell konkret. Automatisches Monitoring soll für Verfügbarkeit maßgeblich sein. Totalausfall zählt mit 1, erhebliche Beeinträchtigung mit 0,5, geringe mit 0,25 und rein kosmetische Fehler mit null. Kritische Infrastruktur wird anders behandelt als weniger wichtige oder externe Dienste. Die Web-Messung endet am Server und schließt Client-Rendering, Nutzernetz und bestimmte Drittabhängigkeiten aus.

Deshalb sind Ausnahmen Teil des Befunds. Geplante Wartung, Fehler Dritter, höhere Gewalt, Endgerät oder Netz des Nutzers und gezielte Sicherheitsmaßnahmen sollen ausgenommen werden. Notfallwartung sowie Störungen durch Missbrauch oder übermäßige Last verschwinden dagegen nicht automatisch. Eine Quote ohne Messbasis und Ausnahmegrund kann Verantwortung verschleiern.

Auch die Folge eines verfehlten Ziels ist begrenzt: Prüfung und Verbesserung statt Strafe. Das Papier beschreibt ein kleines, verteiltes Team mit üblichen Arbeitszeiten, keinen rund um die Uhr besetzten Betrieb. Die Konsultation betrifft somit Erwartungen und Investitionen, nicht eine Produktivitätsnote.

Die vorhandenen Messdaten werden nur sieben Tage gehalten und nicht regelmäßig exportiert. Fehlende Langzeitanalyse ist ein Grund, Beobachtung zu verbessern. Sie ist kein Beleg für aktuelle Störungen.

Worüber die UX-Uhr entscheidet

Die UX-Konsultation setzt an der organischen Entwicklung der Werkzeuge an. Viele Oberflächenentscheidungen lagen bei Entwicklern; beim neuen rfc-editor.org wurden Fachleute einbezogen. Ein formales, portfolioübergreifendes Verfahren für Gemeinschaftsfeedback fehlte bislang.

Gefragt wird nach Entscheidungen: mehr Kommandozeilen- oder Offline-Funktionen, vertretbare JavaScript-Abhängigkeit, Reichweite von Single Sign-on und Selbstverwaltung, mögliche KI- oder MCP-Nutzung und externer Sachverstand für Barrierefreiheit. Das sind Produkt- und Zugangsfragen.

Sie haben messbare Folgen. Offline-Fähigkeit benötigt möglicherweise synchronisierte Daten oder gepflegte Container. Authentisierung schafft Abhängigkeiten. API und MCP verändern Lastprofile und können Schlüssel oder Begrenzungen erfordern. Dennoch folgt die Messung aus der Wahl; sie ersetzt die Wahl nicht.

Der Beleg für den Übergang

Die Community Engagement Policy der IETF LLC verlangt bereits, Rückmeldungen zu verfolgen, sie zu übernehmen oder die Ablehnung zu begründen und die Entscheidung mitzuteilen. Für die parallelen Verfahren sollte daraus ein überprüfbarer Übergangsbeleg werden.

Zu jedem wesentlichen Punkt gehören acht Angaben: Rückmeldung; betroffener Dienst oder Nutzungsmodus; Metrik und Messpunkt; Ausnahmen; entscheidende Stelle; Umsetzungsverantwortung; Prioritäts- und Zeitstatus; spätere Berichts- oder Prüfstelle. Verwandte SLA- und UX-Einträge werden verlinkt, behalten aber je einen eigenen Zustand.

Bei einem Wunsch nach zuverlässiger Offline-Nutzung würde der UX-Eintrag Annahme, Ablehnung oder Vertagung und die Produktverantwortung zeigen. Der Dienst-Eintrag würde Datensatz, Synchronisationspunkt oder Container, Messort und externe Abhängigkeiten benennen. Ein angenommener Bedarf ist noch kein erfülltes Ziel; eine grüne Verfügbarkeit noch kein gelöster Arbeitsablauf.

Versionen bewahren die Reihenfolge. Eine UX-Entscheidung kann vor Budget und Umsetzung fallen. Neue Last kann später eine Metrik ändern. Jeder Schritt braucht Datum, Befugnis und Reichweite.

Die Spur ist keine zentrale Aufgabenliste. Sie dokumentiert Übergaben: Messung bleibt beim Dienst, Nutzung bei UX und Planung in ihrem eigenen Verfahren.

Quellen