Основное направление
Управление интернетом и маршрутизация
В фасете «Основное направление» значение «Управление интернетом и маршрутизация» группирует публикации по основной предметной области. В одном месте собраны статьи, открытые источники, институты, компании, люди, региональные риски, операционные зависимости и рыночный контекст. Страница объясняет границы области, основных участников и источники, на которые стоит опираться при сравнении сигналов. Она помогает увидеть, как одна тема проявляется в событиях, профилях, изменениях рынка и долгосрочных инфраструктурных решениях.
ICANN
Изменение строки .Brand может добавить слова, но не создать и не расширить contention set
Раунд ICANN 2026 года даёт отвечающему требованиям заявителю .Brand узкий путь изменения строки, включённой в contention set. Это не общее право переименовать заявку.
ICANN
Существенное изменение публичных частей заявки открывает 30 дней для комментариев, но не означает автоматического одобрения
Когда ICANN решает, что изменение существенно затрагивает публичные части заявки, начинается 30-дневный период комментариев, однако запрос ещё не одобрен.
Сообщество номерных ресурсов
Серийный номер кэша RPKI — не метка времени свежести
Два кэша RPKI могут сообщать совершенно точные серийные номера и всё же не показывать оператору, в каком из них глобальные данные новее. RFC 8210 ограничивает номер одной сессией кэша и версией протокола. Если считать большее число признаком свежести, возникает хронология…
ICANN
Консенсусная рекомендация GAC открывает 21-дневный срок для ответа, а не автоматический итог Совета
Формальная консенсусная рекомендация GAC меняет процессуальное положение заявителя, но сама по себе не является решением Совета ICANN.
ICANN
Раннее предупреждение члена GAC — это сигнал, а не вето: запись о реакции заявителя
Раунд 2026 даёт представителю государства способ обозначить обеспокоенность, не превращая это уведомление в автоматическое решение по заявке.
ICANN
Риск единственного и множественного числа не срабатывает сам: 30-дневная запись ICANN
В Раунде 2026 грамматическая пара становится предметом решения программы только после своевременного уведомления с проверяемыми словарными доказательствами.
ICANN
Апелляция по возражению ICANN — не новое разбирательство: что может изменить стандарт явной ошибки
Апелляционная процедура Раунда 2026 проверяет конкретно указанную ошибку в решении по возражению, а не открывает весь спор заново.
ICANN
Возражение сообщества — не CPE: две процедуры ICANN проверяют разные утверждения
Слово «сообщество» есть в обоих названиях, но стороны, критерии доказывания и предмет решения различаются.
ICANN
Какое доказательственное досье подготовить заявителю для оценки приоритета сообщества?
Досье, связанное с критериями, полезнее набора писем поддержки.
Досье
Ответчиками стали шестьдесят имен, но содержание иска по-прежнему определял закон: Harrods v Sixty Internet Domain Names
Название дела меняет привычную расстановку сторон: в качестве ответчиков указаны не люди, а шестьдесят доменных имен. Производство **in rem** по ACPA позволило обратиться в суд, когда установить персональную юрисдикцию над регистрантом не удалось. Однако место регистрации доменов…
ICANN
ICANN проверяет географический смысл каждой заявленной строки — что должно доказывать письмо о поддержке?
В раунде ICANN 2026 года географическую проверку проходит каждая строка. Досье должно подтверждать полномочия, подлинность и точный охват поддержки.
IETF
Corey Bonnell и подпись CRL ключом без полномочия
Криптография может безошибочно подтвердить подпись и при этом не ответить на вопрос о полномочии. RFC 10007 требует задать этот вопрос явно: у v3-сертификата издателя CRL должно быть расширение `keyUsage`, а в нём — установленный бит `cRLSign`.
IETF
Kireeti Kompella и Echo-ответ, который не доказал работу услуги
MPLS Echo Reply способен показать, что определённая проба дошла до маршрутизатора, который объяснил конкретный FEC. Он не доказывает все ECMP-пути, готовность спящего резерва, симметричный возврат, полезную нагрузку клиента или завершение приложения. В LSP Ping важна граница…
IETF
Eliot Lear и политика устройства, которая не была аттестацией
Устройство с узкой функцией способно перечислить необходимые сетевые связи, но таким перечнем оно не доказывает ни свою личность, ни целостность, ни будущее поведение. RFC 8520 делает ограниченное заявление пригодным для автоматизации через Manufacturer Usage Description и…
IETF
Tero Kivinen и новая IKE SA, унаследовавшая работающие Child SA
После успешного rekey управляющие ключи могут стать новыми, а ключи защищённого трафика — остаться прежними. В IKEv2 это нормальная граница: новая IKE SA принимает под управление уже действующие Child SA, но не заменяет их SPI, селекторы, алгоритмы и ключи. RFC 7296 требует…
IETF
Roy Fielding и метод, который называл намерение, а не разрешение
Первый токен HTTP-запроса видят компоненты, ничего не знающие о внутреннем устройстве приложения. Он даёт клиенту, кэшу, посреднику и серверу общий минимум смысла. Но общий язык не становится общей властью. Метод сообщает, чего хочет клиент; он не устанавливает личность, не…
IETF
Mark Nottingham и пользовательский агент, который не мог говорить за всех
Браузер способен ограничить сервис, передать узкую настройку и оставить путь к другой реализации. В этом состоит полезная посредническая роль. Но ни программа, ни её поставщик, ни участник стандартизации не получают вместе с ней доверенность от всех людей, на которых влияет…