Кратко

  • Сообщение APNIC от 1 сентября открыло доступ к рекомендованному проекту NRO NC версии 3.4, redline и документу с обоснованием.
  • Статья 7.2 запретила бы менять документ, пока RIR находится в режиме Temporary Emergency Continuity Arrangement либо пока рассматривается предложение о Derecognition.
  • Заявленная цель — не допустить поспешных изменений под конкретный случай и ослабления требований в трудный момент; это проект, а не свидетельство действующей чрезвычайной ситуации или уже принятого правила.

Одно из самых показательных положений версии 3.4 одновременно и одно из самых коротких. Согласно статье 7.1, для изменения документа потребовалось бы единогласное согласие ICANN и RIR после консультаций с их сообществами. Статья 7.2 добавляет стоп-условие: документ нельзя менять, когда RIR является объектом Temporary Emergency Continuity Arrangement или когда предложение о Derecognition остаётся на рассмотрении.

Сообщение APNIC точно определяет статус текста. Это рекомендованный проект Number Council NRO, опубликованный вместе с сопоставительной версией и разъяснением изменений. В нём не объявляются окончательное принятие, реализация или начало какого-либо дела. Источники не говорят и о том, что какой-либо RIR сейчас работает в аварийном режиме непрерывности, сталкивается с Derecognition или пытается изменить документ.

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

Границу задаёт статья 5. Temporary Emergency Continuity Arrangement — временный механизм предоставления затронутых услуг RIR. Затронутый RIR мог бы начать его для всех или части собственных услуг. ICANN и две трети остальных RIR также могли бы начать или продлить механизм после обсуждения с затронутым RIR и его сообществом, если это разумно возможно. Без продления по той же статье срок не превышает 90 дней, а ICANN должна оперативно публиковать обоснование и объём каждого начала или продления. Это описание возможной процедуры, а не отчёт о произошедшем событии.

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

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

Источники