Модуль 2 Общая информация

ICANN осознает сложность Программы New gTLD: раунд 2026 и подготовила разъяснения, которые помогут кандидатам в случае появления вопросов. Этот модуль дает прямой доступ к самой важной информации и ссылкам на дополнительные ресурсы, позволяя кандидатам и заинтересованным сторонам лучше разобраться в Программе.

В Модуле 2 представлен общий обзор ключевых тем, среди них:

• информация о языках и сопроводительных документов;

• универсальное принятие;

• безопасность и стабильность;

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

Для кандидатов этот модуль должен стать основным справочным материалом по вопросам общего характера.

2.1 Ресурсы и помощь

Существует ряд ресурсов с ответами на вопросы о Программе New gTLD: раунд 2026 года и о процессе подачи заявок, как описано ниже.

2.1.1 Часто задаваемые вопросы

ICANN создала корпус часто задаваемых вопросов (FAQ), который должен стать ценным ресурсом для кандидатов. Доступ к FAQ можно получить на странице «Часто задаваемые вопросы» на сайте Программы New gTLD.¹

2.1.2 Поддержка по общим вопросам

С общими вопросами о Программе New gTLD: раунд 2026 года обращайтесь в Глобальную службу поддержки ICANN² или пишите на почту globalsupport@icann.org.

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

2.1.3 Вопросы, связанные с системой и конкретными заявками

Из соображений защищенности и обеспечения конфиденциальности данных кандидатов, кандидат с вопросами об их заявках следует направить запрос через TAMS. Для подачи заявки в TAMS, нажмите на ссылку «Моя организация» (View My Organization) в левой части главной страницы. Это приведет вас на страницу «Сводная информация об организации» (Organization Summary), где можно нажать кнопку «Создать запрос» (Create Inquiry) в правом верхнем углу

Чтобы узнать, как создать запрос, и получить другую полезную информацию о системе, ознакомьтесь с Руководством пользователя TAMS на сайте Программы New gTLD.³

Как уже отмечалось в Разделе 2.1.2, с общими вопросами о Программе New gTLD надо обращаться в Глобальную службу поддержки ICANN. (globalsupport@icann.org).

2.2 Языки и сопроводительные документы

2.2.1 Руководство кандидата и материалы

Руководство кандидата будет доступно на языках ICANN: английский, арабский, испанский, китайский, русский и французский.⁴ Переведенные версии можно найти на главной странице Руководства кандидата.⁵ Официальной считается английская версия Руководства для кандидатов и других документов.

2.2.2 Язык заявок на новые gTLD

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

2.2.3 Сопроводительные документы, необходимые для заявок на новые gTLD

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

1. оригиналы документов;

2. переводы на английский язык для каждого документа;

3. удостоверение точности перевода каждого документа.

Удостоверение перевода должно быть составлено на английском языке и включать следующее:

1. Указание квалификации.

2. Заявление переводчика, подтверждающее полноту и точность перевода;

3. Идентификатор исходного документа и языка.

4. Имя, подпись переводчика и дату.

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

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

2.3 Универсальное принятие доменных имен и адресов электронной почты

Универсальное принятие (UA) — это важнейшая концепция, обеспечивающая принятие всеми приложениями, устройствами и системами, подключенными к интернету, всех доменных имен и адресов электронной почты, вне зависимости от набора символов, языка или длины TLD. Такой подход позволяет пользователям интернета перемещаться по сети и общаться в интернете, используя доменные имена и адреса электронной почты, отражающие их культурные и языковые предпочтения.

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

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

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

Для получения более подробной информации кандидатам следует ознакомиться с сайтом⁷, посвященным универсальному принятию . Кандидатам на интернационализированные доменные имена рекомендуется ознакомиться с материалами об опыте использования тестовых строк IDN-доменов в корневой зоне.⁸

2.3.2 Более подробная информация об универсальном принятии

ICANN и сообщество продолжают развивать готовность к обеспечению UA во всей экосистеме интернета. Подробная свежая информацию об универсальном принятии публикуется на сайте, посвященном универсальному принятию; там же можно ознакомиться с последним ежегодным отчетом о готовности к обеспечению универсального принятия. В отчете содержится информация о том, как реализуется UA в разных языках программирования, инструментах и службах электронной почты, сетевых утилитах, приложениях для социальных сетей, системах управления контентом, инструментах аутентификации и других технологических решениях. В этом отчете также приводится информация о возможностях сообщать об ошибках, а также о предпринимаемых усилиях по их исправлению. Отчеты об UA, а также технические учебные материалы и руководства по обеспечению готовности систем к UA можно найти на сайте, посвященном универсальному принятию. Положение относительно реализуемости выполнимости строк включено в Раздел 1.2 базового Соглашения об администрировании домена верхнего уровня (Приложение 4).

2.4 Право кандидатов на свободу выражения мнений

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

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

2.5 Безопасность и стабильность

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

Заявки будут рассматриваться в соответствии с порядком приоритетности. Процесс делегирования нового gTLD в корневую зону начинается тогда, когда оператор регистратуры подает запрос на делегирование после создания нового gTLD.¹⁰ В отсутствие чрезвычайных обстоятельств запросы на делегирование будут обрабатываться в порядке очереди до достижения предельных параметров изменений в корневой зоне. Однако запросы на делегирование других типов TLD¹¹ будут иметь приоритет над запросами на делегирование новых gTLD.

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

2.6 Соблюдение юридических обязательств

Кандидат признает, что ICANN обязана выполнять положения всех применимых законов, включая законы, правила и нормы США. Одним из таких нормативных актов является Программа экономических и торговых санкций в ведении Управления по контролю за иностранными активами (OFAC) при Министерстве финансов США.¹² Санкции налагаются на некоторые страны, а также на физических и юридических лиц, включенных в Список граждан особых категорий и запрещенных лиц OFAC («Список SDN»). Корпорации ICANN запрещено предоставлять большинство товаров и услуг жителям стран, находящихся под санкциями, их государственным структурам или SDN без соответствующего разрешения или освобождения от выполнения этого требования со стороны правительства США. ICANN, как правило, не занимается оформлением лицензии на предоставление товаров или услуг физическим или юридическим лицам из списка SDN. В прошлом, когда в ICANN приходили запросы на предоставление услуг физическим или юридическим лицам, которые не состоят в списке SDN, но проживают в подсанкционных странах, ICANN обращалась за лицензиями и получала их в установленном порядке. Кандидат признает, что ICANN не обязана запрашивать эти лицензии, и в любом случае, OFAC может отказать в выдаче лицензии.

2.7 Механизмы подотчетности

ICANN обязуется выполнять обязательства в отношении подотчетности и транспарентности во всей своей работе. ICANN считает эти принципы основополагающими мерами обеспечения дальнейшей эффективности работы своей модели по принципу «снизу-вверх» с участием многих заинтересованных сторон. Механизмы, которыми ICANN обеспечивает подотчетность и транспарентность, являются неотъемлемой частью организации на всех уровнях; они также отражены в ее мандате, начиная с Устава,¹³ подробно описаны в документе «Концепции и принципы подотчетности и транспарентности» ¹⁴ (утвержденном Правлением ICANN в 2008 году) и ежегодно подкрепляются в ее Стратегическом и операционном плане.¹⁵ Для повышения транспарентности и подотчетности ICANN создала механизмы подотчетности для проверки деятельности ICANN. См. Механизмы подотчетности¹⁶ ICANN для получения дополнительной информации.

2.8 Последующие раунды приема заявок

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

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

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

1. Подтверждение списка запрашиваемых строк во время текущего раунда и закрытие окна для запросов на изменение строк. Это даст кандидатам в последующем раунде понимание того, на какие строки можно подавать заявки.

2. ICANN не столкнется со значительными сложностями при получении новых заявок и их обработке.

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

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

2.9 Календарные дни и сроки

Если не указано иное, отсчет периода для всех процессов, упомянутых в Руководстве кандидата, будет вестись в календарных днях и начнется в 00:01 по UTC в день после объявления о начале процесса. Если не указано иное, все сроки будут указываться по универсальному координированному времени (UTC).

2.10 Основные обязательства операторов регистратур перед регистраторами

Этот раздел посвящен обязательствам операторов регистратур, связанных с их взаимодействием с регистраторами. Описание всех обязательств операторов регистратур см. в Приложении 4 Базовое Соглашение об администрировании домена верхнего уровня.

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

Оператор регистратуры должен использовать единое соглашение со всеми регистраторами, уполномоченными регистрировать имена. В Соглашении между регистратурой и регистратором (RRA) должны содержаться все требования к регистраторам. RRA должно содержать определенные условия, указанные в базовом Соглашении об администрировании домена верхнего уровня, и может включать дополнительные условия для конкретного gTLD. Оператор регистратуры должен заблаговременно уведомлять всех регистраторов об изменениях цен в соответствии со сроками, указанными в соглашении. См. Разделы 2.9 и 2.10 базового Соглашения об администрировании домена верхнего уровня.

Все операторы регистратур обязаны соблюдать Кодекс поведения оператора регистратуры, за исключением случаев удовлетворения ICANN запроса о несоблюдении со стороны правомочного оператора регистратуры.¹⁷ Кодекс поведения оператора регистратуры требует, чтобы оператор регистратуры предоставлял недискриминационный доступ к услугам регистратуры всем регистраторам, аккредитованным ICANN, которые заключили и соблюдают RRA для TLD. См. Спецификацию 9, Раздел 1(а) базового Соглашения об администрировании домена верхнего уровня.

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

Оператор регистратуры должен понимать, что регистратор, аккредитованный ICANN, не обязан поддерживать тот или иной gTLD и предлагать его своим клиентам в своих продуктах. Хотя регистраторам рекомендуется следить за обновлениями Программы New gTLD, чтобы знать о делегированных gTLD, решение о заключении RRA с каждым оператором регистратуры остается на усмотрение регистраторов.

ICANN продолжит оказывать поддержку операторам регистратур gTLD при запуске и поддержании работы регистратур. В ICANN есть контактное лицо для операторов регистратур gTLD для оказания помощи на постоянной основе. Операторам регистратур также рекомендуется ознакомиться с сайтом для операторов регистратур¹⁸ и разделом, связанным с этапом, который наступает после заключения соглашения на сайте Программы New gTLD¹⁹ получения дополнительной информации.

Отдел по контролю исполнения договорных обязательств (отдел комплаенс) ICANN проводит регулярные аудиты для обеспечения соблюдения операторами регистратур gTLD своих договорных обязательств и расследует любые случаи несоблюдения. Дополнительную информацию о текущей деятельности по обеспечению соблюдения договорных обязательств см. на сайте отдела комплаенс²⁰.

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