Zusammenfassung

  • Antragsteller müssen angeben, welche RSPs kritische Registry-Dienste erbringen würden, wenn der Antrag bis zur Delegierung gelangt.
  • Während des Vertragsprozesses bittet ICANN den benannten RSP gesondert um Bestätigung, dass er die Unterstützung dieses Antragstellers und der betreffenden gTLD oder gTLDs plant.
  • Nach der Einreichung können ausgewählte RSPs über das Verfahren für Application Change Requests angegeben oder geändert werden.

Dieser Artikel erläutert die beiden vom Applicant Guidebook gestützten Vorgänge anhand zweier Aufzeichnungen. Die erste nennt den vom Antragsteller vorgesehenen Anbieter. Für den zweiten Vorgang bittet ICANN den RSP während der Vertragsphase um Bestätigung seiner Pläne zur Unterstützung des Antragstellers und der betreffenden gTLDs. Das Zwei-Aufzeichnungen-Modell ist eine BTW-Analyse, keine ICANN-Vorgabe.

Der vom Antragsteller eingetragene Name dokumentiert dessen Absicht, nicht aber die spätere Bestätigung des RSP. Da sich die Auswahl nach der Einreichung ändern kann, sollten Datum, Umfang und Grund jeder Änderung erhalten bleiben. Die erste Benennung ist kein endgültiger Vertragsnachweis.

Dies belegt weder Zustimmung noch Ablehnung des Anbieters, Vertragsabschluss, Bewertungsergebnis oder Delegierung. Es zeigt nur, dass Benennung und Bestätigung unterschiedliche Fragen beantworten.

Analyse

Ein belastbarer Kontrollpfad besteht aus zwei Dokumenten. Der Antrag zeigt RSP und vorgesehene Dienste; der Vertragsdatensatz verfolgt die von ICANN angeforderte Bestätigung des RSP, dass er die Unterstützung des Antragstellers und der betreffenden gTLDs plant. Bei einem Wechsel lässt sich dadurch erkennen, welche Auswahl ersetzt wurde und von welchem Anbieter ICANN später eine Bestätigung erbitten würde. Dieser Pfad ist eine Governance-Empfehlung von BTW, keine von ICANN vorgeschriebene Dokumentationspflicht.

Sources