Модуль 1 Путь кандидата

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

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

В этом модуле предлагается четкий план действий, чтобы помочь кандидатам разобраться в сложном процессе подачи заявки и подготовить их к каждому шагу на пути к получению нового gTLD.

1.1 Информация, необходимая перед подачей заявки

1.1.1 Правомочность

Подать заявку на новый gTLD могут только юридические лица, такие как корпорации, организации и учреждения, а также правительственные, неправительственные и межправительственные организации. Заявки от частных лиц и индивидуальных предпринимателей рассматриваться не будут. Кроме того, не принимаются заявки от еще не сформированных организаций и от имени еще не сформированных организаций, а также заявки, которые предполагают будущее формирование юридического лица (например, совместное предприятие на этапе оформления).

1.1.2 Сборы

Кандидаты должны внести плату за рассмотрение заявки на gTLD в полном объеме в размере 227 000 долларов США за каждую заявку. Исключение составляют кандидаты, которые имеют право на участие в Программе поддержки кандидатов (ASP), и кандидаты, подавшие заявки на варианты строк согласно критериям, описанным в Разделе 3.3 Сборы и платежи. Плата вносится после получения счета, а полная оплата должна поступить в ICANN не позднее, чем через семь дней после окончания периода приема заявок. Если кандидат не внес плату за рассмотрение заявки gTLD в течение этого семидневного срока, то, как правило, рассмотрение заявки прекращается, и она аннулируется.

Все кандидаты, в том числе те, которые отвечают требованиям ASP,¹ могут быть обязаны оплатить дополнительные сборы за обусловленные оценки. Например, если кандидат хочет обозначить свою заявку как заявку на брендовый TLD или внести в Соглашение об администрировании домена верхнего уровня добровольное обязательство регистратуры. Если кандидат не оплатит обусловленную оценку, то, в зависимости от ее типа, ему может быть предложено подать запрос на внесение изменений в заявку, удалить соответствующий раздел заявки и продолжить процедуру ее рассмотрения. В противном случае, чтобы избежать дисквалификации, необходимо своевременно оплачивать проведение требуемых обусловленных оценок. Более подробную информацию можно найти в Разделе 3.3 Сборы и платежи.

1.1.3 Условия и положения

Все кандидаты должны согласиться с условиями и положениями подачи заявок на TLD Программы New gTLD: раунд 2026 года для подачи заявок (см. Приложение 10 Условия и положения, с полным текстом которых кандидатам рекомендуется ознакомиться).

1.1.4 Система управления заявками на TLD

Заявки следует подавать в электронном виде через Систему управления заявками на TLD (TAMS). Заявки на бумажном носителе не принимаются. Кандидатам рекомендуется ознакомиться с Руководством пользователя TAMS на сайте² New gTLD, чтобы получить инструкции по использованию системы и обеспечить правильное понимание до подачи заявки.

1.1.5 Добросовестное намерение

Заявки подаются при условии наличия добросовестного намерения (bona fide) управлять gTLD. В рамках подачи любой заявки в TAMS кандидаты должны подтверждать свое добросовестное намерение управлять gTLD (см. группу вопросов 21 в Приложении 1 Вопросы заявки). ICANN оставляет за собой право отклонить заявку, если она не была подана с добросовестным намерением.

1.1.6 Универсальное принятие

Цель обеспечения универсального принятия — обеспечить принятие всеми приложениями, устройствами и системами, подключенными к интернету, всех доменных имен и адресов электронной почты, независимо от системы письменности, языка или длины TLD. Для получения дополнительной информации об универсальном принятии в Программе New gTLD см. Раздел 2.3 Универсальное принятие доменных имен и адресов электронной почты.

1.1.7 Программа поддержки кандидатов

Кандидаты, которые хотят подать заявку на новый gTLD и управлять регистратурой, могут обратиться в Программу поддержки кандидатов (ASP). При соответствии критериям, кандидаты могут получить финансовую и нефинансовую поддержку. За дополнительной и самой свежей информацией обращайтесь к разделу ASP на сайте³ Программы New gTLD.

1.2 Этапы подачи заявки

В этом разделе описаны все этапы, которые проходит заявка в процессе ее подачи и после него. Некоторые из этих этапов должны пройти все поданные заявки, другие — только при определенных обстоятельствах. В этом разделе представлен общий, неисчерпывающий обзор различных процессов. Для получения полной информации кандидатам и другим сторонам следует обратиться к соответствующим разделам Руководства кандидата.

1.2.1 Подача заявки

Ожидаемая продолжительность: 105 дней

1.2.1.1 Создание аккаунта на сайте ICANN

Прежде чем подать заявку через TAMS, кандидаты должны зарегистрировать пользовательский аккаунт на сайте⁴ ICANN и включить многофакторную аутентификацию.

1.2.1.2 Период приема заявок

Прием заявок на участие в Программе New gTLD: раунд 2026 года предположительно начнется не позднее 23:59 по UTC 30 апреля 2026 года, продлится 105 дней и завершится 12 августа 2026 года в 23:59 по UTC. Будут рассмотрены только заявки, поданные до окончания периода приема заявок, так как система не допускает подачу заявок с опозданием. Кандидатам рекомендуется подать заполненные заявки как можно скорее после открытия периода приема заявок. Кандидат, приступающий к процессу подачи заявки в конце периода, не успеет завершить все этапы, необходимые для своевременной подачи полного пакета документов.

Для рассмотрения заявки кандидаты должны внести плату за рассмотрение заявки на gTLD после получения счета и не позднее, чем через семь дней после срока приема заявок, как описано в Разделе 3.3 Сборы и платежи.

После подачи заявки кандидаты не смогут вносить какие-либо изменения, кроме тех, что описаны в Разделе 3.8 Запрос на внесение изменений в заявку. Запросы на внесение изменений в заявку можно подавать только после дня подтверждения строки.

1.2.1.3. Вопросы заявки

Заявка состоит из следующих разделов, которые необходимо заполнить при регистрации пользователя:

1. Данные об организации

2. Финансовая информация

3. Информация о заявке на gTLD

Чтобы заполнить заявку, пользователи должны ответить на ряд вопросов. При необходимости могут быть запрошены подтверждающие документы. Прежде, чем кандидат сможет подать заявку, система проверит, заполнены ли все обязательные поля. Дополнительная информация содержится в Разделе 3.1.3 Вопросы заявки, а также в Приложении 1 Вопросы заявки.

1.2.1.4 Строки в заявке

Каждая заявка подается на один gTLD и может включать одну или несколько подлежащих распределению вариантных строк (если применимо). Заявка может быть подана также на одну или несколько подлежащих распределению вариантных строк уже существующего gTLD.⁵

1.2.1.5 Выбор заменяющей строки

Чтобы уменьшить количество споров в отношении строк, в рамках своей заявки кандидаты могут также выбрать заменяющие строк, как описано в Разделе 5.1 Заменяющие строки.

1.2.1.6 Типы заявок и строк

Как описано в Разделе 3.1.6 Типы заявок и строк, для некоторых типов заявок может потребоваться дифференцированный подход в зависимости от характера заявки, строки или кандидата.

Заявки могут быть следующих типов: обычная, от сообщества, на географическое наименование, на зарезервированное имя, на брендовый TLD, на интернационализированное доменное имя (IDN-домен), на вариант существующего домена верхнего уровня, на первичный IDN-домен (включая один или несколько вариантов), с защитными мерами категории 1, а также заявки от правительств, МПО и получающих поддержку кандидатов (кандидаты от правительства/МПО и заявки от участников Программы поддержки кандидатов).

Кроме того, с некоторыми строками сопряжен запуск определенных процедур обработки и оценки: географические наименования, IDN-домены, зарезервированные имена и строки, относящиеся к защитным мерам категории 1.

1.2.1.7 Закрытые gTLD

Правление ICANN постановило, что одобрение заявок на эксклюзивные строки (закрытые gTLD⁶) станет возможным только после утверждения методологии и критериев оценки того, будет ли предлагаемый закрытый gTLD служить общественным интересам. См. Раздел 3.1.7 Строки исключительного использования (закрытые gTLD).

1.2.1.8 Валидация строк до подачи заявки

Некоторые проверки (см. Раздел 3.1.8 Валидация строк до подачи заявки) первичных и вариантных строк, включая замещающие строки, интегрированы в TAMS и реализуются автоматически средствами этой системы. Если строка не проходит одну из проверок или найдено совпадение, кандидат получит сообщение об ошибке или предупреждение в TAMS с объяснением обнаруженных проблем. В этом случае кандидату либо запретят продолжать оформлять заявку, либо попросят предоставить дополнительные документы. Кандидаты могут ввести свою строку в TAMS, чтобы проверить ее на предмет совпадений.

1.2.1.8.1 Идентификация заблокированных имен

Некоторые строки, так называемые «заблокированные имена», недоступны для делегирования. Во время составления заявки система автоматически сравнивает введенную кандидатом строку и любые применимые вариантные строки со списком заблокированных имен. В случае совпадения кандидат не может продолжать оформление заявки на эту строку и должен выбрать другую сроку, с которой он сможет продолжать оформление заявки. Дополнительная информации находится в Разделе 3.1.8.1 Идентификация заблокированных имен.

1.2.1.8.2 Идентификация зарезервированных имен

Некоторые строки, известные как «зарезервированные имена», доступны в качестве gTLD только после проверки. Эти имена предназначены для особых организаций, именуемых «ограниченное число международных МПО-МНПО», которые являются единственными сторонами, обладающими правом подавать на них заявки. ICANN ведет список зарезервированных имен, который составляется на основании разных источников, и требует от соответствующих организаций предоставления надлежащих документов. Во время составления заявки система автоматически сравнивает введенную кандидатом строку и любые применимые вариантные строки со списком зарезервированных имен. Если строка найдена в этом списке, то запускается процедура получения исключительного права на подачу заявки на зарезервированное имя, в ходе которой кандидату предлагается загрузить документы, подтверждающие, что он является тем самым субъектом, для которого зарезервировано соответствующее имя. Для получения дополнительной информации см. Раздел 3.1.8.2 Зарезервированные имена.

1.2.1.8.3 Проверка стабильности DNS

В ходе этой проверки оценивается, будет ли запрашиваемая строка негативно влиять на безопасность и стабильность системы доменных имен (DNS) и соответствует ли она DNS и другим надлежащим стандартам, как описано в Разделе 3.1.8.3 Проверка стабильности DNS. Проверка стабильности DNS включает проверку соответствия применимым правилам генерирования меток корневой зоны. Если строка не пройдет любой из тестов, кандидат не сможет подать заявку.

1.2.1.9 Выбор провайдера услуг для регистратур

Все кандидаты должны определить одного или нескольких провайдеров услуг регистратур (RSP), прошедших оценку в рамках Программы оценки RSP⁷, услугами которых кандидат намеревается воспользоваться, если запрашиваемая строка или строки достигнут этапа делегирования. Список прошедших оценку RSP можно найти на странице заявок провайдеров услуг регистратур (RSP).⁸

В рамках подачи заявки кандидату рекомендуется указать RSP, услугами которых он намеревается воспользоваться, и услуги регистратуры, которые он намеревается предлагать в запрашиваемом gTLD; кандидат может указать RSP непосредственно перед стадией оценки заявки.

Кандидаты также могут привлекать сторонних RSP или запросить одобрение ICANN на предоставление критически важных услуг регистратуры самостоятельно в качестве RSP через Программу оценки RSP. См. Раздел 3.1.10 Выбор провайдера услуг регистратур.

1.2.2 Процессы предварительной оценки

1.2.2.1 Административная проверка и подготовка ко Дню объявления результатов

Ожидаемая продолжительность: восемь недель

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

Ожидается, что административная проверка всех заявок будет завершена в течение примерно восьми недель в зависимости от общего числа заявок. В случае получения такого большого объема заявок, что ICANN не сможет обработать все заявки в течение установленного периода, ICANN опубликует обновленный срок в максимально сжатые сроки.

1.2.2.2 День объявления результатов

При отсутствии чрезвычайных обстоятельств ICANN планирует опубликовать список всех заявок, прошедших административную проверку в день объявления результатов, не позднее, чем через девять недель после окончания периода приема заявок. Список будет размещен на сайте Программы New gTLD⁹ и будет включать соответствующие строки, на которые поданы заявки, а также все варианты и заменяющие строки при их наличии. Также будет опубликована публичная часть каждой заявки. Список спорных групп, содержащих заявки на тождественные строки, также будет опубликован на сайте. Дополнительная информация находится в Разделе 5.2.4.1 Споры, возникающие из-за заявок на тождественные строки gTLD. Определенные формы взаимодействия и мероприятия запрещены со Дня объявления результатов; см. Раздел 5.2.3.1 Запрещенные формы взаимодействия и мероприятия.

1.2.2.3 Период замены строк

Ожидаемая продолжительность: две недели

Как только кандидаты получат доступ к полному списку заявленных строк, а также вариантных и заменяющих строк, у них появится возможность заменить заявленную строку заменяющей строкой. У кандидатов, выбравших подходящую строку для замены, будет 14 дней, чтобы уведомить ICANN через TAMS о своем намерении заменить свою заявленную строку заменяющей строкой, указанной в их заявке. Дополнительную информацию см. в Разделе 5.1 Заменяющие строки.

1.2.2.4 День подтверждения строк

В день подтверждения строк ICANN опубликует обновленный список заявок и выбранных ими строк (как первоначальных, так и заменяющих, как указано выше). Также будет опубликован список обновленных спорных групп.

1.2.2.5 Приоритизационная лотерея

Ожидается, что приоритизационная лотерея состоится не позднее, чем через 30 дней после дня подтверждения строки. Эта лотерея определяет номер приоритета заявки и общий порядок ее обработки ICANN, как описано в Разделе 3.7 Порядок обработки заявок и приоритизационная лотерея.

1.2.3 Комментарии сообщества, возражения и апелляции

Начиная со Дня подтверждения строк, сообщество сможет предоставить свои комментарии, как описано ниже.

1.2.3.1. Комментарии по заявкам

Ожидаемая продолжительность: 104 дня после Дня подтверждения строк; 30 дней после запросов на внесение изменений в заявку

Широкая общественность сможет разместить комментарии по заявкам на Форуме для обсуждения заявок, как описано в Разделе 4.1 Комментарии по заявкам. ICANN передаст эти комментарии и все ответы экспертам по оценке, назначенным для рассмотрения соответствующих заявок. Группы оценки будут рассматривать только комментарии и ответы, полученные в течение периода обсуждения (104 дня после дня подтверждения строки и 30 дней после соответствующих запросов на внесение изменений в заявку¹⁰).

1.2.3.2 Заблаговременные предупреждения со стороны членов GAC

Ожидаемая продолжительность: 104 дня после Дня подтверждения строк

Члены и наблюдатели Правительственного консультативного комитета (GAC) ICANN могут направлять заблаговременные предупреждения в течение 104 дней после Дня подтверждения строк, как описано в Разделе 4.2 Заблаговременные предупреждения со стороны членов GAC.

1.2.3.3 Консенсусные рекомендации GAC

GAC может дать Правлению ICANN консенсусные рекомендации GAC по любой заявке, как указано в Уставе ICANN и в Разделе 4.3 Консенсусные рекомендации GAC.

1.2.3.4 Уведомления о единственном/множественном числе

Ожидаемая продолжительность: 30 дня после Дня подтверждения строк

В течение 30 дней со дня подтверждения строки общественность может уведомить ICANN о следующем:

• Заявленные строки представляют собой единственное или множественное число одного и того же слова на одном и том же языке.

• Заявленная строка является единственным или множественным числом:

  • делегированной строки

  • строки, обрабатываемой с предыдущего раунда новых gTLD

  • Заблокированное имя

За дополнительной информацией обращаться к Разделу 4.4 Уведомления о единственном/множественном числе.

1.2.3.5 Возражения и апелляции

Ожидаемая продолжительность периода подачи возражений: 104 дня после Дня подтверждения строк

Ожидаемая продолжительность периода подачи апелляционных жалоб: 15 дней после вынесения заключения по возражению для подачи уведомления о подаче апелляции; 15 дней для подачи апелляции

В течение 104 дней после Дня подтверждения строк, обладающие правомочностью стороны могут подавать возражения на конкретные заявки, которые будут оцениваться группой экспертов. Возражения могут быть выдвинуты на основании следующих четырех факторов: схожесть строк, нарушение законных прав, нарушение общественных интересов и нарушение интересов сообщества.

Сторона, возражение которой было отклонено, имеет ограниченную во времени возможность обжаловать решение. Проигравшая сторона должна уведомить поставщика услуг по урегулированию споров (DRSP) о своем намерении подать апелляцию в течение 15 дней после вынесения решения по возражению. Впоследствии у проигравшей стороны будет еще 15 дней с даты уведомления, чтобы подать апелляцию и оплатить необходимые сборы.

Возражения и апелляции подаются непосредственно в DRSP, которого назначила ICANN. Подача и обработка этих документов являются платными для сторон. Дополнительную информацию о расходах и процедурах см. в Разделе 4.5 Возражения и апелляции.

1.2.4 Оценка строк

Ожидаемая продолжительность: 180 дней¹¹

Оценка строк заключается исключительно в оценке запрашиваемых строк и подлежащих распределению вариантных строк. Этот процесс начинается после дня подтверждения строки и, как ожидается, займет 180 дней. Период оценки строки будет частично совпадать с периодом, в течение которого сообщество может предоставить свои комментарии по заявкам, как описано в Модуле 4 Комментарии сообщества, возражения и апелляции. Оценка строки состоит из пяти элементов, описанных ниже, которые будут оцениваться одновременно. Оценка строк, в отличие от оценки заявок и кандидатов, не следует порядку приоритетов.

1.2.4.1 Оценка схожести строк

Оценка схожести строк будет выполняться комиссией экспертов с целью предотвращения введения пользователей в заблуждение и потери доверия к DNS в результате делегирования визуально похожих¹² строк, как подробно описано в Разделе 7.10 Оценка схожести строк.

1.2.4.2 Первоначальная оценка риска доменной коллизии

Первая оценка доменной коллизии направлена на выявление строк с высоким риском доменной коллизии, как описано в Разделе 7.7 Доменная коллизия. Если строка признана высокорисковой, у кандидата будет возможность представить для оценки План снижения рисков, который позволит продолжить рассмотрение заявки в случае одобрения его плана. В противном случае строка будет добавлена в Список строк с риском коллизии, и рассмотрение заявки прекратится. В этом разделе также содержится информация о временном делегировании. Это дополнительный процесс, который применяется в отношении строк, изначально не получивших статус высокорисковых.

1.2.4.3 Оценка потребности в защитных мерах

Оценка защитных мер определяет, потребуются ли в отношении запрашиваемой строки применять особые меры защиты в виде договорных требований в Соглашении об администрировании домена верхнего уровня для обеспечения защиты потребителей, требующих особого подхода строк и регулируемых рынков. Более подробная информация содержится в Разделе 7.8.2 Обязательства по обеспечению общественных интересов в качестве защитных мер.

1.2.4.4 Идентификация географических наименований

В рамках идентификации географических наименований комиссия проверит все строки, на которые поданы заявки, и определит, какие строки могут считаться географическими наименованиями, как описано в Разделе 7.5 Географические наименования. Это отдельный процесс, отличный от более существенного процесса проверки географических наименований, которая проводится в рамках оценки заявки.

1.2.4.5 Оценка уведомлений о единственном/множественном числе

ICANN рассмотрит материалы, представленные в рамках подачи уведомлений о единственном/множественном числе, и определит, представляют ли определенные строки формы единственного и множественного числа одного и того же слова на том же языке. См. Раздел 4.4.3 Результат уведомления о единственном/множественном числе.

1.2.5 Временное делегирование

Временное делегирование применяется к строкам, которые не были идентифицированы как потенциально высокорисковые, как описано в Разделе 7.7.2 Исходная оценка риска доменной коллизии. Временное делегирование может начаться непосредственно после завершения исходной оценки риска доменной коллизии, даже если другие оценки, являющиеся частью всего набора оценок строки, все еще находятся на стадии выполнения; порядок приоритетности будет сохраняться, если применимо. Во время временного делегирования запрашиваемая строка gTLD будет делегирована DNS-серверам под управлением ICANN для сбора данных об объеме и характере DNS-трафика для этой строки.

Продолжительность периода временного делегирования будет определена во время формирования процесса и критериев. Если строка относится к группе высокого риска, она удаляется из корневой зоны, и кандидат получает возможность представить на оценку План снижения рисков, который позволит продолжить рассмотрение заявки в случае одобрения предоставленного плана. В противном случае строка будет добавлена в Список строк с риском коллизии. Дополнительную информацию см. в Разделе 7.7 Доменная коллизия. Для запуска других процессов, таких как подача заявки и ее оценка или принятие решений по спорным группам, завершение временного делегирования не требуется. Тем не менее, заявка может быть переведена на этап заключения соглашения только после завершения процедуры временного делегирования и, в случае необходимости, реализации плана снижения рисков.

1.2.6 Публикация отчетов об оценке строк и списков спорных групп

После завершения оценки строки отчеты об оценке строк всех заявок, а также уточненный список спорных групп будут размещены на сайте Программы New gTLD.¹³

1.2.7 Возражения на основании схожести строк и выявление потенциальных новых спорных групп

Ожидаемая продолжительность: через 30 дней после публикации первоначального списка спорных групп

Как описано в Разделе 4.5 Возражения и апелляции, после завершения оценки строк и публикации обновленного списка спорных групп будет открыто второе 30-дневное окно для подачи возражений только на основании схожести строк. Заявки, в отношении которых поступило возражение на основании схожести строк, могут быть помещены в дополнительные спорные группы по решению DRSP. Если возникнут новые спорные группы, они будут опубликованы на сайте Программы New gTLD.¹⁴

1.2.8 Оценка приоритетности заявок от сообществ

• Обусловленная

После формирования всех спорных групп (то есть, более не допускается внесение изменений в состав групп, кроме случаев самостоятельного отзыва кандидатом своей заявки), все заявки в спорных группах будут иметь право перейти к этапу урегулирования спора. Кандидаты от сообществ, участвующие в споре, могут выбрать процедуру оценки приоритетности заявок от сообществ (CPE).¹⁵ CPE — это независимый анализ, который проводится экспертной комиссией, которая принимает решение о том, соответствует ли заявка от сообщества критериям CPE. Если заявка соответствует критериям CPE, она получит приоритет в спорной группе. Более подробную информацию о процессе и критериях можно найти в Разделе 5.4 Оценка приоритетности заявок от сообществ.

1.2.9 Аукционы новых gTLD ICANN

ICANN будет проводить аукционы для урегулирования споров между кандидатами на новые gTLD. Если победитель аукциона не имеет права на заключение Соглашения об администрировании домена верхнего уровня или не заключает его, ICANN, по своему усмотрению, имеет право предложить второму по приоритетности участнику аукциона, если таковой имеется, возможность продолжить рассмотрение его заявки. Дополнительную информацию см. в Разделе 5.6 Аукцион новых gTLD ICANN. Дополнительную информацию о праве на заключение соглашения см. в Разделе 1.2.15 Заключение соглашения. См. также Модуль 6 Процедуры оценки кандидатов и Модуль 7 Процедуры оценки строк и заявок для получения информации о других применимых оценках, которые победивший кандидат должен пройти после аукциона новых gTLD, чтобы перейти к заключению соглашения.

1.2.10 Оценка кандидата

Оценка кандидата проводится после того, как заявка либо (а) прошла оценку строки и не входит в спорную группу, либо (б) прошла оценку строки и победила в спорной группе. Она проводится параллельно с оценкой заявки на основе приоритетного номера заявки, при условии, что другие процессы не препятствуют продвижению заявки. См. Модуль 6 Процедуры оценки кандидата.

Оценка кандидата состоит из двух обязательных проверок работы, подробно описанных ниже.

1.2.10.1 Проверка основных данных

• Обязательно

Проверка основных данных призвана защищать общественные интересы при распределении критически важных интернет-ресурсов. Таким образом управлять новыми gTLD смогут только зарекомендовавшие себя корпорации, организации или учреждения с хорошей репутацией. ICANN оставляет за собой право отклонить заявку, соответствующую всем остальным критериям, на основании результатов проверки основных данных. См. Раздел 6.1 Проверка основных данных.

1.2.10.2 Оценка финансовых и операционных элементов

• Обязательно

Оценка финансовых и операционных элементов позволяет определить, обладает ли кандидат финансовыми и операционными возможностями для долгосрочной эксплуатации регистратуры, и внедрил ли он разумные меры защиты для обеспечения надежной работы и решения проблемы злоупотреблений.¹⁶ См. Раздел 6.2 Оценка финансовых и операционных элементов.

1.2.11 Оценка заявки

Ожидаемая продолжительность: См. Раздел 1.5 График жизненного цикла

Оценка заявки включает в себя оценки, описанные ниже. Из них только выбор провайдера услуг регистратур является обязательным для всех заявок. Оценка обязательств регистратуры (RCE) является обязательной для всех заявок от сообществ и обусловленной для других заявок.

1.2.11.1 Проверка провайдера услуг регистратур

• Обязательно

ICANN проверит, выбрал ли кандидат одного или нескольких прошедших оценку RSP в рамках своей заявки. Если нет, то кандидат может воспользоваться функцией расширенной оценки, чтобы предоставить запрошенную информацию о выбранных RSP. См. Раздел 7.9 Проверка провайдера услуг регистратур.

1.2.11.2 Проверка географических наименований

• Обусловленная

В процессе оценки строки Совет по географическим наименованиям проверит актуальность и подлинность подтверждающих документов во всех заявках на строки, которые определены как заявки на географическое наименование, как описано в Разделе 7.5.3.2 Проверка географических наименований.

1.2.11.3 Проверка зарезервированных имен

• Обусловленная

В процессе проверки зарезервированных имен будет определено, подана ли заявка на зарезервированную строку имеющей на это право организацией, а также проведена проверка подтверждающих документов, как описано в Разделе 7.2.2 Зарезервированные имена.

1.2.11.4 Оценка плана снижения рисков для высокорисковой строки

• Обусловленная

Кандидат на строку, которую ICANN признала создающей высокий риск доменных коллизий и спор в отношении которой был урегулирован, может представить План снижения рисков для высокорисковой строки. Этот план будет рассмотрен техническими экспертами (см. Раздел 7.7.5 Оценка плана снижения рисков для высокорисковой строки).

1.2.11.5 Оценка возможности освобождения оператора регистратуры от соблюдения требований Кодекса поведения

• Обусловленная

Кодекс поведения оператора регистратуры (включенный в Спецификацию 9 Соглашения об администрировании домена верхнего уровня) представляет собой набор руководящих принципов для оператора регистратуры, касающихся некоторых определенных эксплуатационных аспектов работы регистратуры. Если кандидат предлагает зарегистрировать все доменные имена в gTLD исключительно для собственного использования оператором регистратуры или для использования его аффилированными лицами и желает отказаться от защиты себя и своих аффилированных лиц, ICANN может предоставить освобождение от необходимости соблюдения требований Кодекса поведения при условии, что gTLD не является строкой общего пользования (см. Раздел 3.1.7 Строки исключительного использования (закрытые gTLD), а оператор регистратуры соответствует критериям освобождения от соблюдения требований Кодекса поведения (см. Раздел 7.4 Оценка возможности освобождения оператора регистратуры от соблюдения требований Кодекса поведения).

1.2.11.6 Оценка обязательств регистратуры

• Обусловленная¹⁷

Как описано в п. 7.8.3.2 Оценка обязательств регистратуры, каждое добровольное обязательство регистратур, предложенное кандидатом, и каждое правило регистрации сообщества в рамках Соглашения об администрировании домена верхнего уровня («Правила регистрации сообщества»), предложенные кандидатом на предмет включения в применимое Соглашение об администрировании домена верхнего уровня, будет оцениваться ICANN и публиковаться для общественного обсуждения.

1.2.11.6.1 Оценка добровольных обязательств регистратуры

Каждое предлагаемое добровольное обязательство регистратуры (RVC) будет проходить оценку ICANN. Цель этой оценки — определить, соответствует ли предлагаемое RVC всем критериям, изложенным в Разделе 7.8.3.2 Оценка обязательств регистратуры, на предмет его дальнейшего включения ICANN в Спецификацию 11 базового Соглашения об администрировании домена верхнего уровня.

1.2.11.6.2 Оценка правил регистрации сообщества

Правила регистрации сообщества, которые все кандидаты от сообщества должны предложить во время подачи заявки, подлежат оценке и утверждению ICANN, до включения в Спецификацию 12 базового Соглашения об администрировании домена верхнего уровня. Дополнительную информацию можно найти в Разделе 7.8.4 Правила регистрации сообщества.

1.2.11.7 Оценка соответствия требованиям для брендовых TLD

• Обусловленная

Цель оценки соответствия требованиям для брендовых TLD — подтвердить, что заявка соответствует критериям для обозначения TLD как брендового. Успешное присвоение статуса приведет к добавлению Спецификации 13 в Соглашение об администрировании домена верхнего уровня, которое заключается при условии успешного прохождения кандидатом всех этапов оценки. См. Раздел 7.3 Оценка соответствия критериям определения брендового TLD.

Кандидат на брендовый TLD, который конкурирует другими заявками, имеет возможность изменить свою строку и избежать дальнейших процедур урегулирования споров, заполнив запрос на изменение строки бренда согласно требованиям Раздела 5.3. Запросы на изменение брендовой строки.

1.2.11.8 Оценка вариантных строк

• Обусловленная

Кандидат, запрашивающий одну или несколько подлежащих распределению вариантных строк для запрашиваемого первичного IDN-домена или уже существующего домена верхнего уровня, должен обосновать необходимость в каждой запрашиваемой вариантной строке. Это обоснование будет оцениваться комиссией на основании общего стандарта разумности. Для получения дополнительной информации см. Раздел 7.6 Оценка вариантных строк. Варианты будут включены в Спецификацию 14 базового Соглашения об администрировании домена верхнего уровня.

1.2.12 Уточняющие вопросы

Ожидаемая продолжительность: Семь дней для административных вопросов; 21 день для вопросов по существу

На этапах подачи заявки и оценки кандидата¹⁸ проводящая оценку группа может задать уточняющие вопросы, если для завершения оценки требуется дополнительная информация, если она намерена отклонить заявку, а также если какой-либо из рассмотренных ею комментариев к заявке может повлиять на ее оценку. У кандидатов есть семь дней для ответа на административные уточняющие вопросы¹⁹ и 21 день для ответа на уточняющие вопросы по существу. Если кандидат не ответит в течение этого срока, он может утратить возможность устранить все проблемы, выявленные группой оценки.²⁰

1.2.13 Публикация отчетов об оценке заявки и кандидата

Отчеты об оценке заявки и кандидата составляются после завершения всех необходимых оценок, относящихся к заявке, и публикуются по мере готовности. ²¹ Некоторые процессы, такие как запросы на внесение изменений в заявку, споры или возражения, могут повлиять на сроки публикации отчетов.

1.2.14 Расширенная оценка и оспаривание результатов оценки

В некоторых случаях допускается проведение расширенной оценки и оспаривание оценки, как описано ниже. Ни один из этих процессов не подразумевает оплату обусловленных сборов.

1.2.14.1 Расширенная оценка

Кандидаты, которым не удается устранить пробелы с помощью ответов на уточняющие вопросы, могут иметь право на расширенную оценку, которая дает дополнительное время и возможности обсуждения для решения оставшихся проблем, касающихся конкретной оценки. Кандидаты могут запросить расширенную оценку в течение 15 дней с момента уведомления о результатах оценки заявки и кандидата. Расширенная оценка проводится той же группой экспертов по оценке, которая первоначально проводила оценку соответствующей заявки. При необходимости группа оценки может задать дополнительные уточняющие вопросы в рамках расширенной оценки.

Расширенный вариант может применяться при проведении следующих оценок:

Таблица 1-1. Оценки, для которых предусмотрена расширенная оценка

1.2.14.2 Оспаривание результатов оценки

Механизм оспаривания оценки позволяет кандидатам оспорить результат оценки на основании претензий в отношении процедурных, фактических или системных ошибок в автоматических проверках TAMS, которые могли привести к неправильному результату оценки. Хотя кандидаты могут представить документальные доказательства предполагаемой фактической или процедурной ошибки, им не разрешается представлять какую-либо новую информацию, которая внесла бы существенное изменение в поданную заявку. Как правило, механизм оспаривания не предусматривает уточняющих вопросов.

Механизм оспаривания предполагает «экспресс-оценку». Комиссия может отклонить оспаривание на основании одного или нескольких критериев, указанных ниже:

• Основание для оспаривания не входит в список допустимых оснований.

• Оспаривающая сторона не является кандидатом.

• Не предоставлено никаких доказательств в поддержку основания для оспаривания или доказательств недостаточно.

• Претензия является неправдоподобной, явно надуманной или противоречит здравому смыслу.

• Кандидат выдвигает дублирующие друг друга или повторяющиеся претензии на одном и том же основании в отношении одной и той же оценки.

• Другие факты, которые могут ясно свидетельствовать о том, что претензия является явно необоснованной или представляет собой злоупотребление правом на оспаривание.

Обзор оценок, по которым допускается оспаривание, сроки направления соответствующего запроса и основания для оспаривания см. в Таблице 1-2. Оценки, по которым допускается оспаривание.

Таблица 1-2. Оценки, по которым допускается оспаривание

Комиссия по оспариванию сообщит результат валидации строки до подачи заявки в течение пяти дней после инициирования процедуры оспаривания кандидатом. В отношении других оценок, перечисленных в таблице выше, Комиссия по оспариванию сообщит результат в течение 30 дней с момента инициирования оспаривания кандидатом.

Более подробную информацию о типах оценок и их оспаривании см. в разделах, ссылки на которые приведены в таблице выше. В каждом разделе представлена дополнительная информация о процессе оспаривания и его результатах.

1.2.15 Заключение соглашения

Ожидаемая продолжительность: Кандидат должен заключить соглашение не позднее, чем через 90 дней после даты приглашения к его заключению.

Кандидат, успешно прошедший все соответствующие этапы, описанные в этом разделе, должен заключить с ICANN Соглашение об администрировании домена верхнего уровня, чтобы иметь право на делегирование запрашиваемой строки (и любых вариантных строк, если такие есть) в корневую зону DNS. Кандидатам, прошедшим этап подачи и оценки заявки, будет предложено предоставить дополнительную информацию для заключения соглашения, включая данные об уполномоченном лице с правом подписи. Одновременно кандидаты также должны подтвердить, что все заявления и утверждения, содержащиеся в заявке и дополнительно предоставленные в процессе подачи заявки (включая любые документы или письменные материалы, представленные в связи с заявкой), по-прежнему являются правдивыми, точными и полными во всех существенных отношениях, как того требуют условия Раздела 3.8 Запросы на внесение изменений в заявку и Условия и положения настоящего Руководства (Приложение 10).

Параллельно процессу заключения соглашения, ICANN запросит у указанного кандидатом RSP подтверждение того, что он признает планы по поддержке данного кандидата и этого gTLD.

Базовое Соглашение об администрировании домена верхнего уровня (Приложение 4) является результатом широких консультаций с сообществом. ICANN будет рассматривать вопрос о внесении изменений в соглашение только в исключительных обстоятельствах, таких как уникальные правовые, юрисдикционные или нормативные вопросы, которые юридически препятствуют выполнению организацией базового Соглашения об администрировании домена верхнего уровня в существующем виде. Кандидаты, которые хотят обсудить внесение узких поправок в базовое Соглашение об администрировании домена верхнего уровня, должны будут предоставить обоснование необходимости таких изменений вместе с предлагаемыми изменениями в режиме редакторской правки. Кандидаты должны подать в ICANN запрос на проведение переговоров максимально рано и не позднее, чем через 15 дней после даты приглашения заключить соглашение.

При необходимости Соглашение об администрировании домена верхнего уровня будет включать следующее, в зависимости от ответов кандидата на вопросы по заявке и результатов оценки:

• Обязательства по обеспечению общественных интересов, в том числе добровольные обязательства регистратур и механизмы защиты в Спецификации 11.

• Правила регистрации сообщества в Спецификации 12.

• Информация о заявках на брендовые TLD в Спецификации 13.

• Информация о вариантных строках в Спецификации 14.

• Специальные положения, касающиеся межправительственных организаций или государственных органов включены в статью 7.

При отсутствии чрезвычайных обстоятельств кандидаты должны заключить соглашение в течение 90 дней с момента получения приглашения начать процесс заключения соглашения.

1.2.16 После заключения соглашения

В настоящем разделе «После заключения соглашения» новым операторам регистратур предоставляются ресурсы для понимания требований к запуску и эксплуатации своих gTLD.

После успешного прохождения оценки и подписания с ICANN Соглашения об администрировании домена верхнего уровня, эксплуатация gTLD бывшим кандидатом на новый gTLD регулируется вышеупомянутым Соглашением об администрировании домена верхнего уровня, в котором изложены обязательства оператора регистратуры и ICANN. Операторы регистратур должны выполнить действия по внедрению различных систем и процессов ICANN в соответствии с надлежащим Соглашением об администрировании домена верхнего уровня. Их внедрение имеет решающее значение для обеспечения соблюдения договорных обязательств и выполнения эксплуатационных обязанностей. Новые операторы регистратур обязаны делегировать свой TLD в течение одного года с даты подписания Соглашения об администрировании домена верхнего уровня, за исключением случаев, описанных в Разделе 2.20 базового Соглашения об администрировании домена верхнего уровня.

Новые операторы регистратур могут ознакомиться с информацией на сайте Программы New gTLD, где будут представлены исчерпывающие ресурсы, которые помогут им ориентироваться в том, как работать с ICANN, и разобраться в своих договорных обязательствах. Дополнительную информацию о делегировании gTLD и сроках завершения см. в Разделе 1.2.15 Заключение соглашения и в Приложении 4 Базовое Соглашение об администрировании домена верхнего уровня.

1.2.17 Процедуры урегулирования споров после делегирования

Процедуры урегулирования споров после делегирования дают возможность подать жалобу на поведение оператора регистратуры.

Иногда от истца может потребоваться проведение конкретных мероприятий для устранения проблем до подачи официальной жалобы. Административное ведение процедур урегулирования споров осуществляется ICANN или квалифицированными сторонними поставщиками. В случае назначения экспертной комиссии она определяет были ли оператором регистратуры совершены нарушения, и если да, то рекомендует ICANN принять меры по исправлению ситуации.

Операторы регистратур должны использовать механизмы урегулирования споров, изложенные в базовом Соглашении об администрировании домена верхнего уровня, и обязаться принять любое решение, которые вынесет ICANN или экспертная комиссия, а также внедрять и использовать любые средства правовой защиты, введенные ICANN в результате рассмотрения жалобы.

В настоящее время существует три процедуры урегулирования споров после делегирования:

1. Процедура урегулирования споров в области обеспечения общественных интересов (PICDRP): PICDRP предназначена для рассмотрения жалоб на то, что оператор регистратуры предположительно не соблюдает одно или несколько обязательств по обеспечению общественных интересов (PIC) или добровольных обязательств регистратур (RVC), закрепленных в Соглашении об администрировании домена верхнего уровня. Дополнительную информацию о PIC и RVC см. в Раздел 7.8 Обязательства по обеспечению общественных интересов, добровольные обязательства регистратур и правила регистрации сообщества.

2. Процедура урегулирования разногласий в отношении товарных знаков после делегирования (PDDRP): RRDRP направлена на рассмотрение обстоятельств, при которых оператор регистратуры gTLD сообщества якобы отклоняется от ограничений на регистрацию доменов, изложенных в его Соглашении об администрировании домена верхнего уровня. gTLD сообщества эксплуатируется в интересах четко определенного сообщества. Дополнительную информацию о заявках от сообщества см. в Разделе 5.4 Оценка приоритетности заявок от сообществ.

3. Процедура урегулирования споров о товарном знаке после делегирования (TM-PDDRP): TM-PDDRP в целом направлена на рассмотрение предполагаемого соучастия в незаконном использовании товарных знаков на первом или втором уровне gTLD. Из трех процедур урегулирования споров после делегирования только TM-PDDRP специально предназначена для решения вопросов по товарным знакам, касающихся операторов регистратур. Дополнительные сведения о требованиях к механизмам защиты прав для всех gTLD см. в разделе о механизмах защиты прав.²³

Дополнительная информация о сфере применения процедур, функциях всех сторон и самом процессе вынесения решений в рамках процедур урегулирования споров после делегирования содержится в разделе «Часто задаваемые вопросы» на сайте Программы New gTLD,²⁴ а также на странице «Механизмы защиты прав (RPM) и процедуры урегулирования споров (DRP)».

1.3 Обзор процедуры

Рисунок 1-1: Обзор процедуры

1.4 Публикуемые материалы

ICANN разместит следующие материалы, связанные с поданными заявками, на сайте Программы New gTLD:

• Общедоступные разделы заявок

• Назначенный номер приоритетности

• Статус и этап рассмотрения заявки

• Заявки, по которым поступило заблаговременное предупреждение со стороны членов GAC или консенсусная рекомендация GAC

• Статусы возражений и апелляций

• Комментарии по заявкам

• Изменения в общедоступной части заявки в связи с запросами на внесение изменений в заявку

• Отчеты о результатах оценки (строка, заявка и кандидат, а также CPE)

• Отчет о результатах первоначальной оценки риска доменной коллизии

• Отчет о временном делегировании

• План и отчет по снижению высоких рисков

• Отчеты о результатах проведения расширенной оценки и оспаривания оценки

• Уточняющие вопросы (CQ) и ответы кандидата на CQ по общедоступной части заявок

• Список спорных групп

• Статус выбора CPE

• Статус и результаты аукциона

1.5 График жизненного цикла

В таблице ниже представлена общая оценка продолжительности каждого процесса в месяцах, в зависимости от числа поданных заявок. Указанная продолжительность относится к простым и стандартным заявкам из партии первого приоритета, в отношении которых не поступило консенсусной рекомендации GAC, возражений или обусловленных оценок, и которые при этом не конкурируют с другими заявками и не имеют каких-либо других проблем. Рассмотрение заявок с приоритетом более низкого уровня может быть приостановлено до назначенного времени обработки. На обработку заявок, которые требуют проведения обусловленной оценки или в отношении которых была дана консенсусная рекомендация GAC, либо в отношении более сложных заявок, может потребоваться больше времени.

Таблица 1-3. Расчетная продолжительность каждого процесса

*Расчетная продолжительность процедур онбординга и делегирования будет предоставлена позже.

В таблице ниже приведена расчетная продолжительность некоторых обусловленных процессов, предметом которых может стать заявка.

Таблица 1-4. Расчетная продолжительность некоторых обусловленных процессов

Эти таблицы не охватывают все возможные сценарии, и на продолжительность каждого процесса может повлиять ряд факторов. Показатели по различным процессам будут размещены на сайте Программы New gTLD²⁷, где они будут регулярно обновляться.