Брифинг Стратегического сообщества
Вступите и войдите, чтобы открыть стратегические обзоры.
Вступить в Стратегическое сообществоУправление интернетом / IETF
IETF
IETF пишет протоколы, на которых работает любая сеть. Мы следим за черновиками, спорами в рабочих группах и опубликованными стандартами и объясняем, что каждый из них меняет для операторов ещё до того, как он попадёт в эксплуатацию.
ГлобальныйУправление протоколамиРиск несовместимости
Последние материалы
Главные материалы: IETF
1 656 статей
IETF
NomCom IETF ищет не просто имена, а согласие работать
Перенос срока на 23 октября дал время на ответ. Но согласиться на рассмотрение — ещё не значит получить должность, а предложить человека — не значит обеспечить его участие.
IETF
Модель прошла проверку, но RFC 10057 всё ещё ожидал одобрения.
Datatracker показывал ноль ошибок и предупреждений при проверке YANG редакции 44. Однако 16 октября RFC-to-be 10057 оставался на финальном рассмотрении: две авторские отметки об одобрении не были выставлены, а кластер мог добавить задержку.
IETF
RFC 10065 стандартизирует идентификатор группы, но не его смысл
Атрибут RADIUS может передать идентификатор группы в политику доступа. RFC 10065 не определяет, кто задаёт состав группы и как её метка связывается с трафиком.
IETF
IESG утвердила новый устав PROCON и перенесла ориентиры на ноябрь и декабрь
IESG утвердила устав, который PROCON направила на рассмотрение в сентябре. Новый график задаёт ноябрь для двух документов по процедурам и декабрь для текста о полномочиях председателя IETF. Это поручение группе, а не немедленное изменение действующих правил.
IETF
Mark Townsley и значение благодарности в RFC 6333 для архитектуры DS-Lite
В краткой благодарности RFC 6333 зафиксирован конкретный вклад Mark Townsley: его замечания об общей архитектуре направили работу в сторону предложения SNAT. На титульной странице указаны четыре других автора. Если сопоставить эти записи с ранними черновиками и распределением…
IETF
Tomek Mrugalski и имя DHCPv6, которое направляет IPv4-туннель к оператору
Ответ DHCPv6 может передать полное доменное имя точки AFTR для Dual-Stack Lite. Устройство B4 разрешает это имя и пытается провести IPv4-трафик через туннель поверх IPv6. Само получение имени не доказывает, что DNS ответил, туннель установился, NAT создал состояние, пакет…
IETF
ECN поверх UDP зависит от сокетного API
RFC 10055 называет себя снимком состояния на момент написания и отдельно предупреждает о возможных последствиях для приватности, если ECN реализован не на всех платформах. Поэтому его полезнее читать как описание воспроизводимых интерфейсных различий, а не как вневременную…
IETF
Кто помнит, как продолжить соединение: Marcelo Bagnulo и состояние сети
В журнале инцидентов часто остается только результат: «соединение разорвано». Но чтобы понять причину, нужно выяснить, у какого узла были сведения, необходимые для следующего действия. Это мог быть хост, потерявший маршрут, транслятор между IPv6 и IPv4 или получатель TCP…
IETF
Проект устава MASQUE сокращает список работ, тогда как Ethernet-драфт остаётся на рассмотрении IESG
В проекте устава MASQUE стало меньше документов, которые рабочая группа должна завершить перед закрытием. Ethernet-драфт, исключённый из этого списка, при этом остаётся в отдельной процедуре публикационного рассмотрения IESG.
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. Для руководителя важно отделять сообщение протокола от реально…
Доступ для участников
Закрытая аналитика профиля
Войдите, чтобы открыть полные профили и углублённые разделы.
Обзор Альянса лидеров
Для владельцев IP-активов и руководителей: обзоры Альянса, закрытые отчёты и прямая поддержка аналитиков.
Вступить в Альянс лидеров