Кратко

  • Поправки к Fundamental Bylaws, действующие с 3 июля 2026 года, привязали и проверку эффективности CSC, и периодическую проверку функции имён IANA к предыдущему итоговому отчёту; повторяющийся цикл CSC при этом увеличился с трёх до пяти лет.
  • Модель даёт время завершить проверку и исполнение рекомендаций, но длительность процесса теперь увеличивает расстояние между стартами. ICANN нужен реестр двух таймеров с точкой отсчёта, предельной датой, ранним триггером, задержкой, отчётом, исполнением и каждым новым расчётом.

Полномочие можно назвать точно

Цепочка принятия решения открыта для проверки. 3 мая 2026 года Совет директоров ICANN одобрил поправки к статьям 17 и 18 резолюциями 2026.05.03.11–13. 11 мая Secretary уведомил Empowered Community, приложил точные редакции и предложил рассматривать их вместе, поскольку обе касались надзора за функцией имён IANA.

В публичной карточке процедуры указана поддержка ccNSO, ASO, ALAC и GNSO, воздержание GAC и отсутствие возражений. Для такой поправки Annex D требует поддержки как минимум трёх Decisional Participants и не более одного возражения. Четыре голоса «за», ноль «против» и одно воздержание удовлетворили условию. В действующих Bylaws прямо указано, что они изменены 3 июля 2026 года.

Это устанавливает инструмент и источник власти. Решение не было всеобщим голосованием пользователей Интернета, и выдавать его за такое не нужно. Empowered Community осуществила право одобрения, закреплённое в корпоративной конституции ICANN. Поэтому содержательный вопрос подотчётности уже: что именно сделал новый текст, кто способен включить раннюю проверку и сможет ли внешний наблюдатель пересчитать следующую дату?

Два таймера отвечают за разные вещи. CSC постоянно отслеживает исполнение Public Technical Identifiers требований IANA Naming Function Contract и ожидаемого уровня сервиса. Проверка эффективности CSC оценивает, работает ли сам надзорный орган. Периодическая IANA Naming Function Review изучает работу PTI и более широкую архитектуру контроля. Совместное одобрение поправок не объединило эти мандаты.

Цикл CSC вырос, а ранний отчёт стал новым нулём

Прежняя статья 17.3(b) предписывала провести первую проверку эффективности через два года после первого заседания CSC, а затем повторять её каждые три года. Новая редакция убрала историческое условие для первой проверки и установила пятилетний интервал от сдачи итогового отчёта предыдущей. Точное описание повторяющегося цикла — переход с трёх лет на пять. Формула «с двух на пять» смешивает разовое начальное правило с последующими.

Для срочной ситуации остался выпускной клапан. CSC, ccNSO, GNSO, Совет ICANN или Совет PTI могут запросить внеочередную проверку. Её итоговый отчёт становится точкой отсчёта для новых пяти лет. Поправка к статье 17.2 также разрешила Registries Stakeholder Group и ccNSO назначать запасных членов CSC, а каждой организации, выбирающей liaison, — запасного представителя. Роль и порядок отбора определяет CSC.

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

Право начать раньше полезно, но само себя не исполняет. Кто-то из пяти субъектов должен увидеть проблему, признать достижение порога, записать запрос и принять, что новый итоговый отчёт перезапустит обычный таймер. Без единого публичного места для запроса, ответа и причины фраза «можно проверить раньше» останется юридической возможностью, а не подотчётным предохранителем.

У IFR осталось пять лет, но стартовая черта отодвинулась

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

IFR2 была созвана 10 сентября 2023 года и сдала отчёт 4 сентября 2025-го. По расчёту Совета старый текст требовал начать следующую периодическую проверку не позднее 9 сентября 2028 года. Новый якорь переносит внешний предел на 3 сентября 2030-го. Номинальный интервал не изменился, но возможное расстояние от начала одной проверки до начала следующей выросло почти на всю продолжительность IFR2.

У этого есть разумное объяснение. Группе нужно время на исследование, консультации и завершение текста; организации — на рассмотрение и исполнение рекомендаций до запуска новой группы. Официальная сводка ICANN зафиксировала широкую поддержку изменения. Возможность Special IFR при недостатке или проблеме в работе PTI сохранилась. Отдельная норма позволяет задержать периодическую проверку во время специальной, но требует квалифицированного большинства и в ccNSO, и в GNSO, явного срока и, как правило, окончания отсрочки в пределах 12 месяцев после завершения Special IFR.

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

Один реестр для двух разных часов

Исходные события у ICANN уже есть. Их следует соединить в постоянную контрольную запись для каждой проверки эффективности CSC и каждой периодической или специальной IFR. В каждой строке нужны:

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

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

В документах стоит исправить две неточности

Юридический результат ясен, однако в пояснительной записи есть два расхождения. На странице процедуры Empowered Community строка итогового письма помечена «3 июля 2025 года». Та же страница говорит, что процедура завершена 3 июля 2026-го, связанное письмо относится к 2026 году, а действующие Bylaws несут дату поправки 2026 года. Разумно считать это ошибкой года в публичном реестре, а не признаком несостоявшегося одобрения.

Кроме того, резюме консультации и части обоснования Совета называют прежнее правило CSC «двухлетним циклом». Фоновое описание на той же странице и старая редакция точнее: первая проверка через два года, затем каждые три. Ни одна неточность не отменяет поправку. Обе делают аудиторский след труднее для чтения.

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

Источники