Кратко

  • draft-ietf-radext-connectinfo-00 задаёт ABNF для скоростей, RSSI, потерь, повторов, Global Operating Class и агрегирования в RADIUS Connect-Info. Стандартной становится форма утверждения NAS, а не физический способ измерения.
  • Мгновенное значение Access-Request и итог интервала Accounting-Request нельзя считать взаимозаменяемыми. Вместе с числом нужны тип сообщения, выборка, алгоритм, окно, вес и период.
  • RADIUS/TLS защищает доставку и подлинность стороны, но не истинность измерения, межвендорную сравнимость, допустимость цели, правильность политики, применение и пользовательский результат.

Одно окно содержит разные виды сжатия

Максимальная скорость говорит, что некоторый пик был достигнут хотя бы раз. Средний RSSI сглаживает изменения. Накопленная доля потерь объединяет счётчики. Если оставить только числа и время начала и конца, появится иллюзия, что они одинаково описывают десять минут связи.

Текущий проект RADEXT, его версии HTML и XML формализуют строки Connect-Info. RFC 2869 определил этот атрибут RADIUS под номером 77 и рекомендовал начинать со скорости соединения. Реализации Wi-Fi затем добавляли поколение 802.11, сигнал и канал в разных позиционных форматах.

ABNF называет TxBitRate, RxBitRate, RSSI, FrameLoss, FrameRetry и Global-OC. Она описывает MIN, MAX, AVG-LIN, AVG-EXP, ACC, окна в секундах и минутах, а для экспоненциального среднего — вес и необязательный период выборки. Это позволяет серверу не угадывать назначение каждого фрагмента.

Но сервер не видит, какие кадры отобрал драйвер, как были объединены радиоцепи и ссылки, когда обнулился счётчик и насколько свежим был показатель. RFC 6158 предостерегает от сложных типов данных, если возможны альтернативы. Проект объясняет, что формализует уже широко применяемую сложную строку. Совместимость с наследием не равна метрологической проверке.

Access-Request ещё не располагает историей

В начале подключения у NAS может быть всего несколько кадров. Поэтому скорости и RSSI в Access-Request могут быть мгновенными, а AGGR в таком случае следует исключить. Для Accounting-Request рекомендации иные: максимум для скоростей, среднее для RSSI, накопление для потерь и повторов.

Мгновенные 600 Mbps и максимум 600 Mbps за десять минут совпадают как строки, но не как доказательства. Первый может предшествовать помехе, второй может быть единственным удачным кадром. Ни один не доказывает устойчивую пропускную способность приложения. Хранилище, удалившее контекст, само создаёт ложную сопоставимость.

Для RSSI допускаются 41 и -41, оба означают -41 dBm. Это снимает различие между исторической абсолютной и знаковой записью. Оно не выравнивает антенны, частоту выборки, округление, усреднение и калибровку разных устройств.

Номер канала после появления 6 GHz тоже не всегда однозначно задаёт диапазон. Global Operating Class добавляет контекст и может повторяться при multi-link operation. Если посредник сохраняет только одно повторение, синтаксис остаётся верным, а описание станции — нет.

Расширяемость требует права сказать «не знаю»

Грамматика допускает будущие неизвестные ключи. Старый приёмник может сохранить атрибут, а не отвергать его полностью. Однако неизвестному ключу всё ещё нужны единица, кратность, область выборки, правила агрегирования и версия определения. Состояние «валидно, но семантика не согласована» должно быть наблюдаемым. Иначе обновление парсера незаметно меняет политику доступа.

Полная цепочка начинается с радиомодуля или драйвера. Он наблюдает кадры; реализация отбирает выборку; алгоритм преобразует её; NAS заявляет результат в конкретном сообщении. Транспорт доставляет утверждение; сервер разбирает и нормализует. Затем организация проверяет допустимую цель, правило выдаёт решение, сеть применяет его. Радиорезультат и работа приложения возникают позже.

Ни одно раннее подтверждение не может подписаться за позднее. Успешный парсинг не доказывает свежую выборку. Access-Accept не доказывает применение к нужной сессии. Ассоциация станции не доказывает пригодность голоса, видео или данных.

Защищённый транспорт сохраняет и ошибку

Проект рекомендует передавать Connect-Info только по безопасному каналу, например RADIUS поверх TLS. RFC 6614 задаёт RADIUS/TLS, RFC 7360 — RADIUS/DTLS. Они аутентифицируют стороны и защищают конфиденциальность и целостность в пути. Они не распознают устаревший RSSI и не исправляют неправильную выборку.

В роуминге NAS может принадлежать Access Network Provider, а учётные данные и авторизация — стороннему Identity Provider. Проект допускает использование Connect-Info как помощи в решении, но не определяет технику авторизации. Пороги, история и производные показатели остаются локальными примерами.

Поэтому соглашение о взаимодействии должно определить поля, метод измерения и агрегирования, цель, срок, раскрытие и поведение с неизвестными ключами. Сертификат доказывает, кто отправил сообщение, но не что он обещал измерить и что получатель вправе сделать.

Радиопоказатель способен стать маршрутом человека

Версия рабочей группы выделяет приватность в отдельный раздел и использует термины RFC 6973. RSSI вместе с известными координатами точек доступа может показать присутствие, близость и движение. Связь с постоянной учётной записью создаёт идентифицируемую историю, даже если в атрибуте нет имени или MAC-адреса.

Проект рекомендует минимизацию, недолгое хранение и отказ от связи с постоянными идентификаторами. Он явно не задаёт уведомление пользователя или получение согласия; эти вопросы оставлены политике оператора и применимому праву. Правильная строка не легитимирует цель, срок и вторичное использование.

Минимизация должна работать как срок удаления, разделение идентичности, журнал объединений и контроль по цели. Общее выражение «операционная потребность» не ограничит будущую аналитику.

При принятии рабочей группой исчезло утверждение о масштабе

Замороженные API Datatracker, страница документа и история фиксируют редакцию 00 от 24 сентября 2026 года как активный Internet-Draft RADEXT. Заголовок указывает Informational, но ответственного AD, shepherd и telechat нет, отображаемый intended RFC status равен null. Это не RFC.

Предшественник draft-grayson-connectinfo-10 содержал ненормативный раздел о прототипе и 17 тысячах точек доступа. Рабочая версия удалила его, разделила безопасность и приватность, добавила безопасный канал, политику взаимодействия, минимизацию, unlinkability и границу согласия. Удаление не доказывает отсутствия прежнего внедрения, но текущий текст не подтверждает им масштаб или совместимость.

Источники и пределы вывода

Использованы текущие TXT, HTML, XML, API, статус и история, в сравнении с предшественником. Контекст дают RFC 2869, RFC 6158, RFC 6614, RFC 7360, RFC 6973. Источники не дают текущего масштаба внедрения, калибровки поставщиков, точности авторизации, юридического заключения или измерения пользовательского опыта.