Zusammenfassung

  • ICANN ist eine kalifornische gemeinnützige Public-Benefit-Corporation und keine Regierungsbehörde; seine Gründungsdokumente begründen daher nicht automatisch Gesetzgebungs-, Polizei- oder Rechtsprechungsbefugnisse.
  • Die praktische Wirkung entsteht entlang einer Implementierungskette: Richtlinien werden entwickelt, in Verträge aufgenommen oder in technische Dienste übersetzt, während Revisions- und Beschwerdewege nicht zwingend den eigentlichen Kontrollpunkt erreichen.

Die entscheidende Frage liegt am Kontrollpunkt

Bei Internet-Governance wird Autorität oft als Eigenschaft einer Institution behandelt. Für die Betroffenen ist jedoch eine andere Frage wichtiger: Wer kann unter welchem Instrument die konkrete Handlung ausführen, verhindern oder korrigieren? Bei einer Top-Level-Domain kann das die vertragliche Compliance gegenüber einem Registrar oder einer Registry sein. Bei der Root Zone kann es eine technische Änderungskontrolle oder eine Wartungsleistung sein. Bei Nummernressourcen liegt die politische Ebene teilweise bei den Regional Internet Registries, während die IANA-Nummerierungsdienste vertraglich geregelt sind.

Diese Unterscheidung verhindert zwei gegensätzliche Fehler. ICANN sollte weder als souveräne Weltregierung beschrieben noch als bloß moderierendes Forum unterschätzt werden. Ein privater Vertrag kann für einen Vertragspartner erhebliche, praktisch regulatorische Folgen haben, ohne dadurch öffentliche Hoheitsgewalt zu werden. Umgekehrt kann ein technischer Dienst eine kritische Wirkung auf Nutzer haben, obwohl die zugrunde liegende Organisation keine allgemeine Zuständigkeit für Inhalte oder Dienste besitzt.

1. Die Satzung gibt Zweck und Organisationsform vor

Die Articles of Incorporation errichten ICANN als kalifornische gemeinnützige Public-Benefit-Corporation. Zu den genannten Zwecken gehört die Koordination der globalen Systeme für eindeutige Internet-Kennungen und die Förderung ihrer betrieblichen Stabilität. Das Gründungsdokument beschreibt damit Organisationsform und Zweck, aber keine staatliche Delegation. Es ist kein Nachweis für eine souveräne Lizenzierungs-, Strafverfolgungs- oder adjudikative Befugnis. [Quelle: https://www.icann.org/resources/pages/governance/articles-en]

Die Bylaws konkretisieren die Mission. Sie beziehen sich auf die Koordination der eindeutigen Internet-Kennungssysteme und auf Richtlinien, die angemessen und vernünftig mit diesen technischen Aufgaben zusammenhängen. Zugleich erklären sie, dass ICANN keine staatlich verliehene regulatorische Autorität besitzt und Dienste oder Inhalte außerhalb seiner festgelegten Mission nicht regulieren darf. Diese Bestimmungen sind wichtige konstituierende Dokumente und geben die institutionelle Selbstbeschreibung wieder. Sie entscheiden allein jedoch nicht, ob externes Recht in einem bestimmten Streitfall zusätzliche öffentliche Befugnisse verleiht oder begrenzt. [Quelle: https://www.icann.org/resources/pages/governance/bylaws-en]

Der erste Befund lautet daher: Die Satzung schafft Kapazität und Grenzen, aber noch keinen vollständigen Wirkungsnachweis. Für diesen muss die Untersuchung den nächsten Schritt verfolgen: Wie wird eine Regel operationalisiert?

2. Multistakeholder-Regeln werden erst durch Implementierung wirksam

Eine Policy kann in einem Beratungs- und Entscheidungsprozess entstehen, doch ihre Folgen ergeben sich regelmäßig erst durch Annahme, Einbau in Vereinbarungen oder Ausführung durch einen technischen Dienst. Die Governance-Struktur ist deshalb nicht mit dem Vollzug identisch. Der politische Beschluss und die Stelle, die eine Registrierung, eine Datenanforderung, eine Sicherheitsmaßnahme oder eine technische Änderung tatsächlich veranlasst, können auseinanderfallen.

Das macht die Kette der Verantwortlichkeit länger. Ein Betroffener muss zunächst feststellen, ob die fragliche Norm aus einer ICANN-Richtlinie, einem Vertrag, einer Spezifikation, einer technischen Vereinbarung oder aus einer nationalen Rechtsordnung stammt. Danach muss er den Akteur bestimmen, der die konkrete Folge kontrolliert. Ein allgemeiner Verweis auf ICANN beantwortet keine dieser Fragen.

3. Vor 2016 lag ein Teil der IANA-Funktion in einem US-Aufsichtsrahmen

Der frühere IANA-Vertrag mit der US-Regierung ordnete die IANA-Funktionen vor 2016 in einen Rahmen staatlicher Beschaffung und Aufsicht ein. Dazu gehörten Verantwortlichkeiten im Zusammenhang mit der Verwaltung der Root Zone. [Quelle: https://www.icann.org/en/system/files/files/contract-01oct12-en.pdf] Das ist historische Evidenz. Sie beschreibt den früheren institutionellen Rahmen, beweist aber nicht, welche Befugnisse ICANN nach der Stewardship-Transition besitzt.

Der Übergang von 2016 sollte deshalb nicht als pauschale Übertragung von Souveränität an ICANN gelesen werden. Das Übergangsdokument beschreibt vielmehr eine verteilte Architektur: PTI, einen Vertrag über die IANA-Namensfunktion, die Überwachung durch das Customer Standing Committee, IANA Naming Function Reviews, mögliche Separation-Prozesse sowie gesonderte Beziehungen zu den Regional Internet Registries und der IETF. [Quelle: https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf]

Die operative Frage verschiebt sich damit von „Wer besitzt die IANA?“ zu „Welche Partei ist für welche Leistung zuständig, und welcher Mechanismus kann eine Fehlleistung korrigieren?“

4. Technische Stewardship ist auf mehrere Vereinbarungen verteilt

Der Vertrag zwischen ICANN und PTI beschreibt operative Leistungen, Pflichten, Berichte, Service Levels und Eskalationen für die Namensfunktion. Er stützt eine unternehmens- und vertragsrechtliche Beschreibung der operativen Autorität. PTI ist dabei eine von ICANN kontrollierte verbundene Organisation; die jeweils geltenden Änderungen müssen gesondert geprüft werden. [Quelle: https://www.icann.org/iana_pti_docs/151-iana-naming-function-contract-v-30sep2016]

Auch die Wartung der Root Zone ist nicht als ungeteilte Befehlsgewalt einer einzigen Stelle dokumentiert. Die Root Zone Maintainer Service Agreement verteilt Verantwortlichkeiten zwischen ICANN beziehungsweise PTI und Verisign und behandelt Service Levels, Änderungssteuerung, Sicherheit, Leistung und vertragliche Rechtsbehelfe. [Quelle: https://www.icann.org/en/system/files/files/root-zone-maintainer-service-agreement-30sep16-en.pdf] Das zeigt geteilte operative Verantwortung. Es beschreibt jedoch nicht jeden Beteiligten an der Veröffentlichung der Root Zone und begründet keine allgemeine öffentlich-rechtliche Zuständigkeit.

Bei Nummernressourcen liegt eine weitere Trennung vor. Das IANA Numbering Services SLA ordnet die Nummerierungsdienste in eine vertragliche Beziehung zwischen ICANN und den Regional Internet Registries ein; die politische Entwicklung erfolgt im RIR-System. [Quelle: https://www.icann.org/en/system/files/files/iana-numbering-services-sla-30jun16-en.pdf] Das SLA deckt deshalb nicht automatisch jede Vergabeentscheidung einzelner RIRs ab.

Für Protokollparameter wiederum weist das IETF-ICANN-Memorandum die Policy-Ebene den IETF-Prozessen zu, während die entsprechende Registerarbeit als technischer Dienst erbracht wird. Das Memorandum stammt aus der Zeit vor dem Übergang von 2016 und muss mit späteren Ergänzungen gelesen werden. [Quelle: https://www.icann.org/resources/pages/ietf-icann-mou-2012-02-25-en]

5. Verträge erzeugen den stärksten praktischen Hebel

Bei generischen Top-Level-Domains zeigt sich ICANNs Einfluss vor allem in der Vertragsarchitektur. Die Vertragsverzeichnisse enthalten TLD-spezifische Vereinbarungen, Änderungen, Spezifikationen und einbezogene Policies. Sie regeln unter anderem technischen Betrieb, Datentreuhand, Registrierungsdaten-Dienste, Abuse-Kontakte, Gebühren, Audits, Compliance, Vertragsverletzungen und Kündigung. [Quelle: https://www.icann.org/resources/pages/registries/registries-agreements-en] Die Base Agreement-Unterlagen und genehmigten Spezifikationen konkretisieren diesen Rahmen. [Quelle: https://www.icann.org/en/registry-agreements/base-agreement] [Quelle: https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en]

Auch bei Registraren verweist das veröffentlichte Material auf Konsensrichtlinien und vertragliche Pflichten. [Quelle: https://www.icann.org/resources/pages/registrars/consensus-policies-en] Ein Vertragspartner kann damit unter Bedingungen zu einer Änderung, Dokumentation oder Abhilfe verpflichtet werden. Bei Verstößen können Compliance-Maßnahmen, Vertragsverletzungsverfahren oder letztlich die Beendigung einer Vereinbarung praktisch einschneidend sein.

Das ist der Punkt, an dem „regulatorischer Effekt“ und „öffentliche Regulierung“ auseinandergehalten werden müssen. Ein Vertrag kann Marktteilnehmer disziplinieren, Zugang zu einer kritischen Infrastruktur strukturieren und für Dritte spürbare Folgen haben. Daraus folgt aber nicht ohne weiteres eine staatliche Hoheitsbefugnis. Ebenso wenig folgt aus der privaten Form, dass der Hebel gering wäre.

6. Ein Rechtsbehelf ist nicht automatisch eine wirksame Abhilfe

ICANN veröffentlicht mehrere Rechenschafts- und Abhilfekanäle: Compliance, Reconsideration, den Independent Review Process, den Ombudsman, die Empowered Community, das Customer Standing Committee und IANA-Reviews. [Quelle: https://www.icann.org/compliance] [Quelle: https://www.icann.org/resources/pages/accountability/reconsideration-en] [Quelle: https://www.icann.org/resources/pages/irp-2012-02-25-en] [Quelle: https://www.icann.org/en/system/files/files/irp-supp-procedures-25oct18-en.pdf] [Quelle: https://www.icann.org/ombudsman] [Quelle: https://www.icann.org/resources/pages/empowered-community-2017-03-23-en] [Quelle: https://www.icann.org/csc]

Diese Wege dürfen nicht zu einem einzigen „Beschwerdesystem“ zusammengezogen werden. Aus dem vorliegenden Quellenbestand ist nicht belegt, dass sie dieselben Zulässigkeitsregeln, Prüfungsmaßstäbe, einstweiligen Befugnisse, endgültigen Rechtsfolgen, Bindungswirkungen, Durchsetzungsmechanismen, Bearbeitungszeiten oder Kosten besitzen. Ein Verfahren kann Gründe und Antwortbarkeit verbessern, ohne die konkrete technische Änderung stoppen zu können. Ein anderes kann eine institutionelle Entscheidung prüfen, aber einer nichtvertraglichen betroffenen Partei keine direkte Klagebefugnis geben.

Damit entstehen vier getrennte Stufen der Rechenschaft: Erstens die Antwortbarkeit durch Offenlegung und Begründung. Zweitens die Überprüfbarkeit durch ein Anfechtungsverfahren. Drittens die Abhilfefähigkeit, also die Möglichkeit, einen Schaden zu verhindern oder zu korrigieren. Viertens die Durchsetzbarkeit des Ergebnisses. Nur die letzte Stufe zeigt, ob ein erfolgreicher Einwand den tatsächlichen Kontrollpunkt erreicht.

7. Wer kann eine technische oder vertragliche Folge stoppen?

Die zentrale Untersuchung muss daher konkrete Fälle rekonstruieren: Welche Policy wurde vorgeschlagen? Wer nahm sie an? In welchem Vertrag, welcher Spezifikation oder welchem technischen Prozess wurde sie wirksam? Welche Stelle konnte die Umsetzung auslösen oder blockieren? Welche Frist galt? Konnte eine betroffene Partei eine einstweilige Aussetzung verlangen? War sie Vertragspartner? War die spätere Entscheidung bindend und vollstreckbar?

Diese Fragen sind besonders wichtig für Personen oder Organisationen, die nicht selbst Vertragspartner von ICANN sind. Ihre Betroffenheit kann real sein, obwohl ihr direkter Zugang zu einem Vertragsrechtsbehelf fehlt. Dann hängt die Abhilfe möglicherweise von einem Vertragspartner, einem öffentlichen Gericht, einer Community-Struktur oder einem technischen Betreiber ab. Die institutionelle Nähe zur Entscheidung und die rechtliche Möglichkeit, sie anzufechten, sind nicht dasselbe.

Der vorliegende Quellenbestand erlaubt eine belastbare Kartierung der Instrumente, aber noch keine abschließende Aussage über jede aktuelle Fassung, jedes Amendment oder jeden konkreten Vollzugsfall. Insbesondere fehlen unabhängige gesetzliche Delegationen, gerichtliche Entscheidungen, regulatorische Feststellungen und eine überprüfte Durchsetzungsepisode, die eine öffentliche oder private Einordnung endgültig entscheiden könnte.

Quellen und Abgrenzungen

Die Untersuchung stützt sich auf die folgenden Primärmaterialien: die Articles of Incorporation (https://www.icann.org/resources/pages/governance/articles-en), die Bylaws (https://www.icann.org/resources/pages/governance/bylaws-en), den früheren NTIA-IANA-Vertrag (https://www.icann.org/en/system/files/files/contract-01oct12-en.pdf), den Stewardship-Transition-Vorschlag (https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf), den ICANN-PTI-Vertrag (https://www.icann.org/iana_pti_docs/151-iana-naming-function-contract-v-30sep2016), die Root Zone Maintainer Service Agreement (https://www.icann.org/en/system/files/files/root-zone-maintainer-service-agreement-30sep16-en.pdf), das IANA Numbering Services SLA (https://www.icann.org/en/system/files/files/iana-numbering-services-sla-30jun16-en.pdf), das IETF-ICANN-Memorandum (https://www.icann.org/resources/pages/ietf-icann-mou-2012-02-25-en), die Registry-Verträge (https://www.icann.org/resources/pages/registries/registries-agreements-en), das Base Agreement (https://www.icann.org/en/registry-agreements/base-agreement), genehmigte Spezifikationen (https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en), Registrar-Konsensrichtlinien (https://www.icann.org/resources/pages/registrars/consensus-policies-en), Compliance-Materialien (https://www.icann.org/compliance), Reconsideration (https://www.icann.org/resources/pages/accountability/reconsideration-en), den Independent Review Process (https://www.icann.org/resources/pages/irp-2012-02-25-en), ergänzende IRP-Verfahrensregeln (https://www.icann.org/en/system/files/files/irp-supp-procedures-25oct18-en.pdf), den Ombudsman (https://www.icann.org/ombudsman), die Empowered Community (https://www.icann.org/resources/pages/empowered-community-2017-03-23-en) und das Customer Standing Committee (https://www.icann.org/csc). Der Gegenstand ist außerdem im BTW-Verzeichnis dokumentiert: https://btw.media/de/directory/internet-corporation-for-assigned-names-and-numbers.