Сигналы непрерывности политики, легитимности и подотчётности институтов управления интернетом.
Управление интернетом
Управление интернетом
Раздел «Управление интернетом» отслеживает институты, политические процессы, разработку стандартов, работу регистратур, споры об ответственности и практическое исполнение решений, влияющих на интернет-инфраструктуру. BTW.MEDIA объединяет открытые публикации, аналитику по источникам, институциональный контекст и длительное наблюдение за отдельными делами.
Мониторинг RIRДосьеСообщество номерных ресурсовICANNIETFИстория интернетаNOGs
Сигналы непрерывности политики, легитимности и подотчётности институтов управления интернетом.
Приоритет отдан фактам о внедрении и поведению институтов, а не декларациям.
Последние материалы
Главные материалы: Управление интернетом
7 559 статей
IETF
LWAPP — историческая запись, а не основа развёртывания
RFC 5412 фиксирует Lightweight Access Point Protocol в том виде, в каком он был представлен работе CAPWAP. Он показывает архитектуру контроллера и лёгких точек доступа, но RFC Editor помечает документ как Historic и прямо запрещает использовать его как основу развёртывания. RFC…
Досье
На PP-26 выступления идут по очереди; официальным предложениям нужен отдельный след
Две или три минуты у трибуны могут сделать государственный приоритет заметным, но сами по себе не показывают, что конференция станет с ним делать. До открытия PP-26 ITU опубликовал правила политических заявлений: по одному высокопоставленному выступающему от делегации…
IETF
CATS выбрала контакт сервиса, но рабочий экземпляр остался скрытым: RFC 10053
CATS может направить запрос к подходящему контактному узлу, учитывая состояние сети и вычислительные ресурсы. Но сам выбор не обязательно показывает, какой внутренний экземпляр обработает запрос и описывают ли опубликованные метрики только его.
История
Контроллеру сначала требовалась сеть, чтобы управлять ею: RFC 7149
В марте 2014 года меморандум IETF предложил операторам смотреть дальше наглядной схемы с центральным контроллером. Как он обнаружит устройства, доберётся до них и безопасно повлияет на управляемую сеть? RFC 7149 рассматривает запуск, согласование параметров услуги и сохранение…
IETF
Руководство по SIP — это карта, а не сертификат развёртывания
RFC 5411 делает обширное семейство SIP обозримым: группирует спецификации по темам, показывает статус документов и ведёт к связанным работам. Но это информационный снимок, привязанный к дате, а не живой реестр того, что реально выполняет оператор. Запись может быть…
История
DHCP передавал устойчивый идентификатор абонента, но не определял его смысл: RFC 3993
Клиент мог сменить путь доступа, а оператор хотел сохранить прежнее решение о настройках. RFC 3993 позволил ретранслятору DHCP переносить устойчивую метку абонента, но оставил оператору право определить, кто её присваивает и что она означает.
IETF
Расширение передало сообщение о ключе. Установку ключа оно не доказало.
RFC 5410 добавляет в MIKEY расширение для OMA BCAST 1.0. Оно переносит STKM, LTKM, отчёт LTKM и сообщения родительского контроля. Полученный Type 5 подтверждает формат, но не установку ключа, активацию контекста или разрешённое воспроизведение.
IETF
CMS упаковал ключ, но идентичность получателя всё равно должна совпасть
RFC 5409 описывает BF и BB1 в CMS: они шифруют ключ содержимого, задают кодирование идентичности получателя и OID алгоритма. Открытый конверт не является разрешением на действие.
IETF
Идентичность может стать открытым ключом. Разрешением она не становится.
Шифрование на основе идентичности позволяет отправителю вычислить открытый ключ из идентификатора получателя и публичных параметров. Генератор закрытых ключей (PKG) выдаёт секрет, когда получатель обращается за ним. RFC 5408 формализует этот маршрут, но не смешивает выдачу ключа…
IETF
Лучший узел ещё не означает, что сеанс можно перенести: RFC 10054
Клиент может уйти в другую зону обслуживания, а состояние сервиса останется на прежнем пограничном узле. RFC 10054 предлагает учитывать ресурсы вычислений и сети при выборе экземпляра, но для перенаправления активного сеанса с состоянием требует явного указания приложения…
Досье
Показатель CNCF «2,07 раза» требует ясного описания рассмотренных проектов
CNCF сообщает, что проекты, у которых на момент входа в Sandbox были мейнтейнеры из нескольких организаций, чаще доходят до Graduation. Действующий шаблон проверки управления отдельно требует, чтобы на этапе Graduation среди мейнтейнеров были представители как минимум двух…
IETF
Канал был привязан, но операция оставалась отдельным решением.
An SIP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5407 draws a harder line: SIP Version 2 can bind a SIP message to lower-channel information, but the binding does not become local…
История
Уровень 2 согласовывался для сеанса, а не для устройства целиком: RFC 7147
Одна система хранения может одновременно обслуживать несколько iSCSI-сеансов с разными инициаторами. RFC 7147 записал согласованный уровень протокола в атрибутах каждого сеанса: речь шла о договорённости двух сторон, а не о постоянном свойстве всего устройства.
IETF
Канал был привязан, но операция оставалась отдельным решением.
An IPsec gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5406 draws a harder line: IPsec Version 2 can bind a IPsec message to lower-channel information, but the binding does not become…
IETF
Канал был привязан, но операция оставалась отдельным решением.
An RTP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5404 draws a harder line: G.719 RTP Version 2 can bind a G.719 frame block to lower-channel information, but the binding does not…
IETF
Канал был привязан, но операция оставалась отдельным решением.
An RPC gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5403 draws a harder line: RPCSEC_GSS Version 2 can bind a GSS context to lower-channel information, but the binding does not…
IETF
Аутентификация могла быть односторонней, привязка канала — нет: RFC 5387
Долгоживущее соединение пережило смену SA и не потеряло ни одного пакета. Именно такая гладкость опасна: новый защищённый участок мог принадлежать уже другому посреднику. RFC 5387 требует не верить непрерывной картинке, а доказать, что оба конца связали верхнюю сессию с одним и…
История
Глобальный адрес мог выдаваться во временное пользование, а не определять узел: RFC 1335
В мае 1992 года одно из предложений на фоне дефицита адресов IPv4 исходило из неброского различия: машина могла сохранять адрес внутри своей сети, а глобально уникальный адрес получать лишь на время, когда требовалось выйти за её пределы.
APRICOT
APNOG перевела срок полномочий совета на мартовский цикл. Переход должен быть проверяемым.
APNOG решила отсчитывать сроки полномочий совета с марта по март, не привязывая их точно к дате ежегодного общего собрания. В опубликованном объяснении названы две практические причины: передача дел между уходящими и новыми директорами и время, необходимое новым членам совета для…
IETF
Шифрование и совпавший MIC не отменяют утечку через размер
Шлюз успешно расшифровал обмен, проверил подпись и получил совпадающий MIC. Отчёт назвал канал безопасным. Но до шифрования секретные поля сжимались вместе с данными, на которые мог влиять внешний участник. RFC 3274 напоминает: корректная криптография содержимого не уничтожает…
Карта раздела
Направления управления
Мониторинг RIR
Пять региональных направлений о распределении ресурсов, легитимности советов и непрерывности работы институтов.
Открыть RIR WatchdogДосье
Долгосрочные досье о судебных спорах, выборах и институциональных кризисах.
Открыть досьеСообщество номерных ресурсов
Членство, устав и управление номерными ресурсами в экосистеме NRS.
Открыть раздел NRSICANN
Координация DNS, механизмы подотчётности и глобальный многосторонний процесс.
Открыть раздел ICANNIETF
Развитие стандартов протоколов и риски совместимости при фрагментации политики.
Открыть раздел IETFИстория интернета
История инфраструктуры как основа для понимания управления и долгосрочного прогноза.
Открыть раздел историиNOGs
Практические данные о внедрении от APRICOT, региональных и национальных NOG.
Открыть раздел NOG