Кратко

  • AFPUB-2026-ASN-001-DRAFT02 потребует иерархические имена для новых AS-SET AFRINIC, но позволит существующим плоским объектам сохранять имена и редактироваться без переименования.
  • Сохранение, редактирование, восстановление удалённого объекта и создание нового объекта — разные операции.
  • Сотрудники AFRINIC предупреждают, что восстановление оставляет операционную лазейку; BTW предлагает документированное решение по каждому случаю и агрегированную отчётность без чувствительных данных.

Предложение является правилом на будущее, а не очисткой существующего набора плоских имён. Оно относится к созданию AS-SET в базе WHOIS AFRINIC. Раздел 5 RFC 2622 описывает иерархические имена наборов как компоненты, разделённые двоеточиями; имя может начинаться с ASN. Согласно правилу контроля пространства имён, дочернее имя может создать только мейнтейнер родительского объекта.

Текст намеренно защищает установленное наследие. Существующие неиерархические AS-SET нельзя переименовывать; они могут продолжать использоваться и редактироваться без смены имени. Обоснование состоит в том, что массовое переименование вызвало бы масштабные несоответствия, а надёжного программного способа определить соответствующий ASN для каждой существующей AS-SET AFRINIC нет. Это также сохраняет установленные ссылки в политиках маршрутизации.

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

Обязательный пример предложения — восстановление неиерархической AS-SET, удалённой по ошибке. В предложенной сотрудниками формулировке сказано, что исключение может быть предоставлено при необходимости, а AFRINIC должна задокументировать причину. Сотрудники отдельно предупреждают, что возврат удалённого плоского объекта создаёт операционную лазейку и снижает эффективность политики. В протоколе AFRINIC 37 это описано как оставленная боковая дверь; там же отмечено, что удаление требует аутентификации мейнтейнера.

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

Публичное руководство AFRINIC по IRR описывает создание через портал и WHOIS-web и защиту мейнтейнером. Пакет доказательств не тестирует эти производственные пути и не показывает, что предлагаемое ограничение уже действует. В качестве затронутых систем указаны WHOIS и MyAFRINIC/IRR; проверка предполагается на сервере и в доступных формах или API. Сотрудники говорят о приоритете после MyAFRINIC v2. Это условный план, а не доказательство внедрения.

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

Другой анализ BTW — агрегированно сообщать число исключений и их исход, не раскрывая секреты мейнтейнеров и чувствительную конфигурацию маршрутизации. Это не существующий продукт AFRINIC и не принятое требование.

Примечание о публикации: «Опубликовано» означает запланированную редакционную дату 7 сентября 2026 года по времени Asia/Shanghai. Фактическое время публикации на сервере пока не задано.

Источники

  1. https://www.afrinic.net/policy-proposals.html
  2. https://www.afrinic.net/afpub-2026-asn-001-draft02
  3. https://www.afrinic.net/ppm-afrinic-37.html
  4. https://www.rfc-editor.org/rfc/rfc2622.html
  5. https://afrinic.net/irr-guide