Кратко

  • 1 сентября 2026 года AFRINIC опубликовал рекомендованную третью версию документа об управлении RIR. Это финальный проект для дальнейшего рассмотрения, а не принятая или действующая норма.
  • Статья 4.2 предусматривает Аудит не реже одного раза в пять лет и более узкие Проверки соответствия между Аудитами.
  • Действуют два разных ограничения: годовой перерыв для того же вопроса после подтверждённого соответствия или исправления и не более двух начатых Проверок от каждой инициирующей стороны против того же RIR между Аудитами.
  • Нужна публичная запись с защитой частных данных, которая отличает запрос от запуска и связывает инициатора, положение документа, интервал, порядковый номер, закрытие и срок реабилитации.

Третий запрос требует сначала определить сторону

Допустим, группа участников RIR попросила проверить конкретное обязательство из статьи 4.1. ICANN признала вопрос достаточно существенным и начала Проверку соответствия. Затем была начата вторая Проверка. До очередного Аудита третья коалиция подала новый запрос, частично изменив свой состав.

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

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

Сообщение AFRINIC от 1 сентября открыло рекомендованный текст, сравнение со второй версией и отчёт с обоснованием. Оно не означает, что AFRINIC проходит Проверку или что документ уже вступил в силу.

Несколько входов сходятся в решении о запуске

Рекомендованная версия 3 требует проводить Аудит каждого RIR как минимум раз в пять лет. Между Аудитами запрос может исходить от большинства остальных RIR, от самого RIR, желающего проверить себя, или от группы его участников.

Группа должна преодолеть меньший из порогов: 15 процентов общего числа участников или 1 000 участников. Одно юридическое лицо считается один раз, даже если в иных голосованиях имеет несколько голосов. Запрос указывает конкретное положение статьи 4.1, обосновывает существенность и показывает, что хотя бы один участник пытался решить вопрос через доступные механизмы RIR.

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

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

Первый предел следует за вопросом

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

Точка отсчёта различается. При наличии Плана перерыв длится до года после окончания его графика. Без Плана — до года после закрытия предыдущего Аудита или Проверки. Для расчёта нужны положение, вывод, наличие Плана, его конец и подтверждение исправления.

Понятие «тот же вопрос» тоже требует мотивированной связи. Два запроса могут ссылаться на один пункт, но описывать разные факты. Новые доказательства могут появиться позднее. Один запрос способен охватывать несколько обязательств. Сходный заголовок не должен автоматически объединять дела, а иная формулировка — разъединять их.

Второй предел следует за инициатором и интервалом

Следующее предложение использует другой ключ: каждая инициирующая сторона может начать не более двух Проверок против одного RIR между двумя Аудитами. Это не обязательно общий предел в две процедуры. Коллектив остальных RIR, сам RIR, группы участников и ICANN имеют отдельные пути.

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

ICANN и RIR при самопроверке имеют устойчивую идентичность. Состав большинства других RIR может измениться. Группа участников изменчива ещё больше. Публиковать имена чрезмерно; не хранить идентичность вовсе — значит сделать предел недоказуемым.

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

Итоговый отчёт не объясняет предварительный барьер

Версия 3 требует от ICANN опубликовать сводку после Аудита или Проверки с необходимыми изъятиями конфиденциальных сведений. После Плана реабилитации ICANN проверяет исправление и публикует вывод. Это важные документы закрытия.

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

Отчёт об изменениях и обосновании называет Проверку соответствия более лёгким инструментом для конкретных вопросов между Аудитами. Частотные ограничения должны предотвращать повторные действия и паралич RIR из-за бесконечных процедур. Для этого нужна единая бухгалтерия событий.

Достаточно ограниченной публичной квитанции

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

После запуска добавляются время и порядковый номер. При закрытии — результат, дата, связь с прежним «тем же вопросом», конец Плана, верификация и дата окончания перерыва. Обжалование или исправление меняет актуальный статус, не стирая историю.

Имена, подписи, контакты, внутренние жалобы и конфиденциальные материалы публиковать не нужно. Квитанция объясняет открытие или закрытие входа, но не заменяет закрытое досье.

Страница процесса ICP-2 на сайте NRO по-прежнему описывает документ как рекомендацию Совета по адресам ASO, переданную Исполнительному совету NRO для рассмотрения и координации с ICANN. До принятия ещё можно определить счётчик.

Источники