Кратко

  • В отчёте AFRINIC об опыте внедрения за 2018 год описан конкретный случай: анонимный End User не мог получить дополнительный /24 для резервного второго дата-центра, поскольку совокупное использование ресурсов оставалось ниже 90%.
  • AFPUB-2026-IPv4-002-DRAFT02, находящийся в Last Call, позволил бы не применять порог, если доказанная техническая цель практически не обслуживается имеющимися ресурсами. Общий стандарт, однако, требует лишь достаточно документированного обоснования, а записанное обсуждение прямо отказывается от единого списка документов.
  • Гибкость не означает невидимое решение. Защищённая квитанция с версией может сохранить обычный расчёт, класс исключения, хранение доказательств, вопросы проверяющего, коды причин и путь обжалования, не предписывая оператору архитектуру.

Реальная заявка появилась раньше проекта

История начинается не с Draft 2. На восьмой странице Policy Implementation Experience Report, представленного на AFRINIC-29, сотрудники AFRINIC зафиксировали проблему Hostmaster.

Участник категории End User запросил дополнительный IPv4 /24 для резервирования дата-центра. Текущее использование в сумме составляло менее 90%. По применявшемуся толкованию Soft Landing участник не имел права на новый ресурс и потому не мог развернуть второй дата-центр.

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

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

Исключение пока существует только в условном наклонении

Независимый трекер NOG Alliance индексирует AFPUB-2026-IPv4-002-DRAFT02 под более широким статусом Under discussion. Запись AFRINIC-37 фиксирует rough consensus и перевод в Last Call. Первая версия была подана 6 мая 2026 года, вторая датирована 16 июня и обсуждалась 24 июня. На 23 августа это предложение, а не реализованное исключение.

Обычный порог сохраняется. В Exhaustion Phase LIR или End User, запрашивающий следующую IPv4 allocation или assignment, должен показать использование как минимум 90% всех ранее полученных IPv4-ресурсов. Новая организация без прежних ресурсов по-прежнему освобождается от требования при первой заявке.

Draft 2 добавил бы возможность исключения. AFRINIC мог бы отказаться от порога для доказанных ключевых технических целей, если имеющийся пул практически не способен их обслужить или если цель создаёт техническое ограничение для этого пула. Резервирование, высокая доступность, механизмы перехода на IPv6 и новые сайты перечислены как неисчерпывающие примеры. Для данного пункта заявка рассматривалась бы как первая allocation или assignment.

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

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

У обычного правила есть число, у исключения нет типа

Действующий Consolidated Policy Manual обозначен как версия 1.6. Помимо 90-процентного порога, он допускает инженерные, адресные, топологические и маршрутные планы и требует реалистичных, объяснимых прогнозов. Правила должны применяться справедливо независимо от места, гражданства или размера. Коммерческая информация, необходимая для оценки, но не для публичного реестра, должна оставаться конфиденциальной.

Профессиональная среда проверки существует. Не определён тип новой льготы.

Два заявителя с одинаковой утилизацией могут написать high availability. Первый предпочитает другой город из-за коммерческого контракта. Второй обязан разделить питание, транзит и функцию трансляции, чтобы одна авария не вывела обе площадки. Этикетка совпадает. Только факты под ней показывают, действительно ли существующее пространство непригодно и является ли ограничение техническим, а не операционным.

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

Отказ от единой папки не означает отказ от общей формы

В записи AFRINIC-37 участница спросила, какие технические документы должен представить заявитель для нескольких площадок до достижения 90%. Автор ответил, что универсальный список не подходит: переход IPv6 и multi-site deployment требуют разных доказательств. Рассмотрение будет диалогом input/output со staff.

Это разумное ограничение. Схема дата-центра не обязательно определяет размер пула трансляции. Заказ оборудования не доказывает независимость доменов отказа. Прогноз трафика сам по себе не показывает разнесение маршрутов.

Другой участник поддержал цель, но предупредил: широкая формулировка позволит почти любому сослаться на резервирование или высокую доступность, что затруднит справедливое применение. Автор отказался перечислять все допустимые примеры, поскольку список исключит новые схемы и будет микроконтролем staff. Head of Member Services задал ключевую границу: technical constraints могут оправдать исключение, operational constraints — нет.

Обсуждение отвергло две крайности. Универсальное досье слишком жёстко. Неструктурированное прилагательное плохо проверяется. Между ними не хватает стабильных полей с различными значениями для каждого проекта.

Co-chairs объявили rough consensus на встрече и перевели предложение в Last Call. Запись также говорит, что Secretariat поделится определением utilisation на этой стадии. Нейтральный трекер сохраняет более широкую метку, и ни один используемый здесь публичный источник не доказывает ратификацию, внедрение или полевую схему исключения. Это не значит, что определение нигде не распространялось. Это лишь фиксирует, чего нельзя восстановить из предложения и записи встречи.

Защитный механизм оказался внутри переписки

Презентация и обсуждение предложения помещают защиту в формулу «достаточно документировано». Техническая потребность должна быть показана, непригодность существующих ресурсов — обоснована, а AFRINIC должен проверить связь.

Неявный тест выглядит так:

техническая функция → существующий пул практически непригоден → дополнительный сегмент IPv4

Каждая стрелка требует фактов. Что это за функция? Какие блоки проверены? Почему не подходят повторное использование, renumbering, другая агрегация или размещение? Какому сайту или домену отказа соответствует новый сегмент? Сколько длится параллельная работа? Какой факт опровергнет объяснение?

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

Усмотрение, мотивировка и обжалование — разные функции

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

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

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

Пример с несколькими PoP не создаёт автоматического права

Презентация предложения использует multi-PoP deployment 464XLAT как мотивирующий пример. Это проектный сценарий, а не аудит сети участника, автоматическое право на новое пространство или универсальная топология. Вывод уже: техническая функция может требоваться одновременно в нескольких доменах отказа до достижения совокупной утилизацией последовательного порога.

Архитектура 464XLAT в RFC 6877 соединяет stateful translation в ядре со stateless translation на краю, предоставляя ограниченную IPv4-связность через IPv6-only сеть. RFC имеет статус Informational. Он не предписывает четыре PoP, два устройства на сайт или определённый размер публичного префикса.

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

Минимальная спецификация узкая, а не расплывчатая

Minimum Initial Specification Лу Хэна разделяет минимальные детерминированные факты общей координации и последующие операционные решения тех, кто реально запускает сеть.

AFRINIC управляет конечным IPv4-пулом. Проверка потребности, уникальность, точность реестра и равное применение требуют общего правила. Поставщик дата-центра, NAT64-платформа, внутренний routing и порядок строительства не становятся из-за этого инвариантами реестра.

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

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

Восемнадцать полей квитанции исключения

Ниже предложен аналитический интерфейс статьи, а не существующая форма AFRINIC.

  1. ID заявки или тикета. Связывает одну заявку, доказательства, диалог и результат.
  2. Идентификатор правила. Сохраняет policy, draft или implementation version и применённый пункт.
  3. Заявитель и тип запроса. Различает LIR/End User, allocation/assignment, первую и дополнительную заявку.
  4. Обычная база. Замораживает portfolio snapshot и точный расчёт 90%, действующий без исключения.
  5. Класс исключения. Называет резервирование, высокую доступность, переход IPv6, новый сайт или иную техническую цель.
  6. Функциональные единицы. Указывает площадки, PoP или функции в защищённом деле и использует псевдонимы в публичном выводе.
  7. Запрошенные сегменты. Соотносит каждый префикс или объём с площадкой или функцией.
  8. Окно одновременности. Объясняет совместный запуск и срок сосуществования старых и новых ресурсов.
  9. Связь непригодности. Фиксирует топологическую, маршрутную, трансляционную или отказоустойчивую причину невозможности использовать текущий пул.
  10. Адресный план. Сохраняет текущее и прогнозное использование, единицу и горизонт каждого сегмента.
  11. Анализ свободного пространства. Перечисляет неиспользуемые ресурсы и причины отказа от reuse, renumbering или другого размещения.
  12. Хранение доказательств. Содержит файлы, hashes, владельца, границы доступа и retention без публичной топологии.
  13. История диалога. Добавляет вопросы, ответы и timestamps, не переписывая прежнюю аргументацию.
  14. Классификация и причины. Записывает technical, operational или mixed с устойчивыми codes и пояснением.
  15. Решение и условия. Фиксирует approval/denial, выданный размер, условия, срок и последующую проверку.
  16. Исправление и обжалование. Связывает уведомление, канал фактической коррекции, дедлайн и applicable appeal.
  17. Замещение версии. Указывает последующее правило, изменившее тест, и сохраняет применённую редакцию.
  18. Публичные агрегаты. Публикует количества, классы, интервалы обработки, результаты и коррекции без участника и топологии.

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

Сначала интерфейс, затем действующая дверь

Направление Draft 2 можно защищать. Второй домен отказа не должен ждать почти полного заполнения первого; иначе резервирование создаётся после аварии. Документ 2018 года показывает, что конфликт возник в реальной работе AFRINIC.

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

«Достаточно документировано» начинает разговор, но не служит долговечной записью исключения из дефицитного ресурса. До внедрения AFRINIC следует опубликовать минимальные поля, защиту доказательств и коды причин. Реестр сможет беречь пул, не проектируя сеть; оператор — проектировать сеть, не придумывая стандарт доказательства.

Источники