Hello Antonio,
- "This is ANQP, it should be written in terms of STA, since ANQP is always described in terms
of STA and not non-AP or AP."
But does a non-AP STA ever transmit an Enhanced Broadcast Services ANQP-element?
From what that ANQP-element contains it seems to me that it is always
sent by an EBCS AP
[AO] We have solved multiple comments going into this direction and always agreed within the group that we should use STA. I think it should stay as STA even if you are right concerning that no non-AP STA is going
to send it.
I do not recall a discussion in which we said that "STA" should
be used in situations where the STA in question had to be an AP.
I think it is confusing to talk of a "STA" sending a particular
frame that can in fact only be sent by an AP.
- I still don't understand what "may consider that the ANQP frame can be unsecured or unauthenticated"
means. I do think the whole para should be a NOTE anyway
[AO] Moved to a Note as requested. What we wanted to say here is that ANQP frames, in general, are not secured or authenticated, so it is an advice to the implementer of the security aspects related to the use
of ANQP as a source of information for service discovery.
You can't have a "may" in a NOTE.
This is my point: "may consider"
is a normative statement that an option is allowed, but I think
here you're just trying to make a general observation, something like:
NOTE—An EBCS
traffic stream received
from the content address
signaled in an Enhanced Broadcast Services ANQP-element might be provided by a malicious user, since the ANQP-element is [might be?] unsecured.
There is another comment in the last page:
- Why? Why not just make the subfield reserved in this case?
And the text where it is placed:
Sorry but I cannot understand what you mean by making it reserved.
The idea is that for the ANQP Request and EBCS Info frame Negotiation Methods, you may be associated or not depending on the Association Requried subfield.
I mean something like:
If the Negotiation Method field indicates a request using EBCS Request frames, then the Association Required subfield of the Control
field is reserved. Otherwise, the value of the Association Required subfield of the Control field indicates the required association state of the STA requesting and receiving the EBCS traffic stream.
This should probably go to Clause 9, actually, since it's format not behaviour.
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
El mié, 5 may 2021 a las 9:57, Mark Rison (<m.rison@xxxxxxxxxxx>) escribió:
Thanks, Antonio. What about the ones on the last page?
Comments on a few of the others:
- "identified in the Content ID subfield" should be "identified by the Content ID subfield"
- "ANQP advertises the service, not the stream itself." -- well, as far as I can
tell the so-called Enhanced Broadcast Services ANQP-element actually
advertises the traffic streams, using a list of Enhanced Broadcast
Services Tuples fields
- "Yesterday we agreed on a comment asking to replace set by list. Shall we use set here?"
I think the representation is a list, but the information is a set.
Here it's talking about the information, not its representation
(describing the representation would be duplication)
- "This is ANQP, it should be written in terms of STA, since ANQP is always described in terms of STA and not non-AP or AP."
But does a non-AP STA ever transmit an Enhanced Broadcast Services ANQP-element?
From what that ANQP-element contains it seems to me that it is always
sent by an EBCS AP
- I still don't understand what "may consider that the ANQP frame can be unsecured or unauthenticated"
means. I do think the whole para should be a NOTE anyway
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: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Wednesday, 5 May 2021 08:04
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] New text for the Negotiation Method description of clause 9
Mark, thanks a lot for the comments. I have integrated most of them and answered some others.
Thanks
El mar, 4 may 2021 a las 22:06, Mark Rison (<m.rison@xxxxxxxxxxx>) escribió:
Thanks, Antonio. Some comments attached.
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: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> On Behalf Of ANTONIO DE LA OLIVA DELGADO
Sent: Tuesday, 4 May 2021 08:51
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBC] New text for the Negotiation Method description of clause 9
Dear all,
new text that I hope it helps solving the issues with the Negotiation method field.
Thanks
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-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&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
--
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-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1