Zusammenfassung

  • Der RSSAC Caucus leistet den Großteil der Facharbeit, kann aber nicht formell als RSSAC handeln. Der RSSAC ernennt Mitglieder, kann Arbeitsaufträge verändern, Entwürfe überarbeiten lassen und über die Veröffentlichung abstimmen.
  • RSSAC000v10 beschreibt den Prozess genauer als das Verfahren, das 2018 unabhängig geprüft wurde. Öffentlich fehlen weiterhin aktuelle Ablehnungs- und Beschwerdedaten, eine Verteilung der Beiträge sowie eine vollständige Änderungsspur vom stabilen Caucus-Entwurf bis zur genehmigten Fassung.
  • Der Caucus besitzt vorgelagerte Deutungs- und Strukturmacht. Er betreibt nicht das Root-System, vergibt keine Nummernressourcen, setzt keine RIR-Regeln oder IETF-Standards und kann weder das ICANN Board noch unabhängige Betreiber verpflichten.

Die Rollen stehen im Anhang

RSSAC062, die im Mai 2025 genehmigte Empfehlung zur Meldung von Sicherheitsvorfällen, macht den Produktionsweg sichtbar. Dreizehn Personen werden als Mitwirkende aus dem RSSAC Caucus genannt. Robert Story war Leiter der Arbeitsgruppe, Ken Renard RSSAC-Shepherd. Vier ICANN-Beschäftigte unterstützten die Arbeit, darunter ein Redakteur. Das Dokument verzeichnet weder Dissens noch Rückzug und ordnet die Konsensgenehmigung dem RSSAC zu.

Diese Angaben messen nicht, wer wie viel geschrieben hat. Sie zeigen auch nicht jede Änderung durch den RSSAC. Sie trennen aber fachliche Mitwirkung, Leitung, Verbindung zum formellen Ausschuss, redaktionelle Unterstützung und institutionelle Genehmigung.

RSSAC000v10, am 4. August 2026 genehmigt, macht daraus das aktuelle Verfahren. Danach produziert der Caucus die Mehrheit der RSSAC-Berichte und -Empfehlungen. Zugleich ist der RSSAC die einzige Stelle, die formell als RSSAC handeln kann.

Ein Caucus-Arbeitsprodukt wird zunächst im Caucus geprüft. Danach geht es an den RSSAC, der Kommentare, Fragen und Änderungen zurückgeben kann. Der Leiter arbeitet diese Rückmeldungen ab, bis der Text stabil ist. Erst dann beantragt er eine formelle Handlung; der Vorsitz setzt die Genehmigung auf die Tagesordnung einer regulären Sitzung.

Die Verfasser veröffentlichen nicht selbst. Jeder Root-Server-Betreiber hat im RSSAC eine Stimme. Nach der aktuellen Regel braucht eine Publikation eine qualifizierte Mehrheit von 75 Prozent. Das Personal bereitet die Veröffentlichung erst nach der Genehmigung vor.

Damit existieren zwei Werkstätten. Die größere Gruppe bestimmt, welche Belege zuerst zusammengeführt und welche Optionen als vollständiger Entwurf sichtbar werden. Das kleinere Betreiberorgan entscheidet, ob daraus eine institutionelle RSSAC-Position wird. Frühe Rahmung ist Macht, aber keine formelle Beschlusskompetenz.

Der erste Hebel liegt bei der Aufnahme

Die öffentliche Caucus-Seite zeigte bei der Erfassung 115 Ergebnisse, die RSSAC-Mitgliederseite 24. Das sind Profilzahlen, keine Aktivitäts- oder Stimmzahlen. Sie verdeutlichen dennoch, dass der Produktionspool deutlich größer ist als das formelle Beschlussorgan.

Das Membership Committee prüft Bewerbungen zuerst. Es bewertet Kenntnisse der RSSAC-Arbeit, verfügbare Zeit sowie nützliche Fähigkeiten und Erfahrung. Der RSSAC ernennt dieses Komitee. Die aktuelle Beitrittsseite nennt Shailesh Gupta, Dave Lawrence, Jeff Osborn und Ken Renard.

Wird eine Person vom Komitee nicht empfohlen, erfährt der RSSAC ihren Namen nicht. Der Komiteevorsitz behandelt eine Beschwerde im Einzelfall; innerhalb desselben Zwölfmonatszeitraums ist keine erneute Bewerbung möglich. Eine empfohlene Person wird dem RSSAC für eine einwöchige Entscheidung vorgelegt. Ohne Einwand erfolgt die Aufnahme. Ein einziger Einwand genügt zur Ablehnung. Auf Antrag erhält die betroffene Person eine Erklärung und kann Beschwerde einlegen; der RSSAC-Vorsitz entscheidet im Einzelfall über das Verfahren.

Die geprüften Unterlagen belegen keinen Missbrauch. Sie enthalten aber auch keine Zahl der Bewerbungen, Ablehnungen, Begründungen, Erklärungsanträge oder Beschwerdeergebnisse. Nachweisbar ist daher eine Prüflücke, nicht ein unlauteres Motiv.

Der Zugang wirkt auf spätere Sacharbeit. Wer am Eingang gestoppt wird, kann als Caucus-Mitglied weder vorschlagen noch schreiben oder prüfen. Das Membership Committee entscheidet keinen technischen Befund, prägt aber den Kreis, aus dem der nächste Befund entsteht.

Initiative von unten, Freigabe von oben

RSSAC- und Caucus-Mitglieder können Arbeitsgegenstände im jeweils zuständigen Gremium vorschlagen. Für Caucus-Arbeit ist ein Arbeitsauftrag erforderlich. Der Caucus kann ihn beraten und verändern. Anschließend kann der RSSAC erneut beraten und ändern, bevor der Vorsitz eine Abstimmung über den Beginn ansetzt.

Nach Einsetzung einer Arbeitsgruppe verwaltet das Personal den Start, bis eine Leitung bestimmt ist. Gehört die Leitung nicht dem RSSAC an, wird ein RSSAC-Mitglied als Shepherd benötigt. Die Leitung koordiniert Beitragende, Prüfer und Beobachter und berichtet an den RSSAC. Hält dieser den Fortschritt für unzureichend, kann er die Leitung ersetzen.

RSSAC001v3 liefert ein aktuelles Beispiel. Der Arbeitsauftrag von April 2025 überprüft die Diensterwartungen an Root-Server-Betreiber. Die Gruppe darf feststellen, dass keine neue Fassung nötig ist, muss dies aber zwei Wochen vorher auf der Hauptliste des Caucus ankündigen. Bei einem Dissens entscheidet der RSSAC per Abstimmung über die Beendigung. Entsteht eine neue Fassung, muss auch sie vom RSSAC beschlossen werden.

Der Expertenkreis darf initiieren und produzieren. Die institutionelle Verantwortung für den Namen RSSAC bleibt beim Betreiberorgan.

Eine Bestandsaufnahme von 2018 ist kein Gegenwartswert

Die unabhängige Prüfung von 2018 dokumentierte Anerkennung für Qualität und Sichtbarkeit der Caucus-Dokumente. Zugleich schätzte sie, dass damals nur 25 bis 30 von etwa 90 Mitgliedern aktiv mitwirkten. Sie berichtete unklare Grenzen zum RSSAC, unscharfe Prioritäten, inaktive Mitglieder und eine faktische Kontrolle des RSSAC über Ein- und Austritt.

Diese Befunde erklären spätere Reformen. Sie beweisen nicht die Teilnahmequote von 2026. Anonyme Interviewaussagen im Bericht sind wiedergegebene Wahrnehmungen, keine bestätigten heutigen Motive.

Empfehlung 6a verlangte ein wirksameres und transparenteres Verfahren für Projektauswahl, Beteiligung und Mitgliederverwaltung, Arbeitssteuerung und Verbreitung der Ergebnisse. 2020 berichtete die Implementierungsgruppe, dass substanzielle Diskussionen und Entwurfsprüfungen auf die öffentliche Caucus-Mailingliste verlegt worden seien. Das Membership Committee untersuche die Beteiligung. Strukturelle Änderungen blieben vom Root Server System Governance Working Group abhängig.

2022 erklärte die Gruppe die zweite Prüfung aus Projektmanagementsicht für abgeschlossen, führte Empfehlung 6a aber weiter als abhängig. Das ICANN Board akzeptierte den berichteten Status und verlangte regelmäßige Fortschrittsmeldungen. Die dritte RSSAC-Prüfung wurde verschoben; laut aktueller Statusseite warten Organisationsprüfungen bis zum Abschluss des ersten Continuous Improvement Program-Zyklus.

Für die Gegenwart ist RSSAC000v10 maßgeblich. Es enthält klare Vorschlagsstufen, Leitungen und Shepherds, öffentliche Listenarbeit, Mitgliederüberprüfung, zwei Entwurfsprüfungen, Dissensfelder, formelle Abstimmung und Veröffentlichung. Das beantwortet einen Teil der alten Kritik. Es ersetzt keine aktuellen Ergebnisdaten über Teilhabe, Ablehnung, Beschwerde oder Textänderung.

Beratung endet vor dem Befehl

Die ICANN Bylaws beschreiben den RSSAC mit Beratungsaufgaben: beraten, kommunizieren, Risiken bewerten, reagieren, berichten und Empfehlungen abgeben. Keine geprüfte Regel ermächtigt Caucus oder RSSAC, einen Root-Server zu betreiben, einen unabhängigen Betreiber anzuweisen, ASN oder IP-Adressen zu vergeben, RIR-Politik zu ändern oder IETF-Standards festzulegen.

Auch das ICANN Board wird nicht gebunden. Nach der RSSAC-Genehmigung kann eine 48-stündige Höflichkeitsvorschau erfolgen. ICANN führt zudem einen Ablauf zur Annahme, Prüfung, Umsetzung und Schließung von Empfehlungen. Ein solcher Ablauf belegt Bearbeitung, nicht Annahme, Kausalität oder Zwang.

Für Inhaber von Nummernressourcen bleibt das Thema indirekt relevant. Diensterwartungen und Vorfallprozesse des Root-Systems prägen die Betriebsgrundlage von Netzen. Entscheidend sind aber drei getrennte Nachweise: Expertenentwurf, formelle RSSAC-Empfehlung und Umsetzung durch den zuständigen Akteur.

Quellen