Кратко

  • В сохранённом снимке за 8 сентября, 14:00–15:00 UTC, поле WHOIS total_queries равно 3 192 583, а семь видимых типов дают 3 183 463 — на 9 120 меньше. В той же записи RDAP сумма совпадает точно.
  • Проверка 1 691 архивного часа показала расхождение во всех 1 690 часах с трафиком WHOIS. В 1 011 файлах общий итог больше, в 679 больше сумма типов; одной положительной категории «прочее» недостаточно, чтобы объяснить оба направления.
  • Опубликованная к APNIC 62 презентация называет prop-167 находящейся в реализации и говорит о решаемых проблемах точности, но не связывает их с этой арифметикой. Нужна почасовая ведомость, определяющая этапы подсчёта, исключения, проверку и цепочку исправлений без раскрытия исходных запросов.

Публичная статистика становится доказательством не в тот момент, когда у числа появляется много знаков, а когда читатель может восстановить его из составных частей. APNIC сделала важный шаг, открыв по prop-167 почасовые агрегаты использования WHOIS и RDAP. В них видны объём, типы запросов, исходные ASN и число различных адресов источника, но не сами адреса и не запрошенные объекты. Файлы доступны, сохраняются по месяцам и снабжаются контрольными суммами.

Именно открытость позволяет провести простую проверку. Зафиксированный текущий снимок охватывает 8 сентября 2026 года с 14:00 до 15:00 UTC. В разделе WHOIS total_queries содержит 3 192 583. Распределение указывает 1 670 618 для inetnum, 1 284 709 для route, 93 537 для aut-num, 88 530 для domain, 31 500 для organisation, 13 888 для as-set и 721 для inet6num. Вместе — 3 183 463.

Разница составляет 9 120 запросов, или 0,2857% объявленного итога. Опубликованный MD5 совпадает с вычисленным для скачанного JSON, поэтому нет оснований списывать расхождение на повреждение при передаче. В соседнем разделе RDAP пять типов дают ровно 588 346 — столько же, сколько записано в его общем поле.

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

Проверка каждого часа, а не удобная выборка

Первый файл начинается 30 июня в 03:00 UTC — в день, который страница prop-167 отмечает как завершение реализации. Последний архивный файл проверки заканчивается 8 сентября в 14:00 UTC. Между ними ожидается 1 691 час, и каталог содержит 1 691 файл. Имена идут без пропусков. Все gzip распаковываются, все документы читаются как JSON, внутренние полуоткрытые интервалы соответствуют именам. Одинаковых распакованных содержимых нет.

Для каждой службы применялась одна формула: сложить все значения query_type_distribution и сравнить результат с total_queries. Для каждой показанной строки ASN сумма query_count_by_type сравнивалась с query_count.

RDAP даёт контроль внутри того же набора. Во всех 1 691 часах общий итог равен распределению, и ни одна показанная строка ASN не расходится со своими типами. Значит, формат способен публиковать арифметически связанную разбивку.

WHOIS сходится один раз. В интервале 27 августа с 09:00 до 10:00 UTC раздел показывает ноль запросов, ноль ASN, пустое распределение и отсутствие строк. Это единственное совпадение. Следовательно, все 1 690 файлов с ненулевым трафиком WHOIS имеют два разных итога на уровне службы. В каждом из этих часов есть и хотя бы одна несогласованная строка ASN; за весь период таких видимых строк 347 490.

Расхождение присутствует с самого начала. В первый час общий показатель равен 4 774 145, а типы дают 4 801 599 — на 27 454 больше. В последнем архивном часе общий показатель 2 989 539, типы дают 2 987 334 — теперь на 2 205 меньше.

Перемена знака важнее суммарного сальдо. В 1 011 файлах total_queries больше суммы типов. Возможное объяснение — принятые службой команды, которые затем не попали ни в один опубликованный класс. Категория «не классифицировано» могла бы закрыть такие часы.

В 679 файлах сумма типов превышает общий итог. 14 июля с 05:00 до 06:00 UTC записано 3 288 941 в итоге и 3 652 538 по типам. Типы больше на 363 597, или на 11,0551% итога. Неотрицательная остаточная категория ничего не может вычесть. Максимальный разрыв в другом направлении наблюдается 20 августа с 03:00 до 04:00: +80 961, или 2,3823%.

Складывать положительные и отрицательные разницы и называть остаток числом ошибочных запросов тоже нельзя. Взаимное погашение не создаёт измеряемую величину. Надёжный вывод уже достаточен: два поля не соединены стабильным публичным уравнением.

Оба счётчика могут быть честными

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

Ни один из этих вариантов сам по себе не означает дефект. Публичный пробел в том, что README не выбирает и не описывает вариант. Он говорит, что каждый раздел содержит диапазон времени, общее число запросов, число ASN, распределение по типам и статистику по ASN. Он определяет часовое окно UTC и форму файла. Но в нём нет точки измерения, правила множественной классификации, списка исключений, обращения с повторами и поздними событиями или времени закрытия каждого этапа. Нет поля для неклассифицированных запросов, статуса проверки и ссылки на заменённую версию.

Поэтому доказательства не позволяют объявить 3 192 583 или 3 183 463 правильным ответом. Возможно, оба числа точны для разных вопросов: сколько команд принято на границе и сколько классификационных приращений создано после разбора. Тогда им нужны разные названия. Представление одного как итога, а другого как его естественной разбивки побуждает читателя выполнить операцию, которой документ не обещает.

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

В массиве asns есть ещё одна неописанная граница. Многие часы сообщают о нескольких тысячах исходных ASN, но наблюдаемая таблица содержит не более 1 000 строк. Это похоже на рейтинг для ограничения размера файла, что может быть разумно. Однако README не называет список усечённым и не определяет отбор. Даже исправленная сумма видимых строк не должна подменять всю совокупность службы.

Публикация завершена, уверенность — ещё нет

Официальная страница prop-167 по-прежнему показывает Implemented и строку «Implementation Complete» от 30 июня 2026 года. Одновременно APNIC опубликовала презентацию к заседанию Policy SIG на APNIC 62, запланированному на 10 сентября. Слайд prop-167 говорит «Status: In Implementation», напоминает о первоначальной публикации 30 июня, сообщает о решаемых проблемах точности данных и ожидает завершения к концу третьего квартала.

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

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

Выбор знаменателя становится выбором вывода

Открытый поток полезен. Он позволяет оценивать объём, состав типов, концентрацию по ASN и разнообразие источников без раскрытия IP или объектов поиска. Почасовое сохранение делает исследование повторяемым. Возможность обнаружить предел — достоинство прозрачности, а не довод в пользу закрытия данных.

Но любое повторное использование выбирает знаменатель. Доля строки ASN, разделённой на total_queries, отличается от доли, рассчитанной по сумме типов. Ряд общего поля может двигаться иначе, чем ряд, восстановленный из категорий. Обновление классификатора может выглядеть как изменение поведения пользователей, хотя изменилось только правило.

Файлы не доказывают потерю, дублирование, злоупотребление, ошибочный ответ, нарушение приватности или сетевой ущерб. Несогласованная строка не делает ASN виновником. Нулевой час без независимого сообщения не доказывает отказ. Проверяется способность опубликованного свидетельства объяснить себя, а не вся работа WHOIS.

Сверка без раскрытия пользователей

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

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

Наконец, исправление становится сохраняемым событием. Файл получает состояние «предварительный», «проверенный», «исправленный» или «отозванный» и отпечаток. Замена ссылается на прежний отпечаток, время, класс причины и затронутые поля. Старая версия остаётся доступной для восстановления уже опубликованных анализов.

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

Источники