Кратко

  • Официальный дамп AFRINIC от 30 августа 2026 года содержит 3 790 объектов RPSL с точной формой remarks: Geofeed HTTPS-URL; из них 3 573 — адресные объекты inetnum и inet6num, на которые рассчитан механизм RFC 9632.
  • Форма в примечаниях не является нарушением. RFC 9632 прямо предусматривает её для баз без поля geofeed: и требует от потребителей поддерживать обе формы на всём переходном этапе.
  • Действующие шаблоны адресных объектов AFRINIC содержат remarks:, но не geofeed:. В публичном архиве DBWG есть просьба оформить задачу и оценить последствия, а также повторные запросы, но до августа 2026 года не найдено более позднего публичного решения.
  • Ограниченный протокол миграции мог бы зафиксировать статус, права записи, синтаксис, разрешение конфликтов, судьбу старых данных, отображение WHOIS/RDAP, границы аутентификации и приватности, тесты и откат.

У этого аудита два итога, и оба нужны. 3 790 — число точных строк во всех классах. 3 573 — число адресных объектов, для которых такая строка имеет стандартизованный смысл.

Строгий поиск по официальному дампу AFRINIC находит 3 790 объектов, где после remarks: стоит чувствительный к регистру токен Geofeed и HTTPS-URL. Именно такую резервную форму определяет RFC 9632. Разбор по границам RPSL даёт 3 483 объекта inetnum и 90 inet6num — всего 3 573.

Оставшиеся 217 вхождений распределены между 168 route, 41 route6, пятью domain, двумя as-set и одним organisation. Строка совпадает с шаблоном, но контейнер не относится к адресным объектам, вокруг которых RFC строит поиск.

Это не даёт оснований объявлять 217 записей неисправными. Примечание не имеет собственного типа. В нём может находиться Geofeed, служебная инструкция, сертификат или произвольное пояснение. Машинный смысл создаёт соглашение между публикующей и читающей сторонами; схема видит только текст.

Поэтому в заголовке стоит 3 573. Число 3 790 показывает распространение соглашения по всей базе и одновременно его выход за границы адресных классов. Называть все эти объекты адресными было бы точной арифметикой с неверной семантикой.

Сначала — сильнейшая защита нынешней модели

AFRINIC использует не случайный обходной путь, а предусмотренный стандартом механизм совместимости.

RFC 9632 не предполагает одновременного обновления всех RIR. Если geofeed: ещё не реализовано, применяется точная форма в remarks:. Пока все производители не объявят поддержку отдельного поля, а регистранты не перенесут объекты, потребители обязаны понимать оба представления. Клиент, который раньше времени перестанет читать примечания AFRINIC, нарушит совместимость сам.

Механизм реально принят. В 3 573 адресных объектах встречаются 106 различных HTTPS-URL. По статусам это 3 461 ASSIGNED PA, 71 ALLOCATED PA, 17 ALLOCATED-BY-RIR, 13 ASSIGNED PI и 11 SUB-ALLOCATED PA. Один файл может законно описывать несколько префиксов, поэтому повторение URL естественно.

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

Осторожность AFRINIC также может быть оправданной. Новое поле затрагивает аутентификацию обновлений, веб-формы, почтовые запросы, дампы, WHOIS, RDAP, валидаторы, документацию и поддержку. Нужно решить, что делать с двумя формами в одном объекте, историческими вариантами и клиентами с разными циклами обновления. Маленькая правка шаблона становится изменением нескольких сервисов.

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

Поле проверяет форму, а не географию

RFC 9632 отмечает, что RIR не может формально проверить Geofeed внутри remarks:. Там трудно обеспечить и рекомендацию об одной ссылке на объект. Отдельный атрибут позволил бы проверять HTTPS, ограничивать количество, обнаруживать конфликт и передавать значение другим интерфейсам как данные.

В дампе 3 592 адресных объекта содержат Geofeed-подобное примечание без учёта регистра. 106 строк отклоняются от строгой формы: встречается двоеточие после слова, нижний регистр или HTTP. Неизвестно, какие варианты принимают конкретные сборщики. Известно, что свободный текст не останавливает расхождение правил.

Но структурное поле не удостоверяет всё остальное. Следует разделять:

  • распознавание корректного указателя внутри адресного объекта;
  • полномочия издателя говорить от имени адресного пространства;
  • точность и своевременность координат, городов и стран;
  • приватность пользователей при высокой детализации данных.

HTTPS удостоверяет названную конечную точку и защищает транспорт, но не право на IP-ресурс. Поэтому RFC 9632 описывает необязательную подпись RPKI, усиливающую связь с ресурсным сертификатом. Даже подписанный файл не доказывает, что каждое место в нём соответствует реальному использованию адреса в любой момент.

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

Ранее опубликованный материал об APNIC рассматривал границу между аутентификацией ссылки и истинностью местоположения. Здесь объект иной: в AFRINIC сама ссылка ещё не отделена схемой от обычного примечания.

Публичная задача без найденного публичного финала

27 октября 2025 года участник Database Working Group предложил добавить geofeed: и разрешить владельцам ресурсов его обновлять. Он описал текущий путь через remarks и сообщил, что в его опыте с PI-ресурсами требовалась помощь hostmaster.

На следующий день сопредседатель открыл двухнедельное обсуждение и попросил персонал подготовить оценку плюсов и минусов. 14 ноября, отметив отсутствие возражений, он попросил AFRINIC принять предложение как рабочую задачу и объяснить реализацию вместе с impact assessment.

Автор напомнил о запросе 6 апреля 2026 года. 16 апреля сопредседатель попросил подтвердить активный статус задачи и снова запросил оценку. 17 апреля другой участник поддержал предложение.

Официальный индекс показывает месяцы с сообщениями в январе, феврале, марте, апреле и августе 2026 года; архивов за май, июнь и июль нет. В проверенных ветках до августа не найдено более позднего сообщения с темой Geofeed после 17 апреля.

Вывод должен оставаться узким: в изученном публичном архиве DBWG не найдено последующего ответа или статуса. Это не доказывает бездействие AFRINIC. Внутренний тикет, техническая работа, частный разговор или зависимость могут существовать. Публичная рассылка не видит все процессы.

Недостаёт не обязательного одобрения, а закрывающей записи: принято, отложено, отклонено, заменено или ожидает другого события. Любой статус можно обосновать. Из тишины нельзя воспроизвести ни один.

Тринадцать PI-объектов — граница наблюдения

Заявление о PI можно сопоставить с данными, но нельзя переносить на всех владельцев. В дампе 13 адресных объектов ASSIGNED PI используют строгую форму, и у всех в mnt-by указано AFRINIC-HM-MNT. На более низких уровнях присутствуют maintainer, связанные с ресурсами.

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

Нужна матрица полномочий. Для каждого класса, статуса и сочетания mnt-by/mnt-lower: кто добавляет, изменяет, удаляет и исправляет указатель? Через какой интерфейс и с какой аутентификацией? Если прямое обновление запрещено, куда обращаться и какой номер подтверждает результат?

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

RDAP переносит строку, но не переносит её тип

В ответе AFRINIC RDAP для 160.115.0.0 Geofeed-URL находится в общем описании remarks. Массив соответствия содержит rdap_level_0, nro_rdap_profile_0, cidr0, но не geofeed1 и не структурированную ссылку.

RFC 9877 определяет отношение rel: geofeed и необязательное расширение geofeed1. Сервер может публиковать ссылки. Если он объявляет расширение, то должен предоставить ссылку для имеющегося и доступного URL. AFRINIC не объявляет расширение в проверенном ответе, следовательно, нарушение не установлено.

Установлена другая вещь: человек и специальный парсер понимают примечание, а обычный RDAP-клиент не может узнать из conformance о структурированной поддержке и снова анализирует текст. Значение перешло через API, его семантический тип — нет.

Что должно быть в протоколе миграции

Минимальная запись включает:

  1. ID задачи, владельца, дату принятия, состояние и следующую проверку;
  2. текущую и целевую версии схемы;
  3. влияние на обновления, дамп, WHOIS, RDAP и клиентов;
  4. права записи по классу, статусу и maintainer;
  5. HTTPS-синтаксис, количество значений и ошибки;
  6. сосуществование и приоритет двух форм;
  7. инвентаризацию строгих, вариантных и внеклассовых записей;
  8. решение по geofeed1 и отображению RDAP;
  9. различие между синтаксисом, HTTPS, ресурсной властью RPKI и точностью;
  10. предупреждение о приватности и детализации;
  11. тестовую выборку, совместимость, исправление и условие отката;
  12. запись о внедрении или закрытии с версией, датой, метриками и исключениями.

Такой документ может обосновать отсрочку. Можно оставить remarks и улучшить валидацию, добавить поле без автоматического переноса, отложить RDAP. Подотчётность не означает обязательную победу предложения. Она означает видимость решения.

Реестр заслуживает доверия не тогда, когда знает всё, а когда точно ограничивает собственное знание. AFRINIC не обязана удостоверять географию каждого адреса. Она обязана ясно показать, что её база распознаёт, что лишь переносит и кто может это исправить.