| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Jay and Mike – thank you for this. I started a detailed review – see attached, where I provided some editorial corrections in the definitions clause. During my review it became clear to me that there is a potential critical issue exposed by the proposed changes.
It is my understanding that while the MAC (both upper and lower MAC for an MLD) use the MAC address or any other ID, the MAC does not control or set the MAC address. The MAC address is set/controlled by the SME. So, statements on MLD behavior regarding setting or changing a MAC address should not state that the MLD is doing it, the SME and entities beyond the STA, AP, or MLD is setting or changing the MAC address. The MLDs, affiliated APs, or affiliated AP are supporting the ability. This is also true regarding the IDs (IRM or device ID). The STA, affiliated STA, or affiliated AP may receive or transmit the MAC address or ID, the MLD which is a MAC/PHY logical entity does not it relies on the MLD MAC address in the MLD element. Hence, I think the phrase “AP MLD” should be changed to “affiliated AP” and “non-AP MLD” to “affiliated STA” in most locations in this proposed comment resolution document. I didn’t want to do all the work to update the proposed resolutions until there was agreement that this change should be done.
Note the careful wording of the original clause “To mitigate this sort of traffic analysis a STA can support the ability to periodically and randomly change its MAC addresses and reset counters and seeds prior to association.” The wording states “a STA can support” the STA MAC is not changing these things it is only supporting the SME’s ability to change things. The SME is not wholly contained in the STA and the higher layers providing the management of the MAC address are possibly outside of the SME.
This proposed change impacts the proposed changes throughout this resolution document.
Also, I believe that if the proposed change is in conflict with existing text in the TGbe draft, the conflicting text in the current draft should also be corrected, because if we agree this is the correct way to proceed then the existing text it is technically incorrect.
Regards,
Joseph
From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Thursday, June 6, 2024 2:36 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBH] 24/305r7-- the proposed text for 11bh feature extension for MLO
Hi Mike,
Thanks for the comments, your proposal is merged into the NEW Note5 in the attached document.
Also, I clean up the mess up traces to make the document looks better, please help review it.
Thanks
Best Regards
Jay Yang (杨志杰)
Original
From: MMontemurro <montemurro.michael@xxxxxxxxx>
Date: 2024年06月06日 01:11
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBH] 24/305r7-- the proposed text for 11bh feature extension for MLO
Hi Jay,
Thanks for the updated document. In principle I do not have issues of adding text for 1) and 2). However I don't believe all the text for 1 is required and duplicates requirements in 12.2.12.1.
If an MLD that uses IRM leaves a network and comes back as a STA, it would follow the procedures in 12.2.12.1. Otherwise it follows the requirements in 12.2.12.2.
I would say that adding the following note is sufficient:
NOTE -- When a non-AP MLD using IRM connects to an AP as a non-AP STA, it follows the procedures defined in 12.2.12.1. Similarly, when a non-AP STA using IRM connects to an AP MLD, it follows the procedures defined in 12.2.12.2.
This note would replace all of the text between NOTE 4 and NOTE 5 in your contribution.
I don't think NOTE 5 is needed at all and is actually bad practice for privacy, but I'll let it go for now.
Cheers,
Mike
Cheers,
Mike
On Wed, Jun 5, 2024 at 12:45 PM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:
[+ TGbe reflector]
On Tue, Jun 4, 2024 at 8:09 PM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:
Hi TGbe , TGbh memebers ,
I'm still working on the task to extend 11bh feature for MLO , please help review the latest proposed text(https://mentor.ieee.org/802.11/dcn/24/11-24-0305-07-00be-cr-for-rcm-relevant-cids.docx). In order to meet 11be timeline and Wi-Fi industry timeline requirement , it's great appreciated if we could reach consensus in this round.
See the summary of the main change in this revision as bellow:
1) According to Binita's comments in May session, I add the case of the usage of IRM when a non-AP MLD may become a non-AP STA, or vice versa.
2) Add the extension in FILS authentication as MLO FILS authentication was included into 11be draft6.0(also, 11bh draft already define the usage of the two features in FILS authentication in draft4.0).
Welcome further questions and comments.
Thanks
Best Regards
Jay Yang (杨志杰)
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe/TGbn Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
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
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