Кратко

  • В письме от 14 июля Индия просит проверять электронную почту и телефон до активации домена, ввести обязательную централизованную отчётность о злоупотреблениях DNS и запустить аутентификацию правоохранителей для срочных запросов регистрационных данных.
  • President and CEO ICANN пишет, что первые две темы заслуживают дальнейшего рассмотрения и обсуждаются при расстановке приоритетов GNSO, но он не вправе задавать эту очерёдность или исход PDP.
  • У группы по аутентификации опубликованы встречи и этапы с июня 2026 года по март 2027-го. Она не вырабатывает политику, а её испытания сами по себе не вводят 24-часовое требование.
  • Публичная квитанция для каждого запроса должна показывать компетентный орган, текущее состояние, процедуру, следующее уполномоченное решение и то, чего состояние пока не означает.

Три разных предмета в одном обращении

14 июля 2026 года S. Krishnan, секретарь Министерства электроники и информационных технологий Индии, направил письмо Kurt Erik Lindqvist, President and CEO ICANN. Он назвал несколько вопросов общественного интереса, безопасности пользователей и доверия затянувшимися и попросил немедленно повысить приоритет трёх мер.

Первая меняет момент проверки. Индия предлагает валидировать адрес электронной почты и номер телефона до активации домена. Она противопоставляет это нынешнему сроку ответа после запроса о точности данных и считает, что достаточно небольших контрактных поправок. Публичное разъяснение ICANN о Whois Accuracy Program говорит, что после более чем 15 календарных дней без ответа возможны приостановление, прекращение регистрации или блокировка. Оно не делает предварительную проверку уже принятой обязанностью.

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

Третья мера должна привести в действие уже написанное, но условное правило. Registration Data Policy содержит подтверждение получения за два часа и ответ на срочный запрос в течение 24 часов, кроме ограниченного исключения. Примечание о реализации откладывает вступление Section 10.7 в силу до полной реализации Consensus Policy, устанавливающей аутентификацию заявителя. Индия просит ускорить такой механизм для правоохранителей.

Это документированные предпочтения правительства в сфере публичной политики. Они не являются решением GNSO, изменением договора регистратора или доказательством эффективности выбранного средства. Задача управления — показать маршрут от требования к органу, который вправе совершить следующий действительный акт.

Ответ сохраняет границу полномочий

В письме от 11 августа, опубликованном на следующий день, Lindqvist соглашается с целью безопасной и надёжной DNS, но не выводит из неё дополнительную власть исполнительного руководителя.

Сначала он ссылается на консенсусный совет GAC после ICANN83 и на DNS Abuse Mitigation PDP 1 по Associated Domain Checks. Этот процесс рассматривает обязанности регистратора в отношении других доменов, связанных с учётной записью, по которой поступила требующая действия жалоба. Это реальный активный PDP. Он не равен проверке контактов до активации и не заменяет централизованную отчётность.

О проверке регистрационных данных и прозрачности отчётности ответ говорит осторожнее. ICANN org считает их заслуживающими дополнительного рассмотрения и понимает, что GNSO Council обсуждает их в работе над приоритетами. Это подтверждает внимание, но не место в очереди. Не названы Charter, рабочая группа, контрактные переговоры, рекомендация или срок.

Ограничение заложено в институте. GNSO разрабатывает и рекомендует содержательную политику gTLD и управляет PDP. GAC консультирует по государственным и публично-политическим вопросам. CEO может обеспечить данные, поддержку и операционную экспертизу ICANN org, а затем реализовать принятую политику. Он не может выбрать приоритеты GNSO или определить результат PDP.

Граница защищает обе стороны. Срочность не даёт правительству нового голоса решения. Обсуждение не позволяет GNSO считать озабоченность устранённой. Подготовка реализации не превращает ICANN org в автора правил. Новая обязанность реестров или регистраторов требует надлежащего политического либо контрактного основания.

Публично подтверждены три разных состояния

На 31 августа проверенные источники дают такую картину:

Запрошенная мера Публичное состояние Видимый следующий уполномоченный шаг
Проверка электронной почты и телефона до активации Получена, признана, названа предметом дополнительного рассмотрения и обсуждения приоритетов GNSO Датированное решение о приоритете, Charter, PDP или контрактный шаг не указаны
Обязательная централизованная отчётность о злоупотреблениях DNS Получена, признана, названа предметом дополнительного рассмотрения и обсуждения приоритетов GNSO Датированное решение об обязанности, модели данных, центральной системе или процедуре не указано
Аутентификация правоохранителей для срочных запросов Input Group создана, встречи идут, этапы proof of concept опубликованы Изменения макета RDRS в октябре 2026 года, испытания в декабре, выводы в марте 2027-го, затем необходимый действительный политический инструмент

Это не ранжирование общественной важности, а сравнение открытых процессуальных доказательств.

Протокол GNSO Council от 13 августа показывает, почему нельзя заполнять пробелы догадкой. Council обсуждал проект Charter для DNS Abuse Mitigation PDP 2. Участники спорили об исходной версии, границах автоматизированных механизмов и формулировках, заранее предполагающих обязательный результат. Charter Drafting Team должен был начать еженедельные встречи на неделе 24 августа.

Протокол не включает первые два индийских требования в PDP 2. Зато он фиксирует замечание GNSO-GAC Liaison: вопросы о сроке проверки регистранта пришли на ICANN86 слишком поздно, чтобы Council успел проконсультироваться со своими группами. Это запись о времени коммуникации, не решение политики и не доказательство причинного влияния более позднего письма Индии.

Там же определена граница Liaison. Он может раньше передать мнение GAC, но составление Charter остаётся обязанностью Council. Без изменения описания роли Liaison не выступает адвокатом позиции GAC. Информация пересекает институциональный интерфейс; полномочие решить — нет.

Датированный прототип остаётся прототипом

Маршрут аутентификации легче контролировать. Страница ICANN указывает формирование группы в июне, начало встреч в июле, представление изменений wireframe RDRS в октябре, старт испытаний в декабре и публикацию выводов в марте 2027 года. Доступны записи встреч 22 июля и 12 августа.

Та же страница подчёркивает, что группа не разрабатывает и не рекомендует политику. Её Charter пока помечена как «coming soon». Группа может испытывать совместимость систем идентификации, рабочий процесс, минимизацию данных, журналы и удобство. Она не решает, действительно ли конкретный запрос срочный, законный и необходимый, и не создаёт автоматического права на раскрытие.

Публичные даты повышают подотчётность, позволяя увидеть начало, изменение и задержку. Они не расширяют мандат группы и не заменяют Consensus Policy, от которой зависит вступление 24-часового правила в силу.

Квитанция между ответом и итогом

ICANN опубликовала оба письма. Однако состояние каждой меры разбросано между ответом CEO, страницами GNSO, протоколом Council, страницей Input Group и примечаниями к политике. Читатель вынужден сам собирать цепочку.

Публичная квитанция маршрута для каждой меры закроет разрыв без создания нового решающего органа. Она укажет точный запрошенный результат, класс полномочий отправителя, компетентный орган, состояние — получено, консультация, приоритизация, разработка Charter, PDP, контрактное обсуждение, реализация, завершено, отклонено или заменено — процедуру и публичное дело, владельца поддержки в ICANN org, зависимости, следующий акт и дату либо «не запланировано», последнюю ссылку и историю исправлений.

Главное поле объяснит неслучившееся. «Получен ответ» не значит «назначен приоритет». «Обсуждается при приоритизации» не означает наличия Charter. «Charter разрабатывается» не решает вопрос. «Proof of concept» не создаёт обязанность или право доступа. «Реализовано» должно ссылаться на инструмент, который разрешает принуждение.

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

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

Срочность и компетенция должны быть видны вместе

Сила ответа от 11 августа в том, что CEO не поставлен над GNSO. Документарный недостаток в другом: два требования остаются под широкими словами, тогда как у третьего уже есть последовательность исполнения.

Следующим шагом не обязано быть обещание нужного Индии результата. Достаточно показать следующий уполномоченный акт. Тогда государственная срочность не будет отмыта в мандат, а длительность многостороннего процесса не станет ложным доказательством ответа на общественную проблему.

В более точной системе участники дают факты, требования и возражения. GAC советует. GNSO определяет ход политики gTLD. ICANN org поддерживает и исполняет. Договоры и Consensus Policies несут обязанности. Публичная запись соединяет переходы, не превращая присутствие, переписку или срочность в суверенную власть.

Источники

  1. ICANN — индекс переписки
  2. S. Krishnan — Kurt Erik Lindqvist, 14 июля 2026 года
  3. Kurt Erik Lindqvist — S. Krishnan, 11 августа 2026 года
  4. ICANN — разработка политики
  5. GNSO Council — протокол 13 августа 2026 года
  6. ICANN — Input Group по механизмам аутентификации правоохранительных органов
  7. GNSO — DNS Abuse Mitigation PDP 1
  8. ICANN — Registration Data Policy
  9. ICANN — RAA 2013 года и Whois Accuracy Program Specification
  10. Lu Heng — The Multi-Stakeholder Mirage