Руководство

кандидата

Черновая версия, апрель 2011

г.Рекомендованная итоговая

версия

Модуль 2

Обратите внимание, что это только «рекомендованная» Руководства

кандидата, которая не была одобрена Советом директоров как

итоговачерновая версия. Потенциальные кандидаты не должны

основываться исключительно на изложенных здесь положениях новой

программы gTLD, поскольку программа все еще находится на

рассмотрении и не утверждена.

152 апреля ноября 20110 г.

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

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

Начальная оценка включает следующие элементы:

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

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

См. раздел 2.3 ниже.

2- Модуль Процедуры оценки 2.1 Проверка биографических данных Проверка биографических данных будет проводиться в двух областях:

(a) Основные сведения о коммерческой и преступной деятельности; и (б) История операций киберсквоттинга.

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

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

См. документ http://www.world-exchanges.org/files/statistics/excel/EQUITY109.xls В совокупности эти требования соответствуют требованиям к проверке, которую будет проводить ICANN, или превосходят их.

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

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

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

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

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

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

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

Каждый тип включает несколько элементов.

Проверка строки: первая проверка затрагивает строку gTLD, на которую подана заявка, с целью установить:

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

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

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

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

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

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

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

Модуль 3, "Процедуры разрешения конфликтов"), относящиеся ко всем типам схожести.

Проверка на схожесть выполняется независимой комиссией экспертов по схожести строк.

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

Комиссия выполняет оценку схожести, которая может привести к путанице, рассматривая четыре набора обстоятельств, при сравнении:

Строк gTLD, на которые подана заявка, с существующими TLD и зарезервированными Строк gTLD, на которые подана заявка, с другими строками gTLD, на которые поданы Строк gTLD, на которые подана заявка, со строками, запрошенными как IDN ccTLD; и Двухсимвольных строк IDN gTLD, на которые Схожесть с существующими TLD или зарезервированными именами. Эта проверка подразумевает перекрестное сравнение каждой строки, на которую подана заявка, со списком существующих строк TLD и зарезервированных имен с целью определить, не являются ли две строки настолько схожими, что это может привести к путанице среди пользователей.

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

Проверка идентичных строк также учитывает варианты элементов кода, которые перечислены в релевантной таблице IDN. Например, протоколы воспринимают эквивалентные метки как альтернативные формы одной метки, аналогично тому, как «foo» и «Foo»

воспринимаются как альтернативные формы одной метки (RFC 3490).

Все строки TLD, находящиеся сейчас в корневой зоне, можно найти странице http://iana.org/domains/root/db/.

Таблицы IDN, представленные на рассмотрение ICANN, доступны по адресу http://www.iana.org/domains/ idn-tables/.

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

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

В Модуле 4, «Процедура разрешения разногласий в отношении строк».

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

Схожесть со строками TLD, запрошенными как IDN ccTLD. – Строки gTLD из поданных заявок также проверяются на схожесть со строками TLD из заявок, поданных в ускоренном режиме IDN ccTLD (см. http://www.icann.org/en/topics/idn/fast-track/).

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

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

Подобным образом, заявка на IDN ccTLD, прошедшая оценку (т.е. «проверенная»), будет считаться завершенной, и соответственно, не будет отстранена на основании разногласий в отношении строк с новой поданной заявкой на gTLD.

При отсутствии соответствующих завершенных заявок или если у заявки на gTLD отсутствует требуемое утверждение соответствующего правительства или органа государственной, проверенная заявка на IDN ccTLD будет иметь преимущество, и заявка на gTLD не будет утверждена. Термин «проверенная» определен в документе «Ускоренная программа ввода доменов IDN ccTLD», который можно найти по адресу http://www.icann.org/en/topics/idn.

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

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

a) любой односимвольной меткой (в любом сценарии) и b) любой из возможных двухсимвольных комбинаций в формате ASCII.

Если строка gTLD, на которую подана заявка, будет признана слишком схожей с описанными выше элементами a) или b), она не пройдет эту проверку.

См. http://icann.sword-group.com/algorithm/ В том случае, если кандидат перечислил заявленные варианты в своем заявлении (см. подраздел 1.3.3), комиссия выполняет оценку перечисленных строк для признания строк вариантами в соответствии с таблицей IDN кандидата.

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

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

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

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

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

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

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

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

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

2.2.1.2 Зарезервированные имена Заявки, поданные на строки gTLD, сравниваются со списком зарезервированных имен высшего уровня во избежание отображения в этом списке строки gTLD.

Список зарезервированных имен высшего уровня

AFRINIC IANA-SERVERS NRO

ALAC ICANN RFC-EDITOR

APNIC IESG RIPE

ARIN IETF ROOT-SERVERS

ASO INTERNIC RSSAC

CCNSO INVALID SSAC

GAC ISTF TLD

GNSO LACNIC WHOIS

GTLD-SERVERS LOCAL WWW

IAB LOCALHOST

IANA NIC

*Обратите внимание, что в дополнение к вышеприведенным строкам ICANN зарезервирует перевод терминов «тест» и «пример» на нескольких языках.

Остальные строки зарезервированы только в форме, указанной выше.

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

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

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

2.2.1.3 Проверка стабильности DNS Эта проверка позволяет определить, может ли строка gTLD из поданной заявки дестабилизировать работу DNS.

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

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

Любой новый оператор реестра TLD может получить непредвиденные запросы, а некоторые TLD могут получить нестандартно большое количество таких запросов. Дополнительную информацию см. в отчете Совещательного комитета по безопасности и стабильности (SSAC) по данной теме по адресу http://www.icann.org/en/committees/security/sac045.pdf.

Некоторые общедоступные статистические данные также можно найти по адресу http://stats.l.rootservers.org/.

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

2.2.1.3.1 Стабильность DNS: процедура проверки Новые имена gTLD не должны отрицательно влиять на безопасность или стабильность работы DNS. В течение периода начальной оценки ICANN будет проводить предварительную проверку набора заявок, поданных на строки gTLD, чтобы:

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

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

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

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

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

Если комиссия определяет, что строка не соответствует соответствующим техническим стандартам или создает неблагоприятные условия, влияющие на пропускную способность, время ответа, целостность данных или связность ответов, передаваемых интернетсерверам или оконечным системам, заявка не проходит начальную оценку и никакие другие проверки не проводятся. Если выяснится, что строка может негативно повлиять на безопасность и стабильность DNS, по завершении проверки стабильности DNS Требования к строкам были пересмотрены в соответствии с исправлениями RFC 1123, реализуемыми IETF. См. документ http://tools.ietf.org/html/draft-liman-tld-names-04.

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

На этот период функциональные возможности меток TLD, допустимых в соответствии с IDNA2008, но недопустимых согласно IDNA2003, будут ограничены.

2.1.5 Строка U-метка должна состоять только из символов одинаковой направленности или соответствовать всем требованиям 2.2 Метка должна соответствовать применимым критериям в соответствии с документом ICANN Руководящие принципы внедрения многоязычных доменных имен. См. http://www.icann.org/en/ topics/idn/implementation-guidelines.htm. В нем содержится следующий список ограничений, который не является исчерпывающим:

2.2.1 Все элементы кода в одной метке должны Unicode: свойство алфавита Unicode.

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

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

Часть III. Требования политики для общих доменов верхнего уровня – Эти требования относятся ко всем потенциальным доменам высшего уровня, указанным в заявке на строку gTLD.

3.1 Указанные в заявке строки gTLD в формате ASCII должны содержать не менее трех визуально различимых символов. Не допускается использование двухсимвольных строк в формате ASCII во избежание конфликта с действующими и возможными кодами стран в соответствии со стандартом ISO 3166-1.

3.2 Указанные в заявке строки gTLD в сценариях IDN должны содержать в сценарии не менее двух Note that the Joint ccNSO-GNSO IDN Working Group (JIG) has made recommendations that this section be revised to allow for single-character IDN gTLD labels. See the JIG Final Report at http://ccnso.icann.org/node/15245. Implementation models for these recommendations are being developed for community discussion.

Названия стран и территорий исключены из процесса на основании рекомендаций правительственного консультационного комитета, представленных в недавних сообщениях, связанных с толкованием принципа 2.2 «Принципов GAC» в применении к новым строкам gTLD. Данный принцип утверждает обработку строк, являющихся значимым представлением или аббревиатурой названия страны или территории, посредством запланированного ccPDP; и разрешает использование других строк, связанных с географическими названиями, в пространстве gTLD по соглашению с соответствующими правительствами или органами государственной власти.

i. она представляет собой код альфа-3, ii. она представляет собой полную форму iii. она представляет собой краткую форму определенным агентством по внедрению v. это составной компонент имени страны, составных названий стран», или перевод vi. это преобразование или перестановка изменение последовательности в полной «RepublicCzech» или «IslandsCayman».

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

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

См. документ http://www.unesco.org/new/en/unesco/worldwide/.

См. http://unstats.un.org/unsd/methods/m49/m49regin.htm.

Указанная в заявке строка gTLD, которая соответствует одной из перечисленных выше четырех категорий, считается представляющей географическое название.

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

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

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

Кандидат отвечает за:

определение, попадает ли строка gTLD, на которую он подает заявку, в одну из перечисленных выше категорий;

установление соответствующих правительств или органов государственной власти;

определение, какой уровень правительственной поддержки требуется.

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

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

См. http://gac.icann.org/gac-members Правительство также вправе отозвать документы, направленные в поддержку заявки, на более поздних стадиях, даже после передачи новой строки gTLD, если оператор реестра отклоняется от условий, первоначально установленных в соглашении.

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

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

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

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

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

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

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

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

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

2.2.2.1 Проверка технических и организаторских В своей заявке кандидат отвечает на ряд вопросов (см. вопросы 24 – 44 в формуляре заявления), предназначенных для сбора информации о технических возможностях кандидата и его планов по эксплуатации предлагаемого gTLD.

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

2.2.2.2 Финансовая проверка При подаче заявки кандидат отвечает на ряд вопросов (см. вопросы 45-50 в формуляре заявления), предназначенных для сбора информации о финансовых возможностях кандидата для обеспечения работы реестра gTLD и финансовом планировании подготовки долгосрочной стабильной работы нового gTLD.

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

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

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

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

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

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

2.2.3.1 Определения Под услугами регистрации подразумеваются:

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

распространение файлов зоны TLD, эксплуатация серверов зоны реестра, а также распространение контактной и иной информации, относящейся к регистрации сервера доменного имени в TLD в соответствии с положениями соглашения о регистрации;

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

3. любые иные продукты и услуги, которые может предоставить исключительно оператор реестра по причине его назначения оператором Предлагаемые услуги регистрации будут изучены с целью определения, могут ли они привести к значительным проблемам стабильности или безопасности. Примеры услуг, предоставляемых действующими реестрами, см. по адресу http://www.icann.org/en/registries/rsep/. В большинстве случаев, эти предлагаемые услуги успешно проходят данный запрос.

Услуги регистрации, предоставляемые на данный момент реестрами gTLD, можно найти в приложениях соглашения о регистрации. См. http://www.icann.org/ en/registries/agreements.htm.

Полное описание услуг регистрации см. по адресу http://www.icann.org/en/registries/rsep/rsep.html.

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

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

Стабильность. Влияние на стабильность означает, что предложенная услуга регистрации (1) не отвечает соответствующим официально-применимым стандартам, опубликованным надежным, признанным и полномочным органом стандартизации, например соответствующие RFC "Standards-Track" или "Best Current Practice", спонсируемые IETF, или (2) создает условие, негативно влияющее на пропускную способность, время ответа, целостность данных или связность ответов, передаваемых Интернет-серверам или оконечным системам, функционирующими в соответствии со всеми официально-применимыми стандартами, например, соответствующими RFC "Standards-Track" или "Best Current Practice", и основанными на информации о передаче полномочий оператора реестра или услугах регистрации.

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

получение данных от регистраторов относительно регистрации доменных имен и распространение файлов зоны TLD;

распространение контактной или другой информации относительно регистраций расширения безопасности DNS.

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

Все дополнительные услуги регистрации, уникальные для предлагаемого реестра gTLD, должны быть подробно описаны. Рекомендации по составлению описания услуг регистрации приведены на странице http://www.icann.org/en/registries/rsep/rrs_sample.html.

2.2.3.3 Содержимое зоны TLD ICANN регулярно получает запросы относительно использования различных типов записи в зоне реестра по мере освоения организациями различных технических и бизнес-моделей. К допустимому содержимому зоны TLD относится:

записи Apex NS и соединительные логические схемы типа «in-bailiwick glue» для DNS-серверов записи NS и соединительные логические схемы «in-bailiwick glue» для DNS-серверов зарегистрированных в TLD имен;

записи DS для зарегистрированных в TLD имен;

записи, связанные с подписанием зоны TLD (RRSIG, DNSKEY, NSEC и NSEC3).

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

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

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

Если в процессе предварительного определения выявлена вероятность возникновения значительных проблем, связанных с безопасностью или стабильностью (в соответствии с подразделом 2.2.3.1), при использовании предлагаемой услуги, заявка будет отмечена как требующая расширенной проверки комиссией по технической оценке услуг регистрации RSTEP (см. http://www.icann.org/en/registries/rsep/ rstep.html) Эта проверка, если применимо, осуществляется в период расширенной оценки (см. раздел 2.3).

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

2.2.4 Отзыв заявки кандидатом Кандидат, не прошедший начальную оценку, может отозвать свою заявку на этой стадии и запросить частичное возмещение (см. подраздел 1.5 модуля 1).

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

Географические названия (см. подраздел 2.2.1.4). В данном случае дополнительная плата за расширенную оценку не предусмотрена.

Демонстрация технических и операционных возможностей (см. подраздел 2.2.2.1). В данном случае отсутствует дополнительная плата за Демонстрация финансовых возможностей (см.

подраздел 2.2.2.2). В данном случае отсутствует дополнительная плата за расширенную оценку.

Услуги регистрации (см. подраздел 2.2.3).

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

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

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

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

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

2.3.2 Техническая/операционная или финансовая расширенная оценка Следующие правила применимы к расширенной оценке технических и операционных возможностей кандидата или его финансовых возможностей, как описано в подразделе 2.2.2.

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

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

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

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

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

Никакие другие проверки не проводятся.

2.3.3 Процедура расширенной оценки услуг Этот раздел применим к расширенной оценке услуг регистрации, как описано в подразделе 2.2.3.

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

Группа проверки обычно будет состоять из трех членов, в зависимости от сложности предлагаемых услуг. Если совет состоит из 3 членов, проверка проводится в течение 30–45 дней. В случаях, если требуется группа из 5 членов, это будет определено до того, как начнется расширенная оценка. Если комиссия состоит из пяти экспертов, проверка может занять не более 45 дней.

Стоимость проверки RSTEP будет покрываться кандидатом через оплату проверки услуг регистрации.

См. процедуры оплаты в разделе 1.5 модуля 1.

Проверка группой RSTEP начинается только при получении платежа.

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

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

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

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

Это происходит во время проверки на схожесть строк в период начальной оценки. Комиссия в рамках своей работы может также проверить таблицы IDN, отправленные кандидатами.

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

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

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

Комиссия по финансовой оценке проверяет каждую заявку на соответствие деловым, финансовым и организационным критериям, приведенным в руководстве кандидата, чтоб определить, являются ли финансовые возможности кандидата достаточными для См. http://icann.org/en/topics/new-gtlds/open-tenders-eoi-en.htm.

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

Официальное назначение и объявление о привлечении поставщиков будет размещено на веб-сайте ICANN до начала подачи заявок.

2.4.3 Кодекс поведения членов комиссий Целью Кодекса поведения («Кодекс») новой программы gTLD («Программа») является предотвращение фактических и очевидных конфликтов интересов и неэтичного поведения со стороны любого члена комиссии («Член комиссии»).

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

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

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

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

не использовать личные повестки или не одобренные ICANN повестки в оценке заявок;

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

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

(Существенными подарками считаются подарки стоимостью более 25 долл. США).

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

Конфликты интересов. Члены комиссий должны действовать в соответствии с документом «Руководство по разрешению конфликтов интересов в рамках новой программы gTLD» (см. подраздел 2.4.3.1).

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

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

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

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

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

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

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

Члены комиссий и непосредственные члены семьи:

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

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

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

Определения Член комиссии по оценке: членом комиссии по оценке является любое физическое лицо, имеющее отношение к проверке заявки. К таким лицам относятся основные, второстепенные и возможные сторонние члены комиссии, привлеченные ICANN для проверки новых заявок на gTLD.

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

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

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

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

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

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

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

конкурирующие наборы.

оценка одного или всех четырех элементов:

· Технические и организационные возможности · Географические названия · Услуги регистрации Но НЕ для схожести строк или стабильности DNS Приложение: список составных названий стран В рамках политики, проводимой ICANN, ограничения на использование обозначений стран или регионов в заявке на домен gTLD соответствуют полю свойств стандарта ISO 3166-1.

Номинально стандарт ISO 3166-1 имеет поле English short name (краткое английское название), которое является общим названием страны и на которое могут распространяться подобные ограничения; однако в некоторых случаях указанное в этом поле название не является общеупотребительным. Данный перечень предназначен для добавления дополнительных защищенных элементов, полученных из определений в стандарте ISO 3166-1. Объяснение различных классов приведено ниже.

(Британская территория в (Архипелаг Чагос) Индийском океане) bn Brunei Darussalam (Бруней- B1 Brunei (Бруней) Даруссалам) cv Cape Verde (Кабо-Верде) C So Tiago (Сантьягу) ky Cayman Islands (Каймановы C Grand Cayman (Большой cc Cocos (Keeling) Islands A Cocos Islands (Кокосовые (Кокосовые (Килинг) острова) острова) co Colombia (Колумбия) C Malpelo Island (Остров km Comoros (Коморские острова) C Anjouan (Анжуан) ck Cook Islands (Острова Кука) C Rarotonga (Раротонга) cr Costa Rica (Коста-Рика) C Coco Island (Остров Кокос) fk Falkland Islands (Malvinas) B1 Falkland Islands (Фолклендские острова (Фолклендские острова) (Мальвинас)) fo Faroe Islands (Фарерские A Faroe (Фареры) острова) pf French Polynesia (Французская C Austral Islands (Австралийские tf French Southern Territories C Amsterdam Islands (Острова территории) gp Guadeloupe (Гваделупа) C la Dsirade (Ла-Дезираде) hm Heard Island and McDonald Islands A Heard Island (Остров Херд) (Остров Херд и Острова Макдоналд) va Holy See (Vatican City State) A Holy See (Святой престол) (Святой престол (Городгосударство Ватикан)) (Исламская Республика Иран) kp Korea, Democratic People’s C North Korea (Северная Корея) Republic of (Демократическая Республика Корея) kr Korea, Republic of (Республика C South Korea (Южная Корея) la Lao People’s Democratic Republic B1 Laos (Лаос) (Лаосская НародноДемократическая Республика) (Ливанская Республика) mk Macedonia, the Former Yugoslav B1 ** Republic of (Бывшая Югославская Республика Македония) mh Marshall Islands (Маршалловы C Jaluit (Джалуит) Острова) mu Mauritius (Маврикий) C Agalega Islands (Острова fm Micronesia, Federated States of B1 Micronesia (Микронезия) (Федеративные Штаты Микронезии) md Moldova, Republic of (Республика B1 Moldova (Молдова) Молдова) mp Northern Mariana Islands C Mariana Islands (Марианские (Северные Марианские острова) острова) ps Palestinian Territory, Occupied B1 Palestine (Палестина) (Палестинская автономия) pg Papua New Guinea (Папуа – C Bismarck Archipelago ru Russian Federation (Российская B1 Russia (Россия) Федерация) sh Saint Helena, Ascension, and A Saint Helena (Остров Святой Tristan de Cunha (Острова Святой Елены) Елены, Вознесения и Тристан-даКунья) kn Saint Kitts and Nevis (Сент-Китс и A Saint Kitts (Сент-Китс) pm Saint Pierre and Miquelon (Сен- A Saint Pierre (Сен-Пьер) Пьер и Микелон) vc Saint Vincent and the Grenadines A Saint Vincent (Сент-Винсент) (Сент-Винсент и Гренадины) st Sao Tome and Principe (Сан-Томе A Sao Tome (Сан-Томе) и Принсипи) sb Solomon Islands (Соломоновы C Santa Cruz Islands (Острова za South Africa (Южная Африка) C Marion Island (Остров Марион) gs South Georgia and the South A South Georgia (Южная Sandwich Islands (Южная Георгия Георгия) и Южные Сандвичевы острова) (Шпицберген и Ян-Майен) sy Syrian Arab Republic (Арабская B1 Syria (Сирия) Республика Сирия) tw Taiwan, Province of China B1 Taiwan (Тайвань) (Тайвань, провинция Китая) tz Tanzania, United Republic of B1 Tanzania (Танзания) (Объединенная Республика Танзания) tl Timor-Leste (Тимор-Лешти) C Oecussi (Окуси) tt Trinidad and Tobago (Тринидад и A Trinidad (Тринидад) tc Turks and Caicos Islands (Острова A Turks Islands (Острова Теркс) Теркс и Кайкос) (Объединенные Арабские Эмираты) us United States (Соединенные B2 America (Америка) um United States Minor Outlying C Baker Island (Остров Бейкер) Islands (Внешние малые острова Соединенных Штатов) ve Venezuela, Bolivarian Republic of B1 Venezuela (Венесуэла) (Боливарская Республика Венесуэла) vg Virgin Islands, British (Виргинские B1 Virgin Islands (Виргинские vi Virgin Islands, US (Виргинские B1 Virgin Islands (Виргинские Поддержка Список составных названий стран будет поддерживаться и публиковаться сотрудниками ICANN.

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

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

Если код ISO удаляется из стандарта ISO 3166-1, все записи в данном реестре, происходящие от этого кода, должны удаляться.

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

Класс A. Краткое английское название по ISO 3166-1 состоит из нескольких составных частей, тогда как страна состоит из четко выраженных Класс B. Краткое английское имя ISO 3166-1 (1) или полное английское имя ISO 3166-1 (2) содержит дополнительные сведения о типе страны, к которому принадлежит страна, которые часто не используются при упоминании страны. Например, таким коротким названием для страны «Боливарская Республика Венесуэла» для обычного ** Название «Македония» состоит из отдельных частей в контексте данного списка, однако вследствие непрекращающихся споров, перечисленных в документах ООН, между Греческой Республикой разрешения спора. См. документ http://daccess-ddsny.un.org/doc/UNDOC/GEN/N93/240/37/IMG/N9324037.pdf.

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

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

Правомочность вычисляется по порядку классов. Например, если термин можно извлечь из класса А и из класса C, он приводится только как класс A.

[Письмо должно быть представлено на официальном бланке] ICANN Suite 330, 4676 Admiralty Way Marina del Rey, CA Обратить внимание: процесс оценки новых общих доменов верхнего уровня (gTLD) Тема: письмо в поддержку домена [запрашиваемый домен TLD] Настоящим письмом подтверждается, что [орган государственной власти] полностью поддерживает запрос на домен [TLD], направленный в ICANN от [кандидат] в рамках программы новых общих доменов верхнего уровня. В качестве лица, занимающего позицию [министр/секретарь/должность], автор письма обладает полномочиями выражать мнение [орган государственной власти] по этому вопросу. [Пояснения, касающиеся правительственной организации, отдела, подразделения, компании или агентства, которые наделены соответствующими функциями.] Общий домен верхнего уровня будет использоваться следующим образом [следует пояснить, каковы условия использования кандидатом запрашиваемого имени. Эти условия могут затрагивать такие аспекты как: право регистрировать название, ценовой режим, структуры управления.] Предложение было разработано [орган государственной власти/подразделение] совместно с кандидатом.

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

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

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

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

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

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

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

С уважением, Подпись соответствующего органа государственной власти