Кратко

  • Публичная документация NIR API APNIC показывает асинхронный запрос /nir-delegations/asn, однако называет его делегированием из пула NIR, а не доказательством более позднего механизма прямого назначения.
  • В сентябре 2024 года изменения ядра реестра и NIR API находились в разработке, а в декабре проект дошёл до финального QA. В нынешней записи дорожной карты за 2025 год поля цели и журнала изменений пусты.
  • Короткое свидетельство о релизе могло бы связать проект, версию схемы, момент переключения, участвующие NIR, миграцию старых записей и сверку Whois/RDAP, не раскрывая документы заявителей.

Реконструкция выглядит почти убедительно. Сначала APNIC сообщает о разработке. Затем о финальном тестировании. После этого на публичном сайте обнаруживается инструкция: отправить авторизованный запрос на /nir-delegations/asn, получить ссылку на асинхронную задачу и дождаться статуса SUCCESSFUL. Кажется естественным заключить, что инструкция и есть результат проекта.

Но естественное заключение не равно доказанному. В системах реестра особенно важно различать сходство названий и идентичность версии.

Документация NIR API говорит, что национальные интернет-регистратуры используют интерфейс для управления регистрационной информацией своих субаккаунтов. Перед делегированием необходимы контактные данные: из них формируются части записей Whois и RDAP. Изменяющие состояние операции выполняются асинхронно. Общие правила интерфейса поддерживают Idempotency-Key, чтобы повтор запроса после обрыва связи не создал вторую операцию.

Это зрелые свойства транзакционной системы. Они объясняют, как безопасно обратиться к сервису. Они не объясняют, какой именно вариант распределения ресурсов скрывается за неизменным адресом запроса.

В инструкции фигурирует пул, в проекте — прямое делегирование

Текст учебного примера называет операцию делегированием ресурсов из пула NIR. Запись дорожной карты формулирует иную цель: прямое делегирование ASN владельцам субаккаунтов NIR, реализованное в реестре и доступное через MyAPNIC и NIR API. Ожидаемый результат — повышение согласованности и достоверности данных.

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

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

Дорожная карта доводит проект до 2025 года, но не до даты

Публичная последовательность этапов достаточно подробна. В сентябре 2024 года APNIC сообщала, что обновления ядра реестра и NIR API продолжаются. В декабре проект прямых ASN-назначений находился на финальной стадии QA. В материалах, опубликованных в начале 2025 года, он всё ещё числился среди выполняемых работ.

Текущий набор данных дорожной карты относит инициативу к 2025 году, называет команду Registry и продукты ARMS и MyAPNIC. В карточке сохранены цель и ожидаемое улучшение качества данных. Однако поле плановой даты пусто, как и changelog.

Годовой отчёт APNIC за 2025 год утверждает, что квартальные цели продуктовой дорожной карты достигнуты. В числе конкретных результатов он называет обновлённую авторизацию Whois, объекты RPKI Signed Checklist и прототип новой архитектуры RDAP. Названия проекта прямых ASN-назначений в полном тексте нет.

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

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

Статус задачи не описывает цепочку полномочий

SUCCESSFUL говорит, что сервис завершил обработку. Он не сообщает, из какого пула получен ASN, кто проверил право заявителя, какая версия схемы приняла поля и совпали ли конечные представления Whois и RDAP. Такой лаконичный статус необходим для автоматизации, но его нельзя превращать в замену релизному и нормативному свидетельству.

ASN обозначает автономную систему, обменивающуюся маршрутной информацией по собственной политике. По действующим правилам APNIC заявитель может обратиться за ASN либо в APNIC, либо в соответствующий NIR. Любое выданное ASN должно быть публично зарегистрировано в Whois APNIC или NIR.

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

Прямая запись в ядро способна убрать повторный ввод и уменьшить расхождения. Одновременно она повышает цену неясности: внешнему наблюдателю труднее понять, какой акт был решением NIR, какой — технической проверкой APNIC, а какой — публикацией состояния.

Idempotency-Key предотвращает случайное повторение одного запроса. Она не гарантирует правильность смысловой версии. Операция может выполниться ровно один раз по старому правилу. Два NIR могут находиться на разных этапах миграции. Успешная задача может потребовать последующей сверки публичных объектов. Идемпотентность контролирует повтор, а не происхождение полномочия.

Прямая запись не отменяет национальный уровень

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

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

Именно это могло бы повысить качество данных. Но для проверки результата необходимо определить, что стало прямым: происхождение номера, акт одобрения, транспорт между системами, запись в базе или всё перечисленное. Также важны старые ASN: были ли они перенесены в новую модель субаккаунтов, остались ли параллельные пулы и одинаково ли менялся сервис для разных NIR.

История IPv4 показывает опасность сокращённых формулировок. В 2019 году APNIC писала, что с 2004 года выделения адресов через NIR делались из общего регионального пула и напрямую отражались в реестре APNIC вместо старой конфедерационной схемы. Наследованные блоки сохранились, а последующая сверка исправляла даты, владельцев и пропущенные передачи.

Этот пример не доказывает устройство ASN-функции. Он показывает, что происхождение пула, ответственность за обслуживание и место записи могут меняться отдельно. Поэтому значение слова «прямое» нельзя переносить из IPv4 в ASN без явной версии и даты.

Публичная проверка рассматривает другую совокупность

APNIC ведёт программу проверки ресурсных делегирований. Она включает анализ данных, выборочные проверки соблюдения правил, оценку процедур, точности учётных записей, поддержку NIR и будущий пересмотр соглашений. В июле 2026 года APNIC сообщила о завершении работ по JPNIC, TWNIC и KRNIC и о продолжении анализа других NIR.

Однако основной публично заявленный охват программы конкретен: десять лет делегирований и передач IPv4. Эти результаты не являются независимым показателем нового пути ASN. Они не сообщают число прямых ASN-назначений, набор подключённых NIR или долю расхождений между запросом и публичной записью.

Столь же неверно было бы заключить, что внутренних проверок ASN у APNIC нет. Публичный текст лишь задаёт другой знаменатель. Транзакционная задача описывает отдельный вызов, программа анализа — исторический массив IPv4, а дорожная карта — намерение продукта. Между ними отсутствует свидетельство, которое связывает намерение с исполняемой версией.

Как должно выглядеть минимальное свидетельство

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

Вторая часть опишет внедрение. Какие NIR подключены? Было ли включение одновременным или поэтапным? Сохранился ли старый путь из NIR-пула? Когда он перестал использоваться? Какие группы существующих ASN перенесены в новые субаккаунты, а какие сознательно остались вне миграции?

Третья часть представит агрегированную проверку за ограниченный период: число попыток, успешных и отклонённых запросов, отмен, исправлений и сверок; совпадение ядра реестра с Whois и RDAP; повторы, поглощённые идемпотентностью; нерешённые исключения. Ни одно имя заявителя для этого не нужно.

Такой документ разделит три вида истины. Истина релиза отвечает, какие правила развернуты. Истина транзакции отвечает, что сделал конкретный запрос. Истина состояния отвечает, что сейчас находится в публичном реестре. Система становится проверяемой, когда эти виды связаны версиями и ссылками, а не когда один подменяет остальные.

Источники