Кратко

  • Опубликованная 30 июля процедура очистки AFRINIC описывает действующий операционный ориентир: карантин предварительно длится двенадцать месяцев, может быть продлён, но никогда не сокращается.
  • AFPUB-2026-IPv4-001-DRAFT02 также задаёт двенадцатимесячный срок по умолчанию, однако разрешает AFRINIC уменьшить его при объёме доступного пространства ниже /13 либо по иным операционным причинам. Обязательного минимального срока в нормативном тексте нет.
  • Оценка воздействия говорит, что сотрудники на практике намерены сохранять двенадцать месяцев и при необходимости могут перейти к шести. Это описание ожидаемой практики, а не обязательный шестимесячный предел.
  • Last Call закончился 31 июля 2026 года в 23:59 UTC. Сообщение 015478 от 3 августа отдельно поставило вопрос об отсутствии нижней границы и попросило сохранить его в материалах процесса.
  • Отчёт сопредседателей воспроизвёл возражение, не включил его в оценку из-за поступления после Last Call, отметил для сведения Совета AFRINIC и рекомендовал ратификацию Draft02.
  • Проверенные материалы не подтверждают решение Совета, включение нормы в CPM, реализацию проекта, фактическое сокращение карантина, выпуск адресного блока или его последующее делегирование.

У AFRINIC есть сильное добросовестное объяснение предлагаемой гибкости. Реестру нужен предсказуемый момент завершения Last Call, иначе обсуждение невозможно довести до решения. Ему также может понадобиться быстрее пополнять доступный пул, если чистого IPv4-пространства становится необычно мало. Опубликованная процедура уже предусматривает проверки маршрутизации, реестровых записей, DNS- и спам-списков, работу с несанкционированным использованием и финальную проверку перед переводом ресурса из состояния Reserved в Available.

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

Два текста и две разные функции

AFPUB-2026-IPv4-001-DRAFT02, Version 2.0, был представлен 16 июня 2026 года Jordi Palet Martinez. История версий указывает, что первая версия появилась 6 мая, а вторая учла замечания оценки воздействия. Проект распространяет текущую фазу Soft Landing на возвращённые и восстановленные адреса IPv4 независимо от размера блока и его исходного пула. Фазы должны стать окончательными и необратимыми.

Для восстановленного пространства Draft02 устанавливает двенадцать месяцев карантина по умолчанию. AFRINIC сможет уменьшить этот период, если доступного пространства меньше /13, либо по иным операционным причинам. При этом текст не определяет минимально допустимый срок, исчерпывающий перечень иных причин, обязательные выводы перед сокращением, конкретного утверждающего субъекта или состав публичной квитанции решения.

Оценка воздействия даёт более узкую интерпретацию: сотрудники планируют сохранять двенадцатимесячный период и при необходимости могут скорректировать его до шести месяцев. На AFRINIC-37 автор объяснил, что первая версия предполагала шесть месяцев, но после замечания сотрудников о недостаточности этого срока Draft02 вернулся к двенадцати месяцам, сохранив возможность сокращения. Оценка также предусматривает около шести месяцев на автоматизацию очистки и мониторинга.

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

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

Связанный документ об управлении адресами поясняет, что детальные статусы карантина и временного резервирования ведутся во внутреннем инвентаре и отдельно не отражаются в публичном файле расширенной статистики. Санитизация объектов маршрутизации выполняется вручную и относится к маршрутным данным, тогда как репутационные и чёрные списки требуют отдельной проверки. После очистки предусмотрены переход Reserved → Available и уведомление сообщества; опубликованное уведомление 2019 года служит примером такого сообщения.

Таким образом, недостатка в публичном описании очистки нет. Разрыв возникает между консервативным операционным ориентиром «никогда не короче» и проектом политики, разрешающим сокращение без записанного минимума.

Как возражение прошло через временную границу

На AFRINIC-37 участники обсуждали как необходимость продлевать карантин до подтверждения чистоты, так и проверки маршрутизации и репутации. Сотрудники сообщили, что двенадцать месяцев работали приемлемо и что чистота пространства важнее простого истечения срока. В материалах встречи зафиксированы поддержка проекта и призывы закрепить восстановление и карантин в принятой политике, а не оставлять их только на уровне процедуры. Сопредседатели объявили о приблизительном консенсусе и перевели Draft02 в Last Call.

Last Call открылся 16 июля и должен был завершиться 31 июля в 23:59 UTC. В уведомлении было обещано опубликовать запрошенные на встрече сведения о восстановлении. 30 июля Секретариат разместил документы об управлении и очистке. 1 августа сопредседатели объявили Last Call закрытым и сообщили, что решение ожидается к 14 августа.

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

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

Четырёхстраничный отчёт был завершён 13 августа и публично направлен Совету 19 августа. Пункт 10 воспроизвёл замечание о том, что шестимесячный ориентир из оценки воздействия отсутствует в тексте политики. Отчёт пометил его как не рассмотренное в оценке, поскольку оно поступило после Last Call, но сохранил для сведения Совета. Затем сопредседатели рекомендовали Совету ратифицировать Draft02 при первой возможности.

Следовательно, возражение не исчезло и не было стёрто. Оно получило запись, временную квалификацию и передачу для сведения. Но публичный материал не сообщает, кто после этого обязан принять вопрос: Совет, автор следующей версии, последующая оценка реализации политики, операционная процедура или никто. Рекомендация ратифицировать также не тождественна ратификации. На момент доказательной отсечки официальные поверхности продолжали показывать статус Last call; проверенного решения Совета, Draft03 или интеграции в CPM нет.

Почему реестровое изменение является властным, но не суверенным

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

Этот подход не превращает AFRINIC в государство. AFRINIC — частный членский интернет-реестр. Его Совет, PDWG, сопредседатели, Секретариат и Hostmasters осуществляют частные корпоративные, договорные, технические и процедурные функции. Они не получают законодательной, судебной, полицейской, прокурорской, карательной или общеафриканской регуляторной власти.

Тем не менее перевод дефицитного IPv4-блока из Reserved в Available — не пустая канцелярская операция. По принципу приоритета running code, который подчёркивает Heng Lu, практически значимо состояние, унаследованное сетями и следующими пользователями, а не только институциональное название этапа. Поэтому recovered, quarantined, clean, available, allocated и announced нельзя считать синонимами. Точно так же recommended, ratified и implemented — три разные стадии.

Какая квитанция закрыла бы разрыв

Quarantine-to-Release Ledger — журнал от карантина до выпуска — должен разделять сорок полей, а не сводить их к одной отметке «очищено»:

  1. идентификатор предложения; 2. версию; 3. дату представления; 4. автора; 5. текущий публичный статус; 6. срок, обсуждавшийся в Draft01; 7. охват возвращённых и восстановленных ресурсов; 8. нормативный срок по умолчанию; 9. порог запаса ниже /13; 10. иные операционные основания; 11. обязательный минимальный срок; 12. ожидаемую практику из оценки воздействия; 13. предшествующий операционный ориентир; 14. формулу окончания карантина.

  2. Событие восстановления или снятия регистрации; 16. подтверждённую дату рекламации; 17. состояние во внутреннем инвентаре; 18. отчёт о состоянии префикса и его хеш; 19. проверку таблиц маршрутизации; 20. проверку реестров маршрутов; 21. проверку DNS- и спам-списков; 22. устранение несанкционированного использования; 23. версию списка чистых ресурсов; 24. финальную проверку перед выпуском; 25. отдельную квитанцию перехода Reserved → Available; 26. уведомление сообщества; 27. отражение в публичной статистике.

  3. Снимок доступного запаса, которым обосновано сокращение; 29. подготовившего, проверившего и утвердившего решение; 30. причины, рассмотренные альтернативы и выбранный срок; 31. конфликты интересов и отводы; 32. окно Last Call; 33. квитанцию получения позднего возражения; 34. его процессуальное решение; 35. следующего владельца вопроса; 36. состояние приблизительного консенсуса; 37. рекомендацию о ратификации; 38. решение Совета; 39. версию реализации и последующее распределение или делегирование; 40. процедуру исправления, отката и публичного версионирования.

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