Низкий номер в жеребьёвке приоритета улучшает положение заявки на нескольких важных этапах раунда новых gTLD 2026 года. Но он не подтверждает приемлемость запрошенной строки и не гарантирует, что все результаты появятся раньше. В материалах ICANN проведена прямая граница: номер определяет общий порядок ряда процессов, но не порядок прохождения String Evaluation — оценки самой строки.

Иными словами, инструмент планирования нельзя превращать в прогноз решения.

Что именно упорядочивает номер

По объяснению ICANN, номер приоритета задаёт общий порядок прохождения урегулирования конкуренции, Applicant Evaluation и Application Evaluation, получения результатов этих оценок и, при успехе, движения к заключению договора.

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

Следовательно, номер показывает место в графике, но не обещает результат и не оценивает строку.

Пять проверок на другой временной шкале

Авторитетной версией Руководства заявителя 2026 года ICANN называет V2-2026.04.24. В глоссарии String Evaluation определяется как проверка запрошенных строк и их доступных для распределения вариантов. Пять элементов оцениваются параллельно:

  1. String Similarity Evaluation — визуальное сходство и его возможное влияние на результат или наборы конкурирующих заявок.
  2. Name Collision Initial Assessment — первоначальная оценка риска коллизии имён.
  3. Safeguard Assessment — требования защитных мер, применимые к строке.
  4. Geographic Names Identification — проверка применимости правил о географических названиях.
  5. Singular/Plural Notifications Evaluation — оценка уведомлений о связи единственного и множественного числа между строками.

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

Поэтому заявка с маленьким номером может ждать вывода по строке, а отдельный результат заявки с большим номером может появиться раньше. Само по себе это не доказывает нарушение очереди. Точно так же ранний результат String Evaluation не означает завершения оценки заявителя, оценки заявки, возражений, конкуренции или договорного этапа.

Два реестра вместо одного сигнала

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

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

Так низкий номер перестанет выглядеть сертификатом безопасности, ранний результат — обещанием скорого договора, а различие во времени — автоматическим доказательством привилегии.

Модель «двух часов» — рекомендация по прозрачности, а не уже принятая политика ICANN. Однако её фактическая основа содержится в официальных документах: приоритет управляет лишь частью пути, а оценка строк не подчиняется этому порядку. Публичная отчётность должна так же ясно показывать, где заканчивается очередь и начинается отдельная оценочная шкала.

Источники