Hi Antonio,
I have some concern on the descriptions. In the associated negotiation procedure, a STA is allowed to use EBCS Request frame to request EBCS traffic streams that do not require association (the logic was that
since you are requesting EBCS services anyway, there is no need to send a EBCS request frame in addition to ANQP requests. It is much easier to take care of both type of requests using one EBCS Request frame).
The newly added descriptions seem to put constraints on this kind of optimization behavior. And I feel that this constraint is unnecessary.
Best regards,
Xiaofei Clement Wang
Principal Engineer | InterDigital
T: (631) 622.4028
E: Xiaofei.wang@xxxxxxxxxxxxxxxx
From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx>
On Behalf Of ANTONIO DE LA OLIVA DELGADO
Sent: Wednesday, May 5, 2021 05:07
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] New text for the Negotiation Method description of clause 9
|
External Mail |
Hi Mark, thanks, I completely missed the last page. Find included the comment answers
- "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 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.
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.
Thanks
Antonio
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
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