Re: [STDS-802-11-TGBC] CR 1091

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

> what about the attached?

Remaining/new issues:

- "per EBCS" should be "per EBCS traffic stream"

- "EBCS request using the URL indicated in the EBCS Info frame." should not have a full stop

and for consistency with the cells above be "EBCS request by STAs that might or

might not be associated with the broadcaster [right?], using the URL indicated in the EBCS Info frame".

Or even better:

1	Request using EBCS Request frames	EBCS request by STAs that are associated with the broadcaster
2	Request using EBCS Request ANQP-elements	EBCS request by STAs that might or might not be associated with the broadcaster
3	Request using ~~IP request~~ the URL indicated in the EBCS Info frame	EBCS request by STAs that might or might not be associated with the broadcaster

> Regarding the lat comment

> > Also, new one: aren't similar fixes needed in Table 9-397d—Request Method

> > subfield encoding (in D1.02) and in references to "Request Method" in

> > 11.22.3.3.1 General and 11.100.5 EBCS Termination Notice Procedure?

> Probably yes, but these are other comments so a different resolution will be needed, I have not gone through that

So you mean this will be resolved in a different submission and/or

under a different CID?

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: Tuesday, 13 April 2021 13:39
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] CR 1091

Hi Mark, what about the attached?

Regarding the lat comment

Also, new one: aren't similar fixes needed in Table 9-397d—Request Method

subfield encoding (in D1.02) and in references to "Request Method" in

11.22.3.3.1 General and 11.100.5 EBCS Termination Notice Procedure?

Probably yes, but these are other comments so a different resolution will be needed, I have not gone through that

Antonio

El mar, 13 abr 2021 a las 11:22, Mark Rison (<m.rison@xxxxxxxxxxx>) escribió:

Hello Antonio,

thanks for the quick response ahead of the meeting

added your modifications to the attached doc, answering other comments:

- "is an ~~bit mask~~ octet that " is duplication of the figure defining the element.

Delete

- What does "IP" mean in "Out of band IP request"? The abbreviation does not

appear in Subclause 3.4. In any case, it's not clear to me what it's

telling me, even if it means "Internet Protocol" (does it mean it has

to be IPv4 or IPv6?)

It means IPv4/IPv6, the EBCS Info frame contains an URL that you can use to do this.

I see. In that case wouldn't it be clearer to say something like

"EBCS request using the URL indicated in the EBCS Info frame"?

What is the point of explicitly referring to IP?

- "Note" should be "NOTE"

- "one Negotiation Method" should be "one negotiation method"

- Do we have some general comment to deal with the fact that

"an EBCS" needs to be expanded to "an EBCS traffic stream" (or

better "an EBCS stream" or "an EBCS flow") throughout?

Not sure about it, said so, I think in this case the phrase does not intend to mean EBCS traffic stream, since this is talking about the service itself and not the frames... This is the phrase for the others to consider

"request the transmission of an EBCS identified by the content ID contained in the Content ID subfield"

Hm, I don't think transmission of a service makes sense. Similarly

"Only one negotiation method can be selected per service" should probably be

"per EBCS <something>".

- Does "EBCS request by STAs that are not associated with the broadcaster" imply that you

shall not use this method if you are associated? (It doesn't imply

that you shall use this method if you are not associated, since

otherwise methods 0 and 3 could never be used.) Do we have some

behavioural text associated with this?

As I understand this field, you are indicating if the service can be requested by associated or not associated STAs. So to me value 1 means that you need to be associated to request it, value of 2 means you can request it either associated or not associated and value of 3 means that you need to use another method maybe through another link. This is my understanding though, I did not write this.

So maybe 2 should be something like

EBCS request by STAs that might or might not be associated with the broadcaster

?

Also, new one: aren't similar fixes needed in Table 9-397d—Request Method

subfield encoding (in D1.02) and in references to "Request Method" in

11.22.3.3.1 General and 11.100.5 EBCS Termination Notice Procedure?

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: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> On Behalf Of ANTONIO DE LA OLIVA DELGADO
Sent: Tuesday, 13 April 2021 08:03
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBC] CR 1091

Dear all,

I have committed a new version of the contribution addressing the conflict between CR 1091 and 1451 (https://mentor.ieee.org/802.11/dcn/21/11-21-0581-02-00bc-conflict-1091-1451.docx) and the excel with the resolution for CR 1091 (https://mentor.ieee.org/802.11/dcn/21/11-21-0661-00-00bc-cr-1091.xlsx), no need to modify resolution for 1451.

Marc, if possible we can have a look at the AC.

Br

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