I think I'd be OK with shall ignore -> should ignore.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From:
Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Tuesday, 1 February 2022 08:45
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [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
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