Кратко

  • В текущей документации ARIN простые объекты IRR создаются через Online или REST/XML, а расширенные — через REST/RPSL либо миграцию из IRR-email. Происхождение задаёт доступные способы дальнейшего управления.
  • Мигрированный объект разрешено просматривать и удалять в ARIN Online, но редактировать его нужно через RPSL REST. Удаление и создание заново через веб-интерфейс переводят запись в другой класс происхождения.
  • Обзорная страница и примечания о внедрении расходятся в вопросе RPSL REST для объектов, созданных в Online. Без аутентифицированной проверки на достаточно широком наборе это расхождение остаётся фактом о документации, а не о рабочей системе.
  • Узкая квитанция может связать прежний хеш, класс, версию прав, тип полномочия, канал, результат и хеш преемника без публикации API-ключа, имени сотрудника или частной топологии.

Удалить разрешено там, где исправить нельзя

Руководство ARIN описывает необычную асимметрию. Перенесённый из старой службы IRR-email объект виден в ARIN Online. Уполномоченный пользователь может его удалить. Редактирование через ту же поверхность недоступно: руководство отсылает к REST, а примечания о внедрении предлагают удалить объект и создать его снова, если организация хочет дальше работать через веб. Руководство пользователя IRR ARIN

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

Источники не показывают, что из-за этого организация потеряла объект, маршрут исчез или фильтр дал ошибку. В исследовании не использовались учётная запись, ключ или живой объект ARIN; не наблюдались NRTM и BGP. Анализируется заявленная модель управления, а не инцидент.

Ограничение заслуживает содержательной защиты. Веб-форма может не уметь без потерь представить все атрибуты старого RPSL-объекта. Частичная правка способна незаметно нормализовать или отбросить то, чего нет на экране. В таком случае запрет безопаснее ложной совместимости.

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

Класс говорит о записи, а не о маршруте

ARIN называет простыми объекты, созданные в Online или через REST с XML. Таблица даёт им создание, чтение, изменение и удаление в этих двух каналах и не даёт прав в RPSL REST. Расширенные объекты создаются через RPSL REST либо приходят из IRR-email. Для них доступны четыре операции в RPSL REST, отсутствуют права в XML REST, а в Online остаются просмотр и удаление. Обзор IRR ARIN

Названия не ранжируют надёжность. Advanced не означает более достоверный или актуальный маршрут; simple не означает простую политику. Это классы представления, валидации и управления.

ARIN отдельно указывает, что публичная выдача имеет формат RPSL независимо от класса. Так и должно быть: потребителю важно содержание route, route6, aut-num, as-set или route-set, а не API-ключ сопровождающего. Для аудита изменений, напротив, важно, какой валидатор и какое полномочие породили текущее состояние.

RFC 2622 определяет Routing Policy Specification Language как язык для описания политики и объектов IRR. Он фиксирует утверждение, но не измеряет текущий BGP. Корректный объект не доказывает, что объявление существует, принимается всеми соседями или уже попало во все генераторы фильтров. RFC 2622

Следовательно, происхождение полезно как доказательство операции внутри реестра. Превращать его в сертификат фактической маршрутизации нельзя. Граница между этими областями важнее удобного общего слова «валидно».

Односторонняя миграция может быть разумным контролем

Примечания о внедрении показывают, что старые почтовые записи не просто переименовали. Их разделили по связи с ресурсами ARIN и результату валидации: часть вошла в авторитетную среду, часть оказалась в ARIN-NONAUTH. ARIN пишет, что мигрированные объекты прошли более строгую проверку нового сервиса и отмечаются в интерфейсе. Примечания о внедрении IRR Online

Сохранение метки честно описывает происхождение. Успешный импорт не делает старый объект задним числом созданным в новой форме. Эта история объясняет, почему внешне похожие результаты RPSL обслуживаются по-разному.

Есть и необратимое правило: первое действие организации через веб или REST навсегда отключает для неё обновления IRR-email. Оно сокращает число конкурирующих писателей. Иначе почта и API могли бы применять разные учётные данные, валидаторы и правила конфликтов к одному набору объектов.

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

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

Пара DELETE/POST имеет больше состояний, чем PUT

В REST-руководстве ARIN разделены GET, POST, PUT и DELETE. PUT меняет объект, DELETE удаляет. Нагрузки RPSL и XML действуют в рамках прав соответствующего класса. Протокол уже различает исправление и замену, даже если интерфейс представляет их одной пользовательской задачей. IRR REST API ARIN

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

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

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

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

Две актуальные страницы по-разному описывают RPSL

Текущая обзорная таблица не даёт простым объектам прав в RPSL REST. Примечания о внедрении, на странице со списком обновлений до 17 января 2025 года, утверждают, что созданные в ARIN Online объекты можно просматривать, обновлять и удалять через REST как с RPSL, так и с XML.

Это не косметическая разница. Возможно, тексты относятся к разным версиям, типам или условиям учётной записи; возможно, одна страница отстала. Источники не позволяют выбрать. Даже успешная проверка одного route-объекта доказывала бы только этот случай.

Публикация ARIN от февраля 2021 года помогает восстановить историю появления REST и планировавшихся изменений ограничений. Теперь она находится в Vault, материалы которого ARIN помечает как потенциально устаревшие. Это хроника, а не действующая матрица прав. ARIN Vault об IRR REST

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

Пока ARIN не согласует тексты или не появится аутентифицированная проверка с ясными границами, статья оставляет противоречие открытым. Она не утверждает ни доступность, ни обязательный отказ RPSL для Online-объекта.

Квитанция преемства не обязана раскрывать людей

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

API-ключ, имя сотрудника, внутренние связи организации и частная топология не нужны. ARIN удостоверяет только то, что контролирует: принятие, отказ или удаление реестрового утверждения по определённому пути. Квитанция не доказывает синхронизацию всех зеркал, перестройку фильтров или соответствие BGP тексту RPSL.

Руководство разрешает управлять IRR ролям Admin, Tech и Routing POC, но не Resource POC. Роль и класс объекта — независимые ограничения. Человек может быть правильно уполномочен и всё равно не иметь Online-редактирования из-за происхождения записи. Аудит должен раздельно отвечать на вопросы «кто» и «через какое представление».

Источники не обнаруживают плохой объект. Они показывают более узкий факт: путь возникновения остаётся частью пути исправления. ARIN может обоснованно защищать эту память. Когда смена инструмента требует удаления и нового рождения, та же память должна получить явную связь с преемником.

Источники

  1. ARIN: обзор Internet Routing Registry
  2. ARIN: руководство пользователя IRR
  3. ARIN: примечания о внедрении IRR Online
  4. ARIN: IRR RESTful API
  5. ARIN Vault: история запуска REST
  6. RFC 2622: Routing Policy Specification Language