Сигналы непрерывности политики, легитимности и подотчётности институтов управления интернетом.
Управление интернетом
Управление интернетом
Раздел «Управление интернетом» отслеживает институты, политические процессы, разработку стандартов, работу регистратур, споры об ответственности и практическое исполнение решений, влияющих на интернет-инфраструктуру. BTW.MEDIA объединяет открытые публикации, аналитику по источникам, институциональный контекст и длительное наблюдение за отдельными делами.
Мониторинг RIRДосьеСообщество номерных ресурсовICANNIETFИстория интернетаNOGs
Сигналы непрерывности политики, легитимности и подотчётности институтов управления интернетом.
Приоритет отдан фактам о внедрении и поведению институтов, а не декларациям.
Последние материалы
Главные материалы: Управление интернетом
7 690 статей
История
Идентификатор назвал сеанс, но не перенёс его: RFC 3033
В сообщении сигнализации ATM могли находиться точные адреса, протокол и порты IP-сеанса, а его пакеты всё ещё шли по прежнему виртуальному каналу. RFC 3033 задал общий язык для такого согласования и не выдал имя за доказательство нового VC, переноса состояния или полученного…
История
Сервер сообщил о возможностях. После входа ответ изменился: RFC 2449
Клиент POP3 спрашивает, что умеет сервер, ещё не зная, кто подключается. Ответ может быть намеренно осторожным. После аутентификации сервер способен уточнить его для конкретного пользователя; после установки защиты целостности прежний список может уже не подходить. RFC 2449…
IETF
Срок письма истёк, но право удалить его не возникло
Отправитель может знать, когда перестаёт действовать предложение. Он не знает, когда получателю больше не понадобится запись об этом предложении. Поле `Expires` передаёт первое знание и не превращает его во второе.
История
Сервер подписал вердикт, но объект остался недействительным: RFC 3029
Доверенный сервер выдал подписанный сертификат, в котором стоял отрицательный результат. Подпись не исправляла проверяемый документ. Она связывала вердикт с сервером, запросом, временем и политикой. RFC 3029 построил протокол на различии между успешной работой службы и успешной…
IETF
Реестры согласовали запись, но не право доверять ей
Две организации получили одну и ту же подписанную карточку агента. Хеши совпали, место в журнале подтвердилось, маршрут отвечал. Одна организация допустила агента, другая отказала. Единым оказался факт записи, а не цена ошибки.
IETF
Порядок тестов OAM должен задаваться моделью, а не только текстом
После диагностики сеть оставляет набор измерений. Но если невозможно установить очередность проверок, труднее понять, как получен вывод. Новая редакция проекта IETF защищает настроенную последовательность от незаметного изменения шаблона, одновременно оставляя противоречие между…
История
Сеть считала пакеты равными. Кодек — нет: RFC 2448
В сжатом видео потеря нескольких байтов не обязательно означает небольшой ущерб. Утрата фрагмента изображения может оставить локальный дефект; потеря короткого описания того, как декодировать следующие данные, способна повредить куда большую часть картины. В 1998 году RFC 2448…
История
Команда фильтра ещё не была доставкой: RFC 3028
Слово `redirect` звучит как завершившееся событие: письмо перенаправлено. В Sieve оно означало только решение начать новый участок доставки. Удалённый сервер по-прежнему мог отказать. RFC 3028 дал пользователю ограниченный язык действий, но не позволил принять выбранный глагол за…
IETF
Сервер ответил 200, а запрос остался в ожидании
Система отправила отмену, получила `200 OK` и закрыла дело. Но сервер авторизации никогда не объявлял, что умеет отзывать коды отсрочки. Позже пришёл callback о завершении исходного процесса. Ответ был корректным: протокол специально не раскрывает, изменилось ли состояние.…
IETF
Резерв был создан, но перенос пришлось отменить
Целевая площадка приняла резерв, однако после переноса выяснилось, что часть рабочего набора нельзя сделать пригодной к сроку. Правильным результатом стал не commit, а abort с сохранением исходной площадки.
История
Календарь находился в MIME-части, а не в поле «От»: RFC 2447
RFC 2447 дал протоколу iTIP путь через обычную электронную почту: структурированный объект помещался в MIME-часть `text/calendar`, а параметр `method` должен был совпадать с внутренним `METHOD`. Для почтовых программ без поддержки календаря можно было добавить читаемое описание…
IETF
GAAP-25 отделяет протокол от иллюстративного Python API
Пример кода способен незаметно превратиться в «обязательную» часть спецификации, если разработчики копируют его без оговорок. Новая редакция GAAP прямо ограничивает такую трактовку: общим для участников должен быть обмен Claim, а не внутренний интерфейс приложения.
IETF
Сеть вернулась раньше, чем исчез её старый префикс
Таймер старого префикса продолжал отсчёт после того, как маршрутизатор, создавший этот префикс, потерял прежнюю роль. Новый маршрутизатор уже объявлял другой адресный контекст. Для протокола оба состояния могли быть допустимы; для приложения только одно вело к работающему…
История
Общий XML-парсер открывал байты, но не принимал решение: RFC 3023
Суффикс `+xml` позволял машине узнать семейство представления. Чтобы понять конкретный словарь, проверить полномочия и зафиксировать результат, ей всё равно требовалась полная цепочка доказательств.
IETF
Учётные данные отозвали. Обязательства агента остались.
После компрометации сертификат аннулировали, ключ исключили, а доступ закрыли. Затем система удалила и историю субъекта, будто отзыв способа доказательства отменил прежние действия и обязательства. Защитная мера превратилась в амнистию из-за смешения учётных данных с самим…
История
RFC 2446 и iTIP: как календарный протокол отделил предложение от решения
В ноябре 1998 года RFC 2446 зафиксировал важную для архитектуры интернет-календарей границу: корректное сообщение может быть создано, передано, разобрано и даже отображено пользователю, но всё это ещё не означает, что общее состояние события изменилось. iTIP разделяет…
История
Префикс предполагал линию точка-точка, но не создавал её: RFC 3021
Запись `/31` сообщала маршрутизатору, как понимать два адреса. Она не могла сама доказать, что за интерфейсом действительно только два участника и что второй маршрутизатор читает те же биты по тем же правилам.
IETF
Проект EPP добавляет команду удаления всех записей DELEG для домена
В новой редакции индивидуального Internet-Draft клиент EPP получает предлагаемый способ убрать весь набор записей DELEG одного домена одним обновлением. Техническая краткость команды делает особенно важным разделение полномочий: править отдельные записи и опустошать набор целиком…
IETF
Целый линк появился только после решения контроллера
На схеме два автономных домена соединяла одна уверенная линия. В журнале не было ни одного сообщения, которое видело бы её целиком. Были два объявления с разных сторон и решение контроллера считать их описанием одного соединения.
IETF
Контейнер проверился. Значение оценки оставалось неподдерживаемым.
Подпись файла была действительной, дайджест совпал, а структура прошла проверку. Но потребитель не знал semantic profile, по которому поле `0.95` связывалось с конкретной метрикой, популяцией и критерием. Контейнер можно было хранить и пересылать. Принимать его вывод как…
Карта раздела
Направления управления
Мониторинг RIR
Пять региональных направлений о распределении ресурсов, легитимности советов и непрерывности работы институтов.
Открыть RIR WatchdogДосье
Долгосрочные досье о судебных спорах, выборах и институциональных кризисах.
Открыть досьеСообщество номерных ресурсов
Членство, устав и управление номерными ресурсами в экосистеме NRS.
Открыть раздел NRSICANN
Координация DNS, механизмы подотчётности и глобальный многосторонний процесс.
Открыть раздел ICANNIETF
Развитие стандартов протоколов и риски совместимости при фрагментации политики.
Открыть раздел IETFИстория интернета
История инфраструктуры как основа для понимания управления и долгосрочного прогноза.
Открыть раздел историиNOGs
Практические данные о внедрении от APRICOT, региональных и национальных NOG.
Открыть раздел NOG