Глоссарий
Приведенный ниже глоссарий содержит значения и, где применимо, аббревиатуры терминов, которые часто встречаются в Руководстве кандидата. Для удобства поиска термины отсортированы в алфавитном порядке согласно алфавиту английского языка. Данный список не является исчерпывающим.
Таблица G1. Глоссарий
| Термин | Аббревиатура | Значение |
|---|---|---|
| раунд 2012 года | Раунд рассмотрения заявок в рамках Программы New gTLD, начавшийся в 2012 году. | |
| раунд 2026 года | Раунд рассмотрения заявок в рамках Программы New gTLD, который начался в 2026 году и является предметом настоящего Руководства кандидата. | |
| A-Label | ASCII-форма метки IDN. Все операции, определенные в DNS, используют исключительно метки A-label. Метка A-label начинается с префикса "xn--", за которым следует строка, которая является действительным результатом применения алгоритма Punycode [RFC3492], при чем максимальная длина ASCII-символов составляет 59. | |
| Механизмы подотчетности | Предусмотренные Уставом ICANN механизмы, позволяющие анализировать и пересматривать действия ICANN (см. Раздел 2.7 Механизмы подотчетности). Эти механизмы включают в себя: наделенное полномочиями сообщество, пересмотр ранее принятых решений, процесс независимых проверок и офис омбудсмена. | |
| Административная проверка и подготовка ко Дню объявления результатов | Выполняемый вручную процесс, в ходе которого проводится административная комплексная проверка (см. Раздел 3.2 Административная проверка и подготовка ко Дню объявления результатов) и верификация получения платы за рассмотрение заявки, а также предоставляется время для подготовки ICANN к Дню объявления результатов (см. Раздел 3.4 День объявления результатов). | |
| Рекомендация | Рекомендации, предоставляемые Консультативным комитетом в Правление ICANN. | |
| Консультативный комитет | AC | Официально признанный Уставом ICANN1 орган, который отвечает за предоставление Правлению ICANN рекомендаций относительно политики, соответствующей миссии и сфере компетенции ICANN. Четыре признанных Уставом консультативных комитета это: Консультативный комитет At-Large, Правительственный консультативный комитет, Консультативный комитет системы корневых серверов и Консультативный комитет по безопасности и стабильности. |
| Подтверждения | Подтверждения из Итогового отчета2 по последующим процедурам, применимым к новым gTLD, указывают на то, что эта Рабочая группа считает некоторый конкретный элемент Программы New gTLD 2012 года по-прежнему уместным или, как минимум, приемлемым для его сохранения в последующих процедурах. | |
| Подтверждения с внесением изменений | Как подтверждение, описанное в Итоговом отчете по последующим процедурам и применимое к новым gTLD, но используются в случаях, когда Рабочая группа рекомендует относительно небольшую корректировку политик или выполнения Программы New gTLD 2012 года. | |
| Американский стандартный код для обмена информацией | ASCII | Стандарт кодировки символов для отображения набора из 95 (ориентированных на английский язык) печатных и 33 управляющих символов – всего 128 кодовых точек. |
| Апелляционный процесс | Апелляция | Механизм, позволяющий соответствующим сторонам обжаловать заключение Комиссии по рассмотрению возражений. См. Раздел 4.5.9.1 Подача апелляции. |
| Кандидат | Организация, которая подала заявку в ICANN на новый gTLD путем представления своей заявки в период приема заявок. | |
| Оценка кандидата | Оценка кандидата проводится после того, как заявка либо (а) прошла оценку строки и не входит в спорную группу, либо (б) прошла оценку строки и победила в спорной группе. Она проводится параллельно с рассмотрением заявки (см. Модуль 7 Процедуры оценки строки и заявки) на основе приоритетного номера заявки, если только другие процессы не препятствуют продвижению заявки. Оценка кандидата состоит из двух обязательных проверок: проверки основных данных и оценки финансовых и операционных элементов. Оценка кандидата состоит из двух обязательных проверок: проверки основных данных и оценки финансовых и операционных элементов. См. Раздел 6.1 Проверка основных данных Раздел 6.2 Оценка финансовых и операционных элементов. | |
| Руководство кандидата | AGB | Руководство кандидата на участие в Программе New gTLD, в котором описываются требования к процессам подачи и рассмотрения заявок. |
| Программа поддержки кандидатов | ASP | Отдельная от процесса подачи заявок на gTLD программа, которая позволяет предоставить скидку на базовую сумму сборов ICANN, связанных с Программой New gTLD, соответствующими критериям отбора кандидатам, продемонстрировавших потребность в финансовой помощи. См. Приложение 11 Программа поддержки кандидатов. |
| Заявка | Заявка на новый gTLD, поданная в соответствии с условиями и положениями Руководства кандидата. Заявка состоит из заполненных анкет с ответами на вопросы заявки, любых подтверждающих документов и любой другой информации, которая может быть представлена кандидатом по запросу ICANN. См. Приложение 1 Вопросы заявки. | |
| Запрос на внесение изменений в заявку | ACR | Кандидаты могут направить запрос на внесение изменений в заявку, в том числе, внести добавление или изменение в добровольные обязательства регистратуры или правила регистрации сообщества в ответ на опасения, высказанные в возражении. См. Раздел 3.8 Запросы на внесение изменений в заявку. |
| Рассмотрение заявки | При рассмотрении заявки выполняются следующие проверки и оценки: проверка провайдера услуг регистратур, проверку географических наименований, проверка зарезервированных имен, оценка Плана снижения рисков для высокорисковой строки, оценка освобождения от соблюдения требований Кодекса поведения, оценка обязательств регистратуры, оценка добровольных обязательств регистратуры, оценка правил регистрации сообщества, оценка соответствия требованиям для брендовых TLD и оценка вариантных строк. Среди них обязательной является только проверка провайдера услуг регистратур. См. Модуль 7 Процедуры оценки строки и заявки. | |
| Приоритетность заявки | Каждая заявка получит номер приоритета посредством приоритизационной лотереи (см. Раздел 3.7 Порядок обработки заявок и приоритизационная лотерея). Номер приоритета определяет порядок обработки всех заявок в раунде. | |
| Вопросы заявки | Вопросы, на которые кандидаты дают ответы. В ходе раунда 2012 года они были включены в качестве приложения к Модулю 2 Руководства кандидата. См. Приложение 1 Вопросы заявки. | |
| Раунд приема заявок | Полная последовательность этапов обработки заявок, полученных в течение одного периода приема заявок на gTLD. Условия и положения Руководства кандидата действуют для одного раунда приема заявок (см. Приложение 10 Условия и положения). Все последующие раунды приема заявок будут проводиться в соответствии с обновленной версией Руководства кандидата (см. Раздел 2.8 Последующие раунды приема заявок. | |
| Период приема заявок | Интервал времени, в течение которого можно создавать и подавать заявки. См. Раздел 3.1.1 Период приема заявок. | |
| Система подачи заявок | Система, позволяющая кандидатам безопасно передавать информацию, необходимую для участия в одном или нескольких компонентах Программы New gTLD. В их число входит участие в программе поддержки кандидатов, кандидатов на предварительную оценку провайдеров услуг для регистратур и кандидатов на gTLD. См. раздел «Система управления заявками на TLD (TAMS)». | |
| Запрашиваемая строка gTLD | Строка, являющаяся предметом заявки на gTLD. | |
| Проверка основных данных | Проверка основных данных позволяет защитить общественные интересы при распределении критически важных интернет-ресурсов и, следовательно, управлять новыми gTLD могут только зарекомендовавшие себя корпорации, организации или учреждения с хорошей репутацией. См. Раздел 6.1 Проверка основных данных. | |
| Базовое Соглашение об администрировании домена верхнего уровня | Базовое RA | Версия Соглашения об администрировании домена верхнего уровня с ICANN, которое заключают кандидаты, получившие gTLD, до делегирования нового gTLD. В нем определены юридические, операционные, технические и другие обязательства оператора регистратуры в области управления gTLD, а также соответствующие права и обязанности ICANN. К базовому Соглашению об администрировании домена верхнего уровня можно добавить одну или более спецификаций в зависимости результата рассмотрения заявки и обстоятельств, связанных с каждым конкретным gTLD. Базовое Соглашение об администрировании домена верхнего уровня является результатом обширных консультаций с сообществом. ICANN будет рассматривать вопрос о внесении изменений в соглашение только в исключительных обстоятельствах, таких как уникальные правовые, юрисдикционные или нормативные вопросы, которые юридически препятствуют выполнению организацией базового Соглашения об администрировании домена верхнего уровня в существующем виде. |
| Заблокированные имена | На определенные строки, включая подлежащие распределению вариантные строки, запрещена подача заявок и их делегирование во всех будущих раундах gTLD согласно положениям действующей политики. На заблокированные имена не распространяются процедуры получения исключительного права на подачу заявки на зарезервированное имя, и на них не может подать заявку ни одна организация. См. Раздел 7.2.1 Заблокированные имена. | |
| Идентификация заблокированных имен | При указании кандидатом строки, на которую подается заявка, система автоматически проверяет, не является ли строка кандидата, а также все ее вариантные строки, заблокированным именем. | |
| Брендовый TLD | Обозначение домена верхнего уровня, эксплуатация которого осуществляется организацией-владельцем товарного знака, соответствующего данному доменному имени, в соответствии с условиями Соглашения об администрировании домена верхнего уровня, заключенного данной организацией с ICANN. См. Раздел 7.7 Оценка соответствия требованиям для брендовых TLD и Приложение 4 Базовое Соглашение об администрировании домена верхнего уровня. Чтобы TLD считался брендовым, оператор регистратуры должен подать заявку на получение статуса брендового TLD, а соответствующий бренду товарный знак должен быть зарегистрирован в Депозитарии товарных знаков. | |
| Оценка соответствия требованиям для брендовых TLD | В ходе оценки соответствия требованиям к брендовому TLD подтверждается, что кандидат соответствует критериям для классификации как брендовый TLD. Успешное присвоение статуса приведет к добавлению Спецификации 13 в базовом Соглашении кандидата об администрировании домена верхнего уровня, которое заключается при условии успешного прохождения кандидатом всех этапов оценки. См. Раздел 7.3 Оценка соответствия критериям определения брендового TLD. | |
| Итоговый отчет CCT | Итоговый отчет по результатам проверки конкуренции, потребительского доверия и потребительского выбора от 8 сентября 2018 года. | |
| Уточняющий вопрос | CQ | Группа оценки может направить кандидату уточняющие вопросы для получения дополнительной информации от кандидата. См. Раздел 1.2.12 Уточняющие вопросы. |
| Закрытый gTLD | Согласно Итоговому отчету Рабочей группы по процессу разработки политики по SubPro, закрытый gTLD — это «TLD, представляющий собой строку, которая является общим названием или термином, в пределах которого домены регистрируются и используются исключительно оператором регистратуры или его аффилированными лицами». См. Раздел 3.1.7 Строки закрытых gTLD/строки исключительного использования. | |
| Оценка освобождения от соблюдения требований Кодекса поведения | Если кандидат предлагает регистрировать все доменные имена в gTLD исключительно для использования оператором регистратуры или для использования его аффилированными лицами и желает отказаться от защиты для себя и своих аффилированных лиц, ICANN может предоставить освобождение от соблюдения требований Кодекса поведения (Спецификация 9 базового Соглашения об администрировании домена верхнего уровня) при условии, что gTLD не является строкой общего пользования, а оператор регистратуры соответствует критериям для получения права на несоблюдение этих требований. См. Раздел 7.4 Оценка возможности освобождения от соблюдения требований Кодекса поведения. | |
| Список строк с риском коллизии | Составляемый ICANN список строк, которые, по определению ICANN, характеризуются высоким риском доменной коллизии (см. Раздел 7.7 Доменная коллизия). | |
| Сообщество | ICANN следует модели с участием многих заинтересованных сторон, в которой частные лица, группы некоммерческих заинтересованных сторон, представители индустрии и правительства, совместно именуемые сообществом ICANN, играют важную роль в основанном на консенсусе подходе к разработке политик. | |
| Заявка от сообщества | Заявка на строку gTLD, которую планируется эксплуатировать в интересах четко обозначенного сообщества. См. Раздел 5.4 Оценка приоритетности заявок от сообществ Эта классификация полностью на усмотрение кандидата. Кандидат, классифицирующий свою заявку, как заявку от сообщества, должен быть готов подтвердить свой статус представителя сообщества, которое он указывает в своей заявке. | |
| Возражение сообщества | Возражение, поданное в связи с существенным несогласием на заявку на gTLD со стороны значительной части сообщества, которому строка gTLD может быть явно или косвенно адресована. См. Раздел 4.5.10.4 Принципы: нарушение прав сообщества. | |
| Оценка приоритетности заявок от сообществ | CPE | Процесс урегулирования споров в отношении строк, который может решить применить кандидат от сообщества. См. Раздел 5.4 Оценка приоритетности заявок от сообществ. |
| Правила регистрации сообщества | Правила регистрации сообщества, приведенные в Соглашении об администрировании домена верхнего уровня («правила регистрации сообщества») — это правила, которые подлежат обязательному включению в соответствующее Соглашение об администрировании домена верхнего уровня при подаче заявок от сообщества. См. Раздел 7.8.4 Правила регистрации сообщества. Эти правила должны определять как минимум то, кто может регистрировать доменные имена в запрашиваемом gTLD, и на каких условиях доменное имя второго уровня может быть принято регистратурой. Операторы регистратур TLD сообщества могут иметь дополнительные правила регистрации вне Соглашения об администрировании домена верхнего уровня, при условии, что они не противоречат требованиям применимых соглашений и политик ICANN. | |
| Оценка правил регистрации сообщества | Предлагаемые правила регистрации сообщества также подлежат оценке и одобрению со стороны ICANN до их включения в Спецификацию 12 Соглашения об администрировании домена верхнего уровня. См. Раздел 7.8.4 Правила регистрации сообщества. | |
| gTLD сообщества | gTLD сообщества эксплуатируется в интересах четко определенного сообщества. | |
| Консенсусная политика | Политика, созданная в рамках процесса разработки политик GNSO, описанного в Приложении А к Уставу ICANN3. Список текущих консенсусных политик доступен на сайте договорных сторон4. | |
| Спор в отношении строк | Ситуация, при которой существует более одной заявки на тождественные или похожие друг на друга строки. См. Раздел 5.2 Споры в отношении строк и процедура их урегулирования. | |
| Спорная группа | Группа заявок, которые были определены как тождественные друг другу или похожие друге на друга строки gTLD согласно оценке схожести строк или после итогам возражения на основании совпадения строк. | |
| Управляемое приостановка | Состояние, которое должны установить вновь делегированные gTLD как минимум на 90 дней, в течение которых на все запросы к этому домену верхнего уровня дается особый ответ, помогающий пользователям понять, что произошла доменная коллизия. См. Раздел 7.2 Доменная коллизия. | |
| Национальный домен верхнего уровня | ccTLD | Класс доменов верхнего уровня, зарезервированных для использования странами, территориям и географическими объектами, включенными в список кодов стран стандарта ISO 3166-1. См. Базу данных корневой зоны5. |
| Делегирование | Процесс, посредством которого в корневую зону вносится новый TLD, а управление регистрацией доменных имен в рамках TLD передается оператору регистратуры. | |
| Поставщик услуг по урегулированию споров | DRSP | Организация, уполномоченная ICANN рассматривать процедуры урегулирования споров в ответ на возражения. См. Раздел 4.5.3 Поставщики услуг по урегулированию споров. |
| Проверка стабильности DNS | Проверка стабильности DNS проводится автоматизированной системой, предназначенной для проверки всех запрашиваемых первичных и вариантных строк. См. Раздел 3.1.8.3 Проверка стабильности DNS. Эта оценка позволяет обеспечить соответствие всех строк обязательным требованиям к строкам, в частности требованиям DNS и имен хостов, требованиям IDNA 2008 для IDN-доменов и RZ-LGR. Кандидаты получают предупреждение, если строка не соответствует этим требованиям, и могут запросить пересмотр автоматической оценки. | |
| Доменное имя | Уникальная буквенная строка, состоящая из двух или более уровней (например, john.smith.name), хранящаяся в базе данных регистратуры. | |
| Система доменных имен | DNS | Глобальная иерархическая система доменных имен. |
| Расширения безопасности системы доменных имен | DNSSEC | DNSSEC обеспечивает безопасность поиска доменных имен в интернете путем внедрения цепочки цифровых подписей в иерархию DNS. |
| Оспаривание результатов оценки | Механизм, позволяющий кандидату оспорить определенные результаты оценки на основании системной, фактической или процедурной ошибки. | |
| Группа оценки | Комиссия, обладающая экспертными знаниями в предметной области (например, Комиссия по оценке схожести строк). Группы оценки используют установленные сообществом критерии для оценки того, соответствует ли кандидат этим критериям. | |
| Существующий домен верхнего уровня | Строка, включенная в список в базе данных корневой зоны6. | |
| Расширенная оценка | EE | Расширенная оценка предоставляет кандидатам дополнительное время на прохождение оценок, начатых на этапе первичной оценки. Второй этап оценки применяется к заявкам, которые не прошли первичную оценку, но имеют право на дальнейшее рассмотрение. См. Раздел 1.2.14.1 Расширенная оценка. |
| Протокол EPP | EPP | Протокол используется для электронной коммуникации между регистратором и регистратурой для выделения доменных имен. |
| Окончательная спорная группа | Окончательные спорные группы формируются по итогам оценки схожести строк. См. Раздел 7.10 Оценка схожести строк. | |
| Итоговый отчет GNSO по результатам процесса разработки политики последующих процедур, применимых к новым gTLD | Итоговый отчет по SubPro | Итоговый отчет7 о процессе разработки политики последующих процедур, применимых к новым gTLD от 20 января 2021 года. |
| Итоговая спорная группа | Спорная группа, которая соответствует следующим критериям для участия в аукционе:
|
|
| Оценка финансовых и операционных элементов | Оценка финансовых и операционных элементов позволяет определить, обладает ли кандидат финансовыми и операционными возможностями для долгосрочного обеспечения работы регистратуры и внедрил ли он разумные меры защиты для обеспечения надежной эксплуатации и решения проблемы злоупотреблений. См. Раздел 6.2 Оценка финансовых и операционных элементов. | |
| Будущие раунды | Программа New gTLD организована вокруг раундов, в рамках которых оцениваются заявки. Будущие раунды (или «последующие раунды приема заявок») относятся ко всем раундам, которые будут проходить после раунда 2026 года. См. Раздел 2.8 Последующие раунды приема заявок. | |
| Консенсусные рекомендации GAC по новым gTLD | Рекомендации, которые Правительственный консультативный комитет предоставляет Правлению ICANN в отношении одной или нескольких заявок на gTLD. См. Раздел 4.3 Консенсусные рекомендации GAC. | |
| Заблаговременное предупреждение со стороны членов GAC | Уведомление, выпущенное GAC в отношении заявки на gTLD, о том, что эта заявка рассматривается как потенциально спорная или проблематичная одним или несколькими правительствами. См. Раздел 4.2 Заблаговременные предупреждения со стороны членов GAC. | |
| Организация поддержки доменов общего пользования | GNSO | Орган ICANN по разработке политики8 для TLD общего пользования, который разработал рекомендации по политике в отношении ввода новых gTLD. |
| Домен общего пользования верхнего уровня | gTLD | Класс доменов верхнего уровня (TLD), к которому относятся домены общего назначения, такие как .com, .net, .edu и .org. К этому классу также относятся домены, связанные с Программой New gTLD. Это такие имена, как .futbol, .istanbul и .pizza, для записи которых используются другие алфавиты и языки. ICANN координирует работу по формированию политик и правил, регламентирующих регистрацию доменных имен в gTLD. |
| Географические наименования | Домен общего пользования верхнего уровня и его подлежащие распределению вариантные метки является географическим наименованием, если оно соответствует любому из следующих критериев: это название (на любом языке) столицы любой страны или территории, указанной в стандарте ISO3166-1; это название города или региона, где кандидат заявляет о намерении использовать gTLD для целей, связанных с этим названием; точно совпадает с названием административно-территориальной единицы, такой как округ, провинция или штат, указанной в стандарте ISO3166-2; или с названием, указанным как регион ЮНЕСКО9 или находящимся в разделе M49 Географических регионов ООН10. Для каждой категории существуют разные квалификационные требования. См. Раздел 7.5 Географические наименования. | |
| Идентификация географических наименований | В рамках идентификации географических наименований комиссия проверит все строки, на которые поданы заявки, и определит, какие строки могут считаться географическими наименованиями, как описано в Разделе 7.5 Географические наименования. Это отдельный процесс, отличный от более развернутого процесса проверки под названием «Проверка географических наименований» (Раздел 7.5.3.2), которая проводится в рамках оценки заявки. | |
| Совет по географическим наименованиям | GNP | Группа экспертов, уполномоченная ICANN проверять запрашиваемые строки TLD на предмет идентификации географических наименований и проверки необходимых документов по ним. |
| Проверка географических наименований | Верификация и развернутый анализ ответов в заявке для строк, определенных как географические. Этот развернутый анализ проводится в ходе рассмотрения заявки. См. Раздел 7.5.3.2 Проверка географических наименований. | |
| Правительственный консультативный комитет | GAC | GAC представляет интересы правительств и межправительственных организаций (МПО) в мультистейкхолдерной структуре ICANN. GAC, как консультативный комитет, созданный согласно Уставу ICANN, предоставляет рекомендации Правлению. Ключевая роль GAC состоит в предоставлении ICANN рекомендаций относительно вопросов общественной политики, особенно по вопросам возможного пересечения деятельности или политик ICANN и национальных законов или международных соглашений. |
| Сбор за подачу заявки на gTLD | Сбор, подлежащий уплате каждым кандидатом для рассмотрения его заявки; может состоять из частичного залога и оплаты полной суммы за каждую поданную заявку. | |
| План снижения высоких рисков | В Разделе 7.7.5 Оценка плана снижения рисков для высокорисковой строки, излагаются конкретные превентивные и корректирующие действия, которые кандидат предпримет для снижения риска доменных коллизий, включая любые коммуникационные действия с затронутыми конечными пользователями. Каждое действие по снижения рисков должно иметь конкретные временные рамки реализации. Общий срок не должен превышать двух лет. | |
| Аукцион ICANN | Аукцион, который проводится ICANN в соответствии с процедурами урегулирования споров в отношении строк. | |
| Правление ICANN | Орган, который рассматривает разработанные сообществом ICANN рекомендации по вопросам политики и передает корпорации ICANN утвержденные принципы политики на предмет их реализации. Правление11 также осуществляет стратегический надзор за корпорацией ICANN, обеспечивая эффективную работу организации в рамках своей миссии и этических норм. | |
| Сообщество ICANN | «Сообщество» | ICANN следует принципам модели с участием многих заинтересованных сторон (мультистейкхолдерной модели), в которой частные лица, группы некоммерческих заинтересованных сторон, представители отрасли и правительств, совместно именуемые сообществом ICANN, играют важную роль в основанном на консенсусе подходе к разработке политик. |
| Корпорация ICANN | корпорация ICANN | Организация12, которая выполняет рекомендации сообщества ICANN под руководством Правления ICANN. |
| Регистратор, аккредитованный ICANN | Организация, заключившая с ICANN Соглашение об аккредитации регистраторов.13 Регистратор имеет доступ, позволяющий ему вносить изменения в регистратуру путем добавления, удаления или уточнения записей доменных имен. | |
| Руководящие указания по выполнению рекомендаций | IG | Один из результатов Итогового отчета по SubPro. В этом случае Рабочая группа настоятельно рекомендует выполнить указанное действие и предполагает, что оно будет выполнено, но признает, что при определенных обстоятельствах могут существовать веские причины не выполнять рекомендуемое действие в точности так, как оно описано. Однако сторона, которой рекомендовано действие, должна приложить все усилия для достижения цели, стоящей за рекомендуемым действием (как указано в обосновании и рекомендации, с которой связаны руководящие указания по выполнению рекомендаций, если таковые имеются), даже если эта цель будет достигнута другим способом. Во всех случаях следует понять и тщательно взвесить полный спектр последствий, прежде чем избрать иной образ действия. Руководящие указания по выполнению рекомендаций обычно относятся к тому, как следует выполнить ту или иную рекомендацию. В руководящих указаниях по выполнению рекомендаций обычно используется термин «следует», указывающий на то, что Рабочая группа рассчитывает на выполнение действия с учетом вышеприведенных оговорок. |
| Группа по проверке выполнения рекомендаций | IRT | Группа по проверке выполнения рекомендаций — это группа волонтеров-представителей сообщества ICANN, которая рассматривает предлагаемые планы реализации, разработанные корпорацией ICANN, и проверяет их на соответствие рекомендациям GNSO, утвержденным Правлением ICANN. Эта группа также отвечает на вопросы и получает объяснения от корпорации ICANN по мере необходимости. Она предоставляет консультации по техническим и операционным деталям, касающимся рассматриваемых рекомендаций. |
| Независимый податель возражения | IO | Сторона, выбранная ICANN для действий исключительно в интересах общественности. Независимый податель возражения (см. Раздел 4.5.4 Независимый податель возражения ) может подавать возражения против заявок на основании нарушения общественных интересов (см. Раздел 4.5.1.3 Основание для возражения: нарушение общественных интересов) и от имени сообщества (см. Раздел 4.5.1.4 Основание для возражения: сообщество). |
| Межправительственная организация | МПО | МПО — это организация, состоящая в основном из суверенных государств или других межправительственных организаций. МПО создаются на основе договора или иного соглашения, которое служит уставом, создающим группу. В качестве примеров можно привести Организацию Объединенных Наций, Всемирный банк и Европейский союз. |
| Интернационализированное доменное имя | IDN-домен | Доменное имя, в котором одна или несколько строк содержат символы, не являющиеся буквами, цифрами или дефисами в кодировке ASCII. Поскольку IDN-домены поддерживают использование символов в кодировке Unicode, в их состав могут входить символы местных языков и алфавитов. Например, 실례.테스트 — доменное имя, полностью состоящее из символов алфавита хангыль. |
| Администрация адресного пространства интернета | IANA | Совокупность функций по координации работы интернета, связанных с назначением уникальных в глобальном масштабе параметров протоколов, включая управление корневой зоной DNS и пространством IP-адресов. Функции IANA выполняет Организация по открытым техническим идентификаторам — аффилированная организация ICANN. |
| Возражение на основании факта нарушения законных прав | Возражение, поданное на основании того, что запрашиваемая строка gTLD нарушает существующие законные права подателя возражения. См. Раздел 4.5.1.2 Основание для возражения: нарушение законных прав. | |
| Возражение в связи с нарушением общественных интересов | Возражение, поданное на основании того, что запрашиваемая строка gTLD противоречит общепринятым правовым нормам морали и общественного порядка, признанным в соответствии с принципами международного права. См. Раздел 4.5.1.3 Основание для возражения: нарушение общественных интересов. | |
| Основной провайдер услуг регистратур | Основной RSP | Основной провайдер услуг регистратур предоставляет как минимум услуги протокола EPP и службы каталогов регистрационных данных, а также осуществляет временное депонирование данных у утвержденного провайдера услуг временного депонирования данных для gTLD. |
| Обязательные обязательства по обеспечению общественных интересов | Обязательные PIC | Обязательные обязательства по обеспечению общественных интересов (см. Раздел 7.8.1. Обязательные обязательства по обеспечению общественных интересов) — это правила или рекомендации, установленные ICANN, которых должен придерживаться оператор регистратуры gTLD для защиты общественных интересов и прав потребителей. Они часто принимаются в ответ на опасения, высказанные GAC. |
| Проект по анализу доменных коллизий | NCAP | В 2017 году Правление поручило SSAC создать NCAP для проведения исследований, связанных с доменными коллизиями в ситуации, когда имя, определенное и используемое в одном пространстве имен, может также появиться в другом именном пространстве. Пользователи и приложения, планирующие использовать имя в одном пространстве имен, могут вместо этого его использовать в другом, что в свою очередь может привести к неожиданному поведению, то есть имя будет использоваться с разными целями в двух пространствах имен. Обстоятельства, приводящие к возникновению доменной коллизии, могут быть как случайными, так и злоумышленными. |
| Оценка Плана снижения рисков для высокорисковой строки | Кандидат на строку, которую ICANN признала создающей высокий риск доменных коллизий и которая прошла этап урегулирования споров в отношении строк, может представить План снижения рисков для высокорисковой строки. Этот план будет рассмотрен техническими экспертами. См. Раздел 7.7.5 Оценка плана снижения рисков для высокорисковой строки. | |
| Исходная оценка риска доменной коллизии | Исходная оценка риска доменной коллизии направлен на выявление строк с высоким риском доменной коллизии, как описано в разделе «Доменная коллизия». См. Раздел 7.7.2 Исходная оценка риска доменной коллизии. Если строка признана высокорисковой, у кандидата будет возможность представить для оценки План снижения рисков, который позволит продолжить рассмотрение заявки в случае одобрения его плана. | |
| Портал для регистратур GDD, предоставляющих услуги в сфере присвоения имен | NSp | Интернет-сервис на сайте ICANN, который обеспечивает для сторон, связанных договорными обязательствами (например, это — заключившие договоры с ICANN операторы регистратур и аккредитованные регистраторы), централизованную площадку для осуществления делового взаимодействия с корпорацией ICANN. Портал способствует оптимизации рабочих процессов и по запросу сообщества был дополнен специализированными функциями, такими как отслеживание дел, многопользовательский корпоративный доступ и структурированные рабочие процессы. Через этот портал пользователи могут задавать вопросы, представлять информацию и запрашивать одобрение. |
| Система имен | См. RFC 9499, раздел 2: https://www.rfc-editor.org/rfc/rfc9499.html#name-names. | |
| Возражение | Возражение, поданное поставщику услуг по урегулированию споров, в соответствии с процедурами этого поставщика услуг. См. Раздел 4.5 Возражения и апелляции. | |
| Податель возражения | Лицо или организация, подавшие возражение против заявки на новый gTLD в соответствующей DRSP. | |
| Учетная запись организации | Информация об организации кандидата, предоставляемая на предварительном этапе подачи заявки. Эта информация включает в себя, среди прочего, информацию о кандидате, основную и дополнительную контактную информацию, а также документы, подтверждающие регистрацию организации. Вопросы, связанные с учетной записью организации, см. в группе вопросов 4 Основные данные о подающем заявку субъекте и его организации в Приложении 1 Вопросы заявки. |
|
| Результаты | Подтверждения, рекомендации по политике и руководящие указания по выполнению рекомендаций, вытекающие из Итогового отчета. | |
| Персональные данные | PII | Информация, представленная в любой форме, позволяющая определить личность лица, к которому она относится. |
| Валидация строк до подачи заявки | Валидация первичных и вариантных строк, включая заменяющие строки, автоматически включена и выполняется через TAMS. См. Раздел 3.1.8 Валидация строк до подачи заявки | |
| Предварительные спорные группы | Все заявки на тождественные друг другу строки в День объявления результатов (см. Раздел 3.4 День объявления результатов будут считаться частью предварительных спорных групп. | |
| Отчет по обзору и оценке реализации Программы | PIRR | Отчет, подготовленный корпорацией ICANN в 2016 году, который представляет собой сборник опыта персонала во время операционной реализации раунда 2012 года Программы New gTLD.14 |
| Процедуры урегулирования споров в области обеспечения общественных интересов | PICDRP | PICDRP — это механизм урегулирования споров, согласно которому в определенных случаях используется группа оценки. Для gTLD, в чьи Соглашения об администрировании домена верхнего уровня включены PICDRP, процедурой может воспользоваться любая сторона, пострадавшая вследствие невыполнения оператором регистратуры взятых обязательств по PIC. PIC и PICDRP входят в число защитных мер, созданных для сообщества в рамках Программы New gTLD 2012 года. |
| Обязательства по обеспечению общественных интересов | PIC | Обязательства по обеспечению общественных интересов — это непреложные обязательства операторов регистратур gTLD перед интернет-сообществом в рамках их договоров с корпорацией ICANN. Их соблюдение подлежит проверке и контролю со стороны корпорации ICANN. (См. также PICDRP и RVC). |
| Регистратор | Rr | Организация, через которую физические и юридические лица (владельцы доменов) регистрируют доменные имена. В процессе регистрации регистратор проверяет соответствие запрашиваемого доменного имени требованиям регистратуры и отправляет информацию о доменном имени соответствующему оператору регистратуры. Регистраторы также отвечают за получение от владельцев доменов необходимых данных и за их публикацию в RDDS. |
| Процедура урегулирования споров по ограничениям регистрации | RRDRP | Формальная процедура, позволяющая официальным учреждениям урегулировать споры, связанные с предусмотренными в Соглашении об администрировании домена верхнего уровня ограничениями регистрации. |
| Регистратура | Ry | Авторитетная основная база данных всех доменных имен, зарегистрированных в каждом домене верхнего уровня. Оператор регистратуры ведет основную базу данных, а также создает файл корневой зоны, позволяющий компьютерам направлять интернет-трафик к доменам верхнего уровня и от них в любой точке мира. |
| Соглашение об администрировании домена верхнего уровня | RA | Соглашение, заключенное между ICANN и оператором регистратуры определенного gTLD, регламентирующее права и обязанности оператора регистратуры и подлежащие исполнению при эксплуатации gTLD. См. Приложение 4 Базовое Соглашение об администрировании домена верхнего уровня. |
| Оценка обязательств регистратуры | RCE | Каждое представленное RVC или правило регистрации сообщества, предложенное на предмет включения в соответствующее Соглашение об администрировании домена верхнего уровня, подлежит этой оценке со стороны ICANN для определения соответствия всем критериям, установленным в настоящем Руководстве кандидата. См. Раздел 7.8.3.2 Оценка обязательств регистратуры. |
| Оператор регистратуры | RO | Организация, которая обслуживает основную базу данных (реестр) всех доменных имен, зарегистрированных в том или ином TLD. Операторы регистратур получают от регистраторов запросы о добавлении, удалении или изменении доменных имен и вносят соответствующие изменения в этот реестр. Оператор регистратуры также обеспечивает функционирование авторитативных DNS-серверов TLD и создает файл корневой зоны. Эта информация позволяет рекурсивным DNS-серверам всего интернета преобразовывать доменные имена в IP-адреса, чтобы подключенные к интернету устройства могли связываться друг с другом. |
| Провайдер услуг регистратур | RSP | Провайдер услуг регистратур — это организация, выполняющая определенные технические операции для оператора регистратуры. |
| Программа проверки провайдеров услуг регистратур | Эта программа позволяет провайдерам услуг для регистратур пройти единую оценку по всем услугам, которые они намерены предоставлять кандидатам. Успешно прошедшие проверку кандидаты получат предварительное одобрение на участие в раунде 2026 года. Кандидатам, чьи заявки включают предварительное одобрение RSP, не потребуется проходить техническую оценку, если предварительное одобрение остается в силе. | |
| Политика анализа услуг регистратур | RSEP | Политика, регулирующая оценку предлагаемых услуг регистратуры оператором регистратуры или кандидатом. |
| Группа технической оценки услуг регистратуры | RSTEP | Группа экспертов в области проектирования, управления и реализации сложных систем и стандартов-протоколов, которые используются в инфраструктуре интернета и DNS. Членов RSTEP выбирает председатель группы. Все члены RSTEP и председатель заключили соглашение, обязующее их рассматривать вопросы, стоящие перед комиссией, нейтрально и в соответствии с определенными критериями безопасности и стабильности. |
| Добровольные обязательства регистратуры | RVC | RVC — это обычно добровольные обязательства, которые кандидаты могут взять на себя для преодоления опасений третьих сторон в отношении запрашиваемой строки gTLD или для продвижения общественных интересов, повышения доверия сообщества или принятия дополнительных мер защиты в отношении работы gTLD. После утверждения ICANN на основании оценки обязательств регистратуры (RCE), ожидается, что они будут включены в Спецификацию 11 Соглашения об администрировании домена верхнего уровня в качестве договорных обязательств. |
| Зарезервированные имена | Определенные строки, включая их вариантные строки, подлежащие распределению, которые обычно недоступны для регистрации, поскольку они зарезервированы для определенных организаций. Зарезервированные строки включают имена, связанные с определенными международными и межправительственными организациями (ограниченный список международных МПО-МНПО). Эти имена могут быть запрошены только соответствующей организацией при помощи процедуры получения исключительного права на подачу заявки на зарезервированное имя, которая требует соответствующих документов, как указано в тексте применимых процедур.. | |
| Идентификация зарезервированных имен | При указании кандидатом строки, на которую подается заявка, система автоматически проверяет, не находится ли строка кандидата, а также все ее вариантные строки, в списке зарезервированных имен. См. Раздел 7.2.2.2 Идентификация зарезервированных имен | |
| Проверка зарезервированных имен | Процесс проверки зарезервированных имен позволит определить, подала ли соответствующая организация заявку на зарезервированную строку, и проверит подтверждающие документы, как описано в разделе Зарезервированные имена. См. Раздел 7.2.2.3 Проверка зарезервированных имен | |
| Механизм защиты прав | RPM | Механизм, который способствует защите прав на интеллектуальную собственность в системе доменных имен. Механизмы защиты прав (RPM) включают Единую политику урегулирования споров о доменных именах, единую службу быстрой приостановки и процедуру урегулирования разногласий в отношении товарных знаков после делегирования. |
| Корневая зона | База данных корневой зоны представляет данные о делегировании доменов верхнего уровня, включая gTLD и ccTLD. Как управляющий корневой зоной DNS, IANA отвечает за координацию делегирования в соответствии со своими политиками и процедурами. | |
| Оценка защитных мер | Оценка защитных мер позволяет определить, потребуется ли для запрашиваемой строки создавать особые меры защиты в отношении интересов потребителей, требующих особого подхода строк и регулируемых рынков. См. Раздел 7.8.2 Обязательства по обеспечению общественных интересов в качестве защитных мер. | |
| PIC в качестве защитной меры | PIC в качестве защитных мер были разработаны и внедрены в ответ на консенсусные рекомендации GAC в коммюнике по результатам заседаний на конференции ICANN46 в Пекине и последующую резолюцию Правления ICANN во время раунда 2012 года Программы New gTLD. ICANN делит gTLD, которым необходимы PIC в качестве защитных мер (см. Раздел 7.8.2.2 Применимые PIC в качестве защитных мер, с разбивкой на категории строк), на четыре группы на основе рисков: регулируемые секторы/требования относительно свободного доступа: строки, вызывающие доверие потребителей, но с повышенными рисками; строго регулируемые секторы/требования относительно закрытого доступа: строки, связанные с отраслями, требующими лицензирования или аккредитации; риск кибербуллинга/харассмента: строки, которые могут способствовать харассменту; неотъемлемые государственные функции: строки, связанные с функциями, относящимися к сфере деятельности государственных органов. | |
| Набор символов | Набор букв и других письменных знаков, которые используются для отображения тестовой информации в одной или более систем письма. Например, в русском языке используется подмножество кириллических символов; в украинском языке используется другое подмножество символов. В японской системе письма используется несколько наборов символов. | |
| Оценка уведомлений о единственном/множественном числе | ICANN рассмотрит материалы, представленные в рамках подачи уведомлений о единственном/множественном числе, и определит, представляют ли определенные строки формы единственного и множественного числа одного и того же слова на том же языке. См. Раздел 4.4 Уведомления о единственном/множественном числе. | |
| Строка | Строка символов, составляющая запрашиваемый gTLD или его вариантную строку. | |
| Возражение на основании совпадения строк | Возражение, поданное на основании того, что запрашиваемая строка gTLD сходна до степени совпадения с существующим TLD или другой запрашиваемой строкой gTLD в том же раунде подачи заявок. См. Раздел 4.5.1.1 Основание для возражения: схожесть строк. | |
| Спор в отношении строки | Ситуация, при которой существует более одного соответствующего критериям отбора кандидата на один и тот же gTLD или на gTLD, которые настолько похожи, что создается вероятность путаницы у пользователей в случае, если в корневую зону будет делегировано более одной из этих строк. См. Раздел 5.2 Споры в отношении строк и процедура их урегулирования. | |
| Оценка строк | Оценка строк (см. Раздел 1.2.4 Оценка строк) сосредоточена исключительно на оценке запрашиваемых строк и их подлежащих распределению вариантных строк. Оценка строки состоит из пяти элементов, которые будут рассматриваются одновременно: (см. Раздел 7.10 Оценка схожести строк), Исходная оценка риска доменной коллизии (см. Раздел 7.7.2 Исходная оценка риска доменной коллизии), Оценка защитных мер (см. Раздел 7.8.2 Обязательства по обеспечению общественных интересов в качестве защитных мер), Идентификация географических наименований (см. Раздел 7.5 Географические наименования), Оценка уведомлений о единственном/множественном числе (см. Раздел 4.4 Уведомления о единственном/множественном числе). | |
| Оценка схожести строк | Оценка схожести строк (см. Раздел 7.10 Оценка схожести строк) позволяет определить визуальную схожесть заявок на gTLD с другими заявками на gTLD, а также с существующими TLD, ранее запрашиваемыми gTLD и ccTLD, которые все еще находятся на этих стадиях, с заблокированными именами (см. Раздел 7.2 Обзор заблокированных и зарезервированных имен), а также с двухсимвольными строками, в которых используется код ASCII (т.е. потенциальные будущие ccTLD). | |
| Процедуры для последующих раундов | SubPro | Создание новых gTLD после раунда 2012 года. Относится к процессу разработки политики последующих процедур, применимых к новым gTLD и Итоговому отчету15, который включал набор результатов, связанных с раундом 2026 года Программы New gTLD. |
| Временное делегирование | Строки (включая вариантные), которые не определены как высокорисковые во время первоначальной оценки (см. Раздел 7.7.2 Исходная оценка риска доменной коллизии), будут поставлены в очередь на временное делегирование (см. Раздел 7.7.3 Временное делегирование и окончательный анализ). Временное делегирование начнется после завершения первоначальной оценки, даже если другие оценки, являющиеся частью оценки строки, все еще выполняются. Приоритетность временного делегирования будет определяться на основе присвоенного заявке номера приоритета. | |
| Система управления заявками на TLD | TAMS | Система, позволяющая кандидатам безопасно передавать информацию, необходимую для участия в одном или нескольких компонентах Программы New gTLD. В их число входит участие в программе поддержки кандидатов, кандидатов на предварительную оценку провайдеров услуг для регистратур и кандидатов на gTLD. |
| Домен верхнего уровня | TLD | Домены верхнего уровня (TLD) — это имена верхнего уровня в иерархии имен DNS. Они отображаются в доменных именах в виде набора букв, следующих за последней точкой, например, NET в www.example.net. Администратор TLD контролирует, какие доменные имена второго уровня распознаются в этом TLD. Администраторы корневого домена или корневой зоны контролируют, какие TLD распознаются системой DNS. |
| Депозитарий товарных знаков | TMCH | Механизм, разработанный для помощи в защите прав владельцев товарных знаков. Депозитарий товарных знаков используется для регистрации поступающей со всего мира информации о правах, которая им проверяется. Эта проверенная информация используется в процессах регистрации доменных имен, в частности, при запуске новых gTLD. |
| База данных товарных знаков | TMDB | База данных товарных знаков является частью Депозитария товарных знаков. Она является интерфейсом для регистратур и регистраторов, посредством которого они могут выполнять требования определенных механизмов защиты прав. |
| Единая политика разрешения споров о доменных именах | UDRP | Политика урегулирования споров, возникающих из-за предполагаемых злоупотреблений при регистрации доменных имен (например, киберсквоттинга), позволяющая проводить ускоренные административные разбирательства, которые правообладатель товарного знака инициирует путем подачи жалобы утвержденному поставщику услуг по урегулированию споров. |
| Служба быстрой приостановки | URS | Ускоренная административная процедура, которую правообладатели могут инициировать для разрешения некоторых типов разногласий в отношении доменных имен. Процедура URS является средством быстрой защиты прав в случаях очевидного незаконного использования товарных знаков. |
| Официальные языки Организации Объединенных Наций | Шесть языков ООН | Шесть языков, которыми пользуются в Организации Объединенных Наций: английский, арабский, испанский, китайский, русский и французский. |
| Оценка вариантных строк | Кандидат, запрашивающий одну или несколько подлежащих распределению вариантных строк запрашиваемой первичной строки или уже существующего gTLD, должен обосновать необходимость в каждой запрашиваемой вариантной строке. Это обоснование будет рассмотрено (см. Раздел 7.6 Оценка вариантных строк) группой оценки на основании критериев, приведенных в соответствующей рекомендации в области политики по IDN-доменам, подготовленной по итогам Фазы 1 EPDP. Успешно прошедшие оценку вариантные gTLD будут включены в Спецификацию 14 базового Соглашения об администрировании домена верхнего уровня. См. Приложение 4 Базовое Соглашение об администрировании домена верхнего уровня. | |
| Вариантная строка | Строка, которая считается «такой же» как и другая строка соответствующим сообществом и которая, следовательно, генерируется, как вариант первичной строки по правилам генерирования меток (LGR). Для верхнего уровня определение вариантной строки другой строки задано правилами генерирования меток корневой зоны (RZ-LGR). | |
| Набор вариантных строк | Первичная, подлежащая распределению и заблокированная вариантные строки вместе называются набором вариантных строк. Существующий gTLD считается первичной строкой, на основании которой будет рассчитываться и подаваться в заявке набор вариантных строк. Для верхнего уровня набор вариантных строк для создания первичной строки применяются правила генерирования меток корневой зоны (RZ-LGR). | |
Визуальное сходство -или- Визуально схожа с |
Визуальное сходство строк возникает, когда две или более строки сходны до такой степени, что возникает вероятность путаницы у пользователей, если будет разрешено их сосуществование. См. Раздел 5.2. Споры в отношении строк и процедура их урегулирования. | |
| Рабочая группа | РГ | Временная группа, сформированная Организацией поддержки или Консультативным комитетом для решения той или иной конкретной задачи или выполнения определенного задания. |
| Файл корневой зоны | Файл на авторитативном DNS-сервере, который определяет содержимое зоны в системе доменных имен. Ресурсные записи (RR) в файле корневой зоны содержат IP-адреса хостов (например, веб-серверов, почтовых серверов) и серверов имен в зоне DNS-сервера. По решению владельца зоны файл зоны также может содержать другие типы ресурсных записей (например, записи, содержащие цифровые подписи). Ресурсные записи в файле зоны позволяют авторитативному DNS-серверу предоставлять однозначные ответы на запросы DNS. |
См. Устав ICANN: https://www.icann.org/en/governance/bylaws.↩︎
См. Итоговый отчет SubPro: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎
См. Приложение А Устава ICANN: http://www.icann.org/en/general/bylaws.htm#AnnexA↩︎
См. сайт договорных сторон: http://www.icann.org/en/general/consensus-policies.htm.↩︎
См. Базу данных корневой зоны: http://iana.org/domains/root/db/.↩︎
См. список базы данных корневой зоны: http://iana.org/domains/root/db.↩︎
См. Итоговый отчет GNSO по результатам процесса разработки политики последующих процедур, применимых к новым gTLD: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-20jan21-en.pdf↩︎
См. сайт GNSO: https://gnso.icann.org/en.↩︎
См. Список всемирного наследия ЮНЕСКО: https://whc.unesco.org/en/list/&order=region.↩︎
См. Раздел по географическим регионам M49: https://unstats.un.org/unsd/methodology/m49/.↩︎
См. информацию о Правлении: https://www.icann.org/en/board/about.↩︎
См. сайт корпорации ICANN: https://www.icann.org/.↩︎
См. список аккредитованных регистраторов: https://www.icann.org/en/accredited-registrars.↩︎
См. Отчет по результатам обзора и оценки реализации Программы от 29 января 2016 года: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf.↩︎
См. Итоговый отчет GNSO по результатам процесса разработки политики последующих процедур, применимых к новым gTLD: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf↩︎