Re: [STDS-802-11-TGBH] CIDs 23, 135 and 224

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

El mar, 1 ago 2023, 19:21, Stacey, Robert <robert.stacey@xxxxxxxxx> escribió:

Just an editorial note. You will want to (consistently) refer to these as procedures, operations, or mechanisms (choose one). “Device ID” != “Device ID mechanism”; the former is the identifier and the later the mechanism. Also, don’t call them schemes in one place and mechanisms in another.

Maybe something like:

NOTE: The device ID and IRM procedures are independent and can operate concurrently. If an AP and a non-AP STA supports both, then the non-AP STA might provide both an IRM and a device ID. The two procedures are not related and the success or failure of one is not linked to the success or failure of the other.

-Robert

From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Tuesday, August 1, 2023 2:47 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
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:

If you really think it is needed to state, better language is "The two mechanisms are not related and their failure or success is not linked"

FWIW

From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Monday, July 31, 2023 1:59 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>

Subject: Re: [STDS-802-11-TGBH] CIDs 23, 135 and 224

Hi Benjamin, Luther, thanks for the comments. Regarding the "less words is better approach", I think we really need in this case to state that if both Device ID and IRM are presented and one of them is not recognized it does not mean anything for the other schema.

Following Luther suggestion and trying to simplify, what about:

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. Both mechanisms are not related and their failure or success is not linked.

BTW, I am on vacation and will not be able to connect to the call. If you discuss this and the group agrees on a different wording let me know please

Br and thanks

Antonio

El lun, 31 jul 2023 a las 20:51, Benjamin Rolfe (<ben@xxxxxxxxxxxxxx>) escribió:

Thanks Antonio, I think I am closer to understanding 😉.

I remain a bit confused by "if both mechanisms while used concurrently yield to different results" which led me to think there was a potential conflict. From your explanation I see that these are independent and there is no co-dependency or conflict. Perhaps this is a case where less words is more clear:

"NOTE: Device ID and IRM are independent schemes that allow an AP to recognize a non-AP STA prior to association and identify it during association respectively. "

which seems to clearly state what you have said. The rest is redundant information.

A suggestion FWIW

Ben

From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Saturday, July 29, 2023 3:27 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBH] CIDs 23, 135 and 224

Hi Benjamin, what I am trying to clarify is that there are no possible conflicts since they do not tackle the same thing, therefore there is no possible conflict between them.

The only thing the AP can indicate is whether DeviceId is recognized or not and if IRM is recognised or not. In fact this indication means different things for both cases, for Device ID means the identity cannot be recognised while for IRM means the station is not recognised as a returning STA, that is all.

I am not able right now to see a use case where a failure of, for example IRM, makes a recognised Device ID not valid or vice versa, if you have one please share it since for sure will clarify this issue

Thanks

Antonio

On Fri, 28 Jul 2023 at 16:25, Benjamin Rolfe <ben@xxxxxxxxxxxxxx> wrote:

Thankyou Antonio, for pointing out the need to address the failure cases where Device ID and IRM checks produce different outcomes. The added text still doesn't inform the implementer what behavior is expected. Saying they are not linked still can produce different results, with different potentially conflicting actions. Is the intention that it be implementation specific which is given precedence? Or am I incorrect in thinking there is a conflict in behavior?

Thanks for clarifying.

Ben

From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Thursday, July 27, 2023 11:44 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBH] CIDs 23, 135 and 224

Dear all,

as promised during the last AC I am providing new text for the resolution of these CIDs.

Current text agreed during comment resolution for these CIDs is the following:

NOTE: Device ID and IRM are independent schemes that allow an AP to recognize a non-AP STA prior to association and identify it during association respectively. The device ID is allocated by an AP, and the IRM is selected by a non-AP STA. If an AP and a non-AP STA both support both IRM and device ID, the non-AP STA might provide both an IRM and a device ID.

I think this explanation lacks information on how to proceed if both mechanisms while used concurrently yield to different results. In addition, the above paragraph seems to indicate IRM provides identification, while it is not.

I am proposing the following text, let me know what do you think

NOTE: Device ID and IRM are independent schemes that can be used concurrently. The device ID is allocated by an AP, and enables identification of the STA during association. IRM enables an AP to recognize that a STA has been associated previously to the AP, therefore not providing any identification. If an AP and a non-AP STA both support both IRM and device ID, the non-AP STA might provide both an IRM and a device ID. Both mechanisms are not related and their failure or success is not linked.

Br

Antonio

--

Antonio de la Oliva

Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749

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

--

Antonio de la Oliva

Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749

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

--

Antonio de la Oliva

Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749

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

--

Antonio de la Oliva

Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749

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