Кратко

  • Политика регистрационных данных, опубликованная 12 мая 2026 года, требует подтвердить получение аутентифицированного срочного запроса за два часа и ответить за 24 часа. Лишь исключительные обстоятельства позволяют мотивированно продлить срок максимум до 72 часов.
  • Ответ может предоставить запрошенные непубличные данные либо полностью или частично отказать с объяснением. Часы не заменяют рассмотрение по существу, не отменяют применимое право и не связывают договорные стороны до вступления механизма аутентификации в силу.

Представим, что правильно оформленный запрос поступил в 14:00. К 16:00 получивший его регистратор или оператор реестра должен подтвердить приём. Обычно к 14:00 следующего дня заявитель уже должен получить ответ. Если действительно исключительные обстоятельства требуют больше времени, адресат обязан в те же 24 часа уведомить о продлении, объяснить причину и назвать срок ответа. Крайняя граница — 72 часа с момента получения.

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

Сначала нужно пройти через узкий вход. Раздел 3.8 политики ICANN определяет срочный запрос как подмножество запросов о правомерном раскрытии. Он должен исходить от Аутентифицированного заявителя и касаться непосредственной угрозы жизни, тяжкого телесного вреда, критической инфраструктуры или эксплуатации детей. Раскрытие должно быть необходимо для противодействия угрозе. Одно слово «срочно» в теме письма этот канал не открывает.

Аутентификация — не простое самообозначение. Раздел 3.9 ограничивает круг заявителем из правоохранительного органа либо доверенным или компетентным органом, аутентифицированным механизмом, реализованным по Консенсусной политике ICANN. Поправка разделяет две проверки, которые часто смешивают: действительно ли обращается заявленная организация и необходим ли, правомерен ли именно этот запрос.

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

Новые часы меняют то, как долго такое рассмотрение может оставаться без результата. Для обычного запроса раздел 10.5 допускает до двух рабочих дней на подтверждение и, при отсутствии исключительных обстоятельств, до 30 календарных дней после него на ответ. Для подходящего срочного запроса раздел 10.7 заменяет этот ритм: подтверждение за два часа и ответ без неоправданной задержки, не позднее 24 часов.

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

И всё же «ответ» не означает «выдачу». Раздел 10.6 оставляет два соответствующих политике исхода. Оператор может предоставить данные. Он также может отказать полностью или частично, но должен назвать конкретные причины и объяснить ход решения. Когда это применимо, требуется показать, как основные права и свободы субъекта данных сопоставлялись с законным интересом заявителя.

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

Кроме того, важный переключатель ещё не замкнут. Примечание по реализации 11 говорит, что обязанности раздела 10.7 вступят в силу только после полной реализации ICANN Консенсусной политики, устанавливающей аутентификацию заявителей. Объявление от 12 мая повторяет это условие. Обновлённая 23 июля запись о статусе рекомендаций GAC также указывает, что применение 24-часового срока ожидает этого механизма.

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

После запуска подотчётность должна быть видна в документах. Раздел 11.2 требует хранить записи запросов, подтверждений и ответов по обычным правилам делопроизводства, в том числе для возможного аудита ICANN. Они способны доказать соблюдение двух-, 24- и 72-часовых требований. Сами по себе они не докажут юридическую правильность выдачи или отказа, но сделают молчание измеримым.

Новые часы сильнее всего при точном описании: они разрешают скорость, структуру и проверяемое решение, а не автоматическое раскрытие.

Источники