Модуль 7 Процедуры оценки строк и заявок

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

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

В модуле 7 описывается процесс оценки, в том числе:

Обзор типов заявок и методов их обработки.
Рассмотрение типов TLD, таких как географические наименования и интернационализированные доменные имена.
Стратегии смягчения последствий доменных коллизий.
Оценка схожести строк.

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

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

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

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

Кандидаты должны ознакомиться с информацией в этом разделе, чтобы понять какие требования применяются к разным типам заявок.²

7.1.1 Обычные заявки

Обычная заявка — это заявка, которая не относится ни к одному из типов, определенных в Разделе 7.1.2 Специализированные заявки, и подпадает под стандартный набор требований, определенных в настоящем Руководстве кандидата.

7.1.2 Специализированные заявки

Специализированные заявки — это заявки, к которым могут предъявляться разные требования в зависимости от типа заявки (например, заявка на gTLD сообщества), строки (например, IDN-домен) или кандидата (например, МПО или участников Программы поддержки кандидатов). В этом разделе представлен обзор этих специализированных типов заявок. Заявка может одновременно претендовать на несколько классификаций: например, заявка может быть классифицирована и как заявка на IDN-домен, и как заявка от сообщества.

7.1.2.1 Заявки на gTLD сообщества

Во время подачи заявки кандидат может обозначить запрашиваемую строку gTLD как gTLD сообщества.³ Такой кандидат должен эксплуатировать строку в интересах четко определенного сообщества (см. Раздел 5.4 Оценка приоритетности заявок от сообществ). К кандидатам, подающим заявку от сообщества, будут предъявляться дополнительные требования на разных этапах жизненного цикла заявки, включая следующие:

Вопросы заявки: Кандидатов, обозначающих свою заявку, как заявку от сообщества, попросят ответить на ряд вопросов, относящихся конкретно к заявкам от сообщества.⁴ Ответы на эти вопросы будут проанализированы, если кандидат решит принять участие в CPE. См. Приложение 1 Вопросы заявки (группа вопросов 7 gTLD сообщества).
Оценка: оценка правил регистрации сообщества в Соглашении об администрировании домена верхнего уровня («Правила регистрации сообщества») посредством оценки обязательств регистратуры (RCE), предложенных на предмет включения в Соглашение об администрировании домена верхнего уровня в отношении запрошенного gTLD сообщества, будет проводиться во время оценки заявки при условии, что кандидат от сообщества не решит участвовать в CPE. Такой вариант доступен только для заявок от сообщества в целях урегулирования споров. Если кандидат решит участвовать в CPE, RCE будет проведена раньше, до оценки заявки, поскольку эта оценка должна быть проведена до того, как заявка получит право на участие в CPE. См. Раздел 7.8 Обязательства по обеспечению общественных интересов, добровольные обязательства регистратур и правила регистрации сообщества.
Спор: если заявка конкурирует с другими заявками на одну и ту же строку, то кандидат может принять участие в оценке приоритетности заявок от сообществ (см. Раздел 5.4) и, возможно, в аукционе ICANN. См. Раздел 5.2. Споры в отношении строк и процедуры их разрешения.
Заключение соглашения: кандидат должен перечислить в Спецификации 12 своего базового Соглашения об администрировании домена верхнего уровня правила регистрации сообщества, которые оцениваются и утверждаются ICANN и, при необходимости, оцениваются в ходе CPE. См. Раздел 1.2.15 Заключение соглашения. См. также Раздел 7.8.4 Правила регистрации сообщества ниже, касающийся оценки правил регистрации сообщества.
Сборы: если кандидат решит участвовать в CPE, он должен будет внести дополнительную плату за рассмотрение заявки. См. Раздел 3.3 Сборы и платежи.

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

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

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

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

Также будет взиматься плата за оценку обязательств регистратур (RCE) в Спецификации 12 (см. Раздел 3.3 Сборы и платежи).

7.1.2.2 Заявки на географические наименования

Кандидат имеет право обозначить свою заявку как заявку на географическое наименование.⁷ Кандидат должен сам определить, попадает ли запрашиваемая строка gTLD в какую-либо из существующих категорий географических наименований (см. Раздел 7.5 Географические наименования), проконсультироваться с соответствующими правительствами или государственными органами и определить уровень необходимой государственной поддержки.

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

Вопросы заявки: кандидату будут заданы дополнительные вопросы относительно географического наименования, на которое подана заявка. См. Приложение 1 Вопросы заявки.
Оценка: кандидат на географическое наименование должен представить подтверждающие документы или документ об отсутствии возражений от соответствующей государственной структуры. Совет по географическим наименованиям (GNP) определит, является ли запрошенная строка географическим наименованием, и при необходимости проверит актуальность и подлинность подтверждающих документов. См. Раздел 7.5.3.2 Проверка географических наименований.
Сборы: за проверку географических наименований (Раздел 7.5.3.2) взимается обусловленная плата. См. Раздел 3.3 Сборы и платежи.

7.1.2.3 Заявки на зарезервированные имена

Все запрашиваемые строки gTLD сравниваются со списками зарезервированных и заблокированных имен. Хотя подача заявок на заблокированные имена запрещена, правомочные организации могут подать заявку на зарезервированное имя, как определено в Разделе 7.2 Заблокированные и зарезервированные имена.⁸ Чтобы подать заявку на такое имя, кандидат должен следовать определенной процедуре, как описано в Разделе 7.2.2.2.1 Процедура исключения для подачи заявки на зарезервированное имя. Кандидаты, подающие заявки на зарезервированное имя, могут столкнуться с отличными от обычных требованиями на следующих этапах жизненного цикла заявки:

Вопросы заявки: кандидату необходимо будет ответить на дополнительные вопросы относительно зарезервированного имени, на которое он подает заявку. См. Приложение 1 Вопросы заявки.
Оценка: кандидат на зарезервированное имя должен предоставить документы, включая свидетельство о регистрации и письмо от материнского предприятия, а также документы о поддержке или отсутствии возражений, которая может включать подписанное письмо, в случае необходимости. См. Раздел 7.2.2 Зарезервированные имена.

7.1.2.4 Заявки на брендовые TLD

Кандидат может самостоятельно обозначить свою заявку как заявку на брендовый TLD. Этот тип заявки позволяет кандидату использовать название своей компании или бренда в качестве TLD.⁹ Брендовый TLD — это строка, которая тождественна текстовым элементам (например имени, слову или фразе) зарегистрированного в соответствии с применимым законодательством¹⁰ товарного знака, и которую кандидат использует в качестве брендового TLD.¹¹ Кандидатам, подающим заявки на брендовые TLD, следует быть готовым к выполнению отличных от обычных требований на следующих этапах жизненного цикла заявки:

Вопросы заявки: кандидату будут заданы дополнительные вопросы относительно обозначенной как брендовый TLD заявки (например, его бренд/товарный знак). См. Приложение 1 Вопросы заявки.
Оценка: заявка на брендовый TLD будет рассмотрена на предмет соответствия требованиям для получения статуса брендового TLD.¹² См. Раздел 7.3 Оценка соответствия критериям определения брендового TLD.
Спор: если заявка конкурирует с другими заявками на одну и ту же строку, кандидат на брендовый TLD, для урегулирования спора, может иметь возможность подать запрос на изменение запрашиваемой строки. См. Раздел 5.2 Споры в отношении строк и процедуры их урегулирования.¹³
Заключение соглашения: в случае соответствия требованиям, Спецификация 13 будет включена в базовое Соглашение об администрировании домена верхнего уровня на исполнение.¹⁴ См. Раздел 1.2.15 Заключение соглашения.
Сборы: за оценку брендового TLD на предмет соответствия требованиям взимается обусловленная плата. См. Раздел 3.3 Сборы и платежи.

Если кандидат на брендовый TLD соответствует требованиям, которые предъявляются к брендовым TLD, Спецификация 13 будет включена в применимое Соглашение об администрировании домена верхнего уровня, а также кандидат получит освобождение от необходимости соблюдать Кодекс поведения (CoC). Однако в некоторых случаях кандидат на брендовый TLD может получить освобождение от необходимости соблюдать Кодекс поведения, но не отвечать требованиям Спецификации 13.

7.1.2.5 Заявки на интернационализированные доменные имена

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

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

7.1.2.6 Заявки на варианты уже существующих доменов верхнего уровня

Операторы действующих регистратур могут подать заявку на подлежащие распределению вариантные строки существующих доменов верхнего уровня.¹⁵ Заявки на эти вариантные строки должны соответствовать требованиям, определенным в Разделе 3.1.9 Интернационализированные доменные имена, и кандидатам следует быть готовым к выполнению отличных от обычных требований на следующих этапах жизненного цикла заявки:

Вопросы заявки: кандидату будут заданы дополнительные вопросы относительно вариантной строки, на которую он подает заявку. См. Приложение 1 Вопросы заявки.
Приоритизация: в соответствии с ограничениями и требованиями, указанными в Разделе 3.7 Порядок обработки заявок и приоритизационная лотерея, заявки на подлежащие распределению вариантные строки могут иметь приоритет над заявками не на IDN-домены.
Оценка: кандидат на подлежащий распределению вариант существующего домена верхнего уровня должен предоставить в комиссию обоснование потребности в вариантной строке (например, объяснение того, как первичная и вариантная строки считаются одинаковыми).¹⁶ Дополнительные требования могут включать использование одного и того же RSP для регистратуры варианта и для основной регистратуры. См. Приложение 1 Вопросы заявки и Раздел 7.10 Оценка схожести строк.
Заключение соглашения: Спецификация 14 будет добавлена в базовое Соглашение об администрировании домена верхнего уровня на подписание. См. Раздел 1.2.15 Заключение соглашения.
Сборы: Операторы существующие регистратур, подающие заявки на подлежащие распределению вариантные строки существующих доменов верхнего уровня, будут освобождены от базовой платы за подачу заявки на вариантные строки (до четырех строк);¹⁷ за заявки на вариантные строки в количестве более четырех будут взиматься дополнительные сборы. См. Раздел 3.3 Сборы и платежи.¹⁸

7.1.2.7 Заявки на новые IDN-домены (включая один или несколько вариантов)

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

Вопросы заявки: кандидату будут заданы дополнительные вопросы относительно IDN-домена и его подлежащих распределению вариантных строк, на которые он претендует. См. Приложение 1 Вопросы заявки.
Приоритизация: В соответствии с ограничениями и требованиями, указанными в Разделе 3.7 Порядок обработки заявок и приоритизационная лотерея, заявки на IDN-домены, включая подлежащие распределению вариантные строки, могут получить приоритет в обработке по сравнению с заявками не на IDN-домены.
Оценка: кандидат на новый IDN TLD и его вариантные строки должен в своей заявке представить на рассмотрение комиссии обоснование потребности в вариантной строке (например, объяснить, почему первичная и вариантная строки можно считать одинаковыми).¹⁹ Могут применяться дополнительные требования, такие как использование одного и того же RSP для регистратуры варианта и для регистратуры первичной строки, а также обеспечение согласованности типов TLD в первичной и вариантных строках. См. Раздел 7.10 Оценка схожести строк.
Заключение соглашения: Спецификация 14 будет добавлена в базовое Соглашение об администрировании домена верхнего уровня на подписание. См. Раздел 1.2.15 Заключение соглашения.
Сборы: с новых кандидатов, подающих заявку на первичную строку и ее варианты, не взимается дополнительная плата за подачу заявки сверх базового сбора, если вариантных строк не более четырех. Однако за заявки на первичную строку плюс более четырех вариантных строк взимается дополнительная плата. См. Раздел 3.3 Сборы и платежи.²⁰

7.1.2.8 Заявки от межправительственных организаций или государственных структур

Принимаются заявки от межправительственных организаций (МПО)²¹ и государственных структур²². Кандидаты в этой категории должны учитывать требования к географическим наименованиям, определенные в Разделе 7.5 Географические наименования, а также требования к зарезервированным именам, указанные в Разделе 7.2 Заблокированные и зарезервированные имена. Таким кандидатам следует быть готовым к выполнению отличных от обычных требований на следующих этапах жизненного цикла заявки:

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

7.1.2.9 Заявки для кандидатов, имеющих право на поддержку

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

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

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

7.1.3 Изменение классификации заявки

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

7.2 Обзорная информация по заблокированным и зарезервированным именам

Некоторые имена заблокированы и поэтому недоступны для использования в качестве строк gTLD. Список заблокированных имен формируется на основе ряда источников и входных данных, как описано ниже. Некоторые имена зарезервированы на верхнем уровне на основании консенсусной политики и внесены в список ICANN.²⁴

Примечание: список под названием «Строки, не подлежащие делегированию» в Руководстве кандидата 2012 года теперь называется Список зарезервированных имен, а список, ранее называвшийся «Список зарезервированных имен верхнего уровня», теперь называется Список заблокированных имен.

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

Кроме того, заблокированные и зарезервированные имена, которые не соответствуют концепции допустимых символов DNS, будут преобразованы в метки DNS, содержащие только буквы, цифры и дефисы в соответствии с консенсусной политикой.²⁵

7.2.1 Заблокированные имена

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

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

Доменные имена специального назначения: это особые строки, зарезервированные согласно техническим стандартам для целей, несовместимых с делегированием, как явно указано в Реестре доменных имен специального назначения IANA.²⁶^,²⁷^,²⁸
Технические стандарты: Более подробную информацию см. в Разделе 3.8.3 Проверка стабильности DNS.
Названия стран или территорий в отношении географических наименований: См. Раздел 7.5 Географические наименования.

Органы, связанные с ICANN, IANA и IETF инфраструктурой интернета: К ним относятся, например, организации поддержки (SO) и консультативные комитеты (AC) ICANN,²⁹ региональные интернет-регистратуры,³⁰ органы IETF³¹ и системные идентификаторы, в список в рамках консенсусной политики.³²^,³³

Таблица 7-1. Органы, связанные с ICANN, IANA и IETF инфраструктурой интернета

Органы, связанные с ICANN, IANA и IETF инфраструктурой интернета
AFRINIC	GNSO	INTERNIC	NRO	TLD
ALAC	GTLDSERVERS	INTERNAL	PTI	WHOIS
APNIC	IAB	IETF	RFCEDITOR	WWW
ARIN	IANA	IRTF	RIPE
ASO	IANASERVERS	ISTF	ROOTSERVERS
ccNSO	ICANN	LACNIC	RSSAC
GAC	IESG	NIC	SSAC
Примечание: строки в списке блокируются только в указанной выше форме.

Другие недопустимые строки:
- Делегированные TLD.³⁴
- Строки gTLD, заявки на которые были поданы в предыдущих раундах gTLD и которые все еще находятся в процессе рассмотрения.³⁵
- Существующие ccTLD, прошедшие оценку с положительными результатами.
- Строки, которые в настоящее время запрашиваются как IDN-домены ccTLD.
- Все остальные строки, состоящие из одной или двух букв ASCII.

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

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

7.2.2.2.1 Оспаривание результата идентификации зарезервированного имени

В тех случаях, когда кандидат считает, что ему не позволяют подать заявку или он должен предоставить дополнительные документы, поскольку системная ошибка в автоматизированном процессе идентификации заблокированных имен привела к тому, что строка кандидата была неправильно классифицирована как заблокированное имя, и, следовательно, кандидат не смог перейти к подаче заявки, то кандидат будет иметь возможность подать заявление об оспаривании не позднее, чем за 14 дней до окончания периода приема заявок³⁶ (см. разделы 1.2.14.2 Оспаривание результатов оценки и 3.1.8.4 Оспаривание результатов валидации строк до подачи заявки).

7.2.2 Зарезервированные имена

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

Следующее ограниченное число строк международных МПО-НМПО находятся в списке зарезервированных имен и на них может подать заявку только соответствующее юридическое лицо в порядке исключительного права при условии, что оно представит надлежащие документы, как описано ниже в Разделе 7.2.2.2 Идентификация зарезервированных имен:

Имена, добавленные на основании рекомендаций рабочей группы PDP МПО-МНПО³⁸ в отношении защиты идентификаторов МПО-МНПО во всех gTLD,³⁹^,⁴⁰ включая их подлежащие распределению вариантные строки, могут быть делегированы после проверки. К ним относятся: названия Красного Креста и Красного Полумесяца (КК и КП)⁴¹, Международного олимпийского комитета (МОК)⁴², международных межправительственных организаций (МПО)⁴³ – международных неправительственных организаций (МНПО).⁴⁴

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

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

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

7.2.2.2.1 Оспаривание результатов идентификации зарезервированного имени

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

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

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

7.2.2.3.1 Процедура получения исключительного права на подачу заявки на зарезервированное имя

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

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

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

7.2.2.3.1.1 Проверка представленных документов

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

ICANN может консультироваться с соответствующими органами в рамках дальнейшей проверки.

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

7.2.2.3.2 Расширенная оценка для проверки зарезервированных имен

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

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

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

Кандидаты могут самостоятельно обозначить заявку как брендовый TLD. Этот тип заявки позволяет компании или корпорации использовать название своей компании или бренда в качестве TLD. См. Раздел 3.1.6 Типы заявок и строк.

7.3.1 Проверка наличия права на оценку соответствия требованиям для брендовых TLD

Кандидат, который желает обозначить запрашиваемую строку как брендовый TLD, должен пройти оценку соответствия требованиям к брендовым TLD. Цель этой оценки — подтвердить, что кандидат соответствует критериям для обозначения домена верхнего уровня как брендового TLD. Если заявка проходит оценку соответствия требованиям к брендовым доменам, в соответствующее базовое Соглашение об администрировании домена верхнего уровня добавляется Спецификация 13 (при условии, что заявка перейдет на этап делегирования). Положения Спецификации 13 см. в Приложении 4 Базовое Соглашение об администрировании домена верхнего уровня.⁴⁶

Кандидат может запросить оценку соответствия требованиям к брендовым TLD в своей заявке или через запрос на внесение изменений в заявку. См. Раздел 3.8 Запросы на внесение изменений в заявку.

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

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

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

Чтобы претендовать на классификацию домена верхнего уровня как брендового TLD, кандидат должен предоставить один или несколько файлов Signed Mark Data (SMD) из депозитария товарных знаков (TMCH). Критерии соответствия требованиям см. в руководстве по TMCH.⁴⁷

7.3.3.1 Взаимодействие с Депозитарием товарных знаков перед подачей заявки на брендовый TLD

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

Заявки на брендовые TLD должны включать один или несколько файлов Signed Mark Data (SMD) из Депозитария товарных знаков (TMCH), подтверждающих классификацию в качестве бренда. Поскольку добавление или корректировка файлов в TMCH может занять несколько месяцев и может потребовать оплаты сборов непосредственно в TMCH, кандидаты на брендовый TLD должны тщательно проверить свои существующие файлы SMD в TMCH или получить новые файлы SMD, как только это станет возможным. Кандидат на брендовый TLD должен предпринять следующие шаги в отношении TMCH (при необходимости), прежде чем подавать заявку на брендовый TLD:

Кандидат на брендовый TLD, не имеющий отношения к TMCH или не имеющий файлов SMD, охватывающих строки, на которые он хочет подать заявку, должен инициировать проверку в TMCH.⁴⁸
Убедиться, что все необходимые метки TLD указаны в элементах <mark:label> файлов SMD. Любая строка, на которую претендует кандидат на брендовый TLD, должна точно соответствовать элементу <mark:label> в действительном SMD с датой до дня подачи заявки.
Убедиться, что все желаемые метки вариантов первичной брендовой строки указаны в элементах <mark:label> файлов SMD. Все вариантные строки брендового TLD, на которые подана заявка, должны точно соответствовать элементу <mark:label> в действительном SMD с датой предшествующей дню подачи заявки.
Убедиться, что элементы <mark:goodsAndServices> указаны правильно, полностью и включают слово, которое кандидат может пожелать использовать в качестве замены брендового домена в соответствии с запросом на изменение брендовой строки (см. Раздел 5.3). Дополнительные слова, используемые для дополнения брендовой строки, на которую подается заявка, должны быть указаны в элементе <mark:goodsAndServices> действительного файла SMD с датой предшествующей дню подачи запроса на изменение брендовой строки.

Если слова, используемые для дополнения строки, на которую подана заявка, отсутствуют в файле SMD, запрос на изменение брендовой строки можно будет подать, используя другие документы. См. Раздел 5.3.2 Требования к подаче запросов на изменение брендовой строки.

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

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

1a. Запрашиваемая строка gTLD должна точно соответствовать текстовым элементам зарегистрированного товарного знака, проверенного TMCH в предоставленных файлах SMD; или

1b. Если кандидат изменил заявленную строку посредством запроса на изменение брендовой строки (Раздел 5.3), окончательная строка должна соответствовать всем изложенным требованиям.

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

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

7.3.3.3 Уточняющие вопросы для оценки соответствия требованиям для брендовых TLD

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

7.3.3.4 Результаты оценки соответствия требованиям для брендового TLD

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

Если заявка пройдет оценку соответствия требованиям к брендовым TLD, Спецификация 13 будет добавлена к применимому базовому Соглашению об администрировании домена верхнего уровня (при условии, что заявка переходит на этап делегирования).

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

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

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

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

7.3.5 Споры в отношении строк и изменение строки

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

7.4 Оценка освобождения от необходимости соблюдать Кодекс поведения операторов регистратур

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

7.4.1 Право на оценку возможности освобождения от соблюдения положений Кодекса поведения

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

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

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

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

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

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

7.4.4 Критерии оценки возможности освобождения от соблюдения требований Кодекса поведения

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

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

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

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

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

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

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

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

Если заявка не пройдет оценку возможности освобождения от соблюдения требований Кодекса, рассмотрение заявки может продолжаться с сохранением Спецификации 9.

7.4.6 Оспаривание и расширенная оценка возможности освобождения от соблюдения требований Кодекса поведения

7.5 Географические наименования

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

Рассмотрение географических наименований включает в себя следующее:

Идентификация географических наименований: проверка строки, что является частью оценки строки.
Проверка географических наименований: проверка и предметный анализ ответов на вопросы заявки для строк, определенных как географические. Эта проверка проводится на этапе оценки заявки.

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

7.5.1 Работа с названиями стран или территорий

Заявки на строки, которые являются названиями стран или территорий, не будут одобрены.⁴⁹ Строка считается названием страны или территории, если она соответствует любому из следующих критериев:

Это трехбуквенный код, закрепленный в стандарте ISO 3166-1.⁵⁰
Это полное название, указанное в стандарте ISO 3166-1, или перевод полного названия на любой язык.
Это краткое название, указанное в стандарте ISO 3166-1, или перевод краткого названия на любой язык.
Это краткое или полное название, связанное с кодом, который был обозначен как «исключительно зарезервированный» Агентством по поддержке стандарта ISO 3166.
Это отделимый компонент названия страны или территории, указанный в «Списке отделимых названий стран и территорий», или перевод названия, указанного в списке, на любой язык. См. Приложение 2 Материалы, связанные с географическими наименованиями.
Преобразования и перестановки следующих строк зарезервированы и недоступны для делегирования:

Полные названия, перечисленные в стандарте ISO 3166-1.
Сокращенные названия, перечисленные в стандарте ISO 3166-1.
Сокращенные или полные названия, связанные с кодом, который был обозначен как «исключительно зарезервированный» Агентством по поддержке стандарта ISO 3166.
Отделимый компонент названия страны или территории, указанный в «Списке отделимых названий стран и территорий», или перевод названия, указанного в списке, на любой язык.

Строки, полученные в результате преобразований и перестановок трехбуквенных кодов, перечисленных в стандарте ISO 3166-1, доступны для делегирования, только если такие строки сами не находятся в этом списке.⁵¹

Это широко известное название страны, что подтверждается тем, что страна признана под этим названием межправительственной или договорной организацией.

7.5.2 Географические наименования, требующие подтверждающих документов от государственного органа или учреждения

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

Строки, которые представляют на любом языке название столицы любой страны или территории, перечисленных в стандарте ISO 3166-1.
Названия городов, если кандидат заявляет, что намеревается использовать gTLD для целей, связанных с названием города.

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

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

Из заявлений кандидата в заявке ясно, что кандидат будет использовать TLD в первую очередь для целей, связанных с названием города;
Запрашиваемая строка является названием города, указанным в официальных документах города.⁵²

Строки, точно совпадающие с названиями субнациональных географических объектов, например округов, провинций или штатов, перечисленных в стандарте ISO 3166-2.
Строки, перечисленные как регионы ЮНЕСКО⁵³ или содержащиеся в разделе «Географические регионы» в документе «Стандартные коды стран и районов для статистического использования (M49)».⁵⁴

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

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

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

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

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

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

Кандидат обязан:

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

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

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

7.5.2.1 Требования к документам

Документы о поддержке или отсутствии возражений должны включать письмо, подписанное представителями соответствующей государственной структуры (структур) или органа (органов). Признавая, что форма подписания будет отличаться в разных юрисдикциях, письмо может быть подписано министром, ответственным за администрирование доменных имен, информационные и коммуникационные технологии, МИД или канцелярией премьер-министра или президента соответствующей юрисдикции, или, в качестве альтернативы, старшим представителем агентства или департамента, ответственного за администрирование доменных имен, информационные и коммуникационные технологии, иностранные дела или Канцелярию Премьер-министра. Чтобы получить помощь в определении соответствующих государственных структур или органов по вопросу потенциального географического наименования, кандидат может проконсультироваться с представителем Правительственного консультативного комитета (GAC) соответствующей страны.⁵⁶

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

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

Образец письма о поддержке или отсутствии возражений от государственной структуры/органа приведен в Приложении 2 Материалы, связанные с географическими наименованиями.

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

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

Кандидаты должны учитывать обязательство ICANN перед правительствами⁵⁷ в случае спора между правительством (или государственным органом) и кандидатом или, после делегирования, оператором регистратуры, который представил подтверждающие документы от этой государственной структуры или органа; ICANN будет соблюдать юридически обязывающее судебное предписание в юрисдикции государственного органа или учреждения, которое поддержало заявку. Если поддержка будет отозвана на основании юридически обязывающего судебного предписания, у кандидата или оператора регистратуры больше не будет необходимые документы, и кандидат либо не сможет перейти на следующий этап в процессе обработки заявки, либо, если это произойдет после делегирования, будут инициированы процессы передачи другой регистратуре⁵⁸, указанные в Соглашении об администрировании домена верхнего уровня.

7.5.3 Обработка географических наименований

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

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

Названия городов, которые не попадают в категории, определенные в разделах 1, 3 и 4 «Географические наименования, требующие подтверждающих документов со стороны государственной структуры или органа» (см. Раздел 7.5.2), не будут классифицироваться как географические наименования во время идентификации географических наименований. Однако, если кандидат указывает на намерение использовать запрашиваемую строку в качестве названия города, как описано в разделе 2 «Географические наименования, требующие подтверждающих документов со стороны государственной структуры или органа» (см. Раздел 7.5.2), заявка будет оцениваться Советом по географическим наименованиям на этапе оценки заявки и кандидата. Эта оценка будет включать оценку предполагаемого назначения и всей надлежащих документов.

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

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

GNP рассматривает все полученные заявки, а не только те, в которых кандидат указал запрашиваемую строку gTLD в качестве географического наименования. Если GNP принимает решение о том, что запрашиваемая строка gTLD является названием страны или территории (как определено в этом модуле), заявка отклоняется как не прошедшая проверку географических наименований. В этом случае дополнительные проверки не проводятся.

Если GNP определяет, что запрашиваемая строка gTLD не является географическим наименованием, которое нуждается в подтверждении государственной поддержки или отсутствия возражений (как описано в этом модуле), заявка будет проходить проверку географических наименований без каких-либо дополнительных шагов или сборов.

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

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

7.5.3.2.1 Расширенная оценка для проверки географических наименований

Проверка географических наименований подлежит расширенной оценке в следующих случаях:

Проблемы с предоставленными документами: в тех случаях, когда кандидат не предоставил надлежащие документы, с ним свяжутся и уведомят о требованиях; ему будет определен ограниченный срок для предоставления документов. Если кандидат сможет предоставить документы до окончания периода оценки и будет установлено их соответствие требованиям, то проверка географических наименований будет пройдена успешно. В противном случае кандидат может прибегнуть к расширенной оценке, в рамках которой у него будет дополнительное время для сбора необходимых документов; однако, если кандидат не предоставит необходимые документы в срок (не менее 90 дней с даты уведомления), у него не будет дополнительного времени или возможностей для этого в текущем раунде подачи заявок. При желании кандидат может повторно подать заявку в последующих раундах приема заявок, при условии оплаты сборов и соблюдения требований этих раундов. Дополнительную информацию об оспаривании результатов оценки см. в Модуле 6 Процедуры оценки кандидатов и Модуле 7 Процедуры оценки строк и заявок.
Противоречие в предоставлении поддержки или отсутствии возражений в отношении географического наименования: Как отмечено в Разделе 5.5 Урегулирование споров в отношении заявок на географические наименования, в случае, если имеется более одной заявки на строку географического наименования и при наличии документа о поддержке или отсутствии возражений от разных государственных структур или органов, как определено Советом по географическим наименованиям, такие заявки также пройдут расширенную оценку. Если в ходе расширенной оценки Совет по географическим наименованиям убедится, что подтверждающие органы всех соответствующих заявок соответствуют критериям, и согласится с тем, что эти заявки могут перейти к этапу разрешения спора, то следующим этапом будет либо аукцион, либо CPE, если одна из заявок подана от имени сообщества и кандидат выбирает процедуру CPE.

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

Вариантная строка считается «такой же», как и первичная запрашиваемая строка gTLD или существующий домен верхнего уровня («первичная строка») cообществом, использующим один и тот же набор символов согласно определению Правил генерирования меток корневой зоны (RZ-LGR).⁵⁹ Набор правил в RZ-LGR определяет допустимые домены верхнего уровня и их вариантные строки.⁶⁰ Кандидат, запрашивающий одну или несколько подлежащих распределению вариантных строк для первичного IDN-домена или существующего домена верхнего уровня, должен предоставить обоснование необходимости в каждой вариантной строке. Это обоснование будет оцениваться комиссией на основании общего стандарта обоснованности согласно следующим критериям в контексте запрашиваемого первичного IDN-домена или существующего домена верхнего уровня:

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

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

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

Способность управлять запрашиваемыми вариантными строками вместе с запрашиваемым первичным IDN-доменом или существующим доменом верхнего уровня будет оцениваться как с технической, так и с эксплуатационной точки зрения, как описано в Справочнике RSP.⁶¹

7.6.1 Дополнительные требования к заявкам на вариантные строки

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

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

Кандидаты на IDN-домены сообщества и соответствующие вариантные строки должны предоставить то же одобрение для запрашиваемых вариантных строк, что и для первичного IDN-домена. Если IDN-домен сообщества включен в спорную группу (см. Раздел 5.2 Споры в отношении строк и процедуры их урегулирования), и кандидат решает участвовать в процедуре оценки приоритетности заявок от сообществ (CPE), то IDN-домен сообщества и его запрашиваемые вариантные строки будут оцениваться вместе как набор (см. Раздел 5.4 Оценка приоритетности заявок от сообществ).
Кандидат на IDN-домен с географическим названием и его вариантные строки должен предоставить подтверждающие документы или документы об отсутствии возражений в отношении первичной строки и запрашиваемых вариантных строк от соответствующих государственных структур или органов. То есть в необходимых документах, подтверждающих поддержку или отсутствие возражений, должна быть указаны как запрашиваемый IDN-домен, так и запрашиваемые вариантные строки. См. Раздел 7.5 Географические наименования.
Кандидат на брендовый IDN-домен и его вариантные строки должен представить доказательство того, что запрашиваемая первичная строка и запрашиваемые вариантные строки идентичны зарегистрированным товарным знакам, принадлежащим кандидату и используемым им. То есть любая запрашиваемая вариантная строка также должна содержать доказательство того, что она идентична зарегистрированным товарным знакам, принадлежащим кандидату и используемым им. См. Раздел 7.3 Оценка соответствия критериям определения брендового TLD.

7.6.2 Заявка на варианты строк из списка зарезервированных имен

Если зарезервированное имя является первичной строкой, то подавать заявки на его вариантные строки на верхнем уровне может только организация, связанная с этим зарезервированным именем (см. Раздел 7.2.2 Зарезервированные имена). Хотя вариантная строка не обязательно должна быть зарезервированным именем, она генерируется как вариантная строка зарезервированного имени с использованием RZ-LGR. Заявка на вариантные строки зарезервированного имени не может предшествовать заявке на зарезервированное имя, которое служит первичной строкой для генерации вариантных строк.

7.6.3 Дополнительная зависимость вариантных строк

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

Однако, если какие-либо запрашиваемые вариантные строки дисквалифицированы и не могут быть использованы, кандидат должен подать запрос на внесение изменений в заявку (ACR), чтобы удалить дисквалифицированную запрашиваемую вариантную строку и продолжить процесс подачи заявки. Если процесс ACR завершится успешным внесением изменений, то соответствующий запрашиваемый первичный IDN-домен и любые оставшиеся запрашиваемые вариантные строки, которые не были дисквалифицированы, смогут перейти на следующую стадию процесса.

7.7 Доменная коллизия

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

Чтобы оценить и снизить риск доменных коллизий между глобальной DNS и другими системами имен, ICANN внедрила концепцию управления рисками в сфере доменных коллизий, следуя рекомендациям, изложенным в отчете по второму исследованию в рамках Проекта по анализу доменных коллизий,⁶⁴ в соответствии с указаниями Правления ICANN от 7 сентября 2024 года.⁶⁵

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

7.7.1 Доступ кандидатов к долгосрочным данным о рисках

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

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

Из примерно 1400 уникальных строк, на которые были поданы заявки в ходе последнего раунда, только три (.CORP, .HOME и .MAIL) были оценены как высокорисковые.⁶⁶ Тем не менее, кандидатам не следует предполагать, что если наборы данных указывают на небольшое количество доменных коллизий, то строка будет оценена как безопасная для делегирования.

7.7.2 Исходная оценка риска доменной коллизии

Каждая запрашиваемая строка и любые подлежащие распределению вариантные строки будут подвергаться первоначальной оценке случаев доменных коллизий с использованием соответствующих наборов данных, например журналов корневых серверов и журналов рекурсивных серверов DNS, с использованием как объема, так и разнообразия запросов, источников, Query Name (меток) и типов запросов; индикаторов работоспособности технологий идентификаторов (ITHI)⁶⁷, и качественных доказательств, которые могут помочь определить степень серьезности вреда. Цель этой оценки, которая будет проводиться в соответствии с рабочей процедурой первоначальной оценки случаев доменных коллизий,⁶⁸ заключается в предварительном выявлении высокорисковых строк.

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

7.7.3 Временное делегирование и окончательный анализ

Строки (включая вариантные строки), которые не были определены как высокорисковые во время проведения исходной оценки риска доменной коллизии (Раздел 7.7.2), будут помещены в очередь для временного делегирования. Временное делегирование начнется после завершения первоначальной оценки, даже если другие оценки, являющиеся частью оценки строки, все еще выполняются. Приоритетность временного делегирования будет определяться на основе присвоенного заявке номера приоритета.⁶⁹ Продолжительность временного делегирования будет указана в рабочей процедуре временного делегирования в случае доменной коллизии.⁷⁰ Завершение временного делегирования не требуется для проведения других оценок или урегулирования споров в отношении строк. Тем не менее, заявка может быть переведена в статус заключения соглашения только после завершения процедуры временного делегирования и реализации плана снижения рисков (при необходимости).

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

Во время временного делегирования запрашиваемая строка gTLD будет делегирована DNS-серверам под управлением ICANN для сбора данных об объеме и характере DNS-трафика для этой строки. В рамках временного делегирования будут использоваться четыре разных метода оценки для уведомлений и генерирования данных. Они описаны в Приложении 2 отчета по второму исследованию в рамках Проекта по анализу доменных коллизий и называются следующим образом: без прерываний (No Interruption, NI); управляемое прерывание (Controlled Interruption, CI); видимое прерывание (Visible Interruption, VI); видимое прерывание и уведомление (Visible Interruption and Notification, VIN). Оценка будет проводиться под контролем TRT, в состав которой входят внутренние эксперты из соответствующих отделов ICANN. TRT будет определять в каждом конкретном случае метод или методы проведения каждой оценки.

TRT оценивает данные, собранные во время временного делегирования, включая DNS-запросы к серверам TLD, разнообразие запросов, источники, Query Name (метки), типы запросов и т. д., а также данные, собранные с использованием методов оценки, чтобы определить, будет ли строка:

Обозначена как высокорисковая, и в этом случае строка будет немедленно удалена из корневой зоны.
Иметь право на дальнейшую обработку заявки.

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

7.7.4 Список строк с риском коллизии

ICANN будет вести список строк, которые, по мнению ICANN, представляют высокий риск доменных коллизий — Список строк с риском коллизии.

Запрашиваемая строка будет добавлена в Список строк с риском коллизии, если (1) для этой строки не представлен план смягчения последствий, (2) план смягчения последствий не прошел оценку или (3) план смягчения последствий неэффективен.

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

Кандидат на строку из Списка строк с риском коллизии имеет право изменить свою заявку после урегулирования спора, добавив План снижения рисков для высокорисковой строки и представив его на оценку. Эта оценка будет проводиться в соответствии с рабочей процедурой⁷¹ оценки Плана снижения рисков для высокорисковой строки и подлежит оплате дополнительных сборов. См. Раздел 3.3 Сборы и платежи.

Чтобы добавить в заявку План снижения рисков, кандидаты должны подать запрос на внесение изменений в заявку в течение 90 дней (с возможностью продления по обоснованному запросу до 180 дней) после (а) обозначения строки как высокорисковой или (b) урегулирования спора в отношении строки (если применимо). Если запрос на внесение изменений в заявку не будет отправлен в течение этого периода, то статус заявки изменится на «Terminated». См. Раздел 3.9 Статусы заявок.

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

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

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

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

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

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

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

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

7.7.5.1 Оспаривание результата оценки Плана снижения рисков

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

Делопроизводство по оспариванию результатов оценки будет проходить в соответствии со стандартом «явно ошибочное заключение» (“clearly erroneous” standard of review). В частности, Комиссия по оспариванию должна принять заключение группы оценки, кроме тех случаев, когда группа оценки: (1) не следовала надлежащим процедурам или (2) не рассмотрела/не запросила необходимые существенные доказательства или информацию.

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

Если Комиссия по оспариванию обнаружит фактическую или процедурную ошибку, будет проведена повторная оценка плана снижения рисков. Группа оценки проведет повторную оценку и предоставит результат ICANN. ICANN опубликует результаты и запустит 30-дневное общественное обсуждение. После окончания обсуждения ICANN рассмотрит всю доступную информацию и примет окончательное решение о принятии или отклонении плана снижения рисков. Если план отклоняется, статус заявки изменится на «Terminated».

Если Комиссия по оспариванию не обнаружит фактической или процедурной ошибки в исходной оценке плана снижения рисков, то заявка не будет допущена к дальнейшей обработке и получит статус «Terminated».

7.7.6 Взаимодействие с вариантными строками

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

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

7.8 Обязательства по обеспечению общественных интересов, добровольные обязательства регистратур и правила регистрации сообщества

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

Обязательства по обеспечению общественных интересов (PIC), в частности обязательные PIC (см. Раздел 7.8.1) и PIC в качестве защитных мер (см. Раздел 7.8.2), являются важным средством защиты, встроенным в Программу New gTLD. PIC представляют собой обязательства, изложенные в Спецификации 11 Соглашения об администрировании домена верхнего уровня, и ICANN следит за их соблюдением. Обязательные PIC и PIC в качестве защитных мер единообразны во всех соответствующих Соглашениях об администрировании домена верхнего уровня и были составлены в ответ на выраженную Правительственным консультативным комитетом (GAC) обеспокоенность по поводу заявок в раунде 2012 года. Рассматриваются следующие основные вопросы: защита прав потребителей, права интеллектуальной собственности и регулируемые секторы рынка, такие как финансовый, медицинский и благотворительный.⁷³

В дополнение к PIC, кандидату будет разрешено предложить одно или более добровольных обязательств регистратуры (RVC) (см. Раздел 7.8.3) для обеспечения дополнительных гарантий в отношении эксплуатации запрашиваемой строки gTLD. Кандидат может предложить RVC для устранения проблем, которые еще не были решены с помощью обязательных PIC или PIC в качестве защитных мер, либо другими средствами. Как более подробно изложено в Разделе 7.8.3 Добровольные обязательства регистратур, предлагаемые RVC подлежат отдельной оценке, а именно оценке обязательств регистратуры (RCE). ICANN одобрит предлагаемое RVC только в следующих случаях: (1) RVC соответствует критериям RCE (см. Раздел 7.8.3.3); и (2) кандидат и ICANN согласны с тем, что выполнение предлагаемого RVC в случае включения его в Соглашение об администрировании домена верхнего уровня практически контролируемо в соответствии с Уставом ICANN. Как и в случае с PIC, RVC (после утверждения и включения в Соглашение об администрировании домена верхнего уровня) изложены в Спецификации 11 базового Соглашения об администрировании домена верхнего уровня и являются обязательными к исполнению.⁷⁴

Как PIC, так и RVC подпадают под действие процедуры урегулирования споров в области обеспечения общественных интересов (PICDRP).⁷⁵

Как подробно описано в Разделе 7.1 Типы строк и заявок, кандидат может обозначить запрашиваемую строку gTLD как gTLD сообщества. Если кандидат идентифицирует запрашиваемую строку gTLD как gTLD сообщества, он должен предложить правила регистрации сообщества (см. Раздел 7.8.4) для включения в применимое Соглашение об администрировании домена верхнего уровня, которые будут оцениваться ICANN путем применения критериев RCE (см. Раздел 7.8.3.3).

7.8.1 Обязательные обязательства по обеспечению общественных интересов

Обязательные PIC включены во все Соглашения об администрировании домена верхнего уровня. Обязательные PIC требуют от каждого оператора регистратуры реализации мер по защите владельцев доменов gTLD и интернет-пользователей в более широком смысле, а также включают обязательства, связанные со смягчением последствий злоупотреблений, проверками безопасности и транспарентностью эксплуатации. Обязательные PIC включены в Спецификацию 11, раздел 3(a)-(d) базового Соглашения об администрировании домена верхнего уровня (см. Приложение 4), а именно:

Оператор регистратуры включает в Соглашение между регистратурой и регистратором требование, обязывающее регистраторов включать в свои регистрационные соглашения положение, запрещающее владельцам зарегистрированных имен распространять вредоносное программное обеспечение, принимать участие в злоупотреблениях с использованием бот-сетей, заниматься фишингом, пиратством, нарушать авторские права и права на товарные знаки, вести мошенническую или вводящую в заблуждение деятельность, распространять контрафактную продукцию и вести прочую деятельность, идущую вразрез с применимым законодательством. Кроме того, в этом положении должны быть указаны меры пресечения (соответствующие законодательству и любым сопряженным процедурам) такой деятельности, в том числе приостановка регистрации доменного имени.
Оператор регистратуры будет периодически проводить технический анализ, чтобы определить, используются ли домены DNS для злоупотреблений DNS. Оператор регистратуры составляет статистические отчеты об обнаруженных злоупотреблениях DNS и мерах, принятых в результате периодических проверок безопасности. Оператор регистратуры хранит эти отчеты в течение всего срока действия Соглашения, кроме случаев, когда более короткий срок предусмотрен законом или одобрен ICANN, и предоставляет их корпорации ICANN по запросу.⁷⁶
Оператор регистратуры эксплуатирует TLD с соблюдением норм транспарентности, в соответствии с общими принципами открытости и недискриминационного отношения, путем формирования, публикации и соблюдения регистрационной политики.
Оператор регистратуры «строки общего пользования» TLD не вправе устанавливать критерии отбора при регистрации имен в соответствующем TLD, которые ограничивали бы регистрации эксклюзивным образом до единственного физического или юридического лица и/или аффилированных лиц этого физического или юридического лица (согласно определению в разделе 2.9(c) базового Соглашения об администрировании домена верхнего уровня). Термин «строка общего пользования» означает строку, состоящую из слова или понятия, которое обозначает или описывает общий класс товаров, услуг, групп, организаций или вещей, в противоположность выделению конкретной торговой марки товаров, услуг, групп, организаций или вещей среди других аналогичных товарных знаков.

Дополнительную информацию о строках общего пользования см. в Разделе 3.1.7 Строки закрытых gTLD/строки исключительного использования.

7.8.2 Обязательства по обеспечению общественных интересов в качестве меры защиты

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

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

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

Более подробную информацию и примеры см. в таблице в Разделе 7.8.2.2 Применимые PIC в качестве защитных мер, с разбивкой на категории строк.

Если ICANN во время оценки определит, что запрашиваемая строка gTLD попадает в одну или несколько категорий, указанных в Разделе 7.8.2.2 Применимые PIC в качестве защитных мер, с разбивкой на категории строк, соответствующие применимые PIC (см. раздел 7.8.2.3) должны быть включены в Спецификацию 11 применимого базового Соглашения об администрировании домена верхнего уровня без изменений.⁷⁷

PIC в качестве меры защиты были разработаны и внедрены в ответ на консенсусные рекомендации GAC в коммюнике по результатам заседаний Правительственного консультативного комитета (GAC) на конференции ICANN46 в Пекине⁷⁸ и последующей резолюции⁷⁹ Правления ICANN во время раунда Программы New gTLD 2012 года.⁸⁰

7.8.2.1 Определение группы строк

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

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

Дополнительную информацию о периодах общественного обсуждения см. в Разделе 4.1 Комментарии по заявкам.

7.8.2.2 Применимые PIC в качестве защитных мер, с разбивкой на категории строк

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

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

Таблица 7-2. Концепция PIC в качестве защитных мер

№ группы строк	Группа строк	Описание	Обязательные защитные меры
1	Регулируемые секторы/требования относительно свободного доступа в нескольких юрисдикциях	Строка с большой вероятностью вызовет у потребителей определенный уровень доверия Строка, вероятно, несет повышенный риск причинения вреда потребителю Строка связана с открытым сектором, но могут потребоваться ограничения в отношении регистрации См. неисчерпывающий список определенных в коммюнике GAC по итогам конференции ICANN46 в Пекине строк, относящихся к этой группе.⁸² Примеры: .kid, .degree, .audio, .town	1–3
2	Cтрого регулируемые секторы/требования относительно закрытого доступа	Строка связана с отраслью, в которой лицензирование или аккредитация требуются местными, региональными или национальными правительствами. Обычно требуется оценка квалификации, регулярные проверки и постоянный государственный надзор. См. неисчерпывающий список определенных в коммюнике GAC по итогам конференции ICANN46 в Пекине строк, относящихся к этой группе.⁸³ Примеры: .cash, .bet, .abogado, .earth, .care	1–8
3	Потенциальная угроза кибербуллинга/харассмента	Подразумеваемое или фактическое значение строки может привести к тому, что gTLD будет использоваться для содействия харассменту или кибербуллингу. Примеры строк, отнесенных в коммюнике GAC по итогам конференции ICANN46 в Пекине этой группе⁸⁴: .fail, .gripe, .sucks, .wtf	1–9
4	Неотъемлемые государственные функции	Строка связана с функцией, которая по своей сути относится к сфере деятельности государства, например военные подразделения. Примеры строк, отнесенных в коммюнике GAC по итогам конференции ICANN46 в Пекине этой группе⁸⁵: .army, .navy, .airforce	1-8 и 10

7.8.2.3 PIC в качестве защитных мер

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

Таблица 7-2. Типы PIC в качестве защитных мер

PIC в качестве защитной меры	Описание PIC в качестве защитной меры
1	Оператор регистратуры должен включить в свое соглашение между регистратурой и регистраторами положение, требующее от регистраторов обязать владельцев доменов в рамках регистрационного договора соблюдать все применимые законы, в том числе касающиеся конфиденциальности, сбора данных, защиты прав потребителей (в том числе в отношении вводящего в заблуждение и обманчивого поведения), справедливого кредитования, взыскания долгов, органического земледелия, раскрытия данных и раскрытия финансовой информации.
2	Оператор регистратуры должен включить в свое соглашение между регистратурой и регистраторами положение, образующее регистраторов уведомлять владельцев доменов о необходимости соблюдения всех применимых законов.
3	Оператор регистратуры должен включить в свое соглашение между регистратурой и регистраторами положение, требующее от регистраторов обязать владельцев доменов в рамках регистрационных соглашений при сборе и хранении конфиденциальных медицинских и финансовых данных применять разумные и надлежащие меры безопасности, соразмерные с предложением таких услуг, как это определено применимым законодательством.
4	Оператор регистратуры должен заблаговременно создать четкий процесс для установления рабочих отношений с соответствующими регулирующими или отраслевыми органами самоуправления, публикуя контактные данные и приглашая такие органы к установлению канала связи, в том числе с целью содействия разработке стратегии по снижению рисков мошенничества и другой незаконной деятельности.
5	Оператор регистратуры должен включить в свое соглашение между регистратурами и регистраторами положение, требующее от регистраторов обязать владельцев доменов в рамках своих регистрационных соглашений предоставлять при регистрации действительную административную контактную информацию для уведомления о жалобах или сообщениях о злоупотреблениях, а также контактные данные соответствующих регулирующих или отраслевых органов самоуправления по основному месту деятельности.
6	Оператор регистратуры должен включить в свое соглашение между регистратурами и регистраторами положение, требующее от регистраторов обязать владельцев доменов в рамках своих регистрационных соглашений подтверждать наличие всех необходимых разрешений, уставов, лицензий и/или других соответствующих документов для работы в секторе, связанном со строкой TLD.

PIC в качестве защитной меры	Описание PIC в качестве защитной меры
7	Если оператор регистратуры получает жалобу, в которой выражаются сомнения в отношении подлинности лицензий или учетных данных, оператор регистратуры должен проконсультироваться с соответствующими национальными надзорными или эквивалентными им органами относительно подлинности.
8	Оператор регистратуры должен включить в свое соглашение между регистратурой и регистраторами положение, требующее от регистраторов добавить в свои регистрационные соглашения положения, обязующие владельцев доменов сообщать о любых существенных изменениях в действительности разрешений, привилегий, лицензий и/или других соответствующих мандатов владельцев доменов для работы в секторе, связанном со строкой TLD. Это является гарантией того, что они продолжают соблюдать действующие нормы и требования лицензирования и в целом осуществляют свою деятельность в интересах потребителей, которых они обслуживают.
9	Оператор регистратуры должен разработать и опубликовать правила регистрации, чтобы свести к минимуму риск кибербуллинга и/или харассмента.
10	Оператор регистратуры должен включить в свое соглашение между регистратурой и регистраторами положение, требующее от регистраторов обязать владельца домена подтвердить, в рамках регистрационного соглашения, что будут предприняты разумные шаги, чтобы не допустить искажения или ложного указания на то, что сам владелец домена или его деятельность связаны, спонсируются или поддерживаются вооруженными силами одной или нескольких стран или правительств, если такая принадлежность, спонсорство или поддержка не существует.

7.8.3 Добровольные обязательства регистратур

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

Решение кандидата предложить RVC, как правило, является добровольным, за исключением тех случаев, которые признаны ICANN средством урегулирования возражения или в ответ на консенсусную рекомендацию GAC (см. пояснение в Разделе 7.8.3.2.3.1 Ситуация 1.Обязательства, принятые для преодоления возражений или в рамках выполнения консенсусной рекомендации GAC). Эти обязательства будут иметь обязательную силу в случае их одобрения и включения в Соглашение об администрировании домена верхнего уровня. RVC могут варьироваться, потенциально повышая обязательства, связанные с общественными интересами, или кодифицируя обязательства заинтересованных сторон. RVC также может установить защитные меры, которые могут помочь преодолеть озабоченность третьей стороны в отношении запрашиваемой строки gTLD или заявки. Например, кандидаты могут предложить RVC в ответ на возражения, заблаговременные предупреждения со стороны членов GAC или консенсусные рекомендации GAC, комментарии к заявке или другие обстоятельства, которые могут негативно повлиять на процесс оценки заявки. Дополнительную информацию по этим вопросам см. в Разделе 3.8 Запросы на внесение изменений в заявку и Модуле 4 Комментарии сообщества, возражения и апелляции.

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

Все предложенные RVC, представленные вместе с заявкой или в качестве запроса на внесение изменений в заявку, будут опубликованы в разделе публичных заявок, доступном на сайте Программы New gTLD⁸⁶, и открыты для общественного рассмотрения и комментирования в течение периода общественного обсуждения (см. Раздел 4.1 Комментарии по заявке).

7.8.3.1 Факторы, которые следует учитывать до выдвижения предложения о RVC

Прежде чем предлагать RVC, кандидатам рекомендуется ознакомиться с Уставом ICANN; соответствующими соглашениями ICANN, включая, помимо прочего, Соглашение об администрировании домена верхнего уровня и Соглашение об аккредитации регистратора (RAA); а также с консенсусными и временными политиками ICANN. Кандидатам и любым третьим сторонам, которые выражают обеспокоенность по поводу каких-либо заявок, следует проанализировать, могут ли уже существующие стандартные положения являться достаточным механизмом защиты для запрашиваемой строки gTLD, чтобы избежать необходимости оценки и реализации индивидуального RVC.⁸⁷

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

Кроме того, кандидату следует рассмотреть вопрос о том, требует ли выполнение предлагаемого RVC применения дополнительной услуги регистратуры.⁸⁸ В этом случае кандидат должен обсудить с выбранным им провайдером услуг регистратур (RSP) внедрение такой дополнительной услуги регистратуры, которая должна будет пройти оценку в рамках Программы RSP и получить одобрение ICANN. Если ICANN сочтет, что предлагаемое RVC требует использования дополнительной услуги регистратуры, и такая услуга регистратуры еще не была одобрена для выбранного кандидатом RSP, то нужно получить одобрение ICANN через Программу RSP, прежде чем ICANN рассмотрит вопрос об утверждении предлагаемого обязательства в качестве RVC.⁸⁹

Любое предлагаемое RVC, которое несовместимо с Уставом, политиками и соглашениями ICANN, не будет одобрено, как описано в Разделе 7.8.3.3 Критерии оценки обязательств регистратуры.

Кандидату рекомендуется рассмотреть вопрос о том, существуют ли другие средства, помимо Соглашения об администрировании домена верхнего уровня, которые могли бы помочь решить вопросы, связанные с запрашиваемой строкой gTLD или заявкой. Например, кандидат может рассмотреть возможность решения проблем, возможно, после консультации с третьей стороной, которая их упомянула, путем включения соответствующих обязательств в собственную политику регистратуры, условия использования или заключив отдельное соглашение между кандидатом и третьей стороной. Выполнение любого такого отдельного соглашения не будет контролироваться ICANN, и любая такая третья сторона не должна быть «сторонним бенефициаром» Соглашения с ICANN об администрировании домена верхнего уровня.⁹⁰

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

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

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

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

Кандидат, который предлагает RVC или правила регистрации сообщества, должен внести фиксированный единовременный платеж, покрывающий стоимость оценки обязательств регистратуры. Подробнее о сборах, связанных с RCE, см. Раздел 3.3.2 Обусловленные оценки.

7.8.3.2.1 Кандидаты должны определить цели предлагаемого RVC

Кандидат должен предоставить справочную информацию, чтобы объяснить, почему предлагаемое им RVC является актуальным, важным и необходимым для его заявки. ICANN проведет проверку полноты выполнения этого требования, когда RVC будет предложено кандидатом, до оценки обязательств регистратуры. Эта информация позволит создать контекст для предлагаемого RVC и, в некоторых случаях, может быть полезна, если для достижения целей предлагаемого обязательства потребуются корректировки условий RVC, а также соответствие критериям включения RVC в Соглашение об администрировании домена верхнего уровня, как описано в Разделе 7.8.3.3 Критерии оценки обязательств регистратуры.

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

7.8.3.2.2 Общее правило: оценка обязательств регистратуры в отношении предлагаемых RVC не влияет на ход рассмотрения заявки

В ситуациях, не входящих в Раздел 7.8.3.2.3 Исключение: оценка обязательств регистратуры в отношении предлагаемых RVC влияет на ход рассмотрения заявки, оценка обязательств регистратуры в отношении предлагаемых RVC не повлияет на рассмотрение заявки. При отсутствии подобных исключительных обстоятельств оценка обязательств регистратуры не влияет на оценку способности кандидата или заявки перейти к этапу заключению соглашения, а лишь определяет, соответствует ли предлагаемое RVC критериям включения в применимое Соглашение об администрировании домена верхнего уровня в случае, если заявка будет одобрена.

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

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

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

Если кандидат планирует предложить RVC в запросе на внесение изменений в заявку для решения проблемы, поднятой третьей стороной , он должен учитывать соответствующие сроки и процессы для возражений, консенсусную рекомендацию GAC, заблаговременные предупреждения со стороны GAC, комментарии к заявке и т. д., если он хочет, чтобы RVC было учтено в этих процессах (см. Модуль 4 Комментарии сообщества, возражения и апелляции). Как отмечалось выше, все предлагаемые RVC, которые подаются в качестве запроса на внесение изменений в заявку (см. Раздел 3.8), подлежат рассмотрению в ходе периода общественного обсуждения.

7.8.3.2.3 Исключение: оценка обязательств регистратуры в отношении предлагаемых RVC влияет на ход рассмотрения заявки

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

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

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

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

RVC должно быть одобрено ICANN в рамках оценки обязательств регистратуры для урегулирования возражения или выполнения консенсусной рекомендации GAC. Без такого одобрения рассмотрение заявки не может быть продолжено.⁹¹ См. Раздел 4.5.8.13 Возражения и добровольные обязательства регистратур и Раздел 4.3.3 Консенсусные рекомендации GAC и добровольные обязательства регистратур.

RVC, предлагаемые для преодоления возражений или в рамках выполнения консенсусной рекомендации GAC открыты для публичной дискуссии и комментариев в течение периода общественного обсуждения. Если переговоры с ICANN приведут к изменениям, подлежащим утверждению, то и первая версия предложения, и утвержденные ICANN версии будут опубликованы для общественного обсуждения. Подробнее см. в Разделе 3.8 Запросы на внесение изменений в заявку.

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

7.8.3.2.3.2 Ситуация 2: запрос на внесение изменений в заявку, необходимый после отклонения предложенного RVC

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

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

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

В отношении сроков оценки обязательств регистратуры для предлагаемых RVC в ситуации 1: обязательства, принятые для преодоления возражений или в рамках выполнения консенсусной рекомендации GAC (см. Раздел 7.8.3.2.3.1), и предлагаемые правила регистрации сообщества (см. Раздел 7.8.4), представленные кандидатами от сообщества, участвующими в оценке приоритетности заявок от сообществ (CPE), пройдут оценку обязательств регистратуры в максимально сжатые сроки после того, как ICANN получит соответствующую оплату. ICANN признает значение своевременного проведения RCE для обеспечения беспрепятственного выполнения зависимых процессов.

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

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

ICANN будет публиковать и регулярно обновлять результаты RCE всех представленных RVC и правил регистрации сообщества на сайте Программы New gTLD, и уведомлять соответствующих кандидатов о результатах.⁹²

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

ICANN отклонит любые предложенные RVC, которые нарушают Устав ICANN.⁹³ Подробнее см. критерий 5 в таблице ниже.

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

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

См. инструкции к вопросам 150-155 в группе вопросов 7 gTLD сообщества и группе вопросов 11 Добровольные обязательства регистратур (RVC) в Приложении 1 Вопросы заявки для получения подробной информации о требованиях, которые определяют подход к разработке предлагаемых правил регистрации сообщества и добровольных обязательств регистратуры, подлежащих оценке в рамках RCE.

Как отмечено в Разделе 7.8.3.1 Факторы, которые следует учитывать до выдвижения предложения о RVC, кандидаты могут рассмотреть возможность включения определенных обязательств, выходящих за рамки Соглашения об администрировании домена верхнего уровня, в такие инструменты, как собственные политики регистратуры кандидата, условия использования или отдельное соглашение между кандидатом и третьей стороной. Любое такое обязательство, не предложенное для включения в Соглашение об администрировании домена верхнего уровня, не будет подлежать оценке обязательств регистратуры.⁹⁴

Таблица 7-3. Критерии оценки RVC

Критерий	Описание	Инструкция
В RVC должно быть четко указано, какие обязательства должны быть выполнены.	Предлагаемое RVC должно быть обязательным к исполнению и четко указывать, какие обязательства оператор регистратуры должен выполнять, а не то, какие обязательства оператор регистратуры «может» или «мог бы» выполнить.	Используйте утвердительные формулировки: избегайте оговорок и выражайте уверенность при описании предлагаемого RVC. Укажите, что, по мнению кандидата, «должен» делать оператор регистратуры.
RVC должно быть четким, подробным, понятным и кандидату и ICANN, объективным и измеримым.	В каждом RVC должно быть четко указано, что требуется от оператора регистратуры. Такой уровень детализации в RVC необходим для обеспечения его практической применимости. RVC должно быть четким, чтобы в случае возникновения проблемы с соблюдением условий договора, действия оператора регистратуры можно было бы сравнить с объективной формулировкой в RVC и определить, соблюдал ли оператор регистратуры требования RVC.	Обеспечьте ясность: используйте простые и понятные формулировки. Будьте точны и конкретны: избегайте расплывчатых или двусмысленных утверждений, которые могут привести к недопониманию. Детализируйте информацию: укажите, какая организация будет отвечать за реализацию RVC; опишите действия, шаги или задачи, необходимые для реализации RVC; изложите конкретные действия, которые оператор регистратуры должен предпринять для выполнения RVC. Рассмотрите возможность внутреннего мониторинга соблюдения требований оператором регистратуры: опишите, как оператор регистратуры будет контролировать и оценивать выполнение и соблюдение требований RVC.
В RVC должны быть указаны все применимые ограничения.	Кандидат должен предоставить подробную информацию о том, ограничено ли предлагаемое RVC по времени, продолжительности, объему или любым другим факторам, если это применимо, и если да, то каким образом и почему.	Определите все применимые ограничения предлагаемого RVC: например, если RVC ограничено по времени, в нем должно быть указано, будет ли оно применяться в течение всего срока действия gTLD, только в течение указанного периода запуска или в течение какого-либо другого определенного периода.

Критерий	Описание	Инструкция
В RVC не следует ⁹⁵ дублировать или включать текст, противоречащий требованиям применимого законодательства, соглашений ICANN, а также консенсусных или временных политик ICANN.	RVC не должно дублировать обязательства, которые применяются к оператору регистратуры в соответствии с Соглашением об администрировании домена верхнего уровня, применимыми консенсусными и временными политиками ICANN или применимым законодательством. RVC не будет одобрено, если оно противоречит применимым соглашениям и политикам ICANN. Оператор регистратуры должен быть в состоянии соблюдать требования RVC, а также действующие соглашения и политики ICANN. RVC также не должно препятствовать соблюдению другими сторонами (например, регистраторами) применимых соглашений и политик ICANN.⁹⁶ Если для выполнения предлагаемого RVC требуется использование дополнительной услуги регистратуры, такая услуга регистратуры должна пройти оценку в рамках Программы RSP и быть одобрена ICANN, прежде чем ICANN рассмотрит вопрос об утверждении предлагаемого обязательства в качестве RVC.	Избегайте дублирования: прежде чем предлагать RVC, кандидату следует внимательно изучить положения Соглашения об администрировании домена верхнего уровня, Соглашения об аккредитации регистратора, а также консенсусные и временные политики ICANN, чтобы убедиться, что такого обязательства еще не существует. В противном случае кандидат не следует предлагать RVC. В противном случае кандидат не должен предлагать RVC. Расширение договорных обязательств или обязательств в отношении политики: RVC может углублять, дополнять или расширять требования Соглашения об администрировании домена верхнего уровня и другие применимые обязательства, если RVC не противоречит этим применимым обязательствам. RVC должно применяться наряду с другими требованиями, предусмотренными соглашением и политиками: RVC не может обязать оператора регистратуры предпринимать действия, противоречащие требованиям Соглашения об администрировании домена верхнего уровня или применимым консенсусным или временным политикам ICANN. RVC не должно обязывать оператора регистратуры включать в свои Соглашение между регистратурами и регистраторами условия, которые требуют от регистраторов предпринимать действия в нарушение Соглашения об аккредитации регистратора, применимых консенсусных или временных политик ICANN или применимого законодательства.
RVC должно соответствовать Уставу ICANN.	ICANN не может одобрить RVC, которое несовместимо с Уставом ICANN.	Одним из важных аспектов этого критерия является вопрос о том, будет ли предлагаемое RVC ограничивать содержание или использование запрашиваемой строки gTLD.⁹⁷ Если предлагаемое RVC поставит ICANN в положение, когда она будет вынуждена обеспечивать соблюдение оператором регистратуры ограничения на контент в применимом gTLD, то предлагаемое RVC будет отклонено.⁹⁸ «Контент» — это суть передаваемого сообщения, в то время как факторы, не ограничивающие контент, могут включать, помимо прочего, то, как, когда и кем контент доставляется. В контексте RVC различие между обязательствами, ограничивающими контент, и обязательствами, не ограничивающими контент, предполагает понимание объема, направленности и воздействия обязательств: Сфера применения: обязательства, не ограничивающие контент, могут быть сосредоточены на операционных, процедурных и технических аспектах регистрации и управления доменными именами, а не на конкретном контенте в gTLD. Центр внимания: обязательства, не ограничивающие контент, могут включать соблюдение отраслевых стандартов, требований к регистрации и процедур, не относящихся к контенту в gTLD. Результаты: обязательства, не ограничивающие контент, могут повлиять на управление доменными именами и операционную среду, в которой они существуют.

Критерий

Описание

Инструкция

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

RVC не должно дублировать обязательства, которые применяются к оператору регистратуры в соответствии с Соглашением об администрировании домена верхнего уровня, применимыми консенсусными и временными политиками ICANN или применимым законодательством. RVC не будет одобрено, если оно противоречит применимым соглашениям и политикам ICANN. Оператор регистратуры должен быть в состоянии соблюдать требования RVC, а также действующие соглашения и политики ICANN. RVC также не должно препятствовать соблюдению другими сторонами (например, регистраторами) применимых соглашений и политик ICANN.⁹⁶ Если для выполнения предлагаемого RVC требуется использование дополнительной услуги регистратуры, такая услуга регистратуры должна пройти оценку в рамках Программы RSP и быть одобрена ICANN, прежде чем ICANN рассмотрит вопрос об утверждении предлагаемого обязательства в качестве RVC.

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

RVC должно соответствовать Уставу ICANN.

ICANN не может одобрить RVC, которое несовместимо с Уставом ICANN.

Одним из важных аспектов этого критерия является вопрос о том, будет ли предлагаемое RVC ограничивать содержание или использование запрашиваемой строки gTLD.⁹⁷ Если предлагаемое RVC поставит ICANN в положение, когда она будет вынуждена обеспечивать соблюдение оператором регистратуры ограничения на контент в применимом gTLD, то предлагаемое RVC будет отклонено.⁹⁸

«Контент» — это суть передаваемого сообщения, в то время как факторы, не ограничивающие контент, могут включать, помимо прочего, то, как, когда и кем контент доставляется. В контексте RVC различие между обязательствами, ограничивающими контент, и обязательствами, не ограничивающими контент, предполагает понимание объема, направленности и воздействия обязательств:

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

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

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

7.8.3.4 Добавление, изменение и исключение RVC

Если предлагаемое RVC добавляется или изменяется после даты подачи заявки и до подписания соответствующего Соглашения об администрировании домена верхнего уровня, на него распространяется процесс запроса на внесение изменений в заявку, который включает период общественного обсуждения для внесения существенных изменений, как указано в Разделе 3.8 Запросы на внесение изменений в заявку.. Информацию о различных типах общественного обсуждения предлагаемых RVC см. в Разделе 3.8.3 Типы запросов на внесение изменений в заявку и необходимые процессы.

При отсутствии чрезвычайных обстоятельств, для RVC в соответствии с Ситуацией 1: обязательства, принятые для преодоления возражений или в рамках выполнения консенсусной рекомендации GAC (см. Раздел 7.8.3.2.3.1) — как правило, не могут быть существенно изменены или удалены до заключения соглашения.

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

7.8.3.5 Предлагаемое RVC для вариантных строк

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

7.8.4 Правила регистрации сообщества

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

Как и в случае с предлагаемыми RVC для включения в Соглашение об администрировании домена верхнего уровня, правила регистрации сообщества, которую кандидат предлагает включить в применимое Соглашение об администрировании домена верхнего уровня, должна оцениваться в соответствии с критериями RCE (см. Раздел 7.8.3.3). Результаты оценки повлияют на то, будет ли продолжено рассмотрение заявки от сообщества. В частности, кандидат должен иметь утвержденные правила регистрации сообщества в качестве предварительного условия для того, чтобы его заявка участвовала в оценке приоритетности заявок от сообществ (CPE). Этот вариант доступен только для заявок от сообщества для целей урегулирования спора в отношении спорной группы.⁹⁹ Тем не менее, одобрение требуется не только для участия заявки от сообщества в CPE, но и для продвижения в процессе рассмотрения заявки после RCE. Иными словами, если нет правил регистрации сообщества, которые могут быть одобрены ICANN на предмет включения в Соглашение об администрировании домена верхнего уровня, то рассмотрение заявки от сообщества не может быть продолжено — конкурирует ли она с другими заявками или решает ли кандидат участвовать в CPE.¹⁰⁰

Правила регистрации сообщества, отвечающие критериям RCE (см. Раздел 7.8.3.3), будут включены в применимое Соглашение об администрировании домена верхнего уровня, если запрашиваемая строка перейдет на этап делегирования. См. инструкции к вопросам 150–155 в группе вопросов 7 gTLD сообщества в Приложении 1 Вопросы заявки для получения подробной информации о требованиях, которые определяют подход к разработке предлагаемых правил регистрации сообщества, подлежащих оценке в рамках RCE. Как и в случае с PIC и RVC, утвержденные правила регистрации сообщества будет подлежать контролю исполнения договорных обязательств со стороны ICANN. Правила регистрации сообщества, включенные в Соглашение об администрировании домена верхнего уровня, регулируются процедурой разрешения споров по ограничениям регистрации (RRDRP) и процедурой запросов на внесение изменений в gTLD сообщества.¹⁰¹

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

7.8.5 Обеспечение соблюдения требований ICANN

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

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

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

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

Цель оценки схожести строк — не допустить путаницу среди пользователей и потерю доверия к DNS в результате делегирования визуально похожих строк. Строки или их варианты не должны быть визуально похожими (определено ниже) на существующий домен верхнего уровня или его вариантные строки, или на заблокированное имя или его вариантные строки, как подробно описано в Разделе 7.10.1 Область оценки схожести строк (см. Раздел 7.2.1 Заблокированные имена). Вариантные строки рассчитываются с использованием применимой версии Правил генерирования меток корневой зоны (см. Р
Раздел 3.1.8.3.1.1 Применимая версия RZ-LGR и поддерживаемые наборы символов и языки.)¹⁰³

Заявка базируется на первичной запрашиваемой строке или существующем gTLD. Каждая первичная строка образует набор вариантных строк и входит в него.¹⁰⁴ Заявка может содержать одну или несколько строк из одного и того же набора вариантных строк (см. Раздел 3.1.9 Интернационализированные доменные имена), в зависимости от выбора кандидата и других применимых ограничений.¹⁰⁵ Оценка схожести строк любой заявки проводится с использованием всех строк в наборе вариантных строк, даже если многие из этих строк не запрашиваются кандидатом, как указано ниже.

«Визуально схожие» в этом контексте означает строки, визуально схожие до степени смешения, в частности, «строки, которые визуально похожи настолько, что возникнет вероятность введения пользователей в заблуждение, если в корневую зону будет делегировано более одной такой строки».¹⁰⁶ Оценка схожести строк будет проводиться независимой Комиссией по оценке схожести строк. Если комиссия обнаружит, что запрашиваемые строки или их варианты являются визуально схожими, они будут помечены и исключены из процесса или включены в спорные группы. Оценка схожести строк, которая выполняется в ходе оценки строки, дополняет процесс возражения на основании совпадения строк. См. Раздел 4.5 Возражения и апелляции.

7.10.1 Область оценки схожести строк

Оценка схожести строк включает предварительное сравнение каждой запрашиваемой строки и ее вариантов со строками и их вариантами в соответствующих категориях. Оценка проводится с использованием всех строк в наборе вариантных строк, независимо от того, подает ли на них заявку кандидат, как описано ниже. Сравнение выполняется, чтобы определить, являются ли строки визуально похожими до такой степени, что это создает вероятность путаницы¹⁰⁷ у пользователя, в соответствии с Руководством по оценке схожести строк (см. Раздел 7.10.2.3).

Для каждой заявки первичная строка (если она еще не делегирована) и все подлежащие распределению вариантные строки¹⁰⁸ в наборе вариантных строк будут сравниваться со следующим:¹⁰⁹

Существующие делегированные gTLD и все их подлежащие распределению и заблокированные вариантные строки.
Строки gTLD, на которые были поданы заявки в предыдущих раундах регистрации gTLD и которые все еще находятся в процессе рассмотрения,¹¹⁰ а также все их подлежащие распределению и заблокированные вариантные строки.
Существующие, успешно прошедшие оценку¹¹¹ или делегированные¹¹² ccTLD и все их подлежащие распределению и заблокированные вариантные строки..
Строки, в настоящее время запрашиваемые как IDN-домены ccTLD¹¹³ (см. Раздел 7.10.3.3 Строки, аналогичные успешно прошедшим оценку или делегированным ccTLD или их вариантным строкам), и все их подлежащие распределению и заблокированные вариантные строки.
Другие запрашиваемые строки gTLD в текущем раунде приема заявок и все их подлежащие распределению и заблокированные вариантные строки.
Подмножество заблокированных имен¹¹⁴ и их подлежащие распределению вариантные строки.
Все остальные двухбуквенные строки ASCII¹¹⁵ и все их подлежащие распределению и заблокированные вариантные строки.

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

Существующие делегированные gTLD и все их подлежащие распределению вариантные строки.
Строки, которые были запрошены в предыдущих раундах программы New gTLD и которые все еще находятся в процессе рассмотрения,¹¹⁶ и все их подлежащие распределению вариантные строки.
Существующие, успешно прошедшие оценку или делегированные ccTLD и все их подлежащие распределению вариантные строки.
Строки, в настоящее время запрашиваемые как IDN-домены ccTLD (см. раздел 7.10.3.3 Строки, аналогичные успешно прошедшим оценку или делегированным ccTLD или их вариантным строкам), и все их распределяемые вариантные строки.
Другие запрашиваемые строки в текущем раунде приема заявок и все их подлежащие распределению вариантные строки.
Подмножество заблокированных имен¹¹⁷ и всех их подлежащие распределению вариантные строки.
Все остальные двухбуквенные строки ASCII и все их подлежащие распределению вариантные строки.

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

В таблице ниже приведены сравнения, которые будет выполнять комиссия по оценке схожести строк на основе категорий, отмеченных утвердительно. Как отмечалось, следуя Руководству по оценке схожести строк (раздел 7.10.2.3), комиссия по оценке схожести строк может не проводить сравнения для затемненных ячеек с пометкой «Да*», если она придет к выводу, что наборы символов вряд ли будут перепутаны. Сравнения с пометкой «Нет» выполняться не будут.

Таблица 7-4. Область сравнений, выполняемых комиссией по оценке схожести строк

Категории для сравнения		Запрашиваемая строка
Категории для сравнения		Первичная строка	Все подлежащие распределению вариантные строки	Все заблокированные вариантные строки
Существующий домен верхнего уровня Заявка на строку из предыдущего раунда (раундов) программы New gTLD все еще находится в процессе обработки Существующий национальный домен верхнего уровня Запрашиваемый IDN-домен ccTLD Другая запрашиваемая строка Заблокированное имя Любой двухсимвольный код ASCII	Первичная строка	Да	Да	Да*
	Все подлежащие распределению вариантные строки	Да	Да	Да*
	Все заблокированные вариантные строки	Да*	Да*	Нет

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

7.10.2 Методология оценки схожести строк

7.10.2.1 Одинаковые первичные или вариантные строки

Учитываются как прописные, так и строчные формы букв ASCII, и любой вариант использования регистра в строке может быть использована для оценки схожести строк, например «EXAMPLE», «Example» или «example».

Заявки от разных кандидатов со строками из одного и того же набора вариантных строк будут отмечены комиссией по оценке схожести строк как одинаковые.

7.10.2.2 Пакетная обработка строк

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

7.10.2.3 Руководство по оценке схожести строк

Комиссия по оценке схожести строк проведет оценку в соответствии с Руководством по оценке схожести строк, которое будет опубликовано на сайте Программы New gTLD.

7.10.2.4 Процесс для Комиссии по оценке схожести строк

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

Комиссией по оценке схожести строк предусмотрены следующие этапы оценки схожести строк:

Составление списков строк для сравнения:
1. Существующие домены верхнего уровня
2. Строки, запрошенные в предыдущих раундах Программы New gTLD в отношении которых еще не вынесено решение
3. Существующие национальные домены верхнего уровня
4. Запрашиваемые IDN-домены ccTLD
5. Другие запрашиваемые строки
6. Заблокированные имена
7. Двухсимвольные строки ASCII
Рассмотрение всех подлежащих распределению вариантов указанных выше строк с использованием RZ-LGR.
Рассмотрение всех заблокированных вариантов указанных выше строк с использованием RZ-LGR, которые относятся к одному и тому же набору символов (строки, записанные символами разных наборов символов для алфавитов Kana и Han, как разрешено RZ-LGR).
Определение того, какие заблокированные вариантные строки исключить из оценки, если таковые имеются, и составление обоснования решения. Любое решение комиссии должно основываться на Руководстве по оценке схожести строк (см. Раздел 7.10.2.3), исходя из малой вероятности смешения сравниваемых алфавитов строк.
Идентификация строк в разных заявках, но в одном и том же наборе вариантных строк, чтобы определить, есть ли спорные группы, состоящие из одних и тех же строк или вариантных строк.
Проведение сравнения строк, чтобы определить все наборы визуально похожих строк на основе Руководства по оценке схожести строк (см. Раздел 7.10.2.3), и подготовка документов о результатах анализа. Инструменты для определения визуального сходства не используются в этом процессе, но комиссия по оценке схожести строк может использовать автоматические средства и данные, предоставленные соответствующим сообществом, использующим один и тот же набор символов, чтобы повысить эффективность процесса сравнения.
Вынесение решений и регистрация (вместе с обоснованием) результатов оценки схожести строк.

7.10.3 Результаты оценки схожести строк

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

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

ICANN опубликует результаты оценки схожести строк на странице результатов оценки на сайте Программы New gTLD.

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

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

7.10.3.1 Строки, визуально похожие на существующие домены верхнего уровня или их вариантные строки

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

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

7.10.3.2 Строки, визуально похожие на строки и их варианты, в отношении которых еще не завершен процесс рассмотрения после предыдущих раундов Программы New gTLD

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

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

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

7.10.3.3 Строки, визуально похожие на успешно прошедшие оценку или делегированные ccTLD или их вариантные строки

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

7.10.3.4 Строки, визуально похожие на запрашиваемый IDN-домен ccTLD

Запрос на регистрацию IDN-домена ccTLD можно подать в рамках ускоренной процедуры рассмотрения заявок на регистрацию национальных IDN-доменов верхнего уровня или другой процедуры, которая придет ей на смену, в любой момент.¹¹⁸ Процесс подачи заявки на регистрацию IDN-домена ccTLD отделен и независим от процесса подачи заявки на gTLD. Если будет установлено, что запрашиваемая строка gTLD визуально похожа на любой запрошенный IDN-домен ccTLD¹¹⁹, то комиссия по оценке схожести строк сообщит об этом как о конкуренции с запрошенным IDN-доменом ccTLD, но не будет формировать спорную группу, поскольку спорные группы предназначены только для запрашиваемых строк gTLD. Для урегулирования споров ICANN будет использовать подход, описанный ниже.

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

Заявка на gTLD, которая успешно прошла все соответствующие этапы оценки, включая урегулирование споров и принятие решения по спорным группам (если такие имели место) и имеет право на заключение базового Соглашения об администрировании домена верхнего уровня, считается завершенной, и, следовательно, такая заявка на gTLD (первичная строка и запрашиваемые вариантные строки, если такие есть) не будет дисквалифицирована новым поданным запросом на IDN-домен ccTLD. Кандидат на IDN-домен ccTLD будет проинформирован соответствующим образом.
Валидированная¹²⁰ запрошенная строка первичного IDN-домена ccTLD будет считаться завершившей процесс. Таким образом, такая строка IDN-домена ccTLD (первичная строка IDN-домена ccTLD и запрошенные вариантные строки, если такие есть) не будет дисквалифицирована новой заявкой на gTLD.

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

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

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

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

7.10.3.5 Строки, тождественные запрашиваемым строкам и их вариантам или визуально похожие на них

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

Если будет установлено, что какая-либо запрошенная строка или любая из ее вариантных строк идентичны или визуально похожи на любые другие запрошенные строки или любые их вариантные строки, то наборы вариантных строк¹²¹ для этих заявок будут помещены в спорную группу Комиссией по оценке схожести строк. Спорная группа содержит по меньшей мере две запрашиваемые строки, которые идентичны или визуально похожи друг на друга или их варианты. Для получения дополнительной информации о спорных группах и принятии решений по спорным группам см. Модуль 5 Урегулирование споров в отношении спорных групп.

Спорные группы также будут включать информацию о прямом споре (строка A может быть спутана со строкой B) или косвенном споре через транзитивность визуального сходства строки (строка A может быть спутана со строкой B, а строка B может быть спутана со строкой C, но строка A и строка C не могут быть спутаны) или транзитивность визуального сходства вариантной строки (например, строка A может быть спутана со строкой B-вариант-1, а строка B-вариант-2 может быть спутана со строкой C, но строка A и строка C не могут быть спутаны). Косвенный спор может быть разрешен так, чтобы позволить рассмотрение заявок как на строку A, так и на строку C в случае, если заявка на строку B не будет принята к рассмотрению, но если строка B будет принята к рассмотрению, рассмотрение заявок на строки А и С станет невозможным .

7.10.3.6 Строки, визуально похожие на заблокированное имя

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

7.10.3.7 Визуальное сходство строки с двухсимвольной строкой ASCII

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

7.10.3.8 Результаты оценки схожести строк

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

Таблица 7-5. Результаты для заявки на gTLD по итогам выполнения Комиссией по оценке схожести строк

	Если будет установлено, что запрашиваемая строка или любой элемент ее набора вариантных строк:
	Совпадает с	Является вариантом	Визуально схожа с (но не является вариантом)
Существующий домен верхнего уровня	Заявка не будет принята.	Заявка может быть рассмотрена, если действующий оператор регистратуры также является кандидатом.	Рассмотрение заявки не может быть продолжено.
Заявка на строку из предыдущего раунда (раундов) программы New gTLD все еще находится в процессе обработки¹²³	Заявка не будет принята.	Заявка не будет принята.	Рассмотрение заявки приостановлено до завершения оценки ранее запрошенной строки. Рассмотрение заявки может быть продолжено, если строка gTLD из предыдущего раунда была отозвана или ее оценка оказалась отрицательной.
Существующий национальный домен верхнего уровня	Заявка не будет принята.	Заявка не будет принята.	Рассмотрение заявки не может быть продолжено.
Запрашиваемый IDN-домен ccTLD	Заявка не будет принята, если строка IDN-домена ccTLD прошла валидацию. Рассмотрение заявки приостановлено на время оценки строки ccTLD.	Заявка не будет принята, если строка IDN-домена ccTLD прошла валидацию. Рассмотрение заявки приостановлено на время оценки строки ccTLD.	Рассмотрение заявки может быть продолжено, если она успешно прошла все соответствующие этапы оценки и соответствует требованиям для заключения базового Соглашения об администрировании домена верхнего уровня на момент подачи заявки на национальный IDN-домен верхнего уровня. В противном случае рассмотрение заявки будет приостановлено до завершения оценки ccTLD, и ее рассмотрение может быть продолжено, если запрошенный IDN-домен ccTLD будет отозван или его оценка окажется отрицательной.
Другая запрашиваемая строка gTLD	Заявка помещается в спорную группу.	Заявка не перемещается в спорную группу, если другая запрашиваемая строка является вариантной строкой того же кандидата. Заявка помещается в спорную группу, если другая запрашиваемая строка подана другим кандидатом.	Заявка помещается в спорную группу.
Заблокированное имя	Заявка не будет принята.	Заявка не будет принята.	Рассмотрение заявки не может быть продолжено.
Двухсимвольная строка ASCII	Заявка не будет принята.	Заявка не будет принята.	Рассмотрение заявки не может быть продолжено.

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

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

Делопроизводство по оспариванию результатов оценки будет проходить в соответствии со стандартом «явно ошибочное заключение» (“clearly erroneous” standard of review). В частности, поставщик услуг по оспариванию результатов оценки должен принять заключение Комиссией по оценке схожести строк, кроме тех случаев, когда комиссия: (1) не следовала надлежащим процедурам или (2) не рассмотрела/не запросила необходимые существенные доказательства или информацию.

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

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

Если комиссия по оценке схожести строк не обнаружит никаких фактических, процедурных или системных ошибок:

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

7.10.5 Исключение для брендовых TLD

Если запрошенная строка соответствует критериям для брендовых TLD, (см. Раздел 7.1.2.4 Заявки на брендовые TLD), и этот запрашиваемый брендовый TLD признан схожим в соответствии в Таблицей 7-5. Результаты для заявки на gTLD по итогам выполнения Комиссией по оценке схожести строк выше и, в связи с этим, либо его рассмотрение не может быть продолжено, либо он помещается в спорную группу, то этот кандидат на брендовый TLD будет иметь возможность внести изменения в свою строку. Правила внесения изменений в строки брендовых TLD приведены в Разделе 5.3 Запросы на изменение брендовой строки.¹²⁴

Информацию о жеребьевке, которая будет проводиться для определения номера приоритета заявки и общего порядка, в котором она будет обрабатываться ICANN см. в Разделе 3.7.1 Приоритизационная лотереядля получения информации .↩︎
Также могут существовать различные требования к запросам на внесение изменений в заявку, в том числе к тому, какие типы классификаций заявок могут или не могут быть изменены. Дополнительную информацию см. в Разделе 7.1.3 Изменение типа заявки, а полную информацию о запросах на внесение изменений в заявку см. в Разделе 3.8 Запросы на внесение изменений в заявку.↩︎
После подачи заявки кандидат не может изменить тип заявки с/на заявку от сообщества. См. Раздел 3.8 Запросы на внесение изменений в заявку.↩︎
Запрос на внесение изменений в заявку с целью изменения статуса заявки от сообщества не допускается. Информацию о допустимых запросах на внесение изменений см. в Разделе 3.8 Запросы на внесение изменений в заявку .↩︎
Ожидается, что кандидат и ICANN могут обсудить конкретные формулировки правил регистрации сообщества в ходе оценки обязательств регистратур, чтобы найти предлагаемые формулировки в Соглашении об администрировании домена верхнего уровня, соответствующие критериям RCE (см. Раздел 3.8.4.2 Запросы на внесение изменений в заявку: После получения уведомления от ICANN кандидат должен подать запрос на внесение изменений в заявку, который отражает согласованные формулировки Соглашения об администрировании домена верхнего уровня для предлагаемых правил регистрации сообщества. ICANN не отклоняет предлагаемые правила регистрации сообщества сразу или автоматически без предварительного обсуждения с кандидатом. Однако, если кандидат не представит необходимый запрос на внесение изменений в заявку в течение установленного периода времени, как определено в Разделе 3.8 Запросы на внесение изменений в заявку, это приведет к отрицательному результату оценки RCE.↩︎
См. соответствующие инструкции в группе вопросов 7 gTLD сообщества в Приложении 1 Вопросы заявки для получения подробной информации о требованиях и предлагаемом подходе к разработке правил регистрации сообщества, которые будут оцениваться в рамках RCE.↩︎
Полный список категорий строк, которые можно квалифицировать как географические наименования, см. в Разделе 7.5 Географические наименования.↩︎
В этом разделе подробно описан процесс получения эксклюзивного права, который позволяет кандидатам подать заявку на имя из списка зарезервированных имен. Этот процесс применяется исключительно к именам Красного Креста и Красного Полумесяца (КК и КП), Международного олимпийского комитета (МОК), международных межправительственных организаций (МПО) и международных неправительственных организаций (МНПО).↩︎
Дополнительную информацию о брендовых доменах верхнего уровня и требованиях см. в Спецификации 13 9.3(i) базового Соглашения об администрировании домена верхнего уровня (Приложение 4).↩︎
В случае спора с другими кандидатами, кандидат на брендовый TLD может изменить изменить свою строку, чтобы добавить дескриптор к доменному имени, и в этом случае доменное имя может больше точно не совпадать с текстовыми элементами зарегистрированного товарного знака. См. Раздел 5.3 Запросы на внесение изменений в брендовую строку.↩︎
Не всегда строка, точно повторяющая название бренда, будет эксплуатироваться как брендовая. Возможна ситуация, в которой кандидат подает заявку на строку, которая соответствует названию бренда, не намереваясь использовать ее в качестве брендового TLD.↩︎
В некоторых случаях кандидат на брендовый TLD может быть освобожден от обязанности следовать Кодексу поведения (Спецификация 9), но не отвечать требованиям Спецификации 13.↩︎
См. также Раздел 3.8 Запросы на внесение изменений в заявку, касающийся требований и оценки.↩︎
Как отмечалось выше, кандидаты, соответствующие требованиям, могут также подать заявку на освобождение от необходимости соблюдать Кодекс поведения для регистратур. См. Раздел 7.4 Оценка возможности освобождения оператора регистратуры от необходимости соблюдения требований Кодекса поведения.↩︎
Кандидаты также смогут подать заявку на варианты «новых» IDN-доменов. См. Раздел 7.1.2.7 Заявки на новые IDN-домены (включая один или несколько вариантов).↩︎
См. Рекомендацию 3.5 Итогового отчета по фазе 1 Ускоренного процесса формирования политики в отношении интернационализированных доменных имен: https://gnso.icann.org/sites/default/files/policy/2023/correspondence/epdp-idns2-leadership-team-et-al-to-gnso-council-et-al-08nov23-en.pdf.↩︎
Тот же источник. См. рекомендации 3.11 и 3.12. Общее количество вариантов, на которые можно подать заявку, основано на расчете в RZ-LGR.↩︎
Тот же источник.↩︎
Тот же источник. См. рекомендацию 3.5.↩︎
См. Итоговый отчет по Фазе 1 Ускоренного процесса формирования политики в отношении интернационализированных доменных имен: https://gnso.icann.org/sites/default/files/policy/2023/correspondence/epdp-idns2-leadership-team-et-al-to-gnso-council-et-al-08nov23-en.pdf.↩︎
МПО — это организация, состоящая в основном из суверенных государств или других межправительственных организаций. МПО создаются на основе договора или иного соглашения, которое служит уставом, создающим группу. В качестве примеров можно привести Организацию Объединенных Наций, Всемирный банк или Европейский союз. Источник: Союз международных ассоциаций, https://uia.org/faq/yb3.↩︎
Обычно определяется как национальное правительство или любой его департамент, агентство или подразделение с соответствующими полномочиями.↩︎
См. Руководство по Программе поддержки кандидатов: https://newgtldprogram.icann.org/en/application-rounds/round2/asp/handbook.↩︎
Для получения дополнительной информации см. результаты PDP по защите идентификаторов МПО и МНПО во всех gTLD: https://gnso.icann.org/en/group-activities/active/igo-ingo.↩︎
Правила преобразования меток DNS в разделе «Примечания по реализации политики» для получения дополнительной информации: https://www.icann.org/en/contracted-parties/consensus-policies/protection-of-intergovernmental-organization-and-international-non-governmental-organization-identifiers-policy/protection-of-igo-and-ingo-identifiers-in-all-gtlds-policy-21-02-2024-en.↩︎
См. Доменные имена специального назначения: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.↩︎
См. RFC 6761: https://tools.ietf.org/html/rfc6761.↩︎
Примечание: ICANN зарезервирует переводы терминов «тест» и «пример» на нескольких языках.↩︎
См. Сообщество ICANN: https://www.icann.org/community.↩︎
См. Региональные интернет-регистратуры: https://aso.icann.org/about/aso-and-nro/rirs/.↩︎
См. группы IETF: https://www.ietf.org/about/groups/.↩︎
См. Итоговый отчет рабочей группы по зарезервированным именам: https://gnso.icann.org/en/issues/new-gtlds/final-report-rn-wg-23may07.htm.↩︎
В результате публикации SAC113 и последующей работы под руководством Правления ICANN домен .INTERNAL был добавлен в список заблокированных имен. См. https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-113-en.pdf.↩︎
См. Базу данных корневой зоны: https://www.iana.org/domains/root/db.↩︎
Сайт Программы New gTLD раунда 2012 года: https://gtldresult.icann.org/applicationstatus/viewstatus.↩︎
Кандидатам следует помнить, что никакие претензии, выдвигаемые после этого момента, приниматься не будут, и поэтому им рекомендуется начать подачу своих заявок как можно раньше и выдвигать все претензии не позднее, чем за 14 дней до окончания периода приема заявок.↩︎
Как указано в Разделе 7.10.1 Область оценки схожести строк, согласно предложению 20251113 Совета GNSO, «соответствующие идентификаторы [связанные с Международным движением Красного Креста и Красного Полумесяца и Международного олимпийского комитета и полными названиями конкретных международных межправительственных организаций] не могут быть предметом оценки схожести строк в рамках Программы New gTLD и соответствующий идентификатор не будет препятствием к подаче заявки на схожую до степени смешения строку другим кандидатом, в ходе оценки». См. полный текст предложения Совета GNSO: https://gnso.icann.org/en/council/resolutions/2020-current#20251113.↩︎
См. Процесс разработки политики в области защиты идентификаторов МПО и МНПО во всех gTLD: https://gnso.icann.org/en/group-activities/active/igo-ingo.↩︎
См. резолюцию Правления 2014.04.30.03: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-of-directors-30-04-2014-en#2.a ↩︎
См. резолюцию Правления 2019.01.27.19: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-27-01-2019-en#2.d.↩︎
См. названия Красного Креста: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#red-cross1. Просим отметить, что этот список - и списки названий МОК и МПО - применимы к именам доменов второго уровня, но при этом они также будут перепрофилированы, чтобы зарезервировать эти же имена на верхнем уровне в контексте Программы New gTLD: раунд 2026 года. Ссылка на столбец «Название» в каждом списке привязана к соответствующим именам.↩︎
См. названия МОК: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IOC.↩︎
См. названия МПО: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IGOs.↩︎
См. «Список неправительственных организаций, имеющих консультативный статуса при Экономическом и Социальном Совете по состоянию на 31 декабря 2022 года»: https://docs.un.org/en/E/2023/INF/5, здесь: https://esango.un.org/civilsociety/displayConsultativeStatusSearch.do?method=search.↩︎
См. список членов GAC: https://gac.icann.org/about/gac-members.↩︎
Соответствующие требованиям кандидаты также могут подать заявку на освобождение от необходимости соблюдать Кодекс поведения (Спецификация 9), см. также раздел 7.4 Оценка освобождения от необходимости соблюдать Кодекс поведения.↩︎
См. Депозитарий товарных знаков: https://trademark-clearinghouse.com/.↩︎
См. Депозитарий товарных знаков: https://trademark-clearinghouse.com/.↩︎
Названия стран и территорий исключаются из процесса на основе рекомендаций Правительственного консультативного комитета, содержащихся в прошлых коммюнике. В этих коммюнике трактуется Принцип 2.2 Принципов GAC в отношении новых gTLD, в котором говорится, что строки, которые являются значимым представлением или сокращением названия страны или территории, должны обрабатываться через ccPDP, а другие географические строки могут быть разрешены в пространстве gTLD, если они согласованы с соответствующим государственным органом или учреждением.↩︎
См. список в стандарте ISO 3166-1: https://www.iso.org/obp/ui.↩︎
Преобразование включает в себя удаление пробелов, добавление знаков препинания и добавление или удаление грамматических артиклей, таких как «the». Перестановкой считается изменение последовательности слов в названии, например, «RepublicCzech» или «IslandsCayman».↩︎
Городским властям, обеспокоенным тем, что строки являются дубликатами, кличками или близкими вариантами названия города, не следует полагаться на процесс оценки в качестве основного средства защиты своих интересов в строке. Вместо этого соответствующие заинтересованные стороны могут подать официальное возражение против заявки, против которой возражает соответствующее сообщество, или могут подать свою собственную заявку на такую строку.↩︎
Пять регионов, признанных ЮНЕСКО (на шести языках ООН): Африка, Арабские государства, Азиатско-Тихоокеанский регион, Европа и Северная Америка, Латинская Америка и Карибский регион (по состоянию на май 2025 года).↩︎
См. документ «Стандартные коды стран или районов для статистического использования (M49)»: https://unstats.un.org/unsd/methodology/m49/, опубликованный по состоянию на октябрь 2025 года.↩︎
См. Правила генерирования меток корневой зоны, версия 6: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
См. список членов GAC: https://gac.icann.org/about/gac-members.↩︎
См. замечания Правления ICANN от 4 марта 2011 года об оценочном отчете GAC по новым gTLD: https://archive.icann.org/en/topics/new-gtlds/board-notes-gac-scorecard-04mar11-en.pdf.↩︎
См. Процессы передачи другой регистратуре: https://www.icann.org/en/contracted-parties/registry-operators/services/registry-transition-processes.↩︎
См. RZ-LGR: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
Определения понятий, связанных с вариантами, см. в Глоссарии.↩︎
См. Справочник по Программе проверки провайдеров услуг регистратур: https://newgtldprogram.icann.org/sites/default/files/documents/rsp-handbook-03jun24-en.pdf.↩︎
См. RFC 9499, раздел 2: https://www.rfc-editor.org/rfc/rfc9499.html#name-names.↩︎
Примеры доменных коллизий см. в Разделе 2.2 отчета по исследования в рамках Проекта по анализу доменных коллизий (NCAP): https://icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf.↩︎
См. отчет по второму исследованию в рамках Проекта по анализу доменных коллизий: https://www.icann.org/en/system/files/files/ncap-study-2-report-05apr24-en.pdf.↩︎
См. резолюцию Правления 2024.09.07.01: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-09-2024-en.↩︎
Дополнительную информацию о том, как разрешались доменные коллизии в последнем раунде, см. здесь: https://www.icann.org/resources/pages/name-collision-2013-12-06-en.↩︎
См. Индикаторы работоспособности технологий идентификаторов (ITHI): https://ithi.research.icann.org/.↩︎
Эта процедура будет доступна на сайте Программы New gTLD.↩︎
Подробнее о том, как строкам назначается приоритет, см. Раздел 3.7 Порядок обработки заявок и приоритизационная лотерея.↩︎
Эта процедура будет доступна на сайте Программы New gTLD: https://newgtldprogram.icann.org/en.↩︎
Эта процедура будет доступна на сайте Программы New gTLD: https://newgtldprogram.icann.org/en.↩︎
См. Устав ICANN, статья 1, раздел 1.1 (а): https://www.icann.org/resources/pages/governance/bylaws-en/#article1.↩︎
Подробнее см. в коммюнике по результатам заседаний Правительственного консультативного комитета (GAC) на конференции ICANN45 в Торонто: https://gac.icann.org/contentMigrated/icann45-toronto-communique, коммюнике GAC по итогам конференции ICANN46 в Пекине: https://gac.icann.org/contentMigrated/icann46-beijing-communique и последующей резолюции Правления ICANN 2014.02.05.NG01: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-meeting-of-the-new-gtld-program-committee-05-02-2014-en; подробнее о консенсусных рекомендациях GAC и их влиянии на раунд 2012 года Программы New gTLD: https://newgtlds.icann.org/en/applicants/gac-advice#gac-1-applicant-advisories.↩︎
В базовых Соглашениях об администрировании домена верхнего уровня между ICANN и операторами регистратур, заключенных в рамках раунда 2012 года Программы New gTLD, термины «добровольные обязательства регистратур» и «RVC» отсутствовали, а вместо них использовался термин «конкретные обязательства по обеспечению общественных интересов» (в прошлом также неофициально использовались термины «добровольные PIC» и «частные PIC»). В базовом Соглашении об администрировании домена верхнего уровня для раунда 2026 года Программы New gTLD будет использоваться термин «конкретные добровольные обязательства по обеспечению общественных интересов» для обозначения того, что мы сейчас называем «добровольными обязательствами регистратур» или «RVC». Этот подход соответствует существующей структуре и формулировкам Спецификации 11 базового Соглашения об администрировании домена верхнего уровня, а также процедуре разрешения споров в области обеспечения общественных интересов (PICDRP) ICANN, которая остается процедурой разрешения споров при рассмотрении предполагаемых жалоб на возможное несоблюдение оператором регистратуры одного или нескольких обязательных PIC и PIC в качестве защитных мер, а также будущих утвержденных RVC в своем Соглашении об администрировании домена верхнего уровня. См. Спецификацию 11 в Приложении 4 Базовое Соглашение об администрировании домена верхнего уровня и Раздел 1.2.17 Процедуры разрешения споров после делегирования.↩︎
См. Процедуру урегулирования споров в области обеспечения общественных интересов (PICDRP): https://www.icann.org/picdrp-en.↩︎
Этот пункт отражает Спецификацию 11 базового Соглашения об администрировании домена верхнего уровня, раздел 3(b), с поправками от 5 апреля 2024 года. Для целей базового Соглашения об администрировании домена верхнего уровня «Злоупотребление DNS» определяется как вредоносное ПО, ботнеты, фишинг, фарминг и спам (когда спам служит механизмом доставки для других форм злоупотребления DNS), как эти термины определены в разделе 2.1 SAC 115 — Отчет SSAC об основанном на функциональной совместимости подходе к решению проблемы со злоупотреблением DNS: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-115-en.pdf. См. раздел 4.1 на стр. 2 Глобальной поправки 2024 года к Соглашениям об администрировании домена верхнего уровня: https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-global-amendment-05-04-2024-en.pdf.↩︎
Базовое Соглашение об администрировании домена верхнего уровня является результатом обширных консультаций с сообществом. ICANN будет рассматривать вопрос о внесении изменений в соглашение только в исключительных обстоятельствах, таких как ситуации, в которых уникальные правовые, юрисдикционные или нормативные вопросы юридически препятствуют выполнению организацией базового Соглашения об администрировании домена верхнего уровня в существующей форме. См. Раздел 1.2.15 Заключение соглашения.↩︎
См. коммюнике по результатам заседаний Правительственного консультативного комитета (GAC) на конференции ICANN46 в Пекине: https://gac.icann.org/contentMigrated/icann46-beijing-communique.↩︎
См. резолюцию Правления ICANN 2014.02.05.NG01: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-meeting-of-the-new-gtld-program-committee-05-02-2014-en.↩︎
См. Приложение 2 к резолюции Правления ICANN 2014.02.05.NG01: https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf.↩︎
В Коммюнике по результатам заседаний GAC в Пекине на конференции ICANN46 (см. https://gac.icann.org/contentMigrated/icann46-beijing-communique) был определен неисчерпывающий список строк, которые были применены в раунде 2012 года Программы New gTLD, и Правлению было рекомендовано, чтобы PIC в качестве меры защиты применялись к этим запрашиваемым строкам. GAC распределил эти идентифицированные строки на соответствующие подгруппы.↩︎
См. коммюнике по результатам заседаний Правительственного консультативного комитета (GAC) на конференции ICANN46 в Пекине: https://gac.icann.org/contentMigrated/icann46-beijing-communique.↩︎
Тот же источник.↩︎
Тот же источник.↩︎
Тот же источник.↩︎
См. сайт Программы New gTLD: https://newgtldprogram.icann.org/.↩︎
См. текущие консенсусные политики ICANN: https://www.icann.org/consensus-policies-en.↩︎
Дополнительными услугами регистратуры считаются такие услуги, предлагаемые провайдером услуг регистратур, которые не относятся к критически важным функциям (то есть услуги DNS, правильное разрешение DNSSEC, EPP, RDDS и временное депонирование данных). См. более подробное объяснение того, что является дополнительными услугами регистратуры в Разделе 1.1A-D Политики анализа услуг регистратур (см. https://www.icann.org/rsep-en). Подробнее о критически важных функциях см. в Разделе 6 Спецификации 10 базового Соглашения об администрировании домена верхнего уровня (Приложение 4).↩︎
Если для исполнения утвержденного RVC требуется применение утвержденной услуги регистратуры, само обязательство должно быть включено в Спецификацию 11 применимого базового Соглашения об администрировании домена верхнего уровня, а утвержденная услуга регистратуры должна быть включена в Приложение A к базовому Соглашению об администрировании домена верхнего уровня.↩︎
В качестве ответа на группу вопросов 20 Дополнительная информация и вспомогательные материалы в Приложении 1 Вопросы заявки кандидат может включить дополнительную информацию и сопроводительные материалы, которые могут представлять интерес для общественности или иметь отношение к заявке. Например, кандидат может включить ссылки на свои отдельные соглашения с третьей стороной и свои дополнительные обязательства за рамками Соглашения об администрировании домена верхнего уровня. Ответы кандидата на этот вопрос будут носить исключительно информационный характер и не будут оцениваться или иметь обязательную силу для кандидата в соответствии с Соглашением об администрировании домена верхнего уровня. Тем не менее, эти ответы будут открыты для рассмотрения и комментирования общественностью. Соответственно, кандидатам следует тщательно обдумать, хотят ли они раскрывать дополнительную информацию (и какую именно) в ответах на группу вопросов 20. Например, она может быть использована третьей стороной для поддержки возражения, но также может помочь устранить опасения третьей стороны и избежать потенциального возражения.↩︎
Предполагается, что кандидат и ICANN могут обсудить конкретные формулировки RVC в ходе оценки обязательств регистратур, чтобы согласовать предлагаемые формулировки Соглашения об администрировании домена верхнего уровня, которые соответствуют критериям RCE (см. Раздел Запросы на внесение изменений в заявку. Рабочий процесс 2). ICANN не отклоняет предлагаемое RVC напрямую или автоматически без предварительной переписки с кандидатом.↩︎
См. сайт Программы New gTLD: https://newgtldprogram.icann.org/.↩︎
Пять критериев оценки RVC отражают этот фундаментальный принцип, который был признан Правлением ICANN, когда оно поручило корпорации ICANN внедрить критерии и процессы оценки для рассмотрения обязательств, предложенных кандидатами для включения в применимые Соглашения об администрировании домена верхнего уровня: «Для того чтобы заключить какое-либо соглашение, ICANN должна убедиться, что предлагаемые условия (включая любые обязательства по обеспечению общественных интересов) отвечают интересам выполнения миссии ICANN, которая заключается в обеспечении стабильной и безопасной работы систем уникальных идентификаторов интернета». (См. обоснование резолюций Правления ICANN 2024.06.08.08 – 2024.06.08.10: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-08-06-2024-en#section2.b).↩︎
Если кандидат считает, что такие обязательства, не предложенные для включения в Соглашение об администрировании домена верхнего уровня, могут представлять интерес для общественности или иметь отношение к заявке, кандидат может включить их в качестве ответа на группу вопросов 20 Дополнительная информация и сопроводительные материалы в Приложении 1 Вопросы заявки для рассмотрения и комментирования общественностью. Ответы кандидата на этот вопрос будут носить исключительно информационный характер и не будут оцениваться или иметь обязательную силу для кандидата в соответствии с Соглашением об администрировании домена верхнего уровня. Соответственно, кандидатам следует тщательно обдумать, хотят ли они раскрывать дополнительную информацию (и какую именно) в ответах на группу вопросов 18. Например, она может быть использована третьей стороной для поддержки возражения, но также может помочь устранить опасения третьей стороны и избежать потенциального возражения.↩︎
В критерии 4 намеренно используется слово «следует» (а не «должно»). См. RFC2119 Ключевые слова для использования в RFC для указания уровней требований: https://datatracker.ietf.org/doc/html/rfc2119 («Это слово или прилагательное «РЕКОМЕНДОВАННЫЙ» означает, что в некоторых обстоятельствах могут существовать веские основания для игнорирования конкретного элемента, но необходимо понять и тщательно взвесить все последствия, прежде чем выбрать другой подход»). Могут возникнуть обстоятельства, при которых RVC, дублирующее требования применимой консенсусной политики или законодательства, может быть утверждено по собственному усмотрению ICANN, например, если этот тип RVC необходим для выполнения консенсусных рекомендаций GAC.↩︎
См. Приложение 4 Базовое Соглашение об администрировании домена верхнего уровня, Соглашение об аккредитации регистратора: https://www.icann.org/resources/pages/registrars/registrars-en и текущие консенсусные политики ICANN: https://www.icann.org/consensus-policies-en.↩︎
См. дополнительную справочную информацию в резолюции Правления ICANN 2024.06.08.08 - 2024.06.08.10: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-08-06-2024-en#section2.b.↩︎
Устав ICANN гласит, что «ICANN не должна регулировать (то есть вводить правила и ограничения) деятельность служб, использующих уникальные идентификаторы интернета, или контент, который эти службы передают или предоставляют, за пределами полномочий, явно обозначенных в Разделе 1.1(a)...». (См. Устав ICANN, статья 1, раздел 1.1(c): https://www.icann.org/resources/pages/governance/bylaws-en/#article1). После обширных обсуждений и консультаций с сообществом о том, как Устав влияет на оценку RVC, Правление ICANN постановило, что ICANN следует исключить из Соглашений об администрировании домена верхнего уровня раунда 2026 года «любые RVC и другие сопоставимые обязательства регистраторов, ограничивающие контент в gTLD».↩︎
Если кандидат на gTLD сообщества желает, чтобы его правила регистрации сообщества были оценены в рамках процедуры оценки приоритетности заявок от сообществ (CPE), он должен предложить эти правила на предмет включения в Спецификацию 12 применимого базового Соглашения об администрировании домена верхнего уровня при подаче заявки от сообщества. Такая политика является обязательным условием для участия заявки в CPE (см. Раздел 5.4 Оценка приоритетности заявок от сообществ).↩︎
Ожидается, что кандидат и ICANN могут обсудить конкретные формулировки правил регистрации сообщества в ходе оценки обязательств регистратур, чтобы найти предлагаемые формулировки в Соглашении об администрировании домена верхнего уровня, соответствующие критериям RCE (см. Раздел 3.8.4.2 Запросы на внесение изменений в заявку: После получения уведомления от ICANN кандидат должен подать запрос на внесение изменений в заявку, который отражает согласованные формулировки Соглашения об администрировании домена верхнего уровня для предлагаемых правил регистрации сообщества. ICANN не отклоняет предлагаемые правила регистрации сообщества сразу или автоматически без предварительного обсуждения с кандидатом. Однако, если кандидат не представит необходимый запрос на внесение изменений в заявку в течение установленного периода времени, как определено в Разделе 3.8 Запросы на внесение изменений в заявку, это приведет к отрицательному результату RCE.↩︎
См. процедуру урегулирования споров по ограничениям регистрации (RRDRP): https://www.icann.org/rrdrp-en и процедуру запросов на внесение изменений в gTLD сообщества: https://www.icann.org/resources/pages/community-gtld-change-requests-en.↩︎
Если кандидат на gTLD сообщества считает, что дополнительные правила регистрации, которые он планирует внедрить, но не предлагает включить в применимое Соглашение об администрировании домена верхнего уровня, могут представлять интерес для общественности или иметь отношение к заявке, он может включить их в качестве ответа на группу вопросов 20 Дополнительная информация и сопроводительные материалы в Приложении 1 Вопросы заявки, чтобы общественность могла их рассмотреть и прокомментировать. Ответы кандидата на этот вопрос будут носить исключительно информационный характер и не будут оцениваться (например, они не будут учитываться в рамках оценки приоритетности заявок от сообществ (CPE)) или иметь обязательную силу для кандидата в рамках Соглашения об администрировании домена верхнего уровня. Соответственно, кандидатам следует тщательно обдумать, хотят ли они раскрывать дополнительную информацию (и какую именно) в ответах на группу вопросов 20. Например, она может быть использована третьей стороной для поддержки возражения, но также может помочь устранить опасения третьей стороны и избежать потенциального возражения.↩︎
См. Правила генерирования меток корневой зоны: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
Первичная строка любой вариантной строки используется для определения набора вариантных строк согласно Правилам генерирования меток корневой зоны. Набор содержит первичную строку, все подлежащие распределению вариантные строки и все заблокированные вариантные строки.↩︎
Например, кандидат может подать заявку только на подлежащие распределению вариантные строки, но не может подать заявку на заблокированные вариантные строки, как это определено Правилами генерирования меток корневой зоны. См. Раздел 3.1.9.1 Правила для IDN-доменов и их вариантов.↩︎
См. Подтверждение обязательств 24.2, Итоговый отчет о последующих процедурах, применимых к новым gTLD, стр. 108: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎
Такие строки называются визуально похожими.↩︎
В будущем, после следующего раунда регистрации новых gTLD, некоторые из этих вариантных подлежащих распределению строк будут распределены (и включены в эту категорию).↩︎
Согласно предложению 20251113 Совета GNSO, «соответствующие идентификаторы [связанные с Международным движением Красного Креста и Красного Полумесяца и Международного олимпийского комитета и полными названиями конкретных международных межправительственных организаций] не могут быть предметом оценки схожести строк в рамках Программы New gTLD и соответствующий идентификатор не будет препятствием к подаче заявки на схожую до степени смешения строку другим кандидатом, в ходе оценки». См. полный текст предложения Совета GNSO: https://gnso.icann.org/en/council/resolutions/2020-current#20251113. См. Раздел 7.2.2 Зарезервированные имена.↩︎
Это строки, которые не имеют следующего статуса: «Withdrawn», «RA Terminated» или «Delegated». Все строки, находящиеся в процессе обработки после раунда регистрации новых gTLD 2012 года, опубликованы по адресу: https://gtldresult.icann.org/. См. также резолюцию Правления 2025.09.14.05-2025.09.14.06 о процедуре прекращения рассмотрения оставшихся заявок раунда 2012 года, которые были отклонены: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-09-2025-en#section1.c.rationale.↩︎
Список всех IDN-доменов ccTLD, успешно прошедших оценку, см. по адресу https://www.icann.org/resources/pages/string-evaluation-completion-2014-02-19-en.↩︎
Все домены верхнего уровня, которые в настоящее время находятся в корневой зоне, можно найти по адресу https://data.iana.org/TLD/tlds-alpha-by-domain.txt (список регулярно обновляется).↩︎
Строки, которые в настоящее время запрашиваются в ходе ускоренной процедуры рассмотрения заявок на регистрацию национальных IDN-доменов верхнего уровня (см. https://www.icann.org/resources/pages/fast-track-2012-02-25-en) или в соответствии с политикой в отношении IDN ccTLD, которая может заменить указанную ускоренную процедуру рассмотрения заявок на IDN ccTLD. Возможен период, когда одновременно будут действовать ускоренная процедура рассмотрения заявок на регистрацию национальных IDN-доменов верхнего уровня и политика в отношении IDN-доменов ccTLD. В таком случае предполагаемые строки IDN-доменов ccTLD из обоих процессов будут включены в оценку.↩︎
Более широкое определение заблокированных имен приведено в Разделе 7.2.1 Заблокированные имена. Для оценки схожести строк применимы только две категории: (i) доменные имена специального назначения и (ii) органы, связанные с ICANN, IANA и IETF и инфраструктурой интернета. Другие категории заблокированных имен при оценке схожести строк использоваться не будут.↩︎
Все двухбуквенные коды ASCII зарезервированы для присвоения кода страны независимым агентством по поддержке стандарта ISO 3166.↩︎
Строка из предыдущего раунда программы New gTLD будет иметь один из следующих статусов: «Active», «In Contracting», «On-hold» или “«n PDT». Также см. страницу с информацией о статусе заявок: https://gtldresult.icann.org/application-result/applicationstatus.↩︎
Более широкое определение заблокированных имен приведено в Разделе 7.2.1 Заблокированные имена. Для оценки схожести строк применимы только две категории: (i) доменные имена специального назначения и (ii) органы, связанные с ICANN, IANA и IETF и инфраструктурой интернета. Другие категории заблокированных имен при оценке схожести строк использоваться не будут.↩︎
В настоящее время ccNSO работает над процессом разработки политики в области национальных IDN-доменов (ccNSO PDP4 в отношении процедуры отбора строк национальных IDN-доменов верхнего уровня), который призван заменить ускоренную процедуру рассмотрения заявок на регистрацию национальных IDN-доменов верхнего уровня. После утверждения и реализации политики в области IDN-доменов ccPDP4 будет создан еще один механизм для кандидатов на IDN-домены ccTLD, который также будет применим здесь.↩︎
Запрашиваемая строка IDN-домена ccTLD — это строка, которая была отправлена в ICANN через систему подачи заявок на IDN-домен ccTLD и проходит оценку строки.↩︎
Термин «валидированный» по существу означает «успешно прошедший оценку». Этот термин был в первый раз определен в документе «Ускоренная процедура рассмотрения заявок на регистрацию национальных IDN-доменов верхнего уровня» и подтвержден в первоначальном отчете ccPDP4. Подробности см. в разделе «Валидация строк и вариантов национальных IDN-доменов верхнего уровня» первого отчета ccPDP4.↩︎
По определению в Разделе 3.1.8.3.1.3 Выбор первичных и/или вариантных строк с использованием RZ-LGR.↩︎
Более широкое определение заблокированных имен приведено в Разделе 7.2.1 Заблокированные имена. Для оценки схожести строк применимы только две категории: (i) доменные имена специального назначения и (ii) органы, связанные с ICANN, IANA и IETF и инфраструктурой интернета. Другие категории заблокированных имен при оценке схожести строк использоваться не будут.↩︎
Это строки, которые не имеют следующего статуса: «Withdrawn», «RA Terminated» или «Delegated». Все строки, находящиеся в процессе обработки после раунда регистрации новых gTLD 2012 года, опубликованы по адресу: https://gtldresult.icann.org/. См. также резолюцию Правления 2025.09.14.05-2025.09.14.06 о процедуре прекращения рассмотрения оставшихся заявок раунда 2012 года, которые были отклонены: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-09-2025-en#section1.c.rationale.↩︎
Запрос на изменение брендовой строки не связан с процессом замены строк. См. Раздел 5.1 Заменяющие строки.↩︎