Jay, all, (NOT as chair, but my individual opinion …) I know that I haven’t been very active in this discussion (apologies – too much stuff going on). However, I find abandoning any identification of an MLD device while it is pre-association to be too much loss of functionality to support. This would eliminate: - Pre-association client steering
- Which is extremely useful in enterprise and large venue installations
- Customer support and troubleshooting
- We are going to extreme lengths to solve the WPA3-Personal transition problems (yes, I know, that’s in WFA, but IEEE is talking about it, also) to help providers with support call overload, but we’re going to shoot ourselves in the foot by bringing back complete opaqueness in helping resolve “I can’t connect” issues?
- Virtual BSSID
- This is catching on as a very powerful tool in “multi-tenant” situations.
- We could solve it by requiring an associated non-AP STA to use its same address (TA?) when scanning/probing for AP-AP handoffs, but I suspect the client devices are not going to want to do probes differently depending on context.
These are several of the important advantages that IRM has. We are balancing between two facilities (IRM and Device ID), each has its advantages and tradeoffs, making each useful in different scenarios. If we remove all pre-association support from IRM, in my opinion, we might as well remove IRM. It seems to me that rather than sort out how MAC addresses will be used for MLD devices, we are just “punting” and giving up on trying to solve the problem(s). I would vote “no” on this direction. Mark From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, 7 May, 2024 9:10
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD Hi Jay,
Thanks for producing this document. It looks good to me.
Hi All, For 24/305, I received new comments from some members to say, as for the MAC address, the MLD MAC address rather than link MAC address is unique to identify each non-AP MLD. Based on that, in the latest revision 24/305r5, I change the place of IRM from TA field to ML element. Because some frames, like probe request, public action frame don't include ML element according to 11be baseline. I have to drop the relevent use cases in MLO subclause (Maybe these use case are not very strong in MLO senario) . That's, non-AP MLD may set IRM in MLD MAC address field in basic ML element in authentication and association frame. Besides, I have some offline checked with 11bh group members and the Chair Mark, they confirmed that the Reassocation case is out of 11bh scope, and 11bh group intends to git rid of them after initial SA ballot. To keep this align with the on-going 11bh draft, I change (Re)association to Association in all occurrences in new subclause . This is all the change compared with 305r4 that we are ageed with, Welcome futher comments or thought on this. Hi Alfred, Could you help put 24/305r5 (https://mentor.ieee.org/802.11/dcn/24/11-24-0305-05-00be-cr-for-rcm-relevant-cids.docx ) to the MAC queue in F2F meeting? Thanks Best Regards Jay Yang (杨志杰)
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |