Кратко

  • В уведомлении от 25 сентября 2026 года ICANN назвала неоплату аккредитационных взносов Netpia.com, Inc. фундаментальным и существенным нарушением. Работу RDAP и прямую ссылку на порядок запросов о раскрытии данных она указала отдельно как области несоблюдения требований.
  • Публичный RDAP нужен для обязательных открытых сведений о регистрации. Второй канал объясняет, как запросить рассмотрение непубличных сведений; сам факт подачи не дает права на автоматическое раскрытие.
  • Срок исправления — 16 октября. Возможное начало процедуры прекращения аккредитации зависит от дальнейших действий и не является уже состоявшимся прекращением.

У платежа есть дата и сумма. У доступа к данным — адрес, время ответа, набор охватываемых доменов и понятные правила для заявителя. Эти свидетельства нельзя подменять друг другом. Уведомление ICANN регистратору Netpia.com, Inc. (номер IANA 130) позволяет увидеть, почему даже полное погашение задолженности не доказывает исправность двух каналов, с которыми сталкивается внешний пользователь.

В документе финансовая часть получила определенный статус: ICANN сочла задолженность по взносам нарушением раздела 3.9 соглашения об аккредитации и назвала его фундаментальным и существенным. Отдельными пунктами организация признала несоблюдение правил службы RDAP Directory Service и требования разместить на главной странице прямую ссылку на механизм запросов непубличных данных. Еще семь требований к информации на сайте и в регистрационном соглашении помещены в раздел «Additional Concerns». Их нельзя вычеркнуть, но нельзя и приписать каждому ту же формальную квалификацию, что платежному нарушению.

Главный вопрос этой статьи уже: чем подтвердить восстановление двух разных возможностей доступа.

Наличие зарегистрированного адреса не равно доступности службы. По данным ICANN, базовый адрес RDAP Netpia — rdap.ibi.net, однако ее мониторинг SLAM фиксировал периодические сбои и повторяющиеся результаты «down» в соответствующие периоды. При остановке службы запросы по обслуживаемым доменным именам не проходят. Это изложение вывода ICANN, а не независимый замер BTW. Документ не сообщает суммарную длительность сбоя, количество затронутых доменов или факт утечки данных. Для исправления ICANN требует показать бесплатный публичный доступ по запросу к актуальным данным обо всех активных gTLD-именах под управлением Netpia, выполнение технического руководства и профиля ответов RDAP версии февраля 2024 года и предоставить одно обслуживаемое имя для мониторинга. С августа 2025 года эта версия профиля обязательна. Одна удачная проверка не показывает устойчивость работы всей службы.

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

Смешать этот процесс с открытым RDAP — значит потерять границу защиты данных.

До 16 октября 2026 года ICANN ждет оплату, доказательства работы RDAP, прямую ссылку и другие затребованные меры. Если требования не будут выполнены и сведения не поступят вовремя, она может приступить к процедуре прекращения соглашения. Уведомление от 25 сентября такой процедуры не завершает. Приложенная хронология содержит ответы регистратора, которые ICANN сочла недостаточными; представлять дело как полное отсутствие ответов было бы неверно.

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

Источники