Zusammenfassung

  • Die Mitteilung von APNIC vom 1. September macht den empfohlenen Entwurf v3.4 des NRO NC, eine Redline und die Begründung öffentlich zugänglich.
  • Artikel 7.2 würde Änderungen am Dokument ausschließen, solange ein RIR einer Temporary Emergency Continuity Arrangement unterliegt oder ein Derecognition-Vorschlag anhängig ist.
  • Laut Begründung soll dies überhastete, fallbezogene Änderungen und eine Aufweichung von Anforderungen in schwierigen Momenten verhindern; es handelt sich um einen Entwurf, nicht um den Nachweis eines laufenden Notfalls oder geltenden Rechts.

Eine der aufschlussreichsten Regelungen in Version 3.4 ist zugleich sehr kurz. Artikel 7.1 sieht vor, dass eine Änderung die einstimmige Zustimmung von ICANN und den RIR nach Konsultation ihrer Gemeinschaften erfordern würde. Artikel 7.2 ergänzt eine Sperre: Das Dokument dürfte nicht geändert werden, wenn ein RIR einer Temporary Emergency Continuity Arrangement unterliegt oder ein Vorschlag zur Derecognition anhängig ist.

Die APNIC-Mitteilung ordnet den Text korrekt ein. Es ist ein vom Number Council der NRO empfohlener Entwurf mit Redline und Erläuterung. Weder endgültige Annahme noch Umsetzung oder ein konkretes Verfahren werden angekündigt. Die Quellen besagen auch nicht, dass ein RIR derzeit in einer Notfallkontinuität ist, sich einem Derecognition-Verfahren gegenübersieht oder eine Änderung anstrebt.

Der Zweck der Bedingung wird dennoch ausdrücklich erklärt. Die Begründung nennt die Verhinderung hastiger Änderungen für bestimmte Umstände und das Verhindern einer Verwässerung von Anforderungen in schwierigen Momenten. Das ist eine eng gefasste institutionelle Vorsorge. Die Parteien sollten die Regeln für Notfallkontinuität oder Derecognition nicht genau dann umschreiben, wenn sie sich auf diese Regeln stützen.

Artikel 5 beschreibt die Grenze. Eine Temporary Emergency Continuity Arrangement ist ein zeitlich begrenzter Mechanismus zur Bereitstellung betroffener RIR-Dienste. Das betroffene RIR könnte ihn für alle oder einen Teil seiner eigenen Dienste einleiten. ICANN und zwei Drittel der anderen RIR könnten ihn nach Gesprächen mit dem betroffenen RIR und seiner Gemeinschaft, soweit dies angemessen möglich ist, ebenfalls einleiten oder verlängern. Er darf ohne Verlängerung nach derselben Vorschrift nicht länger als 90 Tage dauern; ICANN müsste Grund und Umfang einer Einleitung oder Verlängerung unverzüglich veröffentlichen.

Das sind mögliche Verfahren, kein Bericht über ein eingetretenes Ereignis.

Die öffentliche Bedeutung der Sperre hängt davon ab, ob Außenstehende erkennen können, wann sie gilt. Der Entwurf verlangt mehrere Veröffentlichungen, schafft aber kein einzelnes lesbares Register, das eine konkrete Vereinbarung oder einen Vorschlag mit dem Status von Artikel 7.2 verbindet. Ein knapper Statusbeleg wäre ausreichend: betroffenes RIR, Art des Vorgangs, Entscheidung und Wirksamkeitszeit, Umfang, Link zur Ausgangsmitteilung, Verlängerung oder Ende, veröffentlichende Stelle und Korrekturverlauf. Rechtsberatung, sensible technische Einzelheiten oder Verhandlungspositionen müssten nicht offengelegt werden.

Das würde den Entwurf weder verbindlich machen noch eine Krise lösen. Es würde nur eine künftige Schutzvorkehrung von einer aktuell wirksamen Sperre unterscheiden. Gerade dort, wo Verfahrenssprache leicht als gegenwärtiger Betriebszustand gelesen wird, ist diese Trennung entscheidend.

Quellen