Кратко

  • Автор ACSP 2026.4 сообщил, что после Detailed Reassignment в пользу другой Org API-ключ исходной организации не мог получить дочерний NET по handle. Ключ получателя мог; при этом исходная сторона, по её словам, могла выполнить DELETE и получить объект через mostSpecificNet, указав точные начало и конец диапазона.
  • ARIN закрыла предложение 30 марта 2026 года. После обсуждения иных инструментов поиска и будущих планов развития организация решила, что менять проверку прав в тот момент не нужно. Ответ не подтверждает отдельно каждый заявленный шаг, а Closed не означает внедрение исправления.
  • Неравенство прав может быть правильным: управление получателя отличается от reclaim-полномочия прямого держателя, а публичный Whois/RDAP — от аутентифицированного NET Payload. DELETE не обязан универсально подразумевать GET или PUT.
  • Безопасной недостающей частью мог бы стать урезанный предварительный просмотр: стабильная идентичность, прямая связь, наличие дочерних NET, ожидаемый ticket, последствия и токен версии, плюс публичная матрица ролей, путей, полей, условий и результатов.

Архитектуру прав легче понять, если на время забыть об HTTP-глаголах. В центре находится связь между двумя организациями и одним адресным блоком.

Руководство ARIN по управлению ресурсами разделяет simple reassignment, Detailed Reassignment и reallocation. Простой клиент не получает прямого управления. Org-получатель подробного перераспределения управляет своей записью. Прямой регистрант сохраняет reclaim, а некоторые возможности reverse DNS и IRR могут быть общими. Reallocation даёт получателю право распределять ресурс дальше.

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

Разделение данных тоже обосновано. NET Payload может содержать версию, комментарии, дату регистрации, Org или customer handle, диапазон, родительский handle, имя, origin AS и связи POC. Публичный каталог способен показать часть реестровой идентичности, не выдавая тот же набор, что и интерфейс провижининга.

Поэтому вопрос не звучит как «почему DELETE сильнее GET». Он звучит иначе: какая минимальная текущая информация должна сопровождать разрешённый DELETE, чтобы субъект подтвердил объект и последствия?

Официальная запись о заявленном поведении

ACSP 2026.4 было подано 3 марта 2026 года. Автор описал Detailed Reassignment из собственного NET в пользу другой Org. При попытке GET дочерней записи по handle ключ исходной стороны якобы получил отказ по правам. Ключ Org-получателя запрос выполнял.

Одновременно автор утверждал, что может удалить дочерний NET, получить его по точным адресам начала и конца через mostSpecificNet, а также увидеть публичную информацию в Whois по handle или IP. Из этого он вывел требование разрешить родителю GET и PUT: удаление и повторное создание, по его мнению, дают сходный эффект.

ARIN не приняла такую лестницу полномочий. В ответе от 30 марта сказано, что были обсуждены другие способы получить сведения при помощи существующих инструментов, а также будущие планы разработки. Изменения текущих API-проверок сочли ненужными в тот момент. Автор согласился с закрытием.

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

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

Точный диапазон — это знание до запроса

Каталог Reg-RWS описывает GET по NETHANDLE, GET mostSpecificNet по STARTIP/ENDIP, DELETE по handle и PUT по handle. Первые два возвращают NET Payload. DELETE возвращает Ticketed Request Payload. PUT принимает NET Payload и возвращает состояние после изменения.

Handle является стабильной реестровой идентичностью. Точный диапазон — это свойство, которое клиент должен уже знать. Whois/RDAP представляет третью поверхность, публичную и ориентированную на поиск.

В ACSP 2023.13 зафиксировано ограничение mostSpecificNet: вызов с точными началом и концом не заменяет поиск от любого содержащегося IP. Нужны правильные границы. Такой метод хорошо сверяет точный локальный учёт, но слабее помогает именно тогда, когда учёт мог устареть.

Человек может повторно найти объект в ARIN Online и визуально проверить его. Автоматике нужно машинно доказать, что локальные handle и диапазон по-прежнему относятся к одному объекту и что родительская связь не изменилась между планированием и выполнением.

Наличие потомков меняет саму процедуру удаления

DELETE, согласно ARIN, применяется только к reassignment и reallocation. Если под объектом нет иных NET, запрос может пройти автоматически и вернуть сведения об удалённой сети. Если вложенные распределения есть, создаётся ticket; пространство нельзя выдавать снова до успешной обработки.

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

Для изменения ARIN рекомендует сначала получить текущий NET. Это защита от устаревшего состояния. Для субъекта reclaim, которому полный payload не положен, нужна сокращённая форма той же защиты.

Предварительная проверка без передачи управления

Минимальная preview могла бы содержать:

  1. стабильный handle и нормализованный диапазон;
  2. класс NET и прямую родительскую связь;
  3. тип получателя без закрытых контактов;
  4. признак дочерних NET;
  5. автоматический или ticketed путь;
  6. сводку последствий для DNS, IRR и объектов маршрутизации;
  7. ожидаемые уведомления и аудиторские следы;
  8. короткоживущий токен версии.

DELETE предъявлял бы этот токен. Изменение диапазона, иерархии или значимой зависимости приводило бы к отказу и новой preview. Родитель получает наблюдаемость для своей функции, но не комментарии, частные POC и повседневное редактирование получателя.

Публичная матрица должна описывать единицу доступа так:

роль субъекта × отношение × класс NET × путь идентификации × действие × набор полей × предусловие × результат

Она разносит simple, Detailed и reallocation; прямых детей и более глубоких потомков; handle, точный диапазон и публичный каталог; полный, открытый и урезанный ответ; автоматическую обработку и ticket. Умышленная асимметрия получает объяснение, версию и дату вступления.

Равенство ячеек не требуется. Требуется возможность проверить намерение. Org-получатель видит управляемую нагрузку. Прямой регистрант видит reclaim-preview. Простой клиент не получает управления. Reallocation сохраняет собственные правила. Операторы могут превратить эти ожидания в контрактные тесты до запуска.

Closed — состояние предложения, не всей системы

ARIN могла обоснованно оставить нынешние разрешения и сослаться на существующие инструменты. Разработка имеет цену, а согласие автора с закрытием — часть фактов.

Но Closed не подтверждает все наблюдения и не доказывает поставку изменения. Оно также не превращает вопрос автоматизации в навсегда решённый. Формулировка «в тот момент» правильно ограничивает вывод.

Если намеренная политика состоит в том, что прямой регистрант может reclaim, но не видеть полный handle-payload получателя, это следует записать прямо. Если проверкой служит точный диапазон или ARIN Online, нужно раскрыть предпосылки локального учёта и объём подтверждаемой идентичности.

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