Skip to main content
Resources

Замечания по реализации RSEP

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

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

Вступает в силу 17 июня 2019 года

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

Чтобы вернуться на страницу процесса RSEP, нажмите здесь.

Введение

8 ноября 2005 года Правление ICANN поручило ввести в действие рекомендованную GNSO процедуру рассмотрения запросов на новые услуги регистратуры, руководствуясь положениями соглашения об администрировании домена верхнего уровня .NET в части определений услуг регистратуры. Настоящие Замечания по реализации — это краткое описание процесса политики оценки услуг регистратур (RSEP), составленное для предоставления общей информации о реализации политики корпорацией ICANN. Корпорация ICANN может периодически оценивать эффективность реализации при содействии соответствующих операторов регистратур и групп интересов.

В 2019 году созданная Группой заинтересованных сторон-регистратур (RySG) группа для обсуждений занималась в сотрудничестве с корпорацией ICANN обновлением Замечаний по реализации, не меняя при этом саму политику. Пересмотренные Замечания по реализации призваны сделать процесс RSEP более простым для понимания и более предсказуемым, а также обеспечить постоянное соблюдение базовой политики.

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

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

Все сроки указаны в календарных днях, если не оговорено иначе.

Этап 1. Подача запроса на рассмотрение

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

  1. Стандартная форма запроса RSEP. При подаче запросов RSEP о добавлении планируемой услуги регистратуры, исключении или значительном изменении существующей услуги операторы регистратур должны ответить на ряд стандартных вопросов, чтобы предоставить корпорации ICANN достаточно информации для оценки запроса. Операторы регистратур могут указать, что информация в запросе RSEP является «КОНФИДЕНЦИАЛЬНОЙ», за исключением информации, необходимой для описания цели планируемой услуги регистратуры и последствий для пользователей DNS.

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

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

Этап 2. Проверка полноты информации корпорацией ICANN

Во время проверки полноты информации запросы RSEP не публикуются и все взаимодействие между корпорацией ICANN и оператором регистратуры, относящееся к запросу RSEP, остается конфиденциальным. После подачи запроса корпорация ICANN проверяет полноту информации. Срок такой проверки должен быть менее 15 дней. Для перехода на третий этап «Проверка ICANN» запрос должен отвечать следующим критериям:

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

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

    Вид разрешительного документа и критерии:

    • Поправка к RA: используется, когда планируемая услуга (i) противоречит существующим положениям RA или (ii) не предусмотрена в RA и, следовательно, должна быть добавлена вПриложение А к RA и/или в соответствующее приложение/дополнение.

    • Письмо о возможности беспрепятственного внедрения: используется, когда планируемая услуга уже предусмотрена в RA и не противоречит положениям соглашения.

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

2A. Просьба перейти к следующему этапу

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

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

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

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

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

Этап 3. Проверка ICANN

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

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

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

Этап 4. Утверждение или передача запроса

Вынесенное на третьем этапе предварительное заключение приведет к одному из следующих результатов:

  1. Одобрение запроса RSEP.

  2. Передача запроса Группе технической оценки услуг регистратуры (RSTEP).

  3. Передача запроса соответствующему государственному антимонопольному органу.

  4. Передача запроса и RSTEP, и соответствующему государственному антимонопольному органу.

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

Результат

Заключение

Дальнейшие действия

(1) Одобрение

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

Запрос считается полным и переходит на шестой этап «Разрешение».

(2) Передача на рассмотрение RSTEP

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

Если оператор регистратуры подтверждает готовность к продолжению процесса, планируемая услуга анализируется RSTEP (список членов RSTEP). После передачи запроса RSTEP у группы экспертов есть 45 дней для анализа планируемой услуги и подготовки отчета обо всех проблемах безопасности или стабильности. Оператору регистратуры передается полная версия итогового отчета RSTEP. Необходим пятый этап «Общественное обсуждение и рассмотрение в ICANN».

(3) Передача запроса соответствующему государственному антимонопольному органу

Могут возникнуть существенные проблемы для конкуренции

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

(4) Передача запроса и RSTEP, и соответствующему государственному антимонопольному органу

Могут возникнуть существенные проблемы для безопасности или стабильности и проблемы для конкуренции

Если оператор регистратуры подтверждает готовность к продолжению процесса, корпорация ICANN выполняет шаги 2 и 3.

Этап 5. Общественное обсуждение и рассмотрение в ICANN (если применимо)

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

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

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

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

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

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

После периода общественного обсуждения корпорация ICANN рассматривает вопрос об одобрении запроса RSEP или передает его на рассмотрение Правления ICANN.

Если вопрос передается на рассмотрение Правления ICANN, Правление ICANN будет стремиться принять решение в течение 30 дней после подготовки сводного отчета о результатах общественного обсуждения и анализа комментариев. Правление ICANN может принять следующие решения: 1) одобрить запрос RSEP, 2) отклонить запрос RSEP или 3) отложить рассмотрение запроса RSEP до получения дополнительной информации.

Если корпорация или Правление ICANN одобряет запрос RSEP, оператор регистратуры и корпорация ICANN переходят к шестому этапу «Разрешение». Если Правление ICANN отказывается удовлетворить запрос, его рассмотрение прекращается.

Этап 6. Разрешение

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

  1. Отправляет оператору регистратуры письмо о возможности беспрепятственного внедрения (согласно договоренности, достигнутой на втором этапе), после получения которого оператор регистратуры может внедрить эту услугу.

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

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

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

 

Диаграмма процесса RSEP

См. диаграмму процесса RSEP, где этот процесс представлен в обобщенном виде со ссылками на настоящие Замечания по реализации.

Архив

Эта страница обновлена в июне 2019 года в рамках улучшения организации процесса RSEP (см. статью в блоге корпорации ICANN). Архивная версия Замечаний по реализации доступна здесь.

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."