Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
The purpose of OCVC was to verify that an ongoing exchange was taking place on the channel that both parties believed to be the same
Given that for MLO, the exchanges take place on the same link, existing OCVC procedures will work as specified in the baseline. There is no need to include link ID information in the OCI KDE.
Furthermore, the requested links provided in the reassociation request, and the links advertised links included beacons and probe responses are both validated as part of the 4-way handshake.
Hello all,I took a second look at the following comments on OCVC, which were deferred (see bottom if email)The purpose of OCVC was to verify that an ongoing exchange was taking place on the channel that both parties believed to be the same. Given that for MLO, the exchanges take place on the same link, existing OCVC procedures will work as specified in the baseline. There is no need to include link ID information in the OCI KDE.Furthermore, the requested links provided in the reassociation request, and the links advertised links included beacons and probe responses are both validated as part of the 4-way handshake.I'm inclined to reject these CIDs unless somebody can provide some explanation on what the problem is and why providing operating channel information for links addresses the issue.Thanks,MikeComment
CID
Clause
Page
Line
Comment
Proposed Change
11071
12.7.6.1
355
45
The description implies that OCI KDE can be used for MLO. However, OCI KDE needs to be redesigned to include link ID and information for 320 MHz verification because 320 MHz may have 320 MHz-1 or 320 MHz-2.
Define MLO OCI KDE. Ideally, follow the format of OCI KDE to include link ID and change "Frequency Segment 1
Channel Number" to simply "Channel center frequeny of 320 MHz", which is set to channel center frequency of 320 MHz when 320 MHz is used and 0 otherwise.10678
12.7.6.3
358
46
For MLO, OCI verification should occur on all the links. Will need to make sure OCI works correctly for MLO. e.g., we should include the OCI KDE for each requested link in msg 2 for the AP MLD to verify the operating channels of the STAs corresponding to the requested links
As in the comment
10679
12.7.6.4
361
11
For MLO, OCI verification should occur on all the links. Will need to make sure OCI works correctly for MLO. e.g., we should include the OCI KDE for each requested link in msg 3 for the non-AP MLD to verify the operating channels of the APs corresponding to the requested links
As in the comment
14100
12.7.2
351
5
OCI KDE should have a corresponding MLO KDE defined because RNR in ML probe response is not protected
As in comment
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature