| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Antonio, I can see your point/point-of-view, based on comments that have been made. But, to me, to say “I know the STA has been here before”, without also connecting the STA to some state that has been saved from that previous visit, doesn’t accomplish anything. That is, it doesn’t:
Nor
which is our purpose per the PAR. So, I’ve had it in my mind that the IRM (as well as the Device ID) does result in enabling services/enabling session continuity – which I think means “maps to shared and persistent state” – even if that wasn’t stated explicitly. Interested in others’ views… Mark From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx> Hi Mark, My understanding is the IRM only provides a notion of "returning sta" meaning that the AP only knows the STA has been here before. This is my understanding from the discussion we had during last meetings, if this is not correct then all my arguments are invalid, of course. The problem I see is that in the case IRM is assumed to be an identity (this means we have an sta identified by a Mac address again), we have to make sure there are no collisions, etc.. which I think we were disregarding because IRM is not providing an identity. Thanks and my apologies if I am messing around because of a misunderstanding Br Antonio El mar, 1 ago 2023, 18:38, <mark.hamilton2152@xxxxxxxxx> escribió: Hmm. I don’t understand the comment “IRM does not identify a sta”. My view is that both IRM and Device ID are used as a private (and potentially frequently changing, for both) way to identify a set of “state” that is shared between the client and the network, where that state is relatively durable (survives across multiple associations). I don’t see any difference between the two methods, except that IRM is derived by the STA, and Device ID is derived by the network. But, both mechanisms can be used for the same type(s) of “state”. I’m completely missing this point-of-view that IRM is somehow identifying the STA “as a returning STA”, without also connecting that STA to some durable state that is shared between the STA and network. Mark From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx> Hi Mark, My point is that I think the case of conflict cannot happen because both IDs do not identify the same. IRM does not identify an sta therefore cannot conflict with deviceid. There is absolutely no problem if a device id is recognized but the IRM is not. This means the long term identity of the sta is identified but the sta is not a returning sta. I see no problem. The other way around it's the same, I do not see a problem. The sta is a returning sta but the AP does not recognize the long term identity. The case where both are recognized but map to different identities simply cannot happen because irm does not provide an identity. My two cents Br Antonio El mar, 1 ago 2023, 17:50, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> escribió: Antonio/all, (as an individual, not as Chair): I do not think your proposed text really resolves the problem pointed out in the comment. (I think perhaps I’m agreeing with Jay.) We have agreed that the two mechanisms can be used at the same time (or in an overlapping, but not literally “at the same time” fashion – for example, IRM is used during pre-association, but then a Device ID is provided at association from the same device). So, even if can agree that the mechanisms are independent, there is the scenario that the network does recognize both the identifiers provided, but they do not map to the same long-term information (state) the network has stored because they map to two different devices’ state per the network’s history. I think we need to say what does happen, in this scenario. The choices that I can see are:
So, which is it? Mark From: Jay Yang <yang.zhijie@xxxxxxxxxx> Hi All, I wanna jump in for the disscusion. I guess the following two cases has nothing with the recognize/unrecognize issue if both schemes are applied together. They are talking the recognize result is not consistent issue. E.g. based on IRM, the STA is identified as a returned Device A; based on Device ID, the STA is identified as a returned Device B. How to address such issue?
Jay Yang (杨志杰) Wi-Fi Sandard Research Engineer ZTE Corporation R&D Building I, No.899 Bibo, Pudong District, Shanghai, P. R. China Original From: ANTONIODELAOLIVADELGADO <aoliva@xxxxxxxxxx> Date: 2023年08月01日 17:47 Subject: Re: [STDS-802-11-TGBH] CIDs 23, 135 and 224 Hi Benjamin, thanks for the word smithering, then the final version to be discussed will be: “NOTE: Device ID and IRM are independent schemes that can be used concurrently. If an AP and a non-AP STA both support both IRM and device ID, the non-AP STA might present both an IRM and a device ID. The two mechanisms are not related and their failure or success is not linked.” @Graham, what do you think? Br and thanks Antonio On Tue, 1 Aug 2023 at 00:07, Benjamin Rolfe <ben@xxxxxxxxxxxxxx> wrote:
-- Antonio de la Oliva Associate Professor 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 |