Кратко

  • Слайд APNIC 62 сообщает, что на APNIC пришлось 3,0% «успешных публикаторов Geofeed» в случайной выборке из 200 тысяч строк геолокации, обнаруживаемых через Whois; на ARIN — 21,6%, на RIPE NCC — 75,5%.
  • Группировка выполнена по уникальным netname, а AFRINIC и LACNIC исключены по техническим причинам. Не опубликованы ни размер соответствующей генеральной совокупности, ни дата снимка, ни абсолютное число netname, ни правило успеха.
  • Поэтому проценты описывают состав включённого набора успехов. Они не доказывают, что Geofeed внедрили 3,0% участников, держателей ресурсов, префиксов или сетей APNIC.
  • Интерфейс публикации в один клик может снять часть трения, но его эффект требует версионированной квитанции измерения, связывающей допуск, обнаружение, проверку, поддержку и последующее использование.

Единицу счёта определяет сноска

Три столбца легко принять за региональный рейтинг. У APNIC — 3,0%, у ARIN — 21,6%, у RIPE NCC — 75,5%. Заголовок спрашивает, из каких RIR происходят успешные публикаторы, поэтому высоту столбцов хочется прочитать как результат соревнования по внедрению.

Сноска меняет объект счёта. Исходные данные — случайная выборка из 200 тысяч строк геолокации с geolocatemuch.com, ссылки на которые удалось обнаружить через Whois. Далее записи сгруппированы «по идентификаторам сетей», то есть по уникальным netname. AFRINIC и LACNIC намеренно не включены из-за технических ограничений.

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

Три доли дают в сумме 100,1%. Это обычное следствие округления до одного знака, а не самостоятельное открытие. Существенный пробел в другом: не указано, сколько уникальных netname стоит за каждым столбцом и сколько netname, держателей, префиксов или маршрутизируемых сетей имели право участвовать в каждом RIR.

Состав не равен распространённости

Представим тысячу успешных наблюдений, из которых тридцать отнесены к APNIC. Доля APNIC внутри этого набора составит 3,0%. Если подходящая совокупность APNIC равна шестидесяти объектам, картина распространённости будет иной, чем при шестидесяти тысячах. Один числитель не способен ответить на оба вопроса.

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

Материал APNIC Blog сам называет источник выборкой и говорит о региональных различиях во внедрении Geofeed. Направление тревоги может быть верным: внутри включённого набора мало успехов с меткой APNIC. Но опубликованные сведения не позволяют оценить вероятность того, что оператор APNIC внедрит Geofeed, по сравнению с оператором RIPE NCC.

Исключение двух RIR делает границу ещё яснее. Его раскрыли — это хорошая практика. Одновременно это означает, что столбцы описывают три включённых региона, а не всю систему RIR. Из них ничего не следует об AFRINIC или LACNIC, а технические трудности с включением могут указывать на ограниченную сопоставимость регистрационных данных.

«Успех» нужно разложить на состояния

Публичная страница geolocatemuch.com описывает обнаружение через Whois и предлагает объединённый проверенный фид. Она также показывает сложность соединения данных: один файл может включать несколько префиксов, несколько ресурсных объектов могут вести к одному файлу, а строки за пределами охвата регистрационного объекта должны отбрасываться.

Слайд APNIC 62 не определяет «успешного публикатора». Успехом могло считаться обнаружение ссылки, получение URL, разбор CSV, попадание строки в разрешённый диапазон, проверка полномочий публикатора, прохождение проверок полей или реальное использование данных последующим сервисом. Это разные состояния.

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

RFC 9877 переносит обнаружение в RDAP с помощью отношения geofeed1 и зарегистрированного типа содержимого. Получение и применение данных прямо оставлены за рамками документа. RFC не требует кнопки в кабинете реестра, не определяет знаменатель внедрения и не гарантирует загрузку в стороннюю базу.

Один клик устраняет лишь один вид трения

В пятистраничной презентации Сид Матур предлагает RIR обеспечить публикацию URL Geofeed «в один клик» из личного кабинета. Идею стоит испытать. Реестры уже аутентифицируют учётные записи и ведут ресурсные объекты, с которых начинается обнаружение. Пошаговая форма может предотвратить опечатки, проверить диапазон, показать предупреждения о приватности и сделать малоизвестный механизм заметным.

Сильнейший аргумент сторонников следует признать: оператор не должен изучать случайно сложившийся командный язык, чтобы опубликовать стандартный URL. Хорошая форма способна снизить расходы на поддержку и сделать правильный путь самым простым.

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

В презентации также упомянут неформальный опрос в сообществе APNIC в WhatsApp, где ответ «неясно, как реестр может помочь» якобы занял второе место среди барьеров. Это полезный повод заказать исследование, но не измеренный приоритет региона. Нет числа и способа набора респондентов, формулировки вопроса, вариантов, даты или правила удаления повторов. Неясно, что заняло первое место, насколько велик разрыв и представляют ли ответы тех, кто ещё ничего не публикует.

Квитанция для утверждения о внедрении

Версионированная квитанция измерения начинается до столбчатой диаграммы. Она фиксирует момент снимка, версии файлов и кода, правило отбора 200 тысяч строк, исходные и уникальные количества префиксов, метод обнаружения Whois/RDAP, правило отнесения к RIR и каждое техническое исключение. В ней названо состояние успеха и показан поток через этапы: обнаружено, получено, разобрано, в диапазоне, полномочия подтверждены, актуально, использовано.

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

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

Отчёт APNIC 62 подтверждает, что «The case for RIRs» был докладом в Cooperation SIG. Он не превращает предложение докладчика в политику APNIC. В блоге также указано, что мнения авторов не обязательно отражают позицию APNIC. Такое разделение сохраняет и пространство для эксперимента, и границы ответственности.

Столбец 3,0% не следует выбрасывать. Он даёт основание исследовать проблему. Сноска даёт инструкцию не преувеличивать. Сначала нужно показать, что вошло в выборку, что прошло фильтры, что исключили и кто мог участвовать. Только следующая диаграмма сможет сказать, изменила ли более простая форма реальное внедрение или лишь рассказ о нём.

Источники

  1. APNIC Blog — IP-геолокация на APNIC 62
  2. Sid Mathur — Self-published Geofeeds; the role of RIRs
  3. Отчёт конференции APNIC 62
  4. Geolocate much?
  5. RFC 8805 — Формат самостоятельно публикуемых фидов IP-геолокации
  6. RFC 9632 — Обнаружение и использование данных Geofeed
  7. RFC 9877 — Расширение RDAP для данных Geofeed