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

[STDS-802-11-TGM] Fwd: TGme ANQP response CID



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Dear all,
              following the discussion about the ANQP CID 1618 on the TGme call yesterday, I wanted to check the proposed resolution with Jouni, as he was not on the call and has been involved in some implementations of these messages.

Jouni mentioned that it's ok for me to forward his email to the mailing list. Thanks.

Kind regards

Stephen

---------- Forwarded message ---------
From: Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>
Date: Mon, 31 Jan 2022 at 16:54
Subject: RE: TGme ANQP response CID
To: Stephen McCann <mccann.stephen@xxxxxxxxx>


That wording is ambiguous since "ANQP request/response" is not really clearly defined and it is used in two different contexts: reference to either the full frame containing potentially multiple ANQP-elements (11.22.3.3.1: "The ANQP request consists of one or more ANQP elements") or a single ANQP-element (may other locations, often a bit more vague, but some instances seem to be pretty clear on talking about a single ANQP-element instead of full set of elements). This "shall ignore" rule need to be clearly written to be evaluated separately for each ANQP-element received in the response (i.e., use other received ANQP-elements and only ignore the unrecognized one). I'm not convinced there would need to be a similar rule for the request.

 

It should also be noted that "shall ignore" is problematic here if "ignore" were to be interpreted more like "silently discard", i.e., take no action based on it. There might be other recognized subfields or values in the same ANQP-element and those could still be used. And for the case of an AP reporting that it does not have some data, the information about the AP not having that data could still be used.

 

IMHO, the proposed language looks worse than the current state of uncertainty.. I do agree that there would be room for improvement in this area, but this one does not result in net gain. It would be better to address the specific known issues on case-by-case basis rather than trying to come up with some generic shall statement that is way too easy to result in issues for some existing use cases.

 

- Jouni

 

 

 

From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: 31 January 2022 18:38
To: Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>
Subject: TGme ANQP response CID

 

Jouni,

          regarding the following CID 1618 from Mark Rison (clause: 11.22.3.3.1):

 

Comment

Proposed Change

REVmd WG CC Comments

ANQP-elements with fields with some reserved values need to define the behaviour on receiving such values, since they can be sent without prior capability negotiation.  Typically this will involve ignoring the field in question and any other fields associated with them

After the 2nd para add a para "A STA shall unless specified otherwise ignore an ANQP request or response that contains non-reserved field/subfield values that are    not known to it."

 

We decided to accept this on the TGme call today. Are you ok with this? Thanks.

 

Kind regards

 

Stephen

 


To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1