Re: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

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

Hi Mark,

Please see my responses in-line below:

Regards,

Abhi

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, April 23, 2021 12:36 PM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

CAUTION: This email originated from outside of the organization.

Hello Abhi,

Thanks. I think the remaining issues are:

- "The EBCS Parameters element carries a countdown to the TBTT until the transmission of the next of EBCS Info frame."

is duplication/waffle. But "An EBCS AP advertises its EBCS capabilities and operational parameters in

the EBCS Parameters element" is not true anymore either. Maybe just "An EBCS AP advertises its

EBCS operational parameters in the EBCS Parameters element"?

Abhi: updated as suggested

- Shouldn't "dot11RelayingServiceSupported" have an "EBCS" in it (and ditto the capability

bit)? Also, you need to specify somehow that this can't be true unless

dot11EBCSSupportActivated is true

Abhi: updated as suggested

- Why is the xref to 12.100.2.6 deleted in Table 9-bc6 - Encoding of Frame Signature Type subfield

under CID 1087? It seems like a useful xref to me

Abhi: Table 9-bc6 describes the encoding of the Frame Signature Type subfield. Clause 12.100.2.6 discusses Authentication of the EBCS UL frame – a misfit to the table. Clause 11.100.3.2 (pg 9) makes a reference to 12.100.2.6 when it describes how the criteria are evaluated at an EBCS proxy.

- "The Frame Count subfield is an unsigned integer, initialized to 0" doesn't say when it's initialised,

and this is behaviour not format. Also you don't need to say it's an unsigned

integer as this is covered by the general conventions

Abhi: The text was updated to be in-line with baseline (please see 9.4.2.198, 9.6.14.2, 9.8.5.3).

- I don't understand "The Frame Count subfield is 0 and the value in the previously received EBCS UL frame (if any) is not less than or equal to 2³² – 1."

How can the value not be "less than or equal to 2³² – 1", since it's a 32-bit field?

Abhi: The text was previously updated based on your earlier comment. Now revised to “equal to 2³² – 1 or less (within an acceptable range)”.

The following NOTE is updated as:
“NOTE – The acceptable time difference at an EBCS proxy can be configured based on local policies or based on relationship with the specified destination. In addition, an EBCS proxy implementation can have a validity period for which it stores the last known Frame Count value for a certain transmitter. Furthermore, an EBCS proxy implementation can maintain an acceptable range to account for packet-loss when it performs a replay check.”

- "and which might be collocated with an EBCS AP" should be "and which might be collocated with the EBCS AP"

Abhi: updated as suggested

- "NOTE—[…]an EBCS proxy implementation is expected to account for packet-loss when it performs a replay check."

is informative and cannot override the normative requirement to dump

the frame if

The Frame Count subfield is nonzero and is less than or equal to the value in the previously received EBCS UL frame (if any).

The Frame Count subfield is 0 and the value in the previously received EBCS UL frame (if any) is not less than or equal to 2³² – 1.

So there's still a problem if we miss the frame with FC=0 after a

wrap-around. Please spell out the rules for handling wrap-around of

a replay counter. I'm not convinced wrap-around is compatible with

replay detection…

Abhi: The operation at the proxy is out of scope of the standard. As I mentioned in my previous email, a proxy implementation can take into account frame loss. A simple scheme could be to maintain a sliding window (size x) [i.e., an acceptable range] in which the received FC is checked against a previously received frame (i.e., FC-x).

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: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Friday, 23 April 2021 17:28
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

Hi Mark,

Thank you for your additional feedback.

I’ve addressed all your comments in the updated doc. I’ve attached a copy for your review.

Also attached is a doc with my responses to your comments.

Regards,
Abhi

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, April 22, 2021 4:04 AM
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Cc: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

CAUTION: This email originated from outside of the organization.

Thanks, Abhi. Close now, I think! 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 Abhishek Patil
Sent: Wednesday, 21 April 2021 15:14
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

Hi Stephen,

Thank you for reviewing the doc and providing additional feedback.

Attached doc incorporates your inputs.

Regards,
Abhi

From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Wednesday, April 21, 2021 2:46 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

CAUTION: This email originated from outside of the organization.

Abhi,

Thanks for the updated submission. I've added some additional points in the enclosed. I've not reviewed the clause 4 text within this submission (305r1), as I think it's a duplicate of submission 568r4.

Kind regards

Stephen

On Wed, 21 Apr 2021 at 07:55, Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:

Hi Mark,

Thank you for reviewing the doc and providing feedback.

I have revised the content based on your inputs. In addition, I have also provided by responses to each of your comments in the attached file.

Could you please take a look at the attachments and let me know if you have additional feedback?

Regards,
Abhi

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Tuesday, April 20, 2021 7:08 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: RE: CR doc on pending comments in clause 9

CAUTION: This email originated from outside of the organization.

Thanks for this, Abhi. I attach some comments on 21/0305.

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 Abhishek Patil
Sent: Monday, 19 April 2021 22:32
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

Hi All,

I have prepared doc 11-21/0305 which addresses all the pending comments related to clause 9 that were assigned to me. The proposed changes are in-line with the text in doc 11-21/0568r4.

The excel file for the comments can be found here.

Regards,
Abhi

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

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