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