Кратко

  • 28 августа 2026 года ICANN уведомила IPIP INC. о расторжении Registrar Accreditation Agreement по разделу 5.5.4; документ устанавливает дату вступления решения в силу 13 сентября.
  • Заявленное основание — четыре нарушения, которые, по оценке ICANN, не были устранены к 26 августа: RDAP, депонирование данных регистратора, просроченные аккредитационные сборы и ссылка на процедуру раскрытия непубличных регистрационных данных.
  • Следующий набор назван «дополнительными вопросами, вызывающими озабоченность». Перенос доменов, отзыв лицензии на логотип и сохраняющиеся после расторжения обязанности составляют еще одну отдельную категорию.
  • Публичная таблица движения каждого пункта могла бы связать норму, доказательство, требование, срок, ответ и решение, не раскрывая частную переписку или персональные данные.

У события пока два времени

Решение датировано 28 августа. Юридический эффект в самом уведомлении отнесен на 13 сентября. На 30 августа нельзя превращать будущее время документа в завершенное действие.

ICANN сообщила IPIP INC., регистратору IANA номер 3774, о расторжении Registrar Accreditation Agreement 2013 года на основании раздела 5.5.4. В следующей формулировке указано, что в соответствии с разделом 5.6 расторжение вступит в силу через 16 календарных дней после уведомления — 13 сентября.

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

На странице ICANN с мерами договорного контроля запись от 5 августа о нарушениях связана с уведомлением о расторжении от 28 августа. Это подтверждает изменение статуса правоприменительного процесса. Но из него не следует, что вся последующая операционная цепочка уже исполнена.

Четыре нарушения относятся к разным системам

В уведомлении говорится, что IPIP не устранила нарушения, обозначенные 5 августа, до крайнего срока 26 августа. Затем ICANN перечисляет четыре нарушения, которые оставались открытыми.

Первое связано с RDAP Directory Service. По утверждению ICANN, IPIP не обеспечивала работу сервиса, который возвращал бы необходимые регистрационные данные по всем активным gTLD-именам под ее спонсорством и соответствовал действующим руководству по реализации и профилю ответов. В уведомлении от 5 августа уточнялось: базовый URL был зарегистрирован, однако проверенные ICANN запросы по доменам не вернули регистрационные данные.

Второе касается своевременного депонирования данных регистратора по требуемому графику, условиям и формату. Третье — просроченные аккредитационные сборы. Четвертое — отсутствие на главной странице прямой ссылки на механизм и процедуру подачи запроса о раскрытии непубличных регистрационных данных.

У этих пунктов разные контрольные поверхности. RDAP — публичный сервис доступа к регистрационным данным. Data Escrow — механизм непрерывности, при котором данные передаются утвержденному хранителю. Сборы — платежное обязательство. Ссылка на раскрытие — публичный вход в процедуру, предусмотренную разделом 10.1 Registration Data Policy. Для них различаются доказательства, зависимые стороны и критерии исправления.

Нормативные материалы доступны для проверки. ICANN указывает, что gTLD RDAP Profile от февраля 2024 года стал обязательным 21 августа 2025 года. Спецификация Registrar Data Escrow 2025 года вступила в силу в тот же день. Политика регистрационных данных требует указывать формат запроса, способ ответа и ожидаемый срок обработки.

Однако выводы о конкретном поведении IPIP принадлежат ICANN. BTW не повторял запросы ко всему набору спонсируемых доменов, не проверял счет депонирования и не проводил аудит счетов на оплату. Поэтому точная формула — «ICANN зафиксировала четыре неустраненных нарушения», а не независимое подтверждение редакцией.

Второй список введен другими словами

После четырех нарушений документ начинает новый абзац словами «In addition» и сообщает, что IPIP не рассмотрела и не разрешила «additional concerns» — дополнительные вопросы, вызывающие озабоченность.

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

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

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

Между четырьмя нарушениями также не установлена иерархия. Раздел 5.5.4 допускает расторжение, если регистратор не устранит любое нарушение в течение 21 дня после уведомления. ICANN заявляет, что все четыре пункта остались открытыми, но не сообщает, какой из них имел решающее значение и считался ли какой-либо один пункт достаточным сам по себе. Заголовок не должен дописывать причинность за орган, принявший решение.

Хронология говорит о процедуре, а не о мотивах

В двух уведомлениях описаны несколько последовательностей контактов, начавшихся в марте и июне. ICANN фиксирует последующие или повышенные по уровню уведомления, отклоненные письма, отсутствие ответов, телефонные звонки и один ответ от 2 апреля, который был признан недостаточным для подтверждения соответствия. 5 августа формальное уведомление отправили электронной почтой и курьером. Доставка была подтверждена 7 августа. 19 августа последовали напоминания. 26 августа срок истек, а 28 августа ICANN заявила, что необходимого исправления нет.

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

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

Третий набор — это последствия

Далее уведомление переходит от оснований к результатам. ICANN намерена применить De-Accredited Registrar Transition Procedure, чтобы передать имена под управлением IPIP квалифицированному аккредитованному регистратору. Лицензия на использование логотипа ICANN отзывается с 13 сентября. После расторжения сохраняют силу положения о хранении регистрационных данных, сборах, разрешении споров и ограничениях денежных средств правовой защиты; просроченные и другие указанные суммы остаются к оплате.

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

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

Публичная строка состояния для каждого пункта

Страница уведомлений ICANN дает полезный статус на уровне дела. Компактная таблица на уровне отдельных пунктов сделала бы неверный пересказ намного сложнее.

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

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

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

Текст Heng Lu применяется здесь только как аналитическая дисциплина: институциональная власть с серьезными последствиями должна оставаться связанной с определенной компетенцией, доказательствами, ответственностью и пересмотром. Полномочия ICANN дает договор, а не эссе. Эссе лишь объясняет, почему публичный пересказ не должен незаметно расширять ни полномочие, ни сделанный вывод.

Непосредственный вывод узок. ICANN выпустила уведомление о расторжении договора с IPIP. В нем названы четыре неустраненных нарушения. Другие вопросы записаны отдельно. Дата вступления в силу еще не наступила. Точность начинается с отказа превращать эти предложения в одно неразличимое обвинение.

Источники

  1. ICANN — Уведомление IPIP INC. о расторжении, 28 августа 2026 года
  2. ICANN — Уведомление IPIP INC. о нарушениях, 5 августа 2026 года
  3. ICANN — Уведомления о нарушении, приостановлении, расторжении и непродлении
  4. ICANN — Registrar Accreditation Agreement и связанные материалы
  5. ICANN — Registration Data Policy
  6. ICANN — gTLD RDAP Profile
  7. ICANN — Registrar Data Escrow Program
  8. ICANN — Подход и процедуры Contractual Compliance
  9. ICANN — Прекращение аккредитации
  10. ICANN — De-Accredited Registrar Transition Procedure
  11. Heng Lu — Когда власть реестра отделяется от ответственности