Кратко

  • 12 марта 2026 года Совет ICANN утвердил обновлённую процедуру с немедленным вступлением в силу; действующая страница GNSO подтверждает, что она применяется.
  • В редакции 2013 года сотрудники должны были за десять рабочих дней передать предложение и отчёт профильному комитету Совета, а за 30 календарных дней после консультации — подготовить сводку.
  • Если после двух заседаний окончательного действия не было, Совет объяснял причины и оценивал оставшееся время. После четырёх заседаний либо шести запланированных заседаний в сумме поправки считались вступившими в силу.
  • Редакция 2026 года разрешает организации ICANN и группе определить подходящий график и предупреждает, что длительность взаимодействия может различаться. Старые сроки и предохранители не повторены.
  • Все четыре участника консультации поддержали реформу в целом, однако Registrar Stakeholder Group отдельно просила сохранить сроки рассмотрения. ICANN выбрала график для каждого дела.
  • Публичная версионная квитанция времени сделает такой выбор проверяемым, не навязывая всем уставам один срок и не раскрывая защищённые консультации.

В старой процедуре работали три разных ограничителя

Документ марта 2026 года прямо говорит, что заменяет процедуру, установленную Советом в 2013 году. Резолюция 2026.03.12.01 распорядилась применить новую редакцию немедленно, а сайт GNSO сейчас публикует её пять этапов как действующий порядок.

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

Второй срок наступал после закрытия Public Comment. В течение 30 календарных дней сотрудники готовили сводку поступивших мнений. Дата голосования Совета оставалась открытой, зато момент появления следующего элемента досье можно было проверить.

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

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

Теперь время стало частью конкретного дела

Новый порядок начинается раньше. При запуске пересмотра группа должна как можно скорее уведомить свою команду поддержки в организации ICANN и назначить связного. Вместе стороны могут установить подходящий график. Шаблоны устава и процедур учитывают Bylaws ICANN, операционные правила GNSO и применимые рекомендации Work Stream 2.

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

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

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

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

Общая поддержка не устранила спор о сроках

Все четыре комментария поддерживали обновление в целом. Официальная формулировка точна. Но поддержка пакета не равна согласию с каждым его элементом.

Registrar Stakeholder Group приветствовала шаблоны и повышение прозрачности, а затем выразила конкретную обеспокоенность: без ожидаемого срока проверки следующие шаги становятся неоднозначными, а своевременное одобрение менее гарантированным. Группа не объявляла старые числа неприкосновенными и была готова обсуждать более длительные периоды.

Сводный отчёт ICANN сохранил это возражение. Ответом стал выбор конструкции: вместо фиксированного срока организация будет устанавливать подходящий график с каждой группой. Organizational Effectiveness Committee повторил этот подход перед рекомендацией Совету.

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

Как должна выглядеть квитанция гибкого графика

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

Короткая карточка дела могла бы включать:

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

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

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

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

Чего запись не доказывает

Источники не называют ни одной поправки, уже просроченной по процедуре 2026 года. Они не доказывают очередь, недобросовестность, захват или нарушение обязанности. Также нет полной исторической оценки работы сроков 2013 года.

Раннее взаимодействие может ускорить рассмотрение. Группа способна сама опубликовать календарь. ICANN может выпустить дополнительное руководство. Первые завершённые дела дадут эмпирический ответ; один текст не предрешает его.

Предлагаемая квитанция не меняет полномочий. Члены одобряют, организация проверяет, комитет ведёт к консультации и рекомендации, Совет признаёт или отклоняет. График не голосует, не исправляет дефектный устав и не отменяет обязательную проверку.

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

Источники

  1. ICANN — процедура изменения уставов GNSO, март 2026 года
  2. ICANN GNSO — процедура 2013 года
  3. Совет ICANN — утверждённые резолюции 12 марта 2026 года
  4. Совет ICANN — протокол 12 марта 2026 года
  5. ICANN — Public Comment по обновлённой процедуре
  6. Registrar Stakeholder Group — комментарий
  7. ICANN — сводный отчёт по комментариям
  8. OEC Совета — протокол 23 февраля 2026 года
  9. GNSO — Stakeholder Groups and Constituencies
  10. ICANN — Bylaws
  11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption