Кратко

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

Переписка ICANN показывает, что одна фраза — «реализация Phase 2A» — может обозначать два разных объекта.

11 мая 2026 года председатель Governmental Advisory Committee Nicolas Caballero обратился к председателю Совета ICANN Tripti Sinha. По оценке руководства GAC, работа, призванная обеспечить сбор и публикацию регистрационных данных юридических лиц, не продвигалась с марта 2022 года, когда Совет принял рекомендации EPDP Phase 2A. GAC повторил свою позицию: договорные стороны должны собирать и делать общедоступными данные юридических лиц. Он попросил подтвердить сроки и выразил готовность участвовать в Implementation Review Team.

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

Содержательная часть ответа важнее календаря. Команда Phase 2A решила не менять существующие требования Consensus Policy о различении регистрационных данных юридических и физических лиц. Registration Data Policy разрешает операторам реестров и регистраторам учитывать статус юридического лица или наличие персональных данных при решении о применении редактирования в RDDS, но не обязывает их к этому. Предстоящие лучшие практики также не создадут договорных обязанностей.

Следовательно, перед ICANN стоит не только вопрос очередности. Предпочтительный результат GAC и пакет, ожидающий реализации, различаются по объёму.

Обязательное создание не означает обязательное применение

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

Вторая предлагает выбравшим различение руководствоваться указаниями отчёта. Третья касается возможного учёта этих указаний, если соответствующие контролёры и обработчики разработают внутри ICANN GDPR Code of Conduct. Четвёртая обращена к сторонам, решившим публиковать в открытом RDDS адрес электронной почты на основе регистранта или регистрации, и предлагает оценить юридические рекомендации команды EPDP.

У ICANN org есть настоящий мандат на реализацию. Совет поручил President and CEO либо назначенным лицам разработать и исполнить план в соответствии с указаниями GNSO Council. Добровольное использование поля не отменяет обязанности организации создать предусмотренный технический механизм.

Но граница тоже записана прямо. В обосновании 2022 года Совет сказал, что рекомендации не вводят новых обязанностей для Contracted Parties. Руководства и лучшие практики вне Registry Agreement, Registrar Accreditation Agreement и Consensus Policies не являются договорными требованиями. Поэтому ICANN Contractual Compliance не получает договорных полномочий требовать их исполнения.

Августовский ответ относит рекомендации 1, 2 и 4 к документу лучших практик, а рекомендации 1 и 3 — также к работе ICANN org. Первая попала в обе группы из-за сочетания методического и технического компонентов. Такая группировка не меняет силу текста.

Действующая политика решает несколько разных вопросов

Registration Data Policy разводит сбор, передачу, escrow, публикацию, редактирование, согласие и правомерное раскрытие. Один и тот же элемент может участвовать во всех процессах, но основание решения в каждом из них своё.

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

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

Поле Registrant Organization демонстрирует действующую последовательность. Регистратор обязан предоставить Registered Name Holder возможность указать значение и собрать его, если оно предоставлено. Он должен сообщить, что организация будет опубликована при согласии владельца и станет считаться Registered Name Holder. При согласии значение необходимо опубликовать; без него регистратор может его отредактировать по правилам политики.

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

Техническое поле переносит значение, а не полномочие

Ответ Совета предусматривает координацию с техническим сообществом по полям различения в Extensible Provisioning Protocol и обновлённому gTLD RDAP Profile.

Общая модель данных нужна. Без неё один поставщик использует свободный текст, второй — неописанный флаг, третий — вывод без возможности исправления. Спецификация может определить допустимые значения, неизвестное состояние, отсутствие различения, происхождение, обновление и коррекцию. Она поможет сохранить смысл между EPP и RDAP.

Однако синтаксис не решает, кто обязан заполнять поле. Значение не доказывает качество классификации. Передача через EPP не требует публичного вывода через RDAP. Наличие в профиле не отменяет Registration Data Policy, применимое право и ответственность принимающей решение стороны.

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

Публичная таблица полномочий

План реализации стоит сопровождать соответствием пяти уровней.

Первая строка покажет позицию GAC как рекомендацию и публично-политическое предпочтение. Вторая свяжет принятые рекомендации и решения Совета с задачами ICANN org. Третья перечислит договорные правила сбора, редактирования, согласия, публикации и раскрытия. Четвёртая опишет EPP/RDAP как техническое представление. Пятая назовёт сторону, принимающую решение по конкретной записи на основании политики и права.

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

Такая таблица не решит спор о прозрачности и защите данных. Она решит предшествующий вопрос: что именно строится, кем и на основании какого акта.

Начало в FY2027 ещё нужно подтвердить

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

Отчётность можно сделать точной уже сейчас: назначить владельца, назвать снятые зависимости, сопоставить задачи рекомендациям, публиковать технические предложения и объяснять изменение очередности. Но отчёт о проекте не должен становиться источником новой политики.

GAC вправе добиваться более широкого результата. GNSO вправе вести соответствующий процесс. Совет принимает рекомендации, ICANN org их реализует, техническое сообщество стандартизирует представление. Contracted Parties отвечают за решения по реальным данным в рамках договоров и права.

Совещательное участие не заменяет поправку к договору. Поручение Совета ICANN org не становится новым приказом каждому регистратору. Поле не является разрешением на раскрытие. График не является политикой.

Письмо 24 августа сделало эту границу заметной. Следующий тест — сохранится ли она, когда руководства, схемы и ожидания пользователей начнут соединяться в работающих системах.

Источники

  1. Указатель корреспонденции ICANN
  2. Tripti Sinha — Nicolas Caballero, 24 августа 2026 года
  3. Nicolas Caballero — Tripti Sinha, 11 мая 2026 года
  4. Решение Совета ICANN по EPDP Phase 2A, 10 марта 2022 года
  5. Итоговый отчёт EPDP Phase 2A
  6. Рекомендации Phase 2A для рассмотрения Советом
  7. Registration Data Policy ICANN
  8. Материалы ICANN по RDAP