Открытый орган стандартизации, решения которого внедряются по всему миру.
Управление интернетом / IETF
IETF
Раздел «IETF» отслеживает институты, политические процессы, разработку стандартов, работу регистратур, споры об ответственности и практическое исполнение решений, влияющих на интернет-инфраструктуру. BTW.MEDIA объединяет открытые публикации, аналитику по источникам, институциональный контекст и длительное наблюдение за отдельными делами.
ГлобальныйУправление протоколамиРиск несовместимости
Процесс разработки протоколов и легитимность стандартов.
Разрыв между спецификацией и внедрением у поставщиков и операторов.
Крупные изменения стандартов обычно влияют на системы в цикле продолжительностью от 120 дней.
Последние материалы
Главные материалы: IETF
1 467 статей
IETF
Курс IETF для новых участников не будет отслеживать учащихся. Но его результат всё равно нужно фиксировать
IETF заказывает курс для самостоятельного изучения, который должен помочь новичкам войти в технический процесс, освоение которого может занять годы. Решение не оценивать и не отслеживать каждого учащегося задаёт важную границу для защиты приватности. Остаётся вопрос управления…
IETF
IETF ведёт два отбора на должности INT AD по разным графикам
В IETF одновременно идут два отбора руководителей направления Internet (INT). Один должен заполнить место после отставки Tommy Jensen в середине срока; другой относится к обычной двухлетней должности, которую Éric Vyncke не намерен занимать дальше. У процедур разные графики и…
IETF
Проект IETF расширяет предлагаемую гарантию в NomCom и ставит вопрос о цене проверяемости
Редакция -06 индивидуального Internet-Draft увеличивает предлагаемую гарантию для добровольной группы opt-in с трёх до пяти мест и оставляет самодекларацию без проверки. При этом публичная проверяемость отбора требует постоянного раскрытия принадлежности к группе, а малый пул…
IETF
RFC 10065 связывает группу с политикой, но не доказывает её применение
В RADIUS можно передать предпочтительный идентификатор группы ещё в `Access-Request`, но сервер не обязан его принимать. Эта оговорка показывает, что метка в пакете не равна решению об авторизации. RFC 10065 стандартизирует перенос метки и её использование в ACL, а…
IETF
Syslog мог сообщать о качестве часов. Их границы всё равно задавал оператор: RFC 5424
При сопоставлении журналов из разных систем временная шкала часто выглядит точнее, чем исходные наблюдения. RFC 5424 позволяет отправителю приложить к сообщению оценку состояния собственных часов. Но протокол переносит эту оценку, а не проверяет её: основание для доверия остаётся…
IETF
В туннеле EAP-FAST тип 6 означал другое: RFC 5421
RFC 5421 поместил знакомый код EAP в новый контекст: в реестре тип 6 по-прежнему назывался Generic Token Card, но внутри туннеля EAP-FAST он выбирал внутренний обмен с другим форматом. Спецификация жёстко разделила эти варианты, а примечание IESG предупредило, что повторное…
IETF
Успешная настройка ещё не решала вопрос сетевого доступа: RFC 5422
RFC 5422 отделяет настройку учётных данных от разрешения доступа; режим без аутентификации сервера предназначен только для настройки.
IETF
AAA подтвердила абонента. Домашнему агенту всё ещё требовался ключ: RFC 5419
RFC 5419 объясняет, почему некоторые операторы Mobile IPv6 хотели использовать уже существующую связь с AAA для проверки абонентов. Но главная задача возникает после проверки: домашняя AAA-система может узнать абонента, а выбранному домашнему агенту всё равно нужна пригодная и…
IETF
Аутентификация CAPWAP-канала не разрешает устройство в сети: RFC 5418
RFC 5418 разделяет аутентификацию WTP–AC, регистрацию устройства в конкретной сети, назначение роли и маршрут клиентских данных. Успешная сессия отвечает лишь на часть операционного вопроса.
IETF
Ещё до поиска CAPWAP DHCP задавал порядок контроллеров для точки доступа: RFC 5417
Опция DHCPv4 или DHCPv6 может поставить один контроллер доступа перед другим в начальном поиске точки беспроводного завершения. RFC 5417 определяет этот порядок как настроенное предпочтение; обнаружение и DTLS позднее устанавливают, с каким узлом можно создать управляющую сессию.
IETF
RFC 5416: привязка 802.11 имеет границу поколения
RFC 5416 задаёт привязку CAPWAP для IEEE 802.11, а не универсальную гарантию всех современных возможностей Wi‑Fi. В нём описаны станции, радиопараметры, QoS и соответствие BSSID и WLAN в рамках базы 802.11-2007. Для руководителя важно отделять сообщение протокола от реально…
IETF
В IETF отклонённая апелляция — не то же самое, что оставленная без рассмотрения
Действующие правила IETF различают обращение, которое не дошло до проверки по существу, и апелляцию, отклонённую после рассмотрения. Для них предусмотрены разные публичные записи. Поэтому список принятых апелляций сам по себе не показывает общее число поданных обращений.
IETF
Состояние CAPWAP — не доказательство сервиса: RFC 5415
RFC 5415 организует WLAN control plane: Access Controller управляет Wireless Termination Points, защищает сессии, меняет конфигурацию и переносит данные. Но завершённое состояние, успешный DTLS или пакет в data channel доказывают лишь путь протокола, а не применённую политику…
IETF
WiCoP — историческая запись управления, а не база развёртывания: RFC 5414
RFC 5414 описывает WiCoP для централизованного управления и подготовки крупных WLAN. RFC Editor относит документ к Historic и указывает RFC 5415 как последующую CAPWAP-опору. Поэтому доступный контроллер или подтверждение конфигурации не доказывают актуальную авторизацию…
IETF
Безопасность SLAPP — историческая граница, а не доказательство развёртывания
RFC 5413 фиксирует Secure Light Access Point Protocol в виде, представленном работе CAPWAP. Идеи обнаружения, аутентификации и защищённого транспорта полезны как историческое свидетельство, но RFC Editor опубликовал документ для исторической записи и не рекомендует использовать…
IETF
LWAPP — историческая запись, а не основа развёртывания
RFC 5412 фиксирует Lightweight Access Point Protocol в том виде, в каком он был представлен работе CAPWAP. Он показывает архитектуру контроллера и лёгких точек доступа, но RFC Editor помечает документ как Historic и прямо запрещает использовать его как основу развёртывания. RFC…
IETF
CATS выбрала контакт сервиса, но рабочий экземпляр остался скрытым: RFC 10053
CATS может направить запрос к подходящему контактному узлу, учитывая состояние сети и вычислительные ресурсы. Но сам выбор не обязательно показывает, какой внутренний экземпляр обработает запрос и описывают ли опубликованные метрики только его.
IETF
Руководство по SIP — это карта, а не сертификат развёртывания
RFC 5411 делает обширное семейство SIP обозримым: группирует спецификации по темам, показывает статус документов и ведёт к связанным работам. Но это информационный снимок, привязанный к дате, а не живой реестр того, что реально выполняет оператор. Запись может быть…
IETF
Расширение передало сообщение о ключе. Установку ключа оно не доказало.
RFC 5410 добавляет в MIKEY расширение для OMA BCAST 1.0. Оно переносит STKM, LTKM, отчёт LTKM и сообщения родительского контроля. Полученный Type 5 подтверждает формат, но не установку ключа, активацию контекста или разрешённое воспроизведение.
IETF
CMS упаковал ключ, но идентичность получателя всё равно должна совпасть
RFC 5409 описывает BF и BB1 в CMS: они шифруют ключ содержимого, задают кодирование идентичности получателя и OID алгоритма. Открытый конверт не является разрешением на действие.
Доступ для участников
Закрытая аналитика профиля
Войдите, чтобы открыть полные профили и углублённые разделы.
Брифинг Стратегического сообщества
Вступите и войдите, чтобы открыть стратегические обзоры.
Вступить в Стратегическое сообществоОбзор Альянса лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров