Кратко

  • Рекомендованный проект сентября 2026 года обязывает каждый RIR поддерживать процедуры непрерывности и резервирования и регулярно предоставлять временному оператору достаточные записи, данные, региональные процедуры реализации политик и системы.
  • В проекте есть ограничения по защите данных, объёму услуг, продлению максимум на 90 дней за один период и публичному разбору. Это пока рекомендованный проект; фактическая передача услуг здесь не подтверждена.

План непрерывности, который начинают писать после того, как реестр уже не может работать, опаздывает. Проект Number Resource Organization (NRO) переносит часть подготовки на обычное время: каждый региональный интернет-реестр (RIR) должен поддерживать процедуры непрерывности и резервирования и иметь всё необходимое для временного оператора.

Ключевое положение находится в п. 4.1(m) рекомендованного проекта Governance Document v3. RIR должен регулярно предоставлять записи, данные, региональные процедуры реализации политик и системы в объёме, достаточном для работы временного оператора при необходимости, с надлежащим эскроу или защитой данных. Это не требование открыть данные всем и не автоматическая передача всех систем.

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

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

90 дней — момент нового решения

Пункт 5.1 допускает временное обслуживание всех или части функций, если RIR не способен обеспечить их надлежащим образом по внутренним или внешним причинам. Затронутый RIR может сам запустить механизм для собственных услуг. Альтернативно ICANN и две трети остальных RIR могут инициировать или продлить его после обсуждения с затронутым RIR и сообществом, когда обстоятельства это позволяют.

Период не может превышать 90 дней без продления по тому же пункту. В обосновании версии 3 сказано, что добавлено право затронутого RIR начать механизм самому, внешний порог снижен с единогласия до согласия ICANN и двух третей RIR, а 90 дней оставлены, чтобы временная схема не стала обычной. Поскольку продление возможно, 90 дней — срок повторного решения, а не совокупный максимум.

Затронутый RIR обязан содействовать временному переходу и сохраняет право возобновить услуги после восстановления и проверки операционной способности. Объём услуг временного оператора может меняться во время действия или при продлении. Возврат предусмотрен, однако проект оставляет практические вопросы: кто проверяет восстановление, какие испытания достаточны, как сверяются изменения в реестре и когда отзываются полномочия.

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

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

Это ещё рекомендованный проект

Версия 3 не является принятой нормой. Сообщение NRO EC от 28 июля говорит, что Совет адресной организации ASO передал проект исполнительному совету NRO для дальнейшей координации к финальной версии. Публикация AFRINIC от 1 сентября содержит проект, сравнение и обоснование и указывает, что новые возможности для комментариев объявит NRO EC. Пункт 1.3 предусматривает совместные процедуры реализации.

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

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

Источники

На 15 октября график NRO всё ещё указывает, что финализация продолжается: обновления запланированы на ICANN 87 (17–22 октября), LACNIC 46 (19–22 октября), ARIN 58 и RIPE 93; утверждение и принятие документа отнесены к IV кварталу 2026 года.