Кратко

  • В июне 2024 года ARIN сообщил, что принятие общего стандарта IETF запустит поддержку geofeed в RDAP, ARIN Online и Reg-RWS, а предложение останется Open до разработки и развёртывания функции.
  • RFC 9877 вышел в октябре 2025 года как Standards Track и определил geofeed1, rel=geofeed и application/geofeed+csv, то есть проверяемый язык объявления возможностей сервера.
  • На 12 сентября 2026 года запись ACSP 2024.10 всё ещё имела статус Open. Живой ответ RDAP help не содержал geofeed1, а в одном специально выбранном сетевом объекте URL оставался только в Registration Comments.
  • Эти наблюдения не доказывают бездействие или отсутствие функции во всей базе. Они обосновывают более точное требование: датированную ведомость триггера, интерфейсов, миграции, массовой выдачи, приватности, испытаний и отката.

У внешней зависимости появился срок окончания

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

Но публично названная зависимость не может быть вечным описанием состояния. До окончания стандартизации вопрос звучит так: о какой семантике договорятся участники? После публикации — какой продукт внедрил договорённость и как это проверяется извне?

ACSP Suggestion 2024.10 подали 3 июня 2024 года. Автор просил необязательный атрибут geofeed в сетевых объектах ARIN. Практический контекст был прост: держатель ресурса помещал строку вроде Geofeed [URL] в свободный комментарий. Человек мог понять намерение, а программе приходилось распознавать текст, извлекать URL и решать, является ли он каноническим указателем.

7 июня ARIN ответил, что пять RIR вместе работают в IETF над расширением RDAP. После принятия стандарта изменение будет реализовано в RDAP, а нужная функция появится в ARIN Online и Reg-RWS. Также упоминался единый формат массовой выгрузки. Предложение должно было оставаться открытым до разработки и развёртывания.

Срока в ответе не было. Не было и определения слова «принят»: оно могло означать публикацию RFC, предыдущее одобрение, профиль NRO или иной эксплуатационный рубеж. Поэтому нынешний статус не доказывает просрочку. Однако ARIN сам выбрал внешний, наблюдаемый триггер. После его срабатывания публичная запись должна назвать следующий рубеж.

RFC 9877 определяет не поле, а обещание сервера

RFC 9877 опубликован в октябре 2025 года со статусом Standards Track. Он не требует от каждого RDAP-сервера поддерживать geofeed. Он задаёт правила для сервера, который решил это делать.

Отношение geofeed обозначает назначение ссылки. Тип application/geofeed+csv обозначает представление файла. Идентификатор geofeed1 объявляет, что сервер размещает URL geofeed для своих сетевых IP-объектов. IANA включила этот идентификатор в реестр RDAP Extensions.

Сервер, использующий geofeed1, должен добавлять его в rdapConformance ответа help и ответов lookup/search, содержащих сетевые IP-объекты. Если URL конкретного объекта известен и может быть раскрыт, сервер обязан вернуть соответствующую ссылку.

Так отсутствие ссылки получает ограниченный смысл. После объявления расширения клиент знает об общем обещании сервера. Без объявления он знает лишь, что в конкретном ответе ссылки нет.

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

Поэтому проверка help полезна, но не даёт права отрицать существование ссылок во всей базе. Она показывает декларацию сервера, а не исчерпывающий инвентарь.

Два ответа из production и границы доказательства

В ответе ARIN RDAP help, полученном 12 сентября 2026 года, были перечислены базовый уровень RDAP, профиль NRO, CIDR, origin-AS, поиск RIR и другие расширения. geofeed1 отсутствовал.

Надёжный вывод узок: в этот момент ответ не заявлял расширение RFC 9877. Из него не видны ветки разработки, закрытый пилот, ещё не опубликованная форма ARIN Online или дополнительная межреестровая зависимость. Публичное состояние протокола не равно внутреннему состоянию проекта.

Для 154.54.100.0/22 был выбран второй ответ. В Registration Comments находится Geofeed ai.net/geofeed.csv. В rdapConformance нет geofeed1; ссылки имеют отношения self, alternate и up, но не rel=geofeed.

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

Тем не менее пример ставит правильный вопрос: что станет со старым текстом после появления структурированного поля?

Фраза на ARIN 57 осталась в другой версии времени

В апреле 2026 года инженерный отчёт на ARIN 57 упомянул улучшения RDAP для geofeed и RPKI directory services. Было сказано, что работа «сейчас проходит через IETF». RFC 9877 к тому времени существовал примерно полгода.

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

Он показывает меньшую, но реальную проблему: две публичные временные отметки не согласованы. Короткое уточнение могло бы зафиксировать, что RFC завершён, а текущая зависимость — конкретный профиль, миграция, проверка приватности или продуктовый приоритет. Обновить объяснение значит версионировать публичное знание, а не признать вину.

Главный риск скрыт в переносе старых данных

ARIN Online принимает решения человека. Reg-RWS принимает автоматизированные изменения. RDAP публикует. Массовый канал обслуживает тех, кому не следует обходить миллионы объектов одиночными запросами. Миграция определяет судьбу существующих комментариев.

Поверхности могут развертываться не одновременно. Поле станет доступно в ARIN Online раньше API. Ссылка появится в объекте раньше декларации в help. Массовый snapshot обновится позже транзакционного ответа. Слово «запущено» без матрицы скрывает эти нормальные, но важные различия.

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

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

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

Авторизованный источник не становится измеренной географией

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

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

Машиночитаемость облегчает массовый сбор. Это достоинство, которое одновременно увеличивает значение устаревших кэшей, удаления, специфичности и приватности. RFC 9632 не рекомендует обычный RDAP для массового извлечения. Упоминание общего bulk-формата в ответе ARIN 2024 года уже признавало: транзакционный интерфейс и продукт распространения различаются.

У массовой выдачи должны быть идентификатор и время snapshot, границы полноты, hash, срок хранения и правила удаления. Иначе потребитель не отличит старую копию от ещё действующей публикации.

Структура ведомости внедрения

Первый раздел фиксирует триггер: RFC 9877, относящиеся errata, необходимый профиль NRO/RIR и дату, когда ARIN счёл условие 2024 года выполненным. Если осталась другая зависимость, она получает имя.

Второй раздел — матрица продуктов. Для ARIN Online, Reg-RWS, RDAP help, сетевых lookup/search и массовой выдачи указываются определённые состояния: проектирование, тест, доступно, по умолчанию, устаревает, завершено. Рядом стоят ожидаемые идентификатор, отношение, тип и безопасные положительный и отрицательный примеры.

Третий раздел описывает запись: роли, допустимые URL, нормализацию, удаление, предварительный просмотр и реакцию на временную недоступность. Краткий сетевой сбой не должен молча отменять решение держателя.

Четвёртый — журнал миграции: количество кандидатов, классы решения, подтверждение владельца, приоритет и откат. Публиковать отдельные URL для этой статистики не требуется.

Пятый раздел разделяет часы: принятие изменения, чтение в ARIN Online, чтение в Reg-RWS, видимость в RDAP, включение в массовый snapshot. Eventual consistency управляема, если её окно известно.

Шестой содержит тесты и управление: корректная ссылка, отсутствие, плохой URL, более специфичный объект, несколько языков, ограничение выдачи и удаление; дата rollout и rollback; пояснение слов с ARIN 57; окончательный статус ACSP 2024.10 со ссылкой на доказательства.

Граница, одинаковая для учреждения и критика

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

Ведомость даёт ARIN узкое и сильное утверждение: в эту дату эти интерфейсы поддерживают эти элементы по таким правилам. Пользователь проверяет ту же границу. Open остаётся статусом процесса, один объект — примером, URL — указателем, подпись — подтверждением происхождения.

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

Источники