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

Re: [STDS-802-11-TGBC] New text for the Negotiation Method description of clause 9

Hi Xiaofei, my apologies, my understanding was not that.
I understand your concern relates to this text:

If the Negotiation Method field indicates a request using EBCS Request frames, then the Association Required subfield of the Control field shall be set to 1. 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.

Will something in this line solves your concern?

If the Negotiation Method field indicates a request using EBCS Request frames, then the Association Required subfield of the Control field shall be set to 1. Otherwise, t. 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.

I think this is exactly what we want to say, is not it?
I am starting to think that we may need to go again in the direction of a bitmask to indicate the different mechanisms allowed per traffic stream, I think what we have now is not flexible enough to cover all these cases, since then we are forcing to choose between one mechanism or another when they are not really mutually excluyent.

Thoughts?

Br
Antonio

El mié, 5 may 2021 a las 16:56, Xiaofei Wang (<Xiaofei.Wang@xxxxxxxxxxxxxxxx>) escribió:

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



--
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