Zusammenfassung

  • Ein Mitglied oder Beobachter des GAC kann üblicherweise in den 104 Tagen nach dem String Confirmation Day ohne GAC-Konsens eine Frühwarnung abgeben.
  • Die Warnung hat keine unmittelbare Auswirkung auf den Antrag. Der Antragsteller muss jedoch entscheiden, ob er den Dialog sucht, eine Änderung beantragt, unverändert fortfährt oder zurückzieht.

Eine Frühwarnung eines GAC-Mitglieds hat in der Runde 2026 eine eigenständige und wichtige Stellung. Sie ist konkreter als eine allgemeine politische Besorgnis, aber weder ein Veto noch eine Zurückweisung noch GAC Consensus Advice. Sie ermöglicht einem Mitglied oder Beobachter des Governmental Advisory Committee von ICANN, einen Antrag formal als potenziell sensibel oder problematisch zu kennzeichnen.

Das Anliegen kann nationales Recht oder eine weitergehende Sensibilität betreffen und muss in der Warnung benannt werden. Die Einreichung soll eine schriftliche Erklärung ihres Grundes, einen Hinweis darauf, wie der Antragsteller das Anliegen behandeln könnte, und Kontaktdaten für die Kommunikation enthalten. Für die Abgabe durch ein Mitglied oder einen Beobachter ist kein GAC-Konsens erforderlich.

Ein 104-Tage-Signal, keine unmittelbare Entscheidung

Frühwarnungen sollen während der 104 Tage nach dem String Confirmation Day eingereicht werden. ICANN erklärt, betroffene Antragsteller nach Eingang so bald wie praktikabel zu benachrichtigen.

Die Grenze im Applicant Guidebook ist ausdrücklich: Eine Frühwarnung ist nur eine Mitteilung und hat keine unmittelbare Wirkung auf den Antrag. Prüfer können sie dennoch berücksichtigen. Sie kann außerdem darauf hindeuten, dass der Antrag später GAC Consensus Advice oder einen Einspruch nach sich ziehen könnte; keiner dieser späteren Wege setzt jedoch zuvor eine Frühwarnung voraus.

Diese Unterscheidung verhindert zwei entgegengesetzte Fehler. Wer die Warnung als harmlose Korrespondenz behandelt, unterschätzt ein formelles Risikosignal. Wer sie als abschließende öffentliche Entscheidung behandelt, schreibt ihr eine Autorität zu, die sie nicht besitzt.

Vier Reaktionswege bleiben offen

ICANN ermutigt einen Antragsteller, der fortfahren möchte, so bald wie möglich in einen Dialog mit der besorgten Partei einzutreten. Er kann auch einen Application Change Request beantragen, um das Anliegen aufzugreifen. Er kann sich entscheiden, nichts zu unternehmen und den Antrag unverändert weiterzuverfolgen, oder ihn zurückziehen; bei einer Rücknahme gilt der einschlägige Erstattungsplan.

Dies sind Entscheidungen, keine garantierten Ergebnisse. Unterlassener Dialog kann zu GAC Consensus Advice führen oder nicht. Dialog garantiert ebenso wenig, dass spätere Advice oder ein Einspruch vermieden werden. Das Protokoll muss deshalb die eingegangene Besorgnis, die gewählte Reaktion, die diese Wahl stützenden Belege und jedes später tatsächlich eingetretene Verfahren voneinander trennen.

Nicht jedes Regierungsanliegen ist eine Frühwarnung

GAC-Mitglieder können auch öffentlich verfügbare Kanäle nutzen, darunter das Application Comment Forum oder die direkte Kommunikation mit einem Antragsteller. Ein über diese Wege übermitteltes Anliegen ist dadurch nicht selbst eine Frühwarnung eines GAC-Mitglieds. Die Bezeichnung hängt vom definierten Verfahren ab, nicht allein von der Identität des Sprechers oder der Schwere des Themas.

Das ist für Rechenschaft wichtig. Ein Team sollte öffentliche Kommentare, informellen Dialog, Frühwarnung, Einspruch und GAC Consensus Advice nicht zu einem einzigen Status „Regierungsopposition“ zusammenfassen. Sie haben jeweils eine andere Quelle, eine andere verfahrensrechtliche Wirkung und einen anderen nächsten Schritt.

Ein Reaktionsprotokoll erstellen, ohne Gewissheit zu erfinden

Eine nützliche Steuerungsfläche ist eine Reaktionsmatrix mit fünf Feldern: das erklärte Anliegen, seine angeführte tatsächliche oder rechtliche Grundlage, die vom Aussteller beschriebene Abhilfe, der vom Antragsteller gewählte Weg und die Nachweise eines Dialogs oder Änderungsantrags. Sie sollte Daten und Verantwortliche festhalten, ohne zu behaupten, ein Gespräch allein habe die Frage gelöst.

Diese Matrix ist redaktioneller Rat von BTW und keine Einreichungsvorgabe von ICANN. ICANN legt das Warnverfahren fest und beschreibt Reaktionsmöglichkeiten; dieses interne Dokument verlangt sie nicht. Auch beweist eine Frühwarnung für sich genommen nicht, dass ein Antrag abgelehnt wird, weitergeht oder zur Delegation gelangt.

Quellen