Кратко

  • В ответе от 21 августа Совет ICANN отклонил фиксированный крайний срок, который мог бы помешать предусмотренной Bylaws проверке рекомендаций разной сложности. Вместо этого он намерен публиковать обновление перед каждой ICANN Public Meeting и постоянно рассматривать статус политики на подготовительных семинарах.
  • Регулярность отчётов не заменяет историю решения. Часы от рекомендации до решения должны хранить получение, обязательные материалы, вопросы, ответственных, пересмотр прогнозов и судьбу каждой рекомендации, не наделяя liaison, caucus, сотрудников или диалог полномочиями Совета.

На просьбу обозначить предел Совет ответил обещанием ритма.

25 мая руководители шести Stakeholder Groups и Constituencies в Generic Names Supporting Organization обратились к председателю Совета Tripti Sinha. Они исходили из того, что временное правило уже есть. Annex A требует, чтобы Совет обсудил рекомендацию GNSO Council как можно скорее, желательно не позднее второго заседания после получения Recommendations Report.

Однако начало обсуждения не устанавливает момент завершения. Авторы письма предложили стандартный период: целевое число заседаний и максимальное число месяцев, назвав шесть месяцев примером. Они также попросили о последовательных обновлениях, постоянном месте для Consolidated Policy Scorecard и канале для вопросов к GNSO Council и руководителям соответствующих Working Groups.

21 августа Совет согласился с необходимостью оперативности, но не принял жёсткую границу. Рекомендации различаются по характеру и сложности, а единый предел может мешать проверке по Bylaws. Вместо него Совет выбрал предсказуемость через ожидаемые сроки и статусы: обновление перед каждой публичной встречей и постоянный пункт о политике в повестке семинаров Совета.

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

Оба примера изменили статус до ответа

Майское письмо упоминало две группы рекомендаций. IDN EPDP Phase 2 находилась у Совета с декабря 2024 года, Transfer Policy Review — с апреля 2025 года. На момент письма окончательного решения ещё не было.

7 июня 2026 года Совет принял все 47 рекомендаций Transfer Policy Review и все 14 политических рекомендаций IDN EPDP Phase 2. В обоих случаях President and CEO либо назначенным лицам поручили реализацию с учётом приоритизации, а также операционных, технических, правовых, связанных с безопасностью и ресурсами обстоятельств.

Обоснования прямо признали обеспокоенность сообщества сроками и процессом. Они перечислили Final Reports, Public Comment, оценку реализуемости, уведомление GAC и материалы по существу. Это доказывает решения и часть рассмотренного набора. Оно не даёт унифицированной истории всех прогнозов и пауз до голосования.

Сейчас страница реализации политики помещает оба проекта в implementation queue. Это состояние после решения Совета, но не доказательство начала работы. Очередь не подтверждает назначение команды, запуск IRT, проект текста или дату вступления в силу.

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

Второе заседание — ориентир для обсуждения, не автоматический исход

Нельзя объявлять нарушение Bylaws, просто подсчитав месяцы. Annex A говорит о заседании для обсуждения и выражает предпочтение по сроку. Он не требует принять или отклонить пакет на этом заседании. Проверенные публичные материалы также не раскрывают дату каждой дискуссии и способ подсчёта «заседания» в конкретном деле.

Точный вывод уже: на входе рассмотрения есть временное ожидание, а на выходе нет фиксированной верхней границы.

Эта свобода защищает обязанность Совета. Рекомендация с поддержкой GNSO supermajority должна быть принята, если более двух третей имеющих право голоса директоров не установят, что принятие не отвечает лучшим интересам ICANN community или ICANN. Высокий порог уважает bottom-up policy, но оставляет Совету проверку права, безопасности, реализуемости, стоимости и публичного интереса.

Автоматическое принятие по истечении шести месяцев разрушило бы эту роль. Бессрочное «на рассмотрении» без причин сделало бы её неподотчётной. Время должно иметь зафиксированную причину и владельца следующего действия.

Ранний вопрос не создаёт неформального права поправки

В ответе названы Board liaisons, заблаговременный диалог и Board Caucus Groups. Доклад Board Readiness 2025 года объяснял проблему: Совет нередко начинал работу через месяцы после Final Report, когда PDP-команда уже распалась, а волонтёры, знавшие историю компромиссов, вернулись к своей профессии.

Ранние вопросы могут сохранить знания. Liaison сообщает о возможной проблеме Bylaws, стоимости или реализации, пока Working Group способен объяснить выбор. Caucus организует анализ директоров. Сотрудники собирают комментарии и данные о реализуемости. Руководство Working Group объясняет, была ли двусмысленность намеренной.

Но ни один из этих участников не получает права переписать рекомендацию. Liaison не определяет консенсус GNSO. Доклад сотрудников не заменяет текст. Если разговор меняет содержание, запись должна показать полномочный орган и необходимость возврата в policy body. Августовский ответ проводит ту же линию: прояснять запись и поднимать вопросы, не меняя роли Board и GNSO Council.

Scorecard показывает место, а часы — путь

ICANN org периодически публикует Consolidated Policy Scorecard, сводя status community-developed policy. Это снижает поиск по письмам, решениям, страницам GNSO и спискам реализации.

Но последняя строка не объясняет переход. Перемещение в implementation queue не показывает, когда комплект стал полным, какой вопрос сдвинул график и были ли одни рекомендации приняты, а другие pended. Даже слово «pending» может означать незакрытый Public Comment, ожидание GAC, правовой вопрос, техническую оценку, место в повестке или отсутствие ответственного.

Публиковать привилегированное юридическое мнение не требуется. Ограниченные категории — правовая проверка, техническая реализуемость, ресурсы, public-policy input, запрос разъяснения, agenda capacity — уже показывают тип зависимости.

Часы от Recommendations Report до решения

Предложение Daniel Kade начинает запись при авторитетном получении Recommendations Report. Оно хранит идентификатор и hash пакета, голосование GNSO, путь Bylaws и применимый порог. Для Public Comment, уведомления GAC, feasibility analysis и других названных материалов записываются открытие, закрытие и включение в дело Совета.

Координация отделена от власти. Liaison, caucus или сотрудник могут быть владельцами информационного шага; решающим органом остаётся Board. Первое обсуждение, существенное рассмотрение и голосование — разные события.

Словарь статусов должен быть узким: получено, ожидаются материалы, готово к рассмотрению, запрошено разъяснение, решение назначено, принято, отклонено, pended, отозвано или заменено. У каждого состояния есть дата доказательства, следующий акт, ответственный и прогноз. Изменение прогноза не удаляет старое значение, а сохраняет причину.

Финал записывается по каждой рекомендации с голосованием, основанием и условием. Отдельный handoff различает очередь реализации и её начало. Эти часы не вводят принятие по молчанию; они делают использование времени проверяемым.

Источники

  1. Указатель корреспонденции ICANN
  2. Tripti Sinha — Mason Cole, Rafik Dammak и другим, 21 августа 2026 года
  3. Owen Smigelski, Mason Cole и другие — Tripti Sinha, 25 мая 2026 года
  4. Утверждённые решения Совета ICANN, 7 июня 2026 года
  5. Действующие ICANN Bylaws
  6. Страница ICANN о реализации политики
  7. Итоговый доклад GNSO Board Readiness Small Team
  8. Страница проекта GNSO IDN EPDP
  9. Страница проекта GNSO Transfer Policy Review