Кратко

  • prop-167-v002 требовал два выхода: публичную почасовую статистику WHOIS/RDAP и функцию MyAPNIC, показывающую держателю запросы к его ресурсам.
  • Resolution 2025-32 одобрила публичную статистику. Функцию MyAPNIC EC тогда не счёл осуществимой: стоимость, ресурсы и возможные риски для приватности перевешивали непосредственную пользу.
  • Одобренный выход реализован и наблюдаем: архив начинается 30 июня 2026 года, текущий JSON содержит отдельные объекты RDAP и WHOIS.
  • Общий Implemented может верно описывать одобренный объём работ, но не сохраняет сам по себе отдельное решение по второму выходу.

Фактическое внедрение видно без доступа к внутренним отчётам. В каталоге APNIC лежат текущий JSON, checksum и годовой архив. Июньский каталог начинается файлами за 30 июня 2026 года и содержит сжатые почасовые снимки. Текущий объект разделяет RDAP и WHOIS, указывает часовой диапазон, число запросов, типы, ASN и количество разных исходных IP.

На странице prop-167 та же дата отмечена как Implementation Complete, а текущий статус — Implemented. Публичная ветвь имеет и административное завершение, и эксплуатационный артефакт.

Однако текст v002 описывал не одну ветвь. На этапе EC две части получили разные решения.

Выход v002 Решение EC 4 декабря 2025 года Проверяемое публичное состояние в августе 2026 года
Почасовая машиночитаемая статистика WHOIS/RDAP Одобрена Resolution 2025-32 Текущий JSON и почасовые архивы с 30 июня
Просмотр запросов к собственным ресурсам в MyAPNIC Тогда признан неосуществимым по опубликованным причинам Проверенные источники не доказывают последующее решение или внедрение

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

Два выхода отвечали на разные вопросы

prop-167-v002 был опубликован 21 августа 2025 года. В нём говорилось, что с 1 апреля по 30 июня APNIC ответил примерно на 5,5 млрд обращений к справочным сервисам, а в некоторые часы RDAP получал запросы более чем от 365 тыс. уникальных IP-адресов. Предложение ссылалось на внутренние данные APNIC.

Эта атрибуция обязательна. Публичный пакет не воспроизводит исторический расчёт и не показывает назначение каждого запроса. Упомянутые в предложении mining, массовый сбор или автоматический анализ были возможными объяснениями, а не установленным нарушением конкретного ASN.

Первый выход должен был дать обществу агрегированную картину. Данные обновлялись бы каждый час в JSON или CSV, отдельно для WHOIS и RDAP. В набор входили как минимум тысяча ведущих исходных ASN, количество исходных IP на ASN, тип и метод запроса.

Второй выход был связан с авторизованным держателем. В MyAPNIC он видел бы, сколько раз запрашивали его IP-адреса или ASN, с разбивкой по типу и, если возможно, по исходному ASN. Такая поверхность связывает учётную запись, права на ресурс и более детальную историю запросов.

Impact assessment тоже разводил работы. Публичный поток требовал извлечения и публикации на условиях best-effort, без SLA. Добавление MyAPNIC, если оно возможно, требовало большого объёма logging в базовых WHOIS-системах.

11 сентября v002 достиг консенсуса на APNIC 60. 14 октября закончился final comment. На этом общественный текст с двумя выходами был зафиксирован, но процесс APNIC ещё предусматривал отдельное исполнительное решение.

Роль EC записана в самом PDP

Policy Development Process говорит: после сохранения консенсуса SIG Chair просит EC одобрить предложение; после одобрения Secretariat внедряет политику. Поэтому нельзя представлять консенсус как автоматический приказ внедрить каждую фразу или EC как орган без полномочий определять scope.

Resolution 2025-32 одобрила v002 применительно к публикации статистики в реальном или почти реальном времени. Затем решение отдельно процитировало функцию MyAPNIC. Стоимость, потребность в ресурсах и возможные privacy concerns превышали непосредственную пользу, поэтому EC не считал функцию осуществимой на тот момент. Решение было единогласным.

With respect to ограничивает одобренную часть. Три причины принадлежат публичному решению; источники не дают оснований заменять их предположениями о мотивах. At this time привязывает оценку к 4 декабря 2025 года, но не обещает пересмотр и не устанавливает вечный запрет.

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

Работающий файл завершает одобренный маршрут

На APNIC 61 prop-167 ещё имел статус In Implementation, завершение ожидалось к концу Q2. Описание концентрировалось на машиночитаемой статистике. Текущие данные Product Roadmap называют задачей реализацию одобренных требований.

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

Один снимок не доказывает безупречную непрерывность, неизменность schema или выполнение любой возможной трактовки полей. Best-effort нельзя превращать в SLA. Данные 2026 года также не пересчитывают автоматически заявленные 5,5 млрд за 2025 год.

Но существование публичного выхода доказано. Значит, редакционная задача состоит не в поиске отсутствующего feed, а в правильной записи его объёма.

Родительская строка должна показывать, из чего она выведена

Каноническая страница связывает v002 и impact assessment, где остаётся требование MyAPNIC. Затем она показывает endorsement EC и Implementation Complete. В строках состояния нет отдельной disposition по двум выходам.

Если Implemented означает «реализован scope, одобренный EC», статус подтверждён. Если его прочесть как «весь текст консенсуса находится в production», он становится слишком широким. Страница не публикует правило, которое различает эти значения.

У предложения один идентификатор, но несколько независимо решаемых результатов. Proposal status пригоден для навигации. Минимальной единицей институционального решения он становится только тогда, когда все части получили одинаковую disposition.

Для MyAPNIC не подходит Failed: не доказан одобренный delivery, который провалился. Не подходит и «окончательно отказались». Источники допускают более точную строку: не одобрено 4 декабря 2025 года; тогда неосуществимо по указанным основаниям; последующий пересмотр публично не установлен.

Публиковать нужно связь решений, а не приватные запросы

Выходной реестр не требует сегодня создавать MyAPNIC-функцию. Он не требует открывать исходные адреса, отдельные обращения или частный вид участника. Именно такие данные могли затрагивать privacy boundary.

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

Поле Что оно удерживает раздельно
Версия и fingerprint Рассмотренный текст и последующие правки
ID выхода и исходный пункт Документ и единицу решения
Консенсус и final comment Общественный статус и исполнительное полномочие
Resolution и disposition Предполагаемое полное одобрение и фактический scope
Артефакт и начало production Объявление и наблюдаемый результат
Состояние неодобренного выхода Временную оценку, пересмотр и вечный отказ
Correction и supersession Новое решение и переписывание прошлого
Правило общего статуса Точное содержание Implemented

Это не новый PDP. Это компактная проекция уже состоявшегося процесса. Инженерные тесты, подробные расходы и защищённые logs могут оставаться внутренними.

Неизвестное нельзя превращать в обвинение

Источники не показывают, оценивал ли APNIC позже более дешёвый или более приватный дизайн MyAPNIC. Они не доказывают и отсутствие внутренней работы. Общее обновление портала не было бы доказательством конкретного resource-level query view.

Нет случая ущерба держателю, утечки, нарушения SLA или security incident. Нет оснований называть privacy concerns предлогом. Статья исследует сохранение scope, а не выносит решение по неопубликованной архитектуре.

Также неизвестна общая конвенция APNIC для статуса после scoped endorsement. Если Implemented обычно относится к одобренной части, строки могут сохранить этот summary и сделать видимым его основание.

Публичный feed — подтверждённый результат. MyAPNIC — иной, датированный исход. Точная институциональная память позволяет двум утверждениям стоять рядом.

Источники