Кратко

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

Меняется оператор, а не сам реестр

Если RIR не может надлежащим образом предоставлять все услуги или их часть, предложенный RIR Governance Document позволяет квалифицированному Temporary Emergency Operator временно выполнять затронутые функции. Текст не превращает такого оператора в новый RIR. Речь идёт о передаче определённых услуг: делегировании номерных ресурсов, ведении регистрационных и справочных данных или связанных технических функциях, на которые полагаются владельцы ресурсов и другие сети. Передача может охватывать только часть услуг и менять объём.

1 сентября 2026 года AFRINIC разместила рекомендованный проект ASO AC, таблицу изменений и пояснительный доклад. На странице NRO версия 3 обозначена как FINAL DRAFT; в календаре NRO сказано, что ASO AC/NRO NC передал её NRO Executive Council 28 июля. По состоянию на 14 октября документ ещё дорабатывается, а утверждение и принятие в IV квартале остаются будущими этапами. Это предложение для всей системы RIR, а не действующая процедура. Ни объявление, ни проект не доказывают, что AFRINIC или любой другой RIR сейчас не способен предоставлять услуги. Объявление AFRINIC сообщает о публикации пакета; анализируемые правила находятся в тексте версии 3 от NRO.

Два пути к началу arrangement

Пункт 5.1(a) существенно меняет предыдущую версию. Если RIR не может адекватно предоставлять все услуги или некоторые из них, он вправе сам начать Temporary Emergency Continuity Arrangement для собственных функций. В версии 2 для этого требовалось единогласие остальных RIR и ICANN. Версия 3 сохраняет внешний путь координации в 5.1(b), но снижает порог: ICANN и две трети остальных RIR также могут начать или продлить arrangement после обсуждения с затронутым RIR и его сообществом, если обстоятельства делают это разумно возможным.

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

Однако запуск и продление — разные решения. Пункт (a) называет затронутый RIR стороной, которая может начать передачу собственных услуг. Пункт (b) — единственный, где прямо указано, что arrangement можно начать или продлить с согласия ICANN и двух третей остальных RIR. Пункт (c) запрещает превышать 90 дней без продления на условиях этого раздела. Он не говорит прямо, может ли RIR, который запустил процесс по (a), сам его продлить или же нужно внешнее согласие по (b).

Текст допускает как минимум два прочтения. Прямое упоминание продления только в (b) можно понять как указание на единственный описанный способ продления. Другая трактовка состоит в том, что право RIR начать arrangement по (a) включает и продление им же начатой передачи. Пункт 5.1(f) связывает оба пути, позволяя соответствующему инициатору или инициаторам по (a) либо (b) менять объём услуг. Но он не отвечает на вопрос, кто продлевает самостоятельный запуск. Это неоднозначность формулировки, которую следует устранить, а не готовый правовой вывод или доказательство того, что такой arrangement нельзя продлить.

Объём услуг распределяет контроль

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

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

В проекте есть значимые гарантии. Пункт 5.1(d) обязывает ICANN быстро опубликовать решение о начале или продлении, его обоснование и объём. После начала процесса нужно как можно скорее вовлечь сообщества всех RIR; дополнительное обсуждение после продления остаётся на усмотрение RIR. Пункт 5.1(e) требует от затронутого RIR сотрудничать при передаче, но сохраняет его право возобновить услуги после восстановления и проверки операционной готовности. Пункт 5.2 требует совместного разбора после завершения и публичного отчёта об обстоятельствах, услугах, сроках и возврате, а также оценки оператора, отзывов сообщества и предложений по улучшению.

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

Процедура должна показывать передачу полномочий

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

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

Согласно опубликованному календарю NRO, финализация всё ещё продолжается; обновления ожидаются на будущих встречах RIR и ICANN, а утверждение и принятие запланированы на IV квартал. Следующую версию можно проверить тремя вопросами: может ли RIR, начавший arrangement по 5.1(a), продлить его сам? Если нет, какое конкретное решение требует 5.1(b)? Кто контролирует объём услуг при смене пути начала? Ясные ответы сохранят скорость, к которой стремится версия 3, и позволят проследить ответственность после истечения 90 дней.

Источники