Skip to main content
Resources

Процедура подачи запросов об изменении соглашений с gTLD сообществ

Страница также доступна на следующих языках:

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

Введение

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

Корпорация ICANN опубликовала проект процедуры для проведения общественного обсуждения в феврале 2018 года. По результатам полученных комментариев корпорация ICANN и рабочая группа пришли к выводу о том, что эти комментарии не указывают на наличие противоречий между процедурой и существующей политикой, и обсудили обновление процедуры. Кроме того, 26 апреля 2018 года Совет GNSO решил [PDF, 574 Кб], что «корпорация ICANN должна заниматься процессом обработки запросов об изменении соглашений с gTLD сообществ в рамках его реализации». В апреле 2018 года рабочая группа и корпорация ICANN согласовали опубликованную редакцию процедуры.

Процедура

Редакция: апрель 2018 года

Запрос на изменение gTLD сообществ

Запрос на изменение gTLD сообществ («запрос») представляет собой процедуру, в рамках которой оператор регистратуры gTLD сообщества запрашивает у ICANN разрешение на изменение правил регистрации для сообществ, перечисленных в Спецификации 12, для своего Соглашения об администрировании домена верхнего уровня. В соответствии с разделом 2.19 Соглашения об администрировании домена верхнего уровня, «оператор регистратуры обязуется управлять TLD таким образом, чтобы сообщество TLD могло вести обсуждение и участвовать в разработке и изменении политики и практических методов работы TLD». Оператор регистратуры gTLD сообществ не вправе запрашивать изменения, которые аннулируют правила регистрации для сообществ, слишком смягчают или слишком ужесточают условия регистрации для владельцев доменов и/или требования относительно выбора названий и создают существенные негативные последствия для сообщества соответствующего TLD.

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

1. Определения

1.1 gTLD сообществ – это gTLD с заключенным с ICANN Соглашением об администрировании домена верхнего уровня, которое включает Спецификацию 12 и раздел под названием «Правила регистрации для сообществ» или «Правила TLD».

1.2 Изменение gTLD сообществ – это изменение Спецификации 12 к Соглашению об администрировании домена верхнего уровня, заключенному с ICANN.

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

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

1.5 Под всеми днями, упоминаемыми в рамках данной процедуры, имеются в виду календарные дни.

2. Процедура подачи запросов об изменении соглашений с gTLD сообществ

2.1 Оператор регистратуры подает запрос об изменении соглашений с gTLD сообществ («запрос»)

Оператор регистратуры может подать запрос в любой момент. Запрос необходимо подавать ICANN в письменном виде с приложенной заполненной анкетой для подачи запроса об изменении соглашений с gTLD сообществ (см. Приложение A) [PDF, 38 Кб], и этот запрос должен включать в себя сопроводительную документацию в пользу такого изменения от сообщества TLD (включая организации, представляющие любое предложение по расширению сообщества TLD, если применимо), а также от уполномоченного руководства, если применимо.

2.2 Предварительная проверка корпорацией ICANN запроса

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

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

2.3 Период обсуждения запроса об изменении

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

2.4 Период ответа в отношении запроса об изменении

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

3. Анализ и решение ICANN

3.1 Анализ ICANN

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

  1. Описание TLD сообщества — имеется ли четкое описание требований и критериев для регистрации имен в данном TLD и последствий с точки зрения этих требований и критериев в результате удовлетворения поданного запроса?
  2. Свидетельства информирования и поддержки со стороны сообщества TLD — представлены ли были разумные свидетельства того, что оператор регистратуры связывался с сообществом данного домена верхнего уровня и прилагал усилия для того, чтобы «управлять TLD таким образом, чтобы сообщество TLD могло вести обсуждение и участвовать в разработке и изменении политики и практических методов работы TLD»? Представлены ли разумные свидетельства поддержки запроса сообществом TLD?
  3. Польза для сообщества TLD — объясняется ли должным образом в ответах на вопросы 1.3 и 1.4 анкеты для подачи запроса об изменении соглашений с gTLD сообществ польза, которую принесет сообществу TLD одобрение данного запроса? Не принесет ли принятие этих изменений вреда сообществу TLD?
  4. Опасения, поднятые в ходе общественного обсуждения — поднимались ли в ходе общественного обсуждения какие-либо серьезные опасения в отношении возможного вреда для сообщества данного домена верхнего уровня или интернет-сообщества в целом? Предоставил ли оператор регистратуры убедительные ответы на эти опасения? Убедительные ответы могут включать предоставленные оператором регистратуры свидетельства того, что (1) не будет причинен вред репутации сообщества; (2) не будет нарушена базовая деятельность сообщества; (3) сообществу не будет нанесен экономический ущерб.

3.2 Заключение ICANN

3.2.1 Одобрение

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

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

3.2.2 Отказ

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

ПРИЛОЖЕНИЕ A:Анкета для подачи запроса об изменении соглашений с gTLD сообществ [PDF, 38 Кб]

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."