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

So if the Association Required subfield is set to 0, and b0 is set to 1 in

the Negotiation Method bitmask, is association required to request the

traffic stream using EBCS Request frames or not?


[AO] This means that the service can be requested in associated state using EBCS Request frames, but the STA does not need to be associated to receive it. Also, I think this is what Xiaofei is trying to explain in his latest emails. In case only b0 is set to 1, this situation means you need to request the service in the associated state using EBCS Request frames but you do not need to be associated to consume it.

Br
Antonio

El vie, 7 may 2021 a las 10:25, Mark Rison (<m.rison@xxxxxxxxxxx>) escribió:

Hello Antonio,

 

In my understanding, the Association Required subfield indicates if the association is needed to receive the EBCS traffic stream, so it is applicable to all Negotiation Methods (since it talks about the service).

Now in case b0 is set to 1 in Table 9-bc3, then regardless of Association Required subfield value, the service can be requested in the associated state through EBCS Request frames. 

 

So if the Association Required subfield is set to 0, and b0 is set to 1 in

the Negotiation Method bitmask, is association required to request the

traffic stream using EBCS Request frames or not?

 

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: Friday, 7 May 2021 08:49
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

 

Hi Mark, let see if we are able to find a common ground for this, since it is getting complicated.

regarding this phrase

 

image.png

 

Which you say is not applicable to b0. In my understanding, the Association Required subfield indicates if the association is needed to receive the EBCS traffic stream, so it is applicable to all Negotiation Methods (since it talks about the service).

Now in case b0 is set to 1 in Table 9-bc3, then regardless of Association Required subfield value, the service can be requested in the associated state through EBCS Request frames. 

In case b1 is set to 1, the service can be also requested through Enhanced Broadcast Services Request ANQP-elements, but depending on the Association Required subfield value, the STA needs to be associated or not.

Similar behavior happens with b2.

 

Do we agree on this behavior?

 

 

El jue, 6 may 2021 a las 16:54, Mark Rison (<m.rison@xxxxxxxxxxx>) escribió:

Thanks, Antonio.  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: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Thursday, 6 May 2021 15:26
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

 

Dear Mark, Xiaofei, 

I have tried to address all comments in rev6. Please note I have changed the field in clause 9 to be a bitmask, I think it makes more sense after the comment from Xiaofei. 

Mark, I have included (I think) all your comments.

 

Please let me know if you are ok with this.

Br

Antonio

 

El mié, 5 may 2021 a las 18:48, Mark Rison (<m.rison@xxxxxxxxxxx>) escribió:

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: 

image.png
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


 

--

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



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