Кратко

  • Версия 3 требует начать взаимодействие со всеми сообществами RIR после запуска временного аварийного режима непрерывности, но разрешает самим RIR решить, проводить ли дополнительный процесс после продления.
  • Продление всё равно требует публикации решения, обоснования и охвата; во внешнем варианте нужны ICANN и две трети остальных RIR, а также обсуждение с затронутым реестром и его сообществом, когда это разумно возможно.
  • Краткая квитанция о продлении позволит сохранить скорость восстановления и одновременно показать суммарный срок, изменения охвата и причину повторного общего обсуждения либо отказа от него.

Для первых и следующих 90 дней установлена не вполне одинаковая норма участия.

Это небольшое, но существенное переключение находится в статье 5.1 рекомендованной версии 3 RIR Governance Document, которую AFRINIC и Number Resource Organization опубликовали 1 сентября. Документ предусматривает Temporary Emergency Continuity Arrangement (TECA), если Региональный интернет-реестр не способен надлежащим образом предоставлять все или часть своих услуг. Тогда их временно может взять на себя квалифицированный аварийный оператор.

Перед нами рекомендованный финальный проект. Проверенные источники не доказывают его принятие, замену ICP-2 или вступление в силу. Они также не утверждают, что AFRINIC или иной RIR сейчас находится в таком режиме.

Норма меняется на границе продления

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

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

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

После продления проект, однако, говорит, что RIR «могут решить» провести дополнительные процессы с сообществами. Первый глобальный контур обязателен, следующий — дискреционен. Это не позволяет обойти затронутое сообщество и не отменяет публикацию. Меняется состояние конкретного межрегионального канала обратной связи.

Граница важна потому, что измениться может не только время. Статья 5.1(f) позволяет увеличить или уменьшить объём услуг временного оператора во время TECA или при продлении. Следующий период способен длиться дольше и охватывать не то же самое, что первый. Текст ограничивает отдельный период 90 днями, но в проверенных положениях не устанавливает числового суммарного предела продлений.

Скорость — самый сильный довод защиты

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

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

Поэтому ответ — не референдум каждые 90 дней, а запись, показывающая применение усмотрения.

Квитанция о продлении

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

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

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

Версия 2 уже предусматривала 90 дней, участие сообществ и продление. Версия 3 яснее описывает путь продления, снижает внешний порог и разделяет в рабочем тексте обязательное первоначальное участие и необязательное дополнительное. В обосновании NRO это представлено как способ реагировать быстрее, сохраняя 90-дневный предел и усиливая прозрачность.

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

Источники