Zusammenfassung

  • ICANNs Autorität ist auf mehrere Instrumente verteilt: Gesellschaftszweck, Bylaws, Verfahren der Konsenspolitik, Verträge mit Registraren und Registries sowie die operative Umsetzung der IANA-Funktionen.
  • Konsenspolitik wird für Vertragspartner dort praktisch verbindlich, wo der einschlägige Registrar- oder Registry-Vertrag sie einbezieht. Die operative Kontrolle ist damit wesentlich vertraglich und nicht einfach hoheitlich.
  • Reconsideration, Independent Review, Ombudsman und Community-Befugnisse sind unterschiedliche Rechenschaftswege. Keiner bildet automatisch eine uneingeschränkte Berufung oder beweist, dass ein angegriffenes Ergebnis sofort ausgesetzt oder rückgängig gemacht wird.

Die erste Frage lautet: Welche Befugnis wird ausgeübt?

ICANN wird häufig als eine Instanz beschrieben, die das Internet-Adresssystem „regiert“. Diese Kurzform verdeckt jedoch, wie die Autorität rechtlich und organisatorisch entsteht. Die Articles of Incorporation beschreiben ICANN als eine kalifornische gemeinnützige Public-Benefit-Körperschaft. Zu ihren Zwecken gehört die Koordination des globalen Systems eindeutiger Internet-Kennungen im Einklang mit den maßgeblichen Dokumenten und Richtlinien. Das ist eine institutionelle Grundlage, aber noch keine vollständige Beschreibung jeder konkreten operativen Maßnahme. https://www.icann.org/resources/pages/articles-2012-02-25-en

Die Bylaws konkretisieren diese Grundlage. Sie legen Mission und Befugnisse, die Rolle des Board, Strukturen der Politikentwicklung, Beteiligungsmöglichkeiten der Community und Rechenschaftsmechanismen fest. Damit liefern sie den zentralen institutionellen Rahmen dafür, wie eine Organisation Entscheidungen vorbereitet, erlässt und überprüfbar macht. Die Bylaws sind jedoch kein universelles Berufungsgesetz: Ob und wie eine konkrete Entscheidung angegriffen werden kann, hängt vom jeweiligen Instrument und dessen Voraussetzungen ab. https://www.icann.org/resources/pages/governance/bylaws-en

Von der multilateralen Politik zum Vertrag

ICANNs besondere operative Reichweite entsteht dort, wo eine entwickelte Politik in die Vertragsbeziehungen mit denjenigen Organisationen gelangt, die Registrierungs- oder Registry-Dienste erbringen. Die Materialien zur Konsenspolitik verbinden den Multistakeholder-Prozess mit der vertraglichen Durchsetzbarkeit gegenüber Contracted Parties, wenn der anwendbare Registrar- oder Registry-Vertrag die betreffende Politik einbezieht. https://www.icann.org/resources/pages/consensus-policy-2012-02-25-en

Das ist ein wichtiger Unterschied zwischen politischer Legitimation und operativer Durchsetzung. Ein Verfahren der Politikentwicklung kann die Grundlage einer Regel bilden. Die praktische Verpflichtung eines Vertragspartners ergibt sich dann aus dem Vertrag und den darin aufgenommenen Policies.

Die Autoritätskette lautet also nicht schlicht „ICANN entscheidet, und das Internet muss gehorchen“, sondern eher: Ein institutioneller Rahmen erlaubt die Politikentwicklung; die einschlägige Vereinbarung integriert bestimmte Regeln; Compliance-, Audit-, Berichts- und Streitbeilegungsmechanismen machen diese Regeln gegenüber dem Vertragspartner wirksam.

Der Registrar Accreditation Agreement veranschaulicht diese Struktur. Er regelt die Beziehung zu akkreditierten Registraren und enthält, zusammen mit einbezogenen Policies und Vertragsbedingungen, Vorgaben zu Compliance, Meldungen, Audits, Suspendierung, Beendigung und Streitigkeiten. Welche Maßnahme zulässig ist, hängt dabei von der konkreten Vereinbarung, ihren Anlagen und den jeweils geltenden Änderungen ab. https://www.icann.org/resources/pages/registrars/raa/approved-with-specs-2013-09-17-en

Auch der New gTLD Registry Agreement ist kein bloßes politisches Statement. Er regelt die Vertragsbeziehung zu Registry-Betreibern und behandelt unter anderem den Betrieb der Registry, Konsenspolitik, technische Pflichten, Compliance, Gebühren, Data Escrow, Streitbeilegung, Beendigung und die Übergabe nach Vertragsende. Die operative Kontinuität eines Registry-Dienstes wird dadurch in eine konkrete Vertragsarchitektur eingebettet. https://newgtlds.icann.org/en/applicants/agb/base-agreement

IANA ist nicht die gesamte ICANN-Funktion

Eine zweite notwendige Unterscheidung betrifft IANA. Die Übergangsmaterialien trennen die operative Leistung der IANA-Funktionen von ICANNs weitergehenden Rollen bei Politikentwicklung und Vertragsbeziehungen. Sie beschreiben außerdem den Übergang von der Aufsicht durch einen Vertrag mit der Regierung der Vereinigten Staaten zu Arrangements, an denen ICANN und die globale Internet-Community beteiligt sind. https://www.icann.org/resources/pages/iana-2016-08-15-en https://www.icann.org/resources/pages/iana-functions-transfer-2016-08-15-en

Diese Trennung verhindert eine falsche Gleichsetzung: Die operative Durchführung einer IANA-Funktion ist nicht identisch mit jeder politischen oder vertraglichen Entscheidung von ICANN. Für eine konkrete Streitfrage muss daher festgestellt werden, ob sie die technische Ausführung einer Funktion, eine Policy, eine Vertragsentscheidung oder ein Rechenschaftsverfahren betrifft. Jede dieser Ebenen kann andere Akteure, Dokumente und Rechtsfolgen haben.

Vier Wege der Rechenschaft – keine allgemeine Berufung

Wenn eine betroffene Partei eine Entscheidung beanstanden will, ist die entscheidende Frage nicht nur, ob sie einen Nachteil behauptet. Entscheidend ist, welches Verfahren auf die angegriffene Handlung passt, wer es einleiten darf, welche Frist gilt, welches Gremium entscheidet und welche Abhilfe überhaupt vorgesehen ist.

ICANN beschreibt Reconsideration, Independent Review, den Ombudsman und Community-Befugnisse als eigenständige Rechenschaftswege. Sie unterscheiden sich bei Zulässigkeit, Fristen, Prüfungsmaßstab, Entscheidungsträgern und möglichen Ergebnissen. Die Bylaws und die einschlägigen Verfahrensunterlagen verteilen die Kontrollfunktion somit auf mehrere Instrumente, statt eine einzige uneingeschränkte Berufungsinstanz zu schaffen. https://www.icann.org/resources/pages/accountability/reconsideration-en https://www.icann.org/resources/pages/independent-review-process-2017-03-24-en https://www.icann.org/resources/pages/governance/accountability-mechanisms-en

Reconsideration ist deshalb nicht automatisch ein erneutes Verfahren über die gesamte Sache. Independent Review ist ebenfalls kein allgemeiner Weg, jede operative Entscheidung vollständig neu zu entscheiden. Community-Befugnisse setzen wiederum die in den Bylaws festgelegten institutionellen Rollen und Verfahren voraus. Der Ombudsman erfüllt eine andere Funktion als ein entscheidendes Gericht oder ein Vertrags-Schiedsorgan. Die Bezeichnung „Rechtsbehelf“ allein sagt daher wenig über den tatsächlichen Zugriff auf eine Entscheidung aus.

Was ein Erfolg nicht automatisch bewirkt

Ein formaler Rechenschaftsweg beweist nicht von selbst, dass die angegriffene Handlung während des Verfahrens ruht, nach dessen Abschluss aufgehoben wird oder operativ wiederhergestellt werden muss. Die praktische Wirkung hängt vom jeweiligen Instrument, der einschlägigen Bylaws-Regel oder Vertragsbestimmung, dem Zeitpunkt der Anrufung und dem Ergebnis des Verfahrens ab. https://www.icann.org/resources/pages/accountability/reconsideration-en https://www.icann.org/resources/pages/independent-review-process-2017-03-24-en https://www.icann.org/resources/pages/governance/accountability-mechanisms-en https://www.icann.org/resources/pages/governance/bylaws-en

Das erzeugt eine zeitliche Asymmetrie. Eine Partei kann einen zulässigen Antrag stellen, ohne dass der operative Zustand bis zur Entscheidung eingefroren wird. Umgekehrt kann eine erfolgreiche Prüfung eine institutionelle Korrektur auslösen, ohne dass damit jede bereits eingetretene technische, vertragliche oder wirtschaftliche Folge verschwindet. Aus den allgemeinen Architekturunterlagen lässt sich jedoch nicht das Ergebnis oder der Zeitplan eines konkreten Falls ableiten.

Ein Prüfmodell für konkrete Entscheidungen

Für eine belastbare Analyse sollte eine angegriffene ICANN-Maßnahme in fünf Schritten untersucht werden.

Erstens muss die Quelle der behaupteten Befugnis identifiziert werden: Articles of Incorporation, Bylaws, eine Policy, ein Registrar-Vertrag, ein Registry-Vertrag oder ein operatives IANA-Arrangement. Zweitens muss geklärt werden, ob die Regel unmittelbar institutionell gilt oder erst durch einen Vertrag gegenüber einem bestimmten Vertragspartner wirksam wird. Drittens ist die operative Handlung zu bestimmen: Policy-Entscheidung, Compliance-Maßnahme, Vertragsdurchsetzung, technische Funktion oder Community-Aufsicht.

Viertens muss der passende Kontrollweg ausgewählt werden. Dabei sind Initiator, Frist, Zuständigkeit, Prüfungsmaßstab und mögliche Abhilfe getrennt zu prüfen. Fünftens muss die zeitliche Wirkung analysiert werden: Gibt es eine ausdrückliche Suspendierung, eine Entscheidung mit Rückwirkung oder nur eine Prüfung und Empfehlung? Ohne diese letzte Frage bleibt eine Aussage über „Erfolg“ unvollständig.

Die institutionelle Konsequenz

ICANNs Legitimität hängt deshalb nicht nur davon ab, ob es Regeln veröffentlicht. Entscheidend ist, ob nachvollziehbar bleibt, wie eine Regel entstanden ist, welchem Vertragspartner sie auferlegt wird, welche operative Folge sie erzeugt und welcher Akteur sie unter welchen Bedingungen überprüfen kann. Die Architektur verbindet globale Beteiligung, institutionelle Dokumente und private Vertragsdurchsetzung. Gerade diese Verbindung macht ICANN handlungsfähig – sie begrenzt aber zugleich die Reichweite jeder einzelnen Anfechtung.

Die vorliegenden offiziellen Materialien belegen die Architektur der Autorität und der Rechenschaftswege. Sie belegen nicht, dass jede Beschwerde eine Maßnahme automatisch stoppt, dass ein bestimmter Vertrag unverändert gilt oder dass eine konkrete Partei mit einem bestimmten Verfahren Erfolg haben wird. Solche Aussagen erfordern den Fall, die maßgeblichen Fassungen und den tatsächlichen Verfahrensstand.

Mehr zum Directory-Eintrag von ICANN