Кратко

  • 6 сентября Совет ICANN разрешил заключить контракт на разработку и поддержку систем для программы новых gTLD раунда 2026 года. В опубликованном 9 сентября решении названы функциональность, своевременное реагирование на инциденты, стабильность и критические процессы, но скрыты подрядчик, сумма и значительная часть мотивировки.
  • Решение от 3 мая описывало шесть месяцев усиленного дежурства — от открытия окна заявок до подтверждения строк, которое тогда ожидалось 30 октября, — после чего команду предполагалось сократить и вернуть к обычным рабочим часам.
  • Открытые документы не подтверждают, что оба решения относятся к одному подрядчику, контракту или объему работ. Но они подтверждают существование временной границы, итог которой должен быть проверяемым.
  • ICANN может опубликовать безопасный итоговый тест: штатный режим каждой функции, внутреннего владельца, доказательство передачи, открытые исключения, дату решения и следующего пересмотра.

Сентябрьское разрешение не отменяет майскую границу

Решения от 6 сентября уполномочивают President and CEO ICANN либо назначенных им лиц заключить контракт и производить выплаты за разработку и поддержку систем раунда 2026 года. Публичный текст называет достаточную функциональность, своевременное реагирование, стабильность и поддержку критических бизнес-процессов. Финансовое влияние уже учтено в бюджете FY27 и будущих планах.

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

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

Тогда Совет продлил контракты для усиленной модели дежурной поддержки. Обоснование очертило шестимесячный период повышенного спроса и сложности: с открытия приема 30 апреля до String Confirmation, ожидавшегося 30 октября. Расширенные часы должны были обеспечить реакцию вне обычного рабочего времени. По окончании периода команда, как ожидалось, уменьшится и перейдет на штатный график.

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

Связь контрактов нельзя придумывать. Майский документ говорил, что действовавший тогда поставщик был выбран в ходе RFP октября 2023 года, поставил системы RSP и ASP и продвигал TAMS. Сентябрьский текст не подтверждает того же исполнителя, соглашения или объема. Проверка выхода должна следовать за функцией и ее внутренним владельцем, а не за предполагаемым коммерческим именем.

Прием заявок закончился, обработка — нет

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

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

Отчет перед ICANN85 показывает поэтапность. В феврале build 5 TAMS и пользовательское приемочное тестирование были завершены, началась сквозная интеграционная проверка; builds 6, 7 и 8 еще планировались для функций оценки и контрактования. Отдельно шли управление программой, инфраструктура, операционализация, подготовка сотрудников и подрядчиков, финансы, закупки и юридическое сопровождение.

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

Одной страницы достаточно

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

  1. Какая поддержка была исключительной и каков целевой штатный режим?
  2. Какая внутренняя роль ICANN принимает услугу и решает сократить, продлить или перестроить поддержку?
  3. Какие виды доказательств проверены: восстановление, открытые дефекты, прогноз работ, передача инструкций или четко определенные данные дежурств?
  4. Какие функции и когда перешли в устойчивую эксплуатацию?
  5. Какие исключения остались, почему и до какого пересмотра?
  6. Когда наступит следующая публичная точка решения?

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

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

Состояние можно открыть, чувствительные детали — оставить закрытыми

Documentary Information Disclosure Policy исходит из доступности документов, но допускает неразглашение по убедительным причинам, включая защиту коммерческих интересов. Publication Practices описывают публикацию решений, предварительных отчетов и протоколов по Bylaws вместе с допустимыми исключениями.

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

Contracting and Disbursement Policy требует одобрения Совета для обязательств свыше 750 тыс. долларов и периодических отчетов CFO о значительных выплатах. Сумма сентября скрыта, поэтому порог не позволяет ее оценить. Финансовое разрешение также не заменяет эксплуатационную приемку. Это разные контрольные действия.

Граница знания

Ни один источник не сообщает об отказе, нарушении времени реакции, взломе, плохой работе, перерасходе, привязке к поставщику или неудачной передаче. Количество заявок не измеряет нагрузку. Упоминание TAMS, RSP и ASP в мае не доказывает, что сентябрьский объем ограничен ими.

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

Источники

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. ICANN — Одобренные решения от 6 сентября 2026 года
  5. ICANN — Одобренные решения от 3 мая 2026 года
  6. ICANN — Отчет о раунде 2026 года перед ICANN85
  7. ICANN — Раунд 2026 года завершил прием более 1600 заявок
  8. New gTLD Program — Applicant Journey
  9. ICANN — Documentary Information Disclosure Policy
  10. ICANN — Publication Practices
  11. ICANN — Contracting and Disbursement Policy