On 12/16/2024 11:46 PM, Jeff Johnson wrote:
On 12/16/2024 2:54 AM, Johannes Berg wrote:
On Fri, 2024-12-13 at 12:11 -0800, Jeff Johnson wrote:
On 12/13/2024 4:16 AM, Johannes Berg wrote:
On Fri, 2024-12-13 at 17:41 +0530, Veerendranath Jakkam wrote:
Update 6 GHz regulatory info subfield mask and Indoor AFC standard power
type definitions to align with spec changes introduced in the Draft
P802.11Revme_D4.2, Figure 9-896 and Table E-13.
Huh. That seems like a change explicitly *designed* to break backward
compatibility? Should we accept the old value from older APs or so?
Otherwise we can't connect in some scenarios, I think?
Or at least should we say here in the commit message or so why backward
compatibility was broken, and that it was for other clients that didn't
behave well or something but our code was already fine?
Or am I completely confused about it?
IEEE Drafts sometimes make non-backward-compatible changes.
Umm. Me voicing confusion isn't a reason to state obvious things back to
me as if that explained anything at all?
In any case, they actually do that _very_ rarely (these days at least,
that was different 20 years ago I'd say) without taking existing
deployed things into account though.
This change brings
us up to date with the language in Draft 7.0 that was ratified and will be
published as IEEE 802.11be-2024.>
That's not what this claimed in the commit log.
You are correct. When writing my response I referenced IEEE 802.11be Draft 7.0
when I meant to reference P802.11Revme_D7.0 (since that is the latest Revme)
I've been so focused on 11be that I completely messed up the reference.
It also _cannot_ be correct since this stuff is in baseline as far as
802.11be is concerned, so it really cannot make incompatible changes
that suddenly make all HE stations non-compliant.
And now that you're forcing me to look into it, I see that of course it
doesn't do that. This has nothing to do with Draft 802.11be in any
version which only makes one simple change to Annex E to add 320 MHz.
The commit log claims that REVme changes it, and while that might be
true, looking at REVme (I don't have a redline version at hand right
now) indicates that certainly it didn't make it backward incompatible,
it now accepts multiple values and accepts the old values.
So if anything breaks, it is because it
hasn't been updated from the draft to the ratified standard.
Clearly not.
Suggest you go back to the drawing board with these changes.
Veerendranath, can you follow up on this part.
/jeff
Thanks Johannes and Jeff for the comments.
As per my understanding, if client supports reading the 4th bit of
regulatory info sub-field (i.e, dot11ExtendedRegInfoSupport is true) in
HE Operation Element. it needs to use the values from "Table E-13,
P802.11Revme_D7.0". I didn't keep the value 4 definition as it is
reserved currently in "Table E-13" .
If we need to support both "Table E-12" (applicable when
dot11ExtendedRegInfoSupport is not true) and "Table E-13" (applicable
when dot11ExtendedRegInfoSupport is true) with same client, then I think
value "12" also should be considered as Indoor AFC standard power type
as per "Table E-12". So, we need to map to 4, 8 and 12 to Indoor AFC
standard power type. Please let me know if this is fine.
