Zusammenfassung

  • Der GAC verlangte einen Zeitplan und beschrieb das gewünschte Ergebnis als Erhebung und öffentliche Verfügbarkeit der Registrierungsdaten juristischer Personen.
  • ICANN nennt FY2027 als bedingte Startperspektive, betont aber: Die geltende Policy erlaubt die Unterscheidung, schreibt sie nicht vor; Best Practices werden keine vertraglichen Pflichten.

„Umsetzung“ klingt nach einem gemeinsamen Arbeitsgegenstand. Die am 25. August veröffentlichte Korrespondenz zeigt jedoch, dass GAC und Board damit nicht dasselbe Ergebnis bezeichnen.

Am 11. Mai 2026 schrieb GAC-Vorsitzender Nicolas Caballero an Board-Vorsitzende Tripti Sinha. Nach Einschätzung der GAC-Leitung war die Arbeit zur Erhebung und Veröffentlichung der Registrierungsdaten juristischer Personen seit der Board-Annahme der EPDP-Phase-2A-Empfehlungen im März 2022 nicht vorangekommen. Der GAC wiederholte seine Position, Contracted Parties sollten Daten juristischer Personen erheben und öffentlich verfügbar machen. Er bat um einen Zeitplan und bot seine Mitarbeit in einem Implementation Review Team an.

Die Antwort vom 24. August enthält eine konditionierte Aussicht. Nach Abschluss bestehender Projekte, die dieselben dedizierten Umsetzungsressourcen binden, erwartet ICANN org, in FY2027 beginnen zu können. Ein Beginn ist kein Abschlussdatum und die Formulierung keine unbedingte Zusage.

Wichtiger ist die Sachgrenze. Das Phase-2A-Team habe die bestehenden Consensus-Policy-Anforderungen zur Unterscheidung zwischen Daten juristischer und natürlicher Personen nicht geändert. Die Registration Data Policy erlaube Registries und Registraren, bei der Anwendung der RDDS-Redaktionsregeln die juristische Person oder das Vorliegen personenbezogener Daten zu berücksichtigen; sie verlange dies nicht. Die vorgesehenen Best Practices würden keine vertraglichen Pflichten für Contracted Parties schaffen.

Damit geht es nicht nur um den Platz eines Projekts in einer Warteschlange. Das vom GAC gewünschte Publikationsergebnis reicht weiter als das Paket, dessen Umsetzung das Board 2022 angeordnet hat.

Vier Empfehlungen, unterschiedliche Verbindlichkeit

Empfehlung 1 verlangt die Schaffung eines oder mehrerer Felder, die zwischen Registrierungsdaten juristischer und natürlicher Personen und/oder zwischen personenbezogenen und nicht personenbezogenen Daten unterscheiden helfen. Contracted Parties, die differenzieren, dürfen diese Felder nutzen.

Empfehlung 2 richtet die Guidance an diejenigen, die sich für eine Unterscheidung nach Personentyp entscheiden. Empfehlung 3 betrifft eine mögliche künftige Berücksichtigung der Guidance in einem innerhalb ICANN entwickelten GDPR Code of Conduct. Empfehlung 4 fordert diejenigen, die eine registranten- oder registrierungsbezogene E-Mail-Adresse im öffentlichen RDDS veröffentlichen wollen, zur Prüfung der vom EPDP-Team eingeholten Rechtsberatung auf.

Für ICANN org besteht ein echter Auftrag. Das Board wies den President and CEO beziehungsweise Beauftragte an, einen Umsetzungsplan zu entwickeln und auszuführen, der mit der Guidance des GNSO Council übereinstimmt. Dass die spätere Nutzung eines Feldes optional ist, entbindet ICANN nicht von der technischen Umsetzung der angenommenen Empfehlung.

Für Registries und Registrare besteht ebenso klar eine Grenze. Die Board-Begründung von 2022 sagt, die Empfehlungen schüfen keine neuen Pflichten für Contracted Parties. Guidance und Best Practices außerhalb von Registry Agreement, Registrar Accreditation Agreement und Consensus Policies seien keine Vertragsanforderungen. ICANN Contractual Compliance könne ihre Befolgung daher nicht vertraglich durchsetzen.

Das August-Schreiben ordnet die Empfehlungen 1, 2 und 4 dem Best-Practices-Dokument zu; 1 und 3 verlangen außerdem Arbeit von ICANN org. Dass Empfehlung 1 in beiden Gruppen liegt, erklärt sich aus ihren beratenden und technischen Bestandteilen. Der Projektplan macht aus Guidance keine Vertragspflicht.

Die geltende Policy kennt keinen automatischen Publikationsschalter

Die Registration Data Policy trennt Erhebung, Übermittlung, Escrow, Veröffentlichung, Redaktion, Einwilligung und rechtmäßige Offenlegung. Der Status des Registranten kann relevant sein, ersetzt aber keine dieser Entscheidungen.

Nach Abschnitt 9.2.1 müssen Registry Operator und Registrar die Redaktionsregeln anwenden, wenn personenbezogene Daten zur Einhaltung des anwendbaren Rechts zu redigieren sind. Unter weiteren definierten Umständen dürfen sie die Regeln ebenfalls anwenden. Bei der Entscheidung dürfen sie berücksichtigen, ob Registrierungsdaten eine juristische Person betreffen oder personenbezogene Daten enthalten. Sie sind dazu nicht verpflichtet.

Eine juristische Person kann in ihrem Datensatz personenbezogene Angaben führen. Bei einem Unternehmensdomainnamen können Namen und Kontaktdaten von Beschäftigten, Geschäftsführern, externen Beratern oder technischen Ansprechpartnern stehen. Die Organisationsform des Registranten macht diese Werte nicht automatisch zu nicht personenbezogenen Daten.

Das Feld Registrant Organization zeigt den bestehenden Entscheidungsweg. Der Registrar muss dem Registered Name Holder die Angabe ermöglichen und den Wert erheben, wenn er angegeben wird. Er muss zugleich informieren, dass der Wert bei Zustimmung veröffentlicht wird und die Organisation als Registered Name Holder gilt. Bei Zustimmung ist zu veröffentlichen; ohne Zustimmung darf der Wert nach der Policy redigiert werden.

Die notwendige Kette enthält folglich das konkrete Datenfeld, seine Herkunft, einen möglichen Personenbezug, die anwendbare Regel, gegebenenfalls die Einwilligung und den verantwortlichen Entscheider. „Juristische Person“ ist ein Merkmal in dieser Kette, kein Endurteil über Öffentlichkeit.

Ein Datenfeld standardisiert Bedeutung, nicht Zuständigkeit

ICANN erwartet eine Koordinierung mit der technischen Community über Differenzierungsfelder im Extensible Provisioning Protocol und als Ergebnis ein aktualisiertes gTLD RDAP Profile.

Das ist kein belangloses Detail. Gemeinsame Werte können freien Text, undokumentierte Wahrheitswerte und nicht korrigierbare Ableitungen ersetzen. Sie können unbekannt, nicht differenziert, Quelle, Aktualisierung und Korrektur so definieren, dass nachgelagerte Systeme dieselbe Bedeutung erhalten.

Die Syntax entscheidet aber nicht, wer das Feld befüllen muss. Ein Wert beweist nicht, wie belastbar die Klassifizierung war. Sein Transport über EPP erzwingt keine öffentliche Ausgabe in RDAP. Seine Aufnahme in ein Profil verdrängt weder Registration Data Policy noch anwendbares Recht oder die Verantwortung des Datenverarbeiters.

Technische Standardisierung kann eine autorisierte Unterscheidung portabel machen. Sie kann die fehlende Autorisierung für eine allgemeine Veröffentlichung nicht nachliefern.

Eine Konkordanz für den öffentlichen Arbeitsplan

Der Umsetzungsplan sollte fünf Ebenen in einer nachvollziehbaren Tabelle verbinden.

Erstens: GAC-Schreiben und Kommuniqués als Beratung und formulierte Public-Policy-Präferenz. Zweitens: die angenommenen Empfehlungen und Board-Beschlüsse als Auftrag an ICANN org. Drittens: Registration Data Policy und Verträge als Regeln für Erhebung, Redaktion, Einwilligung, Veröffentlichung und Offenlegung. Viertens: EPP- und RDAP-Arbeit als technische Repräsentation. Fünftens: die Einzelfallentscheidung der Contracted Party unter Policy und Recht.

Für jede Zeile gehören Version, verantwortlicher Akteur, Verbindlichkeit, Umsetzungsstand und Änderungsweg in die Übersicht. Wer eine Pflicht zur Differenzierung verlangt, muss erkennen können, welches Policy-Verfahren sie schaffen könnte. Wer ein fertiges RDAP Profile sieht, muss erkennen können, dass es weder flächendeckende Nutzung noch die Erfüllung des weitergehenden GAC-Ziels beweist.

Diese Konkordanz entscheidet nicht, wie der Konflikt zwischen Transparenz und Datenschutz endet. Sie verhindert, dass ein Statusbericht eine noch nicht angenommene Regel simuliert.

Was der Beginn in FY2027 belegt

Das Schreiben verweist auf Ressourcen, operative Planung und Budgetzyklen und lädt den GAC zur Teilnahme an der FY2028-Planung ein. Es veröffentlicht noch kein endgültiges Feldmodell, keine Best Practices, keinen Abschlusstermin und keine Nutzungszahlen.

Fortschritt lässt sich dennoch prüfen: zuständige Leitung, geklärte Abhängigkeiten, Zuordnung jeder Aufgabe zur Empfehlung, veröffentlichte technische Vorschläge und begründete Terminänderungen. Diese Projekttransparenz darf jedoch keine neue normative Wirkung erzeugen.

Der GAC kann eine weitergehende Politik vertreten. Der GNSO kann ein zuständiges Policy-Verfahren führen. Das Board kann Empfehlungen annehmen. ICANN org kann sie umsetzen. Technische Gremien können eine interoperable Darstellung definieren. Contracted Parties bleiben für konkrete Datenentscheidungen unter Vertrag und Recht verantwortlich.

Beratung ist keine Vertragsänderung. Ein Board-Auftrag an ICANN org ist kein neuer Befehl an jeden Registrar. Ein Feld ist keine Offenlegungserlaubnis. Ein Zeitplan ist keine Policy.

Das Board-Schreiben hat diese Grenzen sichtbar gemacht. Die nächste Bewährungsprobe besteht darin, ob sie lesbar bleiben, wenn Guidance, Datenmodelle und betriebliche Erwartungen ineinandergreifen.

Quellen

  1. Korrespondenzindex von ICANN
  2. Tripti Sinha an Nicolas Caballero, 24. August 2026
  3. Nicolas Caballero an Tripti Sinha, 11. Mai 2026
  4. Board-Entscheidung zu EPDP Phase 2A vom 10. März 2022
  5. Abschlussbericht EPDP Phase 2A
  6. Phase-2A-Empfehlungen zur Board-Prüfung
  7. Registration Data Policy von ICANN
  8. RDAP-Ressourcen von ICANN