摘要

  • draft-ietf-radext-connectinfo-00 用 ABNF 规范 RADIUS Connect-Info 中的收发速率、RSSI、丢帧、重试、Global Operating Class 与聚合信息。它让 NAS 的陈述可以被一致读取，却不验证无线样本本身。
  • Access-Request 的瞬时值与 Accounting-Request 的区间汇总属于不同证据。必须连同消息类型、样本范围、算法、窗口、权重与采样周期保存，才能避免把同单位的不同事实混为一谈。
  • RADIUS/TLS 能保护传输中的完整性与机密性，不能证明测量准确、用途合法、策略合理、执行到位或体验良好。每个环节都需要自己的回执。

同一个信道号可以落在不同现实里

旧式 Connect-Info 字符串常把连接速率、802.11 代际、RSSI 与信道依次塞进一个字段。RFC 2869 定义了 RADIUS 属性 77，并建议把连接速率放在开头。多年实现积累以后，接收端往往依靠位置和供应商习惯解释剩余数字。

新的 RADEXT 工作组草案文本 以及对应的 HTML 和 XML 为这些内容定义 ABNF。命名字段包括 TxBitRate、RxBitRate、RSSI、FrameLoss、FrameRetry 和 Global-OC。这一步把“第几个斜杠后的数字”变成有名字的参数，是实质性的互操作改进。

信道案例同时说明改进的边界。随着 6 GHz 使用与旧频段发生号码重叠，CHANNUM 不再足以唯一确定频率。Global Operating Class 补上监管域与信道组合的上下文，还可以为 multi-link operation 重复出现。如果中间系统只保留一个 Global-OC，字符串仍然通过语法检查，多链路事实却已经丢失。

RFC 6158 对 RADIUS 中复杂数据类型保持谨慎。草案的理由是：这里不是新造复杂类型，而是把广泛存在的格式正式化并扩展。这个历史判断有助于兼容部署；它不能替代测量定义、固件行为或跨厂商校准。

聚合算法是事实的一部分，不是显示选项

草案支持 MIN、MAX、AVG-LIN、AVG-EXP 和 ACC，窗口可以用秒或分钟表示，指数平均还可以携带权重与可选采样周期。一个数字在这些变换前后可能完全相同，但证据含义不同。

Access-Request 通常发生在连接早期，可供计算的 802.11 帧很少。草案因此允许 Tx/Rx 速率和 RSSI 是瞬时值；报告瞬时值时不应带 AGGR。Accounting-Request 总结一段会话时则建议：速率用最大值，RSSI 用平均值，丢帧和重试比例用累计。

于是 600 Mbps 至少可能表示三种东西：刚好观察到的一帧、十分钟内出现过一次的峰值，或者数据库丢失聚合标记后留下的裸数。它们单位相同，却不能直接比较，更不能自动推出吞吐或应用质量。把消息类型、窗口和算法拆掉，再画成一条趋势线，是数据系统制造的新结论，不是无线网络提供的证据。

RSSI 还有兼容表示问题。草案接受 41 和 -41，两者都解释为 -41 dBm。这能统一旧实现的绝对值与有符号写法，但不会统一天线链选择、采样节奏、平均方式、校准误差或舍入规则。解析器修正了符号，不能顺便给无线电做校准。

未知键可以通过语法，却不能直接进入评分

ABNF 留有可扩展的键值形式，让未来参数不至于导致整条属性被拒绝。这是良好的演进设计。不过一个未知键即使字符合法，也仍缺少单位、重复规则、采样对象、聚合语义和版本承诺。接收端应把“语法有效但语义未知”作为显式状态，而不是悄悄投进质量分数。

完整链条比字段更长。无线硬件或驱动先观察帧；实现选择哪些帧、链路和方向进入样本；算法做聚合；NAS 在特定 RADIUS 消息里作出陈述；传输把陈述送到服务器；服务器解析并归一化；制度规则判断能否使用；策略作出授权决定；接入网络执行；最后才有真实无线状态和应用体验。

这些箭头不能互相代签。语法成功不能证明样本新鲜。策略引擎返回 Access-Accept 不能证明正确会话已执行。终端完成关联也不能证明语音、视频或数据在目标时段可用。最有价值的系统不是把步骤压成一个绿色图标，而是给每一步留下可核对的回执。

TLS 保护的是封装，不是无线事实

工作组版本建议 Connect-Info 只通过安全信道传送，并以 RADIUS/TLS 为例。RFC 6614 定义 RADIUS over TLS，RFC 7360 定义 RADIUS over DTLS。它们可以认证通信对端，保护路径上的机密性和完整性。但一个被 TLS 完整保护的旧 RSSI 仍然是旧的；一个由错误驱动统计出的重试率不会因加密而变真。

草案讨论 Access Network Provider 与第三方 Identity Provider 的场景：前者运行 NAS，后者认证凭证并利用 Connect-Info 协助授权。关键动词是“协助”。草案没有规定授权技术，阈值、历史数据和派生指标只是可能做法，不是经过验证的统一规则。

因此跨域关系不仅需要证书，还需要互联政策：哪些参数可以交换，采样和聚合如何定义，未知键如何处理，允许什么目的，保留多久，谁能再披露。如果一方只证明 TLS 建立成功，另一方只证明策略运行成功，两份回执之间仍可能缺失语义与权限。

RSSI 不带姓名，也可能形成行动轨迹

工作组 00 版把隐私单独成节，并采用 RFC 6973 的术语。RSSI 看似网络运维数据，但与已知 AP 位置、时间和持久账号关联后，可以推断某人的出现、接近或移动。属性本身不包含用户名或 MAC 地址，并不妨碍它参与识别。

草案建议数据最小化、只传输必要指标、避免保留过久，也建议不要把 RSSI 与持久用户标识关联。它还明确说，没有定义向终端用户告知或取得同意的机制；是否需要由运营政策和适用法律决定。这意味着一条完全合规的语法仍可能被用于不合适目的，或被保留得远超原始会话。

真正的最小化必须落在系统上：到期自动删除、身份与遥测分隔、联合查询留痕、用途版本绑定、二次分析重新授权。只在协议或合同里写“用于运营”，无法约束未来把无线痕迹变成跨场所历史。

工作组采纳时删除了具名部署段落

冻结的 Datatracker API、文档页 与历史页 显示，00 版是 2026 年 9 月 24 日提交的 RADEXT 活跃工作组 Internet-Draft。页眉写 Intended status: Informational，但 Datatracker 没有负责 AD、shepherd 或 telechat，所显示的目标 RFC 状态为 null。它还不是 RFC。

前身 draft-grayson-connectinfo-10 曾有一段非规范性实现说明，提到概念验证与 17,000 个接入点。工作组 00 版删除了这一节，同时把安全与隐私分开，新增安全信道、互联政策、数据最小化、不可关联性以及告知/同意范围边界。删除不等于否认旧部署；它意味着现行工作组文本不再以该数字支撑当前状态，不能把“被采纳”夸大为部署普查或互操作认证。

来源与结论边界

技术依据是现行 TXT、HTML、XML，由 API、状态页 和历史页限定版本，并与前身 10 版比较。RADIUS 与隐私背景来自 RFC 2869、RFC 6158、RFC 6614、RFC 7360 和 RFC 6973。这些材料没有提供当前部署数量、厂商校准对比、授权准确率、法律意见或应用体验测量。