Hi Jarkko,
Thanks for the comments, see my response inline.
Thanks
Best Regards
Jay Yang
From: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 2023年2月24日 11:02
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] RRCM versus e-RRCM for TGbh motion on Feb 28
-
Are there aspects of e-RRCM that you oppose, and bringing those into the proposal that is put to motion next week would cause you to vote No?
1) RRCM and e-RRCM allow STA to use only MAC addresses that are calculated by using RMAK.
- This limits STA operation flexibility to freely select its MAC address.
àBased on 11aq, each STA calculates its RMA based on one private equation. In e-RRCM, both side calculate the same RMAs based on the pre-defined equation, it’s
easy for implementor to switch from private equation to the pre-defined equation. Anyway, If you have a strong concern on the MAC based solution, we can move it to the IE element. The purpose of the generated RMA is to find the right key on both side in e-RRCM
solution, no matter it’s MAC address or other staff.
2) The use case for pre-association STA identification is not clear to me.
- What benefits does STA get if it identifies itself before association?
àWhen we talk some use cases like use case 4.8 and use case 4.26 etc. in last year, your guys also agree these cases should be addressed and updated them into
the latest use case tracking document, which is approved by the group with unanimous consensus.
Anyway, I’m happy to explain the benefit to the STA again, in order to get some STA vendor’s support.
If you look Link recommendation feature defined in the latest 11be draft, in which “An AP MLD may also use Multi-Link Traffic Indication element and AID Bitmap element in a Link Recommendation frame to recommend
a non-AP MLD to use one or more enabled links for all exchanges both for DL and UL”. Actually, Link recommendation inherits the spirt from Client steering/band steering function, in which AP provides the recommended candidate bands or Neighbor APs, so that
STA can obtain the better services on that AP/band. However, the Client steering/band steering is based on the BTM request/response frame change, while allow STA make the final decision. Please see the details in
818r2 “P5, Client steering”
3) RRCM, e-RRCM and Device ID are alternative, non-interworking, protocols to identify a device.
- Why Device ID is not enough? Device ID has been long time in 802.11bh draft.
àThe current Device ID is only carried in 4-WAY handshake, if the Device ID or other identifier can be carried in other frame, like triggered probe, it will address
a lot of implementation broken issue.
Further, Our chair Mark made a lot of interpretation on the use cases defined in 11bh PAR in the previous meeting, and seems the current Device ID approach can’t meet the requirement on any of them. It’s decided
by whether you want to see the group to finish the task group job in the following plenary meeting. Or we still have enough time, like use more than 1 years to analysis the PAR, analysis the use case from End to End perspective as Sid proposed during the call.
After the down-select procedure, Sid provided 4 extra requirements for pre-association identification scheme in the last call. Suppose some of “Apple funs” keep this position as well. If we insist to working on RRCM solution, I believe
“Apple funs” will strong against the down-select results. And the expected motion will be failure definitely.
May I request to go with e-RRCM solution which may meet the 4 extra requirements listed by Sid? I would like to hear the group’s opinion.
-
Consent
-
Unauthenticated environment
-
Malicious 3rd party protection
-
What is identifier used for
I took an action item to start this discussion on the reflector…
On today’s call, we completed our down-selection process and settled on RRCM as the favored solution to work on, to try to get any additional solution into the Draft (or agree that we are not adding anything else). However, in discussion
following the down-selection process, it seems that some of the objection that might exist and prevent RRCM from passing such a motion, *might* be resolved by aspects of what’s in e-RRCM. So, we are left in a quandary – do we modify RRCM to include
some/all e-RRCM extensions to satisfy the concerns, or is that reversing our straw poll guidance that RRCM is preferred over e-RRCM, and therefore we’ll lose some RRCM supporting voters if we do so?
So, I’d like to start this thread to see if there is a sense in the group:
-
Can those who preferred RRCM over e-RRCM provide an understanding of what made that decision for you?
-
Are there aspects of e-RRCM that we can add to RRCM (to satisfy those who expressed concerns with RRCM as-is) and still hold your approval of RRCM going forward into the Draft?
-
Are there aspects of e-RRCM that you oppose, and bringing those into the proposal that is put to motion next week would cause you to vote No?
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
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
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
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
|