Dear All,
I don’t support this way forward. The simplicity of IRM is that it uses a MAC address which is in the open, allows for privacy as only the target network and the STA know the meaning of the IRM, and is useful preassociation. I think it
is a needless complication to IRM to somehow hide this MAC address, if the user of the STA wishes to have a higher level of privacy than IRM provides, the user should not use IRM.
Joseph
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, May 8, 2024 1:53 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD
Thanks, Jerome,
FTM is also an important use case.
That said, note that we do have STA identification carried in PASN negotiation frames. So, I think the question is what do we think about using FTM, without PASN (so no privacy protection), using MLO (and therefore an MLD address that
wouldn’t be covered by the 802.11bh basic IRM mechanism), and with all that the client wanting to be identified? I can certainly see it could happen. But, I also wonder if this is getting way into a corner, and maybe not worth adding support directly in
the FTM frames.
Mark
The goal of IRM is to allow the non-AP STA to be recognized at or before next association. So if the group decides that the right vehicle for the IRM is the ML element, then
should we also make sure that the element is present in all pre-associaiton frames of interest (ANQP, as you mention, but also of course FTM)?
Hi Mark,
I quickly check the approved use cases tracking document in 11bh group (https://mentor.ieee.org/802.11/dcn/21/11-21-0332-37-00bh-issues-tracking.docx),
Specially in subclause 4.1 Preassociation client steering(AP steering, band steering, network steering).
In the comment part, you marked up as a case to say "Need to consider Neighbor Report ANQP -element" based on the discussion from the group, I guess that's why in current11bh
draft, we have the rule to say the IRM can be applied in public action frame.
Personally, I think there is a useful use case in Passpoint network(e.g. 3GPP and Wi-Fi hybrid network), if a STA roams from 3GPP network to Wi-Fi network, the STA may send
a ANQP query frame, and the AP will respond with ANQP response frame including NR element. At this moment, based on 11bh identifier, the network can recommend the some serving AP/AP MLD list in NR element. To capture this, I add Basic ML element in Table
9-412—ANQP -element definitions. Please help review it.
Hi TGbe members,
I would like to remind you to help review this documents as well, based on the discussion and the new direction in this
mail loop, I add Basic ML element in probe request and ANQP frame to support 11bh feature under MLO framework.
Welcome further comments.
Thanks
Best Regards
Jay Yang (杨志杰)
Original
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD
HI, Mike,
-
what is the point of band steering?
I didn’t mean band steering, but AP (that is, the device, not “IEEE AP”) steering. Plus, at least for the short term, we’re seeing a lot of MLD clients that don’t connect
on all available bands, and we’d still need to be able to band steer them (perhaps?).
-
I'd be OK with adding Muti-Link Probe Request frames to the list of frames that could contain the IRM in the Basic Multi-Link element.
That seems like a big help. Good suggestion. Any other public action frames that we really need to round out the use cases?
@Yang.zhijie@xxxxxxxxxx: Can you think of significant use cases that would still be missing?
Mark
Hi Mark,
In my opinion, the features you are asking for go beyond the scope of the comments.
Even with 11bh with non-MLO , a STA is not required to active scan prior to selecting an AP.
Furthermore, if the device is multi-link (and likely multi-band) what is the point of band steering? You could use TTLM to steer traffic and possibly use link reconfiguration
on BTM to steer traffic flow over multiple links.
In any case, a non-AP MLD can elect to do an ML Probe Request which includes an ML element. I'd be OK with adding Muti-Link Probe Request frames to the list of frames that
could contain the IRM in the Basic Multi-Link element.
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?
-
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
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
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
|