Кратко

  • RSSAC Caucus выполняет большую часть экспертной работы, но не может формально действовать от имени RSSAC. RSSAC назначает участников, может изменить задание, возвращает проект на доработку и голосует за публикацию.
  • RSSAC000v10 описывает процесс точнее, чем процедура, изученная независимой проверкой 2018 года. Однако нет открытой современной статистики отказов и апелляций, распределения вкладов и полной истории содержательных правок от устойчивого проекта до утвержденной версии.
  • Власть Caucus находится в начале цепочки — в выборе экспертов, вопроса и первого полного изложения. Это не право управлять корнем, распределять номерные ресурсы, устанавливать правила RIR или стандарты IETF, приказывать ICANN Board либо независимым операторам.

Один документ, несколько центров работы

RSSAC062, рекомендация по сообщению об инцидентах безопасности, утвержденная в мае 2025 года, показывает цепочку через список участников. В ней названы тринадцать представителей RSSAC Caucus. Robert Story указан руководителем рабочей группы, Ken Renard — RSSAC shepherd. Поддержку оказывали четыре сотрудника ICANN, в том числе редактор. Документ фиксирует отсутствие особых мнений и самоотводов и относит консенсусное одобрение к RSSAC.

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

RSSAC000v10, утвержденный 4 августа 2026 года, закрепляет это разделение. Caucus готовит большинство отчетов и рекомендаций RSSAC. Но только RSSAC может совершать формальные действия в качестве RSSAC.

Проект Caucus сначала проходит проверку внутри Caucus. Затем его рассматривает RSSAC и может направить вопросы, комментарии и изменения. Руководитель обрабатывает замечания, пока текст снова не станет устойчивым. Лишь после этого он запрашивает формальное действие, а председатель включает одобрение в повестку очередного заседания.

Авторы не публикуют документ самостоятельно. Каждый оператор корневого сервера имеет в RSSAC один голос. По действующей процедуре для публикации нужно квалифицированное большинство в 75%. Только после одобрения сотрудники готовят публичную версию.

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

Входной фильтр действует раньше технической дискуссии

При сборе материалов страница Caucus показывала 115 результатов, страница RSSAC — 24. Это число публичных профилей, не активных участников и не голосов. Тем не менее оно показывает разницу между производственным пулом и органом принятия решения.

Первичную проверку проводит Membership Committee. Он оценивает знакомство кандидата с работой RSSAC, доступное время и ценность навыков или опыта. Комитет назначает RSSAC. На актуальной странице перечислены Shailesh Gupta, Dave Lawrence, Jeff Osborn и Ken Renard.

Отрицательное решение проходит иначе, чем положительное. Если Membership Committee не рекомендует кандидата, его имя не сообщают RSSAC. Председатель комитета рассматривает апелляцию индивидуально; повторная заявка невозможна в тот же двенадцатимесячный период. Рекомендованная заявка рассылается RSSAC на неделю. Без возражений кандидат принят. Одного возражения достаточно для отказа. Кандидат может запросить объяснение и подать апелляцию, но ее порядок председатель RSSAC определяет индивидуально.

Изученный пакет не доказывает злоупотребление этими полномочиями. Он также не содержит числа заявок, отказов на каждом этапе, категорий причин, запросов объяснений или результатов апелляций. Проверяемая проблема — отсутствие открытого учета, а не предположение о мотивах.

Фильтр меняет будущий состав доказательств. Остановленный на входе человек не сможет как участник Caucus предлагать, писать или рецензировать. Membership Committee не утверждает техническое заключение, но влияет на круг людей, которые его сформируют.

Инициатива распределена, окончательное разрешение — нет

Участник RSSAC или Caucus может предложить работу в своем органе. Для проекта Caucus требуется statement of work, который обсуждается и меняется внутри группы. Затем RSSAC может снова обсудить и изменить его, прежде чем председатель поставит начало проекта на голосование.

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

Текущий RSSAC001v3 показывает границу на практике. Задание апреля 2025 года пересматривает ожидания к услугам операторов корневых серверов. Группа может решить, что новая версия не нужна, но обязана дать двухнедельное уведомление в основной рассылке Caucus. Если есть хотя бы одно возражение, закрытие решает RSSAC голосованием. Если создается новая версия, она также должна быть утверждена RSSAC до публикации.

Экспертам делегированы инициатива и производство. Право институциональной подписи не делегировано.

Данные 2018 года нельзя переносить в 2026-й

Независимая проверка 2018 года отметила удовлетворенность технических читателей качеством и доступностью документов Caucus. Одновременно она оценила, что тогда активно работали лишь 25–30 из примерно 90 участников, сообщила о неясных границах с RSSAC, размытых приоритетах, неактивности и фактическом контроле RSSAC над вступлением и выходом.

Эти выводы объясняют последующие изменения, но не устанавливают нынешний уровень участия. Анонимные цитаты являются восприятиями, собранными проверяющими, а не доказанными современными мотивами.

Рекомендация 6a потребовала более эффективной и прозрачной процедуры определения проектов, вовлечения и управления участниками, организации работы и распространения результатов. В 2020 году рабочая группа сообщила, что содержательные обсуждения и проверка проектов перенесены в публичную рассылку Caucus, а Membership Committee оценивает участие. Структурные изменения оставались зависимыми от Root Server System Governance Working Group.

В 2022 году группа объявила вторую проверку завершенной с точки зрения управления проектом, сохранив рекомендацию 6a в зависимой категории. ICANN Board принял сообщенный статус и запросил периодические обновления. Третью проверку RSSAC отложили; текущая страница говорит, что организационные проверки ждут завершения первого цикла Continuous Improvement Program.

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

Рекомендация не становится командой из-за публикации

ICANN Bylaws определяют роль RSSAC глаголами консультирования: советовать, сообщать, оценивать риски, отвечать, отчитываться и давать политические рекомендации. Ни один изученный документ не позволяет Caucus или RSSAC эксплуатировать корневой сервер, приказывать независимому оператору, выдавать ASN или IP-адрес, менять политику RIR или принимать стандарт IETF.

Публикация не связывает ICANN Board. После одобрения RSSAC документ может пройти 48-часовое ознакомление Board из вежливости. ICANN также ведет процесс приема, рассмотрения, исполнения и закрытия рекомендаций. Это доказательство обработки, но не принятия, причинности или принуждения.

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

Источники