Основное направление
Управление интернетом и маршрутизация
В фасете «Основное направление» значение «Управление интернетом и маршрутизация» группирует публикации по основной предметной области. В одном месте собраны статьи, открытые источники, институты, компании, люди, региональные риски, операционные зависимости и рыночный контекст. Страница объясняет границы области, основных участников и источники, на которые стоит опираться при сравнении сигналов. Она помогает увидеть, как одна тема проявляется в событиях, профилях, изменениях рынка и долгосрочных инфраструктурных решениях.
ICANN
ICANN: как устав, политика и контракты превращают координацию в операционный контроль
Власть ICANN над экосистемой уникальных интернет-идентификаторов не сводится к одному источнику и не равна классическому государственному регулированию. Она складывается из нескольких связанных инструментов: учредительных документов, устава, многосторонней разработки политики…
IETF
IETF и W3C: власть определяется не логотипом, а инструментом
Под общим названием IETF–W3C часто описывают две опоры интернет-стандартов. Но это не единая организация и не единый центр управления. В IETF полномочия по разработке стандартов распределены между сообществом, рабочими группами, IESG и IAB; административные и корпоративные…
ICANN
Как ICANN превращает возражение в формальную процедуру: три маршрута подотчётности и их пределы
У ICANN нет единой апелляции, которая позволяла бы любому затронутому участнику оспорить любое решение по существу. Вместо этого система распределяет возражения между несколькими инструментами: полномочиями Empowered Community, процедурой reconsideration и Independent Review…
Истории
DATAMATIX и AS210973: что публичные маршруты доказывают — и чего не доказывают
Аналитическая справка о DATAMATIX и AS210973: что публичные маршруты доказывают — и чего не доказывают объясняет событие, доступные открытые подтверждения, участвующие организации, региональный контекст, рыночные риски и возможные последствия для инфраструктуры. В категории…
ICANN
Пятый вариант строки, доступный для распределения, влечёт ещё один полный оценочный сбор
Для нового заявителя первые четыре варианта строки могут входить в оценочный сбор gTLD, но каждый дополнительный вариант, допустимый к распределению, требует полного оценочного сбора.
ICANN
После подачи заявки gTLD остаётся семидневный срок оплаты
Своевременной подачи заявки gTLD недостаточно: ICANN должна получить оценочный сбор в отдельный платёжный период.
ICANN
Административная проверка — процедурный этап, а не решение по существу
ICANN проверяет сведения о подаче и готовит группы одинаковых строк, но это не одобрение заявки по существу.
ICANN
Одна оценка RSP может охватывать много gTLD — только для квалифицированных услуг
Оценку можно повторно использовать для разных gTLD, но квалификация ICANN относится к конкретным услугам реестра.
ICANN
Покрытие RSP — это карта функций, а не число поставщиков
Заявитель может назвать несколько поставщиков услуг реестра и все же оставить критическую функцию без покрытия. В раунде ICANN 2026 года роли Main, DNS, DNSSEC и необязательного Proxy RSP имеют разные функции и ограничения по количеству.
ICANN
Указание RSP не является подтверждением на этапе заключения договора
Заявитель может указать поставщика услуг реестра в заявке, а на этапе договорного оформления ICANN отдельно запрашивает подтверждение у этого поставщика. Выбор заявителя, запрос ICANN и любой фактический ответ RSP — разные доказательства.
ICANN
Выбор RSP можно отложить до оценки, но не бессрочно
Правила ICANN 2026 года позволяют подать заявку без указания поставщиков услуг реестра, однако к этапу оценки должно быть обеспечено покрытие минимального набора критических функций реестра.
ICANN
Наборы вариантов участвуют в разрешении конфликта вместе
Если разные заявители запрашивают строки из одного набора вариантов, правила ICANN 2026 года рассматривают заявленную основную строку и её заявленные допустимые к распределению варианты как единую конфликтную группу.
ICANN
Заявки на варианты существующих gTLD получают приоритет, но не одобрение
ICANN ставит одну категорию заявок раньше в очереди обработки: заявки на варианты существующих gTLD раунда 2012 года, допустимые к распределению. Этот приоритет меняет последовательность, а не итоговое решение.
ICANN
Для вариантов существующего gTLD требуется единое соглашение 2026 года
Заявка на варианты существующего gTLD, допустимые к распределению, — не просто добавление отдельных меток при неизменном договоре. Правила ICANN 2026 года требуют перехода на новое Базовое соглашение о реестре и объединяют существующий gTLD со всеми его вариантами в одном…
ICANN
Только оператор существующего gTLD может подать заявку на его варианты IDN
В раунде ICANN 2026 года заявитель на варианты IDN существующего gTLD должен быть тем же юридическим лицом, что и оператор реестра этого gTLD.
ICANN
Варианты IDN должны использовать поставщика серверных услуг реестра основного gTLD
В раунде ICANN 2026 года основной IDN gTLD и его варианты должны использовать одного поставщика серверных услуг реестра, пока они делегированы.
ICANN
При отзыве основной заявки IDN отзываются и все её варианты
В раунде ICANN 2026 года при отзыве основной заявки IDN отзываются и все строки-варианты, заявленные вместе с ней.
ICANN
Заявка на вариант IDN не может предшествовать заявке на основную строку
В раунде ICANN 2026 года заявку на доступный для распределения вариант IDN нельзя подать раньше заявки на соответствующий основной IDN gTLD.
ICANN
Для предлагаемой основной строки выбор может изменить варианты, доступные для распределения
Если предлагаемая основная строка сама не является существующим gTLD, общее число строк в полном множестве строк-вариантов RZ-LGR сохраняется, но состав подмножеств вариантов, доступных для распределения, и заблокированных вариантов может меняться в зависимости от её выбора.
ICANN
ICANN разрешает отозвать варианты IDN после подачи, но не добавить новые
В раунде 2026 года подача фиксирует исходный состав из основного IDN и запрошенных вариантов: затем его можно сократить отзывом, но нельзя расширить.