Модуль 3 Подача заявки

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

В Модуле 3 также освещаются дополнительные важные темы, в том числе:

• Стабильность DNS и правила генерирования меток корневой зоны.

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

• Сборы и платежи.

• Запросы на внесение изменений.

Эта информация предназначена для разъяснения процесса подачи заявки, что позволит кандидатам тщательно подготовиться и уверенно его пройти.

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

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

Период приема заявок предположительно начнется не позднее 23:59 по UTC 30 апреля 2026 года, продлится 105 дней и завершится 12 августа 2026 года в 23:59 по UTC.

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

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

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

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

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

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

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

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

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

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

Чтобы заполнить заявку, пользователи должны ответить на ряд вопросов, перечисленных в Приложении 1 Вопросы заявки; их попросят предоставить подтверждающие документы, по потребности. Система проверит, заполнены ли все обязательные поля, прежде чем кандидат сможет подать заявку.

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

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

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

3.1.4 Строки в заявке на gTLD

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

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

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

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

В этом разделе описываются различные типы заявок на новые gTLD, включая обычные заявки, заявки от сообщества, заявки на географические наименования, зарезервированные имена, бренды, IDN-домены, варианты существующих gTLD, первичные варианты IDN-доменов для нового gTLD, заявки от государственных структур, МПО и кандидатов с поддержкой ASP (типы заявок «кандидаты от правительства/МПО» и «кандидаты, получившие поддержку по ASP»). В отношении каждого типа заявки могут применяться свои требования и порядок обработки, о чем кандидату следует знать при подаче заявки (см. Раздел 7.1 Типы строк и заявок).

В нижеприведенной таблице представлен обзор различных типов заявок, а также конкретных областей, в которых могут применяться разные требования. Подробную информацию смотрите в разделах, см. по ссылкам на разделы в Таблице 3-1.

Таблица 3-1. Обзор типов заявок и основные различия в работе с ними

3.1.7 Строки исключительного использования (строки закрытых gTLD)

В Базовом Соглашении об администрировании домена верхнего уровня (Приложение 4) домен общего пользования верхнего уровня определен как «строка, состоящая из слова или понятия, которое обозначает или описывает общий класс товаров, услуг, групп, организаций или вещей, в противоположность выделению конкретного бренда товаров, услуг, групп, организаций или вещей среди других аналогичных брендов». В базовом Соглашении об администрировании домена верхнего уровня в отношении категории «эксклюзивный» gTLD устанавливаются критерии приемлемости, которыми регистрация ограничивается одним лицом или организацией и/или «аффилированных организаций (лиц)» этого лица или организации. Операторам регистратур воспрещается администрировать gTLD общего пользования для эксклюзивного пользования. Эта ситуация известна под названием запрет на закрытые gTLD. Примерами потенциальных строк общего пользования являются .tree и .banana, но следует отметить, что эти примеры также могут подпадать под определение брендового TLD.

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

Под понятием «брендовые TLD» не подразумевается общий класс товаров, услуг, групп, организаций или вещей, и поэтому они не подпадают под запрет на закрытые домены общего пользования. В Разделе 9.3 Спецификации 13 базового Соглашения об администрировании домена верхнего уровня⁹ записано, что «брендовые TLD — это TLD, в которых: (ii) владельцами доменных имен, регистрируемых в данном TLD, являются только оператор регистратуры, его аффилированные организации (лица) или лицензиаты товарных знаков, в управлении которых находятся записи DNS, связанные с доменными именами на всех уровнях данного TLD». Дополнительную информацию см. в Разделе 7.3 Оценка соответствия требованиям для брендовых TLD.

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

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

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

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

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

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

Строки новых gTLD не должны создавать угрозу безопасности или стабильности DNS. Проверка стабильности DNS определяет, соответствует ли запрашиваемая строка gTLD стандартам DNS и другим применимым нормам. Эта оценка включает в себя проверку строки на соответствие техническим требованиям, указанным для строк gTLD. Заявки не будут рассматриваться до успешного завершения проверок.

Запрашиваемая строка gTLD должна соответствовать следующим требованиям:

1. Метка ASCII должна быть либо NR-LDH¹⁰ или действительной A-Label, как описано в разделе 2.3 RFC 5890¹¹.

2. Метка NR-LDH должна состоять исключительно из букв (алфавитных символов от a до z) в соответствии с разделом 2.1 RFC1123.¹²

3. Строки IDN-доменов gTLD должны соответствовать IDNA2008¹³ (RFC 5890-5893) и всем RFC по стандартам, обновляющим IDNA2008.

4. IDN-строки gTLD должны соответствовать применимым правилам генерирования меток корневой зоны.¹⁴ Подробнее о правилах RZ-LGR и обработке заявок см. в Разделе 3.1.8.3.1 Правила генерирования меток корневой зоны.

5. Если строка gTLD классифицируется как вариантная строка существующего gTLD в корневой зоне или первичного запрашиваемого gTLD, она должна быть подлежащей распределению вариантной строкой этого первичного gTLD (см. Раздел 3.1.9 Интернационализированные доменные имена). RZ-LGR является единственным источником для расчета вариантных строк основного gTLD и их значений расположения, как подлежащих распределению, так и блокируемых.

Проверки, описанные выше, встроены в TAMS и реализуются через эту систему. Это означает, что вышеперечисленные проверки будут выполняться автоматически, когда кандидат вводит строку в свою заявку.

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

В Разделе 7.7 Доменная коллизия и Разделе 2.5 Безопасность и стабильность описаны дополнительные соображения и требования, касающиеся проверок стабильности и безопасности.

3.1.8.3.1 Правила генерирования меток корневой зоны

3.1.8.3.1.1 Применимая версия RZ-LGR и поддерживаемые наборы символов и языки

Интернационализированные доменные имена (IDN-домены) необходимы для обеспечения многоязычия в интернете. В целях обеспечения безопасной и стабильной работы DNS были разработаны правила генерирования меток корневой зоны (RZ-LGR)¹⁵ для определения действительности запрашиваемых первичных строк в разных наборах символов, а также подлежащих распределению вариантных строк.

DNS предназначена для идентификаторов, а не для написания литературных текстов, поэтому не предполагается, что RZ-LGR будет обеспечивать всю языковую полноту выражения ни на одном из использующихся в DNS естественных языков, а сгенерированная по правилам RZ-LGR строка не обязательно должна быть словом на каком-либо языке.

Будет использоваться версия 6 RZ-LGR, в которую вошли все указанные ниже¹⁶ наборы символов и системы письма, разработанная Комиссиями сообщества по выработке правил и интегрированная группой экспертов-рецензентов (Комиссия по интеграции правил).

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

Правила RZ-LGR содержат отдельные LGR для каждого набора символов или системы письма. Система письма может содержать более одного набора символов, например, японская система письма состоит из хираганы, катаканы и кандзи (хань).

3.1.8.3.1.2 Заявки на строки, записанные при помощи неподдерживаемого набора символов

Согласно правилам RZ-LGR, принимаются в качестве действительных только строки в наборах символов или системах письма, интегрированных в правила. Кандидаты не смогут подать заявку на строку в наборе символов, не интегрированном в соответствующую версию RZ-LGR.

В этих случаях потенциальному кандидату следует сначала поработать с сообществом, использующим соответствующий набор символов, над его включением в RZ-LGR по процедуре RZ-LGR.¹⁷ ICANN будет оказывать активную поддержку этому процессу. Потенциальный кандидат может инициировать этот процесс в ICANN в любой момент, отправив электронное письмо на адрес globalsupport@icann.org в любое время. Кандидат сможет подать заявку в последующий период подачи заявок, если соответствующий набор символов будет интегрирован и доступен в соответствующей версии RZ-LGR.

3.1.8.3.1.3 Выбор первичных и/или вариантных строк с использованием RZ-LGR

Первичная строка — это основная строка, предложенная кандидатом, которая должна быть действительна согласно расчету RZ-LGR. Вариантные строки первичной строки также рассчитываются с помощью RZ-LGR и отмечаются как подлежащие распределению или заблокированные вариантные строки. Первичная, подлежащая распределению и заблокированные вариантные строки вместе называются набором вариантных строк. Существующий gTLD считается первичной строкой, на основании которой будет рассчитываться и подаваться в заявке набор вариантных строк.

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

Выбор первичной строки (где первичная строка не является существующим gTLD) в наборе вариантных строк не изменит общее количество строк в этом наборе, но может изменить подмножества подлежащих распределению и заблокированных вариантных строк в наборе. Поэтому при выборе первичной строки кандидатам следует учитывать подлежащие распределению и заблокированные вариантные строки, которые будут созданы в соответствии с основной строкой. Инструмент LGR, предоставляемый ICANN, находится по адресу https://lgrtool.icann.org/. Им можно воспользоваться для определения подлежащих распределению вариантных строк первичной строки.

3.1.8.3.1.4 Результаты использования расчетов согласно RZ-LGR

Правила RZ-LGR применяются к первичной строке для определения того, является ли первичная строка допустимой в качестве TLD согласно RZ-LGR.

RZ-LGR применяется к вариантной строке первичной строки или существующего gTLD для:

1. Определения допустимости вариантной строки в качестве gTLD согласно RZ-LGR.

2. Решения о том, принадлежит ли вариантная строка основной строке или существующему gTLD, указанному кандидатом.

3. Определения того, принадлежит ли подлежащая распределению вариантная строка первичной строке или существующему gTLD.

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

3.1.8.4 Оспаривание результатов валидации строк до подачи заявки

Если кандидат считает, что ему мешают подать заявку или он вынужден предоставить дополнительные документы из-за того, что валидация строк до подачи заявки была проведена неправильно или неправильно закодирована, у него будет возможность оспорить это решение не позднее, чем за 14 дней до окончания периода приема заявок.¹⁸ Подробное описание порядка оспаривания подобных решений приведено ниже:

• Идентификация заблокированных имен: Системная ошибка в автоматизированном процессе идентификации заблокированных имен привела к тому, что строка кандидата была ошибочно классифицирована как заблокированное имя. Вследствие этого кандидат не смог приступить к подаче заявки. См. Раздел 3.1.8.1.

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

• Проверка стабильности DNS: Системная ошибка в расчетах автоматизированного инструмента проверки стабильности DNS и выявленная системная ошибка стали причиной того, что кандидат не прошел проверку стабильности DNS. Вследствие этого кандидат не смог приступить к подаче заявки. Данный механизм оспаривания не применим к наборам символов, не охваченных RZ-LGR. См. Раздел 3.1.8.3 и Раздел 3.1.8.3.1.2 Заявки на строки, записанные при помощи неподдерживаемого набора символов.

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

3.1.9 Интернационализированные доменные имена

IDN-домены — это интернационализированные доменные имена, представленные символами, отличными от символов ASCII (буквы a–z для доменов верхнего уровня). Такие доменные имена формируются с использованием символов, не входящих в набор символов ASCII (например, арабских или китайских).

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

3.1.9.1 Правила для IDN-доменов и их вариантов

Запрашиваемый IDN-домен должен соответствовать IDNA2008¹⁹ (RFC 5890-5893)²⁰ и всем последующим версиям. IDN-домен должен соответствовать положениям применимой версии правил RZ-LGR. См. Раздел 3.1.8.3.1 Правила генерирования меток корневой зоны.

IDN-домены могут быть представлены символами Unicode (так называемая U-Label) и эквивалентным им кодом ASCII с префиксом «xn--» (так называемая A-Label) в соответствии с IDNA2008. Заявки на IDN-домены (в формате U-Label) должны быть длиннее одного символа. Это значит, что U-Label должна иметь как минимум две кодовые точки со значением ‘L’ в графе «общая категория»²¹ согласно определению стандарта Unicode. Кодовые точки со значением ‘M’ в графе «общая категория» не будут учитываться при расчете длины при определении того, не является ли запрашиваемый IDN-домен одним символом. Дополнительные требования к строкам см. также в Разделе 3.1.8.3 Проверка стабильности DNS.

Правила RZ-LGR являются единственным основанием для расчета вариантных строк и их значений расположения (подлежащих распределению или блокируемых) для всех существующих gTLD и всех запрашиваемых первичных строк.

Инструмент LGR, предоставляемый ICANN, может использоваться для определения подлежащих распределению вариантных строк для первичного gTLD или строки, на которую подана заявка.²²

3.1.9.2 Подача заявки на IDN-домены

Заявку на IDN-домен, соответствующую обязательным требованиям к строке, включая IDNA 2008, а также правилам RZ-LGR, можно подать через TAMS. Если расчет согласно правилам RZ-LGR во время алгоритмической проверки покажет, что gTLD, на который подается заявка, является «недействительным» или «заблокированным» (например, если запрашиваемая строка является вариантной строкой), эта заявка на несоответствующую требованиям строку не будет принята системой приема заявок. Более полный список проводимых проверок см. в Разделе 3.1.8.3 Проверка стабильности DNS. Кандидат может оспорить расчет согласно правилам RZ-LGR, выполненный системой приема заявок. См. Раздел 3.1.8.3.1 Правила генерирования меток корневой зоны.

3.1.9.2.1 Подача заявки на новый первичный IDN-домен и его вариантные строки

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

Можно подать заявку на подлежащие распределению вариантные строки из набора, созданного с помощью RZ-LGR. Заявка на подлежащую выделению вариантную строку не может предшествовать заявке на ее первичный IDN-домен gTLD. Первичный IDN-домен gTLD и любые подлежащие распределению вариантные строки, на которые подана заявка в том же раунде, должны быть оформлены в одной заявке. Если результаты оценки положительные, первичный gTLD и относящие к нему подлежащие распределению вариантные строки, на которые подается заявка, будут распределяться одному и тому же оператору регистратуры по одному Соглашению об администрировании домена верхнего уровня. Кандидат не может подать заявку на заблокированную вариантную строку нового первичного IDN-домена, рассчитанную по RZ-LGR. Подробнее о регистрационных сборах за подлежащие распределению вариантные строки см. в Разделе 3.3 Сборы и платежи.

После подачи заявки на первичный IDN-домен gTLD ее нельзя изменить, за исключением случаев помещения запрашиваемой первичной строки заявки на брендовый IDN-домен gTLD в спорную группу (см. Раздел 5.3 Запрос на изменение брендовой строки).²³

После подачи заявки кандидат может отозвать любую из запрашиваемых вариантных строк из своей заявки, отправив запрос на внесение изменений в заявку (Раздел 3.8), но не может добавить никакую другую подлежащую распределению вариантную строку, изначально не указанную в заявке. Если кандидат отзывает свою заявку на первичный IDN-домен gTLD, все запрашиваемые им вариантные строки также будут отозваны.

3.1.9.2.2 Подача заявки на вариантные строки существующих gTLD

Кандидат может подать заявку на вариантные строки существующего gTLD только в том случае, если он является тем же юридическим лицом, что и оператор регистратуры этого gTLD. В период делегирования по всем вариантным строкам следует использовать того же конечного провайдера услуг для регистратур, что и для существующего gTLD. Провайдер backend-услуг для регистратур должен быть одобрен через Программу оценки RSP.²⁴

Заявки на подлежащие распределению вариантные строки существующего gTLD можно подавать из набора, созданного с помощью RZ-LGR, и их необходимо подавать в рамках одной заявки. После успешной оценки запрашиваемые подлежащую распределению вариантные строки будут распределены оператору регистратуры существующего gTLD. Оператору регистратуры необходимо заключить базовое Соглашение об администрировании домена верхнего уровня раунда 2026 года; существующие gTLD и все вариантные строки будут распределены по одному соглашению Соглашение об администрировании домена верхнего уровня. Кандидат не может подать заявку на заблокированную согласно расчетам по RZ-LGR вариантную строку существующего gTLD. Подробнее о регистрационных сборах за подлежащие распределению вариантные строки см. в Разделе 3.3 Сборы и платежи.

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

3.1.9.3 Требования и обработка заявок

3.1.9.3.1 Определение приоритета последовательности обработки вариантных строк существующих gTLD

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

3.1.9.3.2 Несколько кандидатов на одну и ту же первичную строку или ее вариантные строки

Если разные кандидаты подают заявки на строки из одного и того же набора вариантных строк, то такие заявки будут помещены в спорную группу, и в результате будет выбран только один кандидат в рамках процесса урегулирования спора. Это означает, что запрашиваемые первичные строки и относящиеся к ним запрашиваемые подлежащие распределению вариантные строки будут участвовать в качестве набора во всех механизмах урегулирования споров в отношении строк, таких как Оценка приоритетности заявок от сообществ (Раздел 5.4) или Аукцион новых gTLD ICANN (Раздел 5.6) (см. Модуль 5 Урегулирование споров в отношении спорных групп).

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

3.1.10 Выбор поставщика услуг для регистратур

Кандидаты должны указать, какие поставщики услуг для регистратур (RSP) будут предоставлять критически важные услуги регистратуре, если их заявка будет передана на делегирование. Список прошедших оценку RSP можно найти на странице заявок провайдеров услуг регистратур (RSP).²⁵

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

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

3.1.10.1 Требования относительно выбора RSP при подаче заявки

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

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

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

Кандидат может указать RSP или изменить свой выбор RSP после подачи заявки, оформив Запрос на внесение изменений в заявку (Раздел 3.8) .

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

3.1.10.2 Функции регистратуры и типы RSP

Базовое Соглашение об администрировании домена верхнего уровня требует, чтобы операторы регистратуры обеспечивали поддержку следующих критически важных функций регистратуры: система доменных имен (DNS), расширения безопасности системы доменных имен (DNSSEC), протокол EPP, протокол доступа к регистрационным данным (RDAP) и временное депонирование данных. Существует четыре типа RSP, каждый из которых обеспечивает набор уникальных услуг, необходимых для выполнения критически важных функций:

1. Основные RSP, которые управляют базой данных регистраций для gTLD, осуществляют депонирование регистрационных данных доменного имени и управляют службами EPP и RDAP для gTLD. У gTLD может быть только один основной RSP.

2. RSP DNS, которые управляют одним или несколькими DNS-серверами для gTLD. У gTLD может быть несколько RSP DNS.

3. RSP DNSSEC, которые выполняют криптографические операции, необходимые для DNSSEC. У gTLD может быть только один RSP DNSSEC.

4. Прокси-RSP, которые выполняют проверку соответствия регистрационных данных требованиям законодательства в конкретной юрисдикции. Следует отметить, что это необязательная дополнительная услуга регистратуры, которая должна быть одобрена ICANN в программе Программа оценки RSP.²⁷ У gTLD может быть несколько прокси-RSP, каждый из которых обеспечивает доступ к разным юрисдикциям.

Организация может пройти оценку на квалификацию RSP по одной или нескольким категориям по Программе оценки RSP.²⁸

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

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

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

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

3.3 Сборы и платежи

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

3.3.1 Плата за рассмотрение заявки на gTLD

Плата за рассмотрение заявки на gTLD установлена на уровне, позволяющем возместить все затраты, связанные с Программой New gTLD. Такой подход обеспечит полное самофинансирование Программы без влияния на доходы, а также без потребности в субсидировании ее за счет других источников финансирования ICANN, включая сборов с операторов регистратуры gTLD и регистраторов, а также взносов ccTLD и региональных интернет-регистратур. По оценкам ICANN, процедуры оценки, заключения соглашений и делегирования в рамках следующего раунда будут продолжаться приблизительно до 30 июня 2030 года.²⁹ Предполагается, что к этому времени все поданные заявки уже пройдут все этапы Пути кандидата (Модуль 1). Плата за рассмотрение заявки на gTLD покрывает все требуемые оценки, включая расширенную оценку, при необходимости, в течение этого периода времени.

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

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

3.3.1.1 Плата за рассмотрение заявки gTLD для заявок с вариантными строками

3.3.1.1.1 Для новых кандидатов

Плата за рассмотрение заявки на gTLD покрывает одну заявку на первичный gTLD и до четырех вариантных строк. Если кандидат хочет подать заявку на более чем четыре вариантных строки одной первичной строки, он должен внести плату за рассмотрение заявки в размере 227 000 долларов США за каждый дополнительный подлежащий распределению вариант строки сверх четырех. За обусловленные оценки (см. Раздел 3.3.2) может взиматься дополнительная плата.

3.3.1.1.2 Для операторов регистратур уже существующих gTLD раунда 2012 года

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

3.3.1.2 Плата за рассмотрение заявки gTLD для квалифицированных кандидатов, участвующих в Программе поддержки кандидатов

Квалифицированные кандидаты ASP будут иметь право на 75–85% снижение платы за рассмотрение заявки на gTLD. Таким образом, плата за рассмотрение заявки на gTLD с учетом скидки для кандидата, прошедшего отбор по Программе ASP, составит от 34 500 долл. США до 56 750 долл. США (включая задаток в размере 2500 долл. США, внесенный для подтверждения финансовой стабильности по правилам ASP). Точная сумма будет зависеть от окончательного числа квалифицированных кандидатов ASP. ICANN проинформирует кандидатов, прошедших отбор по Программе ASP, о том, что они имеют право на получение как минимум 75% скидки, и что об окончательном размере скидки будет сообщено через 12–16 недель после завершения периода приема заявок по Программе ASP. Как указано в Разделе 3.3.1.1 Плата за рассмотрение заявки на gTLD для заявок с вариантными строками, плата за рассмотрение заявки gTLD с учетом скидки включает до четырех вариантных строк. Кандидатам с поддержкой ASP, подающим заявки на более чем четыре вариантные строки, необходимо будет внести плату за рассмотрение заявки в размере 227 000 долларов США за каждый дополнительный вариант сверх четвертого.

3.3.2 Обусловленные оценки

Помимо обязательных оценок, включенных в плату за рассмотрение заявки на gTLD, существует ряд обусловленных оценок, которые кандидаты могут выбрать или обязаны пройти для получения определенного статуса или освобождения от определенных требований. Сборы с кандидатов за подобные обусловленные оценки также устанавливаются для покрытия расходов, связанных с проведением оценок, которые могут осуществляться сторонними поставщиками или реализовываться при их поддержке. Это обеспечивает полное финансирование Программы и нейтральность с точки зрения доходов, а также отсутствие субсидирования ее за счет взносов из других источников финансирования ICANN, в том числе сборов с операторов регистратур gTLD и регистраторов, а также взносов от ccTLD и региональных интернет-регистратур. Информация о том, какие из этих обусловленных оценок понадобятся, например, Проверка плана снижения риска для высокорисковой строки, будет доступна только на более поздних этапах процесса оценки. Подробную информацию о том, что подразумевает каждая из этих оценок, можно найти в соответствующих разделах, указанных в Таблице 3-2. Обусловленные оценки и сборы.

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

Для оценок, отмеченных одной звездочкой (*), квалифицированный кандидат ASP получит ту же процентную скидку, которую он получил на плату за рассмотрение заявки на gTLD. Прежде чем предоставить эту скидку, ICANN попросит кандидата ASP подтвердить сохраняющееся соответствие требованиям на получение дальнейшей финансовой поддержки (см. также Условия и положения ASP).³¹

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

Таблица 3-2. Обусловленные оценки и сборы

3.3.3 Возврат затрат

3.3.3.1 Возврат платы за рассмотрение заявки gTLD

При определенных обстоятельствах кандидаты могут запросить о предоставлении частичного возврата средств³², уплаченных ими ICANN в рамках процесса подачи заявки на новый gTLD, как указано ниже. Сумма возврата зависит от этапа процесса рассмотрения заявки, на котором заявка была отозвана или рассмотрение прекращено в результате изменения статуса заявки на «Terminated» (рассмотрение прекращено, см. Раздел 3.9 Статусы заявок).

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

1. Первый период охватывает промежуток времени с момента получения от кандидата платы за рассмотрение заявки на gTLD и до истечения десяти дней после дня подтверждения строки. В течение этого периода возврату подлежит 65% платы, внесенной за рассмотрение заявки на gTLD.

2. Второй период охватывает промежуток времени от 11 дней после дня подтверждения строки до начала оценок заявки и кандидата, при этом возврату подлежат 35% внесенной платы за рассмотрение заявки на gTLD. Кандидату будет сообщено о предполагаемой дате начала оценки заявки и кандидата. Это уведомление будет отправлено после завершения фазы оценки строки или принятия решения по спорной группе, если применимо.

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

Подробную информацию об этих периодах, а также о том, какие оценки и процессы происходят в эти периоды, см. в Модуле 1 Путь кандидата.

Выплаченный сбор за обусловленную оценку, которая еще не началась, также может быть возвращен, если у заявки статус «Withdrawn», «Will not proceed» или «Terminated».

3.3.3.1.1 Отзыв заявки кандидатом

Кандидат может отозвать заявку в любое время до заключения Базового соглашения об администрировании доменов верхнего уровня с ICANN. Кандидат, решивший отозвать свою заявку, имеет право запросить частичный возврат уплаченных ICANN сборов, как указано ниже. Запрос на возврат должен быть подан в рамках запроса на отзыв заявки. Если кандидат не запросит возврат средств в этот момент, он теряет право сделать это позднее.

3.3.3.1.2 Прекращение рассмотрения заявки

ICANN уведомит кандидата, если его заявка не будет рассматриваться и ей будет присвоен статус «Terminated» (см. Статусы заявок). Получив такое уведомление от ICANN, кандидат может запросить возврат средств в соответствии с периодом возврата и подлежащей возврату доле от платы за рассмотрение заявки на gTLD, как указано ниже. Чтобы иметь право на возврат средств, кандидат должен подать запрос на возврат в течение 90 дней с момента получения уведомления о статусе «Terminated». Кандидаты, не оформившие запрос о возврате средств в течение этого 90-дневного периода, будут считаться отказавшимися от права на запрос возврата средств.

3.3.3.1.3 Возврат средств в результате существенных изменений

Все заявки, отозванные из-за существенных изменений в Руководстве кандидата или процессах Программы, как определено в Приложении 6 Концепция предсказуемости, будут иметь право на возврат средств. В рамках своего решения о внесении любых существенных изменений в Руководство или процессы Программы, Правление ICANN подтвердит право кандидата на возврат средств, а также о подлежащей возврату доле внесенной платы за рассмотрение заявки на gTLD. Кандидат, который отзывает свою заявку в результате этих изменений, должен оформить официальное заявление, сопровождаемое сопроводительными документами, подтверждающими, что в результате изменения: (1) поменялся статус его заявки, или (2) изменился результат оценки заявки, или (3) изменение имело существенное финансовое или операционное влияние на кандидата, или (4) изменение существенно повлияло на сроки обработки и оценки его заявки.³³ Соответственно положениям Раздела 3.3.3.1.1 Отзыв заявки кандидатом, запрос о возврате средств в результате этого изменения должен быть сделан в ходе подачи запроса об отзыве заявки.

3.3.3.1.4 Возврат средств за высокорисковые строки

Кандидат, который решает отозвать свою заявку в течение 90 дней с момента, когда заявленная им строка была определена как имеющая высокий риск доменной коллизии, и который не передал на оценку План по снижению рисков для высокорисковой строки, имеет право на возврат 100% внесенной платы за рассмотрение заявки gTLD. Все заявки на строки, в отношении которых в предыдущем раунде было решено, что они подвержены высокому риску доменных коллизий и/или они не были одобрены в результате такого решения, не будут иметь права на возврат средств (.HOME, .CORP, .MAIL).

3.3.3.1.5 Возврат средств в случае исключения строки из-за процесса подачи заявки на IDN-домен ccTLD

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

3.3.3.2 Возврат средств в случае большого числа заявок

ICANN применила консервативный подход к оценке возмещения своих затрат на реализацию Программы еще до получения первой заявки. Чтобы гарантировать окупаемость усилий по реализации программы, часть платы за рассмотрение заявки на gTLD, относящаяся к предполагаемым расходам на реализацию Программы, была основана на предположении, что поступит 1000 полностью оплаченных заявок. В итоге может быть применима ситуация возврата средств в результате получения большого количества заявок при выполнении двух условий: 1) было получено более 1 000 заявок и, 2) затраты на реализацию раунда 2026 года окупились.

Кандидатам будет предложено указать во время подачи заявки, хотят ли они получить возврат средств в случае получения большого количества заявок, если возникнет такая ситуация.³⁴ Если кандидат не выберет вариант получения возврата за объем, он утратит возможность получить его. После дня объявления результатов ICANN уведомит кандидатов, выбравших вариант возврата средств в случае большого количества заявок, если применимо. Сумма возврата средств в случае получения большого количества заявок будет рассчитана в зависимости от количества полученных заявок и окончательного размера расходов, понесенных в ходе реализации программы. Право на возврат средств в случае получения большого количества заявок в ходе раунда 2026 года будут иметь только кандидаты, оплатившие полную сумму сбора за заявку, а кандидатам, прошедшим отбор по Программе ASP, будет возвращена сумма, пропорциональная оплаченной сумме сбора.

3.3.4 Сборы, обязательные в других случаях

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

• Сборы, связанные с возражениями и апелляциями. См. Раздел 4.5.6 Сборы, связанные с возражениями и апелляциями.

• Аукционы. См. Раздел 5.6 Аукцион новых gTLD ICANN.

• Проверка документов, связанных с запросом на изменение строки брендового TLD. См. Раздел 5.3 Запрос на изменение брендовой строки.

3.3.5 Сборы, взимаемые с действующих регистратур

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

3.3.6 Способы оплаты

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

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

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

За исключением чрезвычайных случаев ICANN планирует опубликовать список всех заявок, прошедших административную проверку, включая соответствующие строки, на которые были поданы заявки, и все вариантные строки и заменяемые строки (если применимо), на сайте Программы New gTLD³⁵ в день объявления результатов, не позднее, чем через 9 недель после завершения периода приема заявок. Также будут опубликованы публичные части каждой заявки, вместе со списком спорных групп, содержащих заявки на одинаковые строки. Некоторые формы взаимодействия и мероприятия будут запрещены после дня объявления результатов для заявок, строки которых занесены в спорные группы. См. Раздел 5.2.3.1 Запрещенные формы взаимодействия и мероприятия.

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

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

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

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

3.7 Порядок обработки заявок и лотерея приоритизации

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

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

К заявкам на IDN-домены применяются особые правила определения приоритетов. См. Раздел 3.7.3 Определение приоритетов заявок на IDN-домены.

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

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

Участие в лотерее не является обязательным. Подробную информацию о том, как определяется приоритет обработки заявок, не участвующих в лотерее, см. в Разделе 3.7.4 Заявки, не включенные в приоритизационную лотерею.

3.7.2 Участие в лотерее

Ожидается, что приоритизационная лотерея состоится не позднее, чем через 30 дней после дня подтверждения строки. Билеты на участие в лотерее будут стоить 100 долларов США и должны быть приобретены лично; покупка через интернет невозможна. Для участия в лотерее кандидат, через назначенного представителя или доверенное лицо, должен лично приобрести билет на каждую заявку, которую кандидат хочет включить в рассмотрение в приоритетном порядке.

Кандидаты не смогут присутствовать в лотерее лично, но смогут следить за ходом мероприятия виртуально.

ICANN планирует объявить полную информацию о лотерее не менее, чем за 30 дней до дня ее проведения.

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

3.7.3 Приоритизация заявок на IDN-домены

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

1. Заявки на IDN-домены для подлежащих распределению вариантных строк IDN-доменов gTLD 2012 года.

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

2. После того, как получат приоритетные номера все заявки на вариантные строки IDN-доменов gTLD 2012 года, и если останется менее 125 заявок на IDN-домены, решивших принять участие в лотерее:

   • Все заявки на IDN-домены будут разыграны в первую очередь, и им будут присвоены номера приоритета до заявок на иные домены, кроме IDN.

3. Однако, если останется 125 или более заявок на IDN-домены, решивших принять участие в лотерее:

   • 25% (125) из первой группы 500 заявок будут заявками на IDN-домены, выбранные случайным образом в ходе приоритизационной лотереи. Эти отобранные заявки на IDN-домены будут рассматриваться в первую очередь и им будут присвоены номера приоритета.

   • Оставшиеся 75% (375) заявок в первой группе на получение номеров приоритета будут включать как заявки на IDN-доменов, так и заявки на не IDN-домены. Они будут случайным образом выбраны из оставшегося пула заявок, участвующих в лотерее, и будут отобраны и распределены по приоритетам случайным образом.

4. Для каждой последующей группы из 500 заявок, решивших принять участие в лотерее:

   • Первые 10% каждой группы будут состоять из заявок на IDN-домены, выбранных случайным образом, отобранных в первую очередь и распределенных по приоритетам, и так до тех пор, пока не останется ни одной заявки на получение IDN-домена.

   • Оставшиеся заявки в каждой группе будут выбраны случайным образом из пула оставшихся заявок на IDN-домены и не IDN-домены, отобраны и распределены по приоритетам случайным образом.

3.7.4 Заявки, не включенные в приоритизационную лотерею

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

В каждой группе из 500 заявок первые 10% должны состоять из заявок на IDN-домены до тех пор, пока не останется больше заявок для отбора. Оставшиеся заявки в каждой группе будут выбраны случайным образом и распределены по приоритетам из пула оставшихся заявок на IDN-домены и не-IDN-домены.

3.7.5 Исключения из правил относительно порядка обработки заявок по номеру приоритета

ICANN будет стремиться сохранять приоритетный порядок рассмотрения заявок на каждом этапе. Однако, порядок может зависеть от операционных возможностей и других вопросов, связанных с заявками, в том числе: возражений, рекомендаций GAC, расширенного рассмотрения, спорных групп, действующих механизмов подотчетности ICANN или случае приостановки обработки из-за запросов на внесение изменений в заявку. Текущая обработка, вероятно, будет приостановлена до завершения этих процессов. Чтобы избежать задержек и обеспечить непрерывный процесс рассмотрения других заявок, ICANN перейдет к рассмотрению следующей по порядку приоритета заявки. Как только ICANN определит, что проблемы, из-за которых было приостановлено рассмотрение заявки, устранены, она возобновит обработку в соответствии с назначенным номером приоритета.

3.8 Запросы на внесение изменений в заявку

В этом разделе описывается процедура обновления неточной или устаревшей информации в своей заявке, а также внесения других изменений по мере необходимости. Запросы на внесение изменений в заявку (ACR) рассматриваются ICANN на основе критериев вынесения решения по запросу на внесение изменений (см. Раздел 3.8.2 Критерии решения по запросу на внесение изменений) и подлежат одобрению ICANN.

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

3.8.1 Рассмотрение запросов на внесение изменений в заявку

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

Если в ходе действия программы, на любом ее этапе, информация, указанная в качестве ответа на вопросы заявки (Приложение 1) или данные об организации становятся неверными, недостоверными или устаревают после заключения, например, соглашения между ICANN и кандидатом по итогам какой-либо из оценок,³⁷ кандидату следует своевременно оформить ACR (и в любом случае в течение семи дней после осознания любого факта или обстоятельства, которое привело к возникновению этого обязательства). ICANN оставляет за собой право потребовать повторного рассмотрения заявки в случае внесения существенных изменений,³⁸ что может повлечь за собой дополнительные расходы. Неуведомление ICANN о любых изменениях обстоятельств, которые могут сделать любую предоставленную в заявке информацию ложной или вводящей в заблуждение, может привести к отказу в рассмотрении заявки.

Кандидат может попросить внести изменения в разные аспекты своей заявки, как описано в Разделе 3.8.3 Типы запросов на внесение изменений в заявку и необходимые процессы. При этом кандидат не имеет право изменить строку, на которую подается заявка, за исключением случаев, в которых заявка кандидата была отнесена к категории брендовых TLD (см. Раздел 7.3 Оценка соответствия брендовых TLD требованиям) и помещена в спорную группу. Запросы на внесение изменений в брендовую строку выполняются по процедуре, описанной в Разделе 5.3 Запрос на изменение брендовой строки.³⁹

Оформление некоторых запросов ACR может потребовать повторного рассмотрения или других процессов, как описано в Разделе 3.8.3 Типы запросов на внесение изменений в заявку и необходимые процессы, что может повлечь за собой дополнительные расходы для кандидата. Подробнее о сборах и платежах см. в Модуле 6 Оценка кандидата, Модуле 7 Оценка строки и заявки и Разделе 3.3 Сборы и платежи.

Запросы ACR от кандидатов, получающих поддержку ASP, также будут рассматриваться с учетом права кандидата на получение дальнейшей финансовой поддержки через Программу поддержки кандидатов. См. Условия и положения Программы поддержки кандидатов для получения подробной информации.⁴⁰

3.8.2 Критерии решения по запросу на внесение изменений

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

1. Исправление ошибок, возникших при подаче заявки: этот критерий применяется, когда кандидат просит внести изменения, чтобы исправить ошибку. Кандидат должен предоставить достаточно информации для обоснования своего запроса. Такие запросы редки, но в случае их подачи этот критерий имеет значительный вес.

Имеются ли доказательства, подтверждающие утверждение или заявление о том, что изменение запрашивается с единственной целью исправления ошибки?

2. Объяснение: Данный критерий требует, чтобы кандидат дал объяснение запрашиваемых изменений. Если объяснения не предоставлены, кандидату будет дана возможность устранить недостатки.

Предоставлено ли разумное объяснение?

3. Причина изменения:

Запрашивается ли изменение в ответ на комментарии третьих лиц, например комментарии к заявке, возражения, консенсусные рекомендации GAC или заблаговременное предупреждение со стороны членов GAC? Отражает ли запрашиваемое изменение организационные изменения (например, изменение названия организации или почтового адреса)?

4. Прецеденты: ICANN оценивает, создаст ли одобрение запроса на изменение новый прецедент или оно соответствует ранее одобренным аналогичным запросам. На данном этапе Программы New gTLD запросы, которые могли бы создать новый прецедент, вряд ли будут одобрены.

Схоже ли рассматриваемое изменение с другими, ранее одобренными изменениями? Может ли данное изменение побудить других подать запросы на внесение аналогичных изменений, которые могут повлиять на третьих лиц или привести к нежелательным последствиям для Программы?

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

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

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

Повлияет ли изменение на результаты оценки, оспаривание строк или может ли оно привести к возражениям?

7. Время поступления запроса: Этот критерий позволяет определить, влияет ли время поступления запроса на критерии с 4 по 6, указанные выше. Если будет установлено, что время подачи запроса оказывает влияние на эти критерии, ему будет придан больший вес.

Не мешает ли время подачи запроса процессу рассмотрения заявки каким-либо образом?

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

3.8.3 Типы запросов на внесение изменений в заявку и необходимые процессы

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

За исключением того, что указано в таблице, соответствующие оценки, такие как Процедуры оценки строки и заявки (Модуль 7) и Процедуры оценки кандидата (Модуль 6), будут выполнены повторно с учетом конкретных разделов, затронутых запросом ACR; это решение будет приниматься в каждом конкретном случае.

Следует отметить, что одобрение изменений в заявке может зависеть от конкретных фактов и обстоятельств, связанных с запросом ACR и заявкой, в том числе относительно кандидата и строки. Если одобрение запроса ACR приведет к необходимости провести повторное рассмотрение, может взиматься дополнительный сбор.

Таблица 3-3. Типы запросов на внесение изменений в заявку и необходимые процессы

3.8.4 Рабочие процессы запроса на внесение изменений в заявку

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

• Запросы на внесение изменений в заявку: Рабочий процесс 1: запросы ACR, касающиеся всех областей, за исключением правил регистрации сообщества и добровольных обязательств регистратур, рассматриваются в рамках рабочего процесса 1. См. Раздел 3.8.4.1.

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

Каждый рабочий процесс адаптирован для удовлетворения конкретных требований и соображений, связанных с соответствующими типами запросов ACR. См. Раздел 3.8.4.2.

3.8.4.1 Запросы на внесение изменений в заявку. Рабочий процесс 1

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

1. Подача: кандидат подает ACR.

2. Административная проверка: ICANN решает, принимается ли в принципе этот тип ACR на рассмотрение, как указано в таблице в Разделе 3.8.3 Типы запросов на внесение изменений в заявку и необходимые процессы. Если изменение не допускается, ICANN сообщает кандидату, что запрос ACR отклонен.

3. Оценка ICANN: ICANN изучает материалы запроса на изменение, руководствуясь семью критериями, указанными выше. В случае необходимости ICANN запрашивает дополнительную информацию у кандидата.

4. Вынесение заключения: После завершения проверки ICANN оповещает кандидата о своем решении следующими способами:

   1. Если запрос ACR не удовлетворяется, кандидат будет оповещен.

   2. Если запрос ACR удовлетворяется, предлагаемые изменения будут опубликованы на сайте Программы New gTLD, заявка уточняется, кандидат оповещается. Кроме того, кандидат будет оповещен об одном из следующих результатов:

      1. Общественное обсуждение или повторная оценка не требуются (процесс заканчивается здесь).

      2. Необходимо провести общественное обсуждение (см. шаг 5).

      3. Необходимо провести общественное обсуждение и выполнить повторную оценку (см. шаги 5 и 6).

5. Общественное обсуждение: при необходимости провести общественное обсуждение ACR публикуется для проведения 30-дневного обсуждения. Это время даст сообществу возможность ознакомиться с изменениями и отправить комментарии по измененной части заявки.

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

Рисунок 3-1. Запросы на внесение изменений в заявку. Рабочий процесс 1

3.8.4.2 Запросы на внесение изменений в заявку. Рабочий процесс 2

Запросы ACR, касающиеся правил регистрации сообщества и добровольных обязательств регистратур (RVC), будут следовать описанной ниже процедуре.

1. Подача: кандидат подает ACR.

2. Административная проверка: Прежде всего ICANN решает, принимается ли в принципе этот тип ACR на рассмотрение, согласно таблице в Разделе 3.8.3 Типы запросов на внесение изменений в заявку и необходимые процессы. Если изменение не допускается, ICANN сообщает кандидату, что запрос ACR отклонен.

3. Оценка ICANN: ICANN изучает материалы запроса на изменение, руководствуясь семью критериями, указанными выше. В случае необходимости ICANN запрашивает дополнительную информацию у кандидата.

4. Вынесение заключения: ICANN определяет, является ли изменение существенным и предпринимает следующие шаги:

   1. Если изменения не существенные, предлагаемые изменения публикуются на сайте Программы New gTLD, заявка уточняется, кандидат оповещается (на этом процесс завершается).

   2. Если изменения существенные, см. шаг 5.

5. Оценка обязательств регистратуры (RCE): Существенные изменения требуют проведения RCE.

6. Вынесение заключения: выполнив RCE, ICANN вынесет решение относительно запрашиваемого изменения. По итогам вынесения решения возможен один из следующих вариантов:

   1. Если запрашиваемое изменение прошло проверку RCE, перейти к шагу 7.

   2. Если запрашиваемое изменение не прошло проверку RCE, заявка не будет обновлена в соответствии с запросом через ACR и будет рассмотрена без запрошенного изменения.

   3. Если запрашиваемое изменение не прошло проверку RCE или изменение было запрошено в результате рекомендации GAC или решения эксперта в контексте поступившего возражения, и было установлено, что заявка не может рассматриваться без изменения, дальнейшее рассмотрение заявки невозможно. Подробную информацию об этом типе RV см. в Разделе 7.8.3.4 Добавление, изменение и исключение RVC.

7. Публикация: Все представленные RVC или правила регистрации сообщества будут опубликованы вместе с соответствующим решением ICANN после RCE. Если представленные RVC или правила регистрации сообщества претерпят какие-либо изменения в результате переговоров между кандидатом и ICANN с целью их дальнейшего утверждения ICANN, то утвержденные RVC или правила регистрации сообщества будут опубликованы вместе с первоначальной версией, представленной кандидатом.

8. Общественное обсуждение: будет запущено 30-дневное общественное обсуждение. ICANN оставляет за собой право возобновить переговоры или обсудить с кандидатом комментарии, высказанные в течение этого периода.

Рисунок 3-2. Запросы на внесение изменений в заявку. Рабочий процесс 2

3.9 Статусы заявок

Заявка будет иметь один из следующих статусов:

• Active (активный): Заявка находится на рассмотрении в рамках Программы New gTLD.

• On hold (рассмотрение приостановлено): Рассмотрение заявки приостановлено в ожидании проведения мероприятий, которые могут повлиять на ход ее рассмотрения, например, в рамках механизмов подотчетности или выдвижения возражений.

• Withdrawn (отозвана): Заявка добровольно отозвана кандидатом. Это действие необратимо.

• Pending Termination (в процессе прекращения рассмотрения): Заявка не соответствует критериям, изложенным в Руководстве кандидата, и ее дальнейшее участие в Программе невозможно. Ожидается, что кандидат отзовет свою заявку в течение 60 дней, в противном случае ICANN может изменить статус заявки на «Terminated».

• Terminated (рассмотрение прекращено): Рассмотрение заявки по Программе продолжаться не будет, кандидат воспользовался всеми доступными механизмами апелляции и оспаривания.⁴⁸

• Deactivated (неактивная): Этот статус присваивается всем заявкам, которые кандидат решил не продолжать оформлять после периода замены строки. Такие заявки больше не являются активными по программе и не будут переведены на стадию оценки или делегирования.

• Contracted (заключено соглашение): Статус «Contracted» присваивается после полного подписания Соглашения об администрировании домена верхнего уровня. После этого кандидат становится оператором регистратуры для запрашиваемой строки.

• Delegated (делегирован): Домен верхнего уровня добавлен в корневую зону DNS.