WBA/IETF Connect-Info Implementation under way

[Joey Padden]

Alan and Jouni, 

If you’d rather see a VSA, do you have thoughts on which parameters you’d want in Connect-Info and which you’d want moved to a VSA? 

WBA has a Vendor-ID and has some precedence for defining VSAs. So this path can be explored further. 

The current set of metrics Wi-Fi roaming operators are asking for is:

•	Connect Speed
•	Wi-Fi Standard
•	Channel
•	Band
•	RSSI
•	RSSI Minimum
•	Noise Level
•	Channel Utilization
•	TxBitRate
•	RxBitRate
•	Frame Loss
•	Frame Retry
•	Backhaul Downlink Throughput
• 	Backhaul Uplink Throughput
•	Backhaul Latency
•	STA count connected to radio

Do you have a format you’d rather see that is more parsable? I think Mark and Josh chose ABNF syntax as it’s defined and standard. Would you two be advocates for multiple VSAs, one for each parameter or for a similar ABNF syntax just not in Connect-Info? 

BR,
-Joey


> On Oct 7, 2025, at 7:55 AM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Oct 6, 2025, at 5:13 PM, Jouni Malinen <j at w1.fi> wrote:
>> It is quite a bit more difficult understand why the Connect-Info
>> attribute would be an appropriate location overall channel conditions
>> like RSSI and noise and even some of the per-device specific items like
>> TxBitRate/RxBitRate to report TX/RX rate of a single frame (and also
>> noting that TX retries of a single frame might use different rates)
> 
>  Connect-Info is not really an appropriate place for this information.  Among other things, it violates the RFC 6158 prohibitions on packing complex data into one attribute.
> 
>  That being said, this format is supported by the WBA, and has been implemented.  There's an IETF draft for it, which is likely to be accepted by RADEXT as a working group document.
> 
>> do
>> not feel like something I would add into this RADIUS attribute. If you
>> are planning to contribute support for those, I'd suggest leaving those
>> to the end of the set of patches since the likelihood of getting those
>> accepted is quite a bit smaller than the items that I can understand
>> making sense in this particular RADIUS attribute.
> 
>  I would strongly support VSAs for this data.  It is significantly easier to manage each field when the data is broken out into individual RADIUS attributes.  In contrast, parsing a complex string is difficult and error-prone.  The format as defined does not lend itself to easy parsing.
> 
>  I suspect that this proposal will at least become an informational RFC.  But having VSAs in addition to the Connect-Info string format would be very positive.  Doing that would also allow any RADIUS server to construct the Connect-Info from the VSA values.
> 
>  Alan DeKok.
>