| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Po-kai, I don’t think your so-called technical issue is a real one. In order to go with Option 3, what we need to change is to mandatorily include a Multi-link Link Information element within
the frame body for the link-specific Management frame. In this CR round, I also propose a related comment.
To fully exploit the benefit of the cross-link delivery, it’s better to decouple the generation of the Management frame with the link selection for the transmission. Otherwise, it
will complicate the MAC protocol design. Because in that case, after the MPDU Encryption, the AP MLD shall check each individually addressed MMPDU is link-specific or not. If it is a link-specific, then the AP MLD needs to further check whether a Multi-link
Link Information element is include or not. Thus the AP MLD can select a correct link to transmit this MMPDU.
Is this what you want??? Regards Guogang Huang 发件人: Huang, Po-kai [mailto:po-kai.huang@xxxxxxxxx]
Hi Mike, As I have mentioned in the call, I believe this has been brought up several times in the calls, and technical reasons/discussions are available in the past. I cite the meeting minutes for this discussion
in the past below. https://mentor.ieee.org/802.11/dcn/22/11-22-0754-02-00be-minutes-of-tgbe-2022-may-interim-mac.docx
·
Technical Submissions:
1.
704r1
CR for ML Security for Individually addressed Management Frame Guogang Huang [2C 10]
Discussion:
C: some concerns. link specific information should be used to protect the message. By using MLD address, the link specific information is missing. The change is too
late.
A: link ID is used to indicate the intended link. There should be no security issue.
C: wth link ID in the frme body, there should be no issue. But the inclusion of link ID in the frame body is not mandatory.
C: the proposal is the good method.
C: disagree with the comment. The discussion is wrong. The change is too late.
A: link ID will be always in the frame body.
C: this is not true.
SP: Do you support to accept the resolution in 11-22/704r1 for the following CIDs?
5181 and 5184
23Y, 51N, 30A
Best, Po-kai From: M Montemurro <montemurro.michael@xxxxxxxxx>
Hello all, During the discussion of https://mentor.ieee.org/802.11/dcn/22/11-22-1178-03-00be-tgbe-lb266-security-comment-resolutions.docx,
we did not reach a conclusion of CID 12322. I'd like to initiate a discussion on the reflector to see if there is consensus on a resolution to this CID. In the discussion on this CID, there seemed to be consensus for rejecting the comment. However there was no feedback on a technical reason to reject the comment. Is there someone
who can propose a rejection reason? Thanks, Mike 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 |