Summary

  • draft-ietf-radext-connectinfo-00 defines ABNF for Wi-Fi values carried in RADIUS Connect-Info, including bit rates, RSSI, frame loss, retries, Global Operating Class and aggregation metadata. It standardizes how a NAS can state a result; it does not validate how the result was measured.
  • Access-Request snapshots and Accounting-Request summaries are different evidence. A bare number can represent an instantaneous observation, a maximum, an average or an accumulated ratio over a window, so policy must preserve message context and aggregation semantics.
  • RADIUS/TLS can protect transport, but not measurement truth, cross-vendor comparability, lawful purpose, authorization quality, enforcement or user experience. Each of those needs its own receipt.

A clean parse is the start of the inquiry

Imagine a roaming user whose credential is authenticated by an Identity Provider while the access point belongs to another operator. The RADIUS server receives CONNECT, a rate and an RSSI from the Network Access Server. Its parser accepts the attribute. A rule compares the values with a threshold and returns an authorization response. In many operating consoles that sequence collapses into one green event: network quality was checked.

The new RADEXT Working Group draft is more modest and more useful. Its HTML and XML define grammar for a field that already exists. RFC 2869 assigned Connect-Info as RADIUS attribute 77 and recommended beginning with connection speed. Wi-Fi implementations subsequently produced strings such as CONNECT 54Mbps 802.11g, sometimes followed by slash-delimited signal and channel data. The draft gives those practices an ABNF and adds named key-value forms.

That is a genuine interoperability improvement. A receiver can distinguish TxBitRate, RxBitRate, RSSI, FrameLoss, FrameRetry and Global-OC. It can recognize an aggregation annotation rather than guessing whether a number describes one frame or a session. Yet grammar cannot look backward through a device and see which frames its firmware sampled. It cannot establish antenna calibration, decide how a multi-link station apportioned traffic or prove that a counter was fresh. The parser has verified a statement's shape, not the world that the statement describes.

This distinction matters because the field is a complex data type inside a RADIUS string. RFC 6158 warns about complex attribute encodings when viable alternatives exist. The draft argues that it is formalizing and extending a widely used existing format rather than inventing another one. That historical constraint explains the compatibility work. It does not turn compatibility into measurement assurance.

The same number can describe a moment, a window or a policy fiction

The draft allows several aggregation algorithms: minimum, maximum, linear average, exponential average and accumulation. A window can be expressed in seconds or minutes. Exponential averaging can also carry a weight and an optional sample period. Those annotations are not decorative. They decide what population a policy engine is comparing.

At association time, an Access-Request may have very few frames available. The draft therefore says transmit rate, receive rate and RSSI may be instantaneous; if a value is instantaneous, the aggregation definition should not be present. An Accounting-Request summarizing an interval has another job. The draft recommends maxima for transmit and receive rates, an average for RSSI, and accumulated measures for frame-loss and retry ratios.

Suppose one authorization record contains instantaneous TxBitRate:600Mbps, while yesterday's baseline contains a ten-minute maximum of 600 Mbps. The numbers match and the evidence does not. Neither proves that the station sustained 600 Mbps. A maximum may describe one short modulation event; an instantaneous observation may precede congestion, roaming or power-saving behavior. A dashboard that drops the message type, window and aggregation token manufactures comparability after the fact.

RSSI carries a second compatibility trap. The ABNF accepts both 41 and -41 to mean -41 dBm because legacy implementations used absolute and signed forms. Normalizing the sign is appropriate. Treating the normalized value as calibrated across radios is not. Two vendors can truthfully emit -41 dBm while using different sampling cadence, chain selection, averaging, antenna gain treatment or rounding. Syntax eliminates one ambiguity and leaves the physical ones intact.

Channel information shows the same pattern. A channel number no longer uniquely names a band once 6 GHz overlaps earlier numbering. Global Operating Class supplies regulatory and channel context, and the key can repeat for multi-link operation. A downstream warehouse that keeps only one value may parse every character successfully and still destroy the fact that several links were involved.

Extensibility creates a negotiation duty

The grammar contains an extensible key-value alternative for future parameters. That prevents an old parser from failing merely because a new name appears. It does not make the new name interoperable. A receiver still needs a definition, unit, allowed multiplicity, sampling scope, aggregation rules and version boundary. “Unknown but syntactically valid” should be an observable state, not an invitation to feed the value into a score.

This is where the authority chain becomes visible. First a radio or driver samples physical events. An implementation selects frames and links. An aggregation rule transforms them. A NAS asserts the result in a particular RADIUS message. A transport carries it. A server parses and normalizes it. Only then can institutional policy decide whether it may be used and how much weight it deserves. Authorization follows, enforcement follows that, and the user's radio and application outcomes come later still.

Each transition needs its own receipt. A successful parse cannot testify for the sample. A successful policy evaluation cannot testify for enforcement. A successful association cannot testify for usable video, voice or data. The evidence chain is useful precisely because its links are not interchangeable.

Secure transport protects the envelope, not the assertion

The Working Group revision recommends that Connect-Info travel only over secure channels, giving RADIUS secured with TLS as an example. RFC 6614 specifies RADIUS over TLS, and RFC 7360 specifies RADIUS over DTLS. Those transports can authenticate peers and protect the message against interception or alteration on the path. They cannot tell whether the access point reported a stale RSSI, whether its driver miscounted retries or whether an operator selected the wrong metric for admission.

The same boundary applies to federation. The draft describes an Access Network Provider sending metrics to a third-party Identity Provider so the latter can assist an authorization decision. It does not define that decision technique. Thresholds, historical records and derived metrics are examples. No shared rule establishes that -70 dBm has the same operational meaning across venues, hardware or use cases. Secure carriage makes a statement attributable to a peer; it does not make the statement a verdict.

Operators therefore need more than certificates. They need an interconnection agreement that says which parameters can cross the boundary, for what purpose, with what sampling and aggregation definitions, how unknown keys are handled, how long records survive and who can disclose them. They also need live checks that the agreed transport is actually in use. A policy PDF and a TLS label are different evidence.

RSSI can become a movement record without changing its syntax

The adoption revision gives privacy its own section and uses the terminology of RFC 6973. RSSI looks like network-operational data. Correlate it with known access-point locations and a persistent account identifier, however, and it can reveal presence, proximity or movement. The attribute need not contain a username or MAC address to participate in an identifying record.

The draft recommends data minimization and avoiding linkage to persistent identifiers. It also states a critical scope limit: it does not define a mechanism to inform users or obtain consent. Notice and consent, where required, belong to operator policy and applicable law. A standards-conforming string can therefore be collected under an illegitimate purpose, retained too long or joined to a history the user never expected.

This is not an argument against the metric. It is an argument for retaining the authorization context around the metric's use. A defensible record should say why the value was collected, which policy version permitted the use, which identity boundary applied, how long it may remain and whether the raw value was later reused for analytics. Minimization must be executable as retention and linkage controls, not merely described in prose.

Adoption removed a deployment claim and strengthened the boundary

The frozen Datatracker API, status page and history record revision 00 as an active RADEXT Working Group Internet-Draft dated 24 September 2026. The header says Informational; the Datatracker shows no responsible Area Director, shepherd or telechat, and its displayed intended RFC status is null. It is work in progress, not an RFC.

The predecessor, draft-grayson-connectinfo-10, included a non-normative section naming a proof of concept and a 17,000-access-point deployment. The Working Group revision removed that section. It retained the mechanism while splitting security from privacy, adding secure-channel and interconnection-policy recommendations, and expanding minimization, unlinkability and consent boundaries. The deletion does not prove that the implementation vanished. It means the current document no longer offers the deployment paragraph as evidence. Adoption should not be converted into a deployment census that the adopted text chose not to carry.

Sources and limits

The technical basis is the current draft text, HTML and XML, bounded by the Datatracker API, document page and history, and compared with the predecessor revision. RADIUS context comes from RFC 2869, RFC 6158, RFC 6614, RFC 7360 and the privacy framework in RFC 6973. These sources do not provide a current deployment count, vendor comparison, calibration study, authorization accuracy result, legal opinion or application-experience measurement.