> This is admittedly a bit strange design with that special case needed > for SAE. If we were to design the SAE case now in combination with > FILS, I guess this would be quite different (e.g., separate > attributes for Authentication transaction sequence number and Status > code). Unlike the mesh use case with SAE, FILS is only between an AP > and a station and as such, there would not really be a case where the > station would send an Authentication frame with non-zero Status code. > > A future amendment might define a new authentication algorithm that > ends up using more than a single Authentication frame exchange. In > such a case, we would actually have need for Authentication > transaction sequence number even though FILS doesn't need it. > > I think I'd rather maintain a consistent attribute design for all > authentication algorithms and leave this as-is now. Another option > would be to not apply the rename SAE attributes patch and define > something new as a more generic solution, but I'm not sure there is > sufficient justification for the added complexity since we cannot > really get rid of the current SAE design any time soon. Yes, fair point. Maybe you can clarify the nl80211 attribute documentation wrt. this? It just states that it starts with the Authentication transaction sequence field, but afaict that's not true, it also has the status code field, which is also ignored here. johannes
