Дополнение к политике по вопросам службы каталогов регистрационных данных (RDDS)
Просим отметить, что официальной версией всех переведенных материалов и документов является версия на английском языке и что перевод на другие языки приведен исключительно в информационных целях.
Актуализировано 21 февраля 2024 года с учетом изменений, необходимых для реализации политики в области регистрационных данных. Данная политика ранее называлась Дополнением к политике относительно данных WHOIS. Стороны, связанные договорными обязательствами, могут применять данную актуализированную Политику, начиная с 21 августа 2024 года, и должны реализовать ее не позднее 21 августа 2025 года.
Употребляемые в настоящем документе ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ОБЯЗАТЕЛЬНО», «БУДЕТ», «НЕ БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ» и «МОЖЕТ» и «НЕ ОБЯЗАТЕЛЬНО» следует понимать так, как описано в документах BCP 14 [RFC2119] [RFC8174] только в тех случаях, когда эти термины набраны прописными буквами, как показано здесь.
В разделе 1 данной политики подробно описаны не зависимые от технологии требования, которые применяются ко всем службам каталогов регистрационных данных.
В разделе 2 данной политики подробно описаны требования к реализации, относящиеся только к службе WHOIS (доступной через порт 43) и веб-службам каталогов WHOIS.
Регистраторы, аккредитованные ICANN, и регистратуры доменов общего пользования верхнего уровня (gTLD) в силу соответствующих соглашений, заключенных между ними и ICANN, обязаны по запросу предоставлять доступ к определенным регистрационным данным. Настоящее Дополнение к политике по вопросам RDDS дополнительно требует от регистраторов и регистратур включать в выходные данные RDDS информацию, которая поможет пользователям RDDS более эффективно определять регистратора, спонсирующего регистрацию, и понять коды статуса, используемые регистратурами и регистраторами:
- Операторы регистратур и регистраторы ОБЯЗАНЫ выполнять следующие требования:
1.1 включить в результаты поиска по RDDS следующее сообщение: «Дополнительная информация о кодах статуса доменов доступна по адресу: https://icann.org/epp»*
* Обратите внимание, что длинная форма приведенной выше ссылки, которая была включена в раздел 1(c) ранее, т.е. https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en, также соответствует данной Политике.
1.2 при выдаче результатов поиска по RDDS регистратуры ДОЛЖНЫ использовать выданный ICANN Глобальный уникальный идентификационный номер регистратора (GURID, известный как идентификатор в IANA).
- Операторы регистратур и регистраторы ОБЯЗАНЫ реализовать следующие требования к службе WHOIS (доступной через порт 43) и веб-службам каталогов WHOIS:
2.1 статус(ы) ДОЛЖЕН (ДОЛЖНЫ) отображаться с соответствующими статусами доменов;
2.2 рядом с каждым статусом домена ДОЛЖНЫ отображаться ссылка или URL, ведущие на веб-страницу ICANN с описанием или определением соответствующего статуса домена. Список URL доступен здесь: https://www.icann.org/resources/pages/epp-status-codes-list-2014-06-18-en;
2.3 Регистраторы НЕ ДОЛЖНЫ удалять приведенные выше ссылки и сообщение при предоставлении данных Whois из собственной службы Whois или службы Whois другого регистратора или регистратуры.
Примечания: Дополнение к политике относительно данных WHOIS (AWIP), переименованное в Дополнение к политике по вопросам службы каталогов регистрационных данных (ARIP), принято ICANN в виде согласованной политики 6 мая 2012 года. Дата вступления данной политики в силу — 31 января 2016 года. Все аккредитованные ICANN регистраторы и регистратуры gTLD обязаны соблюдать ARIP применительно к регистрациям, спонсируемым ими во всех gTLD, в отношении которых они аккредитованы или которые они администрируют, начиная с даты вступления в силу.
Целью данной политики является разъяснение значения статусов доменов в данных RDDS и обеспечение последовательной идентификации регистратора по GURID в RDDS.
Для справки: 24 июня 2009 года Совет GNSO запустил процесс разработки политики (PDP) в связи с процедурой межрегистраторского переноса (IRTP) (http://gnso.icann.org/en/council/resolutions#200906 – резолюция 20090624-2), а 30 мая 2011 года рабочая группа по PDP (рабочая группа B IRTP) представила итоговый отчет с набором рекомендаций (http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf [PDF, 971 КБ]), включая рекомендацию № 8: стандартизировать и пояснять сообщения RDDS о статусе, касающиеся статуса «Registrar Lock». 22 июня 2011 года Совет GNSO постановил, что до рассмотрения вопроса об утверждении рекомендации относительно стандартизации и пояснения сообщений RDDS, касающихся статуса «Registrar Lock», Совет GNSO просит персонал ICANN представить предложение, призванное обеспечить разработку технически осуществимого подхода для выполнения этой рекомендации. В ответ на эту просьбу персонал ICANN при участии рабочей группы разработал предложение, которое было опубликовано для общественного обсуждения и впоследствии принято Советом GNSO 16 февраля 2012 года (http://gnso.icann.org/en/council/resolutions#20120216-1). После проведения еще одного общественного обсуждения рекомендации и предложения (http://www.icann.org/en/news/public-comment/irtp-b-rec8-21feb12-en.htm) Правление ICANN приняло их 6 мая 2012 года. (https://www.icann.org/en/groups/board/documents/resolutions-06may12-en.htm#1.5)
22 сентября 2011 года дополнительной рабочей группе GNSO (рабочей группе C IRTP) было поручено рассмотреть три вопроса, связанных с IRTP, в том числе вопрос о том, можно ли упорядочить этот процесс путем введения требования об использовании регистратурами для регистраторов идентификаторов IANA вместо собственных идентификаторов (https://community.icann.org/display/gnsoirtppdpwg/3.+WG+Charter). Рабочая группа выпустила первоначальный отчет, который стал предметом общественного обсуждения, а затем итоговый отчет, который был принят Советом GNSO 17 октября 2012 года. После еще одного общественного обсуждения 20 декабря 2012 года Правление ICANN приняло рекомендации, содержащиеся в итоговом отчете (http://www.icann.org/en/groups/board/documents/minutes-20dec12-en.htm#2.a).
