Кратко

  • Заявитель должен указать RSP, которые будут выполнять критически важные функции реестра, если заявка дойдет до делегирования.
  • На этапе заключения договора ICANN отдельно запрашивает у указанного RSP подтверждение того, что он планирует поддерживать заявителя и соответствующий gTLD или несколько gTLD.
  • После подачи заявки выбранных RSP можно указать или изменить через процедуру Application Change Request.

В этой статье два события, описанные в Applicant Guidebook, объясняются через две записи. Первая отражает поставщика, которого заявитель намерен использовать. Для второго события ICANN на этапе договорного оформления запрашивает у RSP подтверждение его планов поддерживать заявителя и соответствующие gTLD. Модель двух записей — анализ BTW, а не требование ICANN.

Название, внесенное заявителем, фиксирует намерение заявителя, но само по себе не фиксирует последующее подтверждение поставщика. Поскольку выбор может измениться после подачи, следует сохранять дату, объем и причину каждого изменения, а не считать первое указание окончательным договорным доказательством.

Это не доказывает согласие или отказ поставщика, подписание договора, результат оценки или делегирование. Это лишь показывает, что указание заявителя и подтверждение RSP отвечают на разные вопросы.

Анализ

Надежная контрольная цепочка состоит из двух документов. Это рекомендация BTW по управлению, а не требование ICANN к ведению документации. В заявке указываются выбранные RSP и предполагаемые услуги; в договорной записи отслеживаются запрос ICANN о подтверждении и любой фактически документированный ответ поставщика. При смене RSP это позволяет установить, какой выбор заменен и у какого поставщика ICANN позднее запросит подтверждение.

Sources