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

Re: [STDS-802-11-TGBC] Feedback Requested for doc 11-21/305r2



 

Hi Mark,

 

Please find my responses in-line below (in green) along with screenshot of corresponding changes in the document:

 

Revised version (still r3) attached.

 

Regards,

Abhi

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, May 10, 2021 6:07 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: RE: Feedback Requested for doc 11-21/305r2

 

CAUTION: This email originated from outside of the organization.

Hello Abhi,

 

Thanks for this.  My comments on your responses (I haven't had the time to

check the updated draft):

 

- "An AP that has dot11EBCSRelayingServiceSupported equal to true, sets the EBCS Relaying Supported field to 1 when dot11EBCSSupportActivated is true. Otherwise an AP sets the field to 0. A non-AP STA sets the field to 0."

 

seems to me a bit mixed-up.  Wouldn't it be clearer to say in Clause 11

that dot11EBCSRelayingServiceSupported shall not be true unless

dot11EBCSSupportActivated is true?  Then here the first sentence can be just

"An AP that has dot11EBCSRelayingServiceSupported equal to true sets the EBCS Relaying Supported field to 1."

 

- "An EBCS AP sets the EBCS Relaying Supported to 1 when dot11EBCSSupportActivated is true and dot11EBCSRelayingServiceSupported is true. Otherwise the AP sets the field to 0. A non-AP STA sets the field to 0."

> The previous sentence covers non-EBCS APs with “dot11EBCSSupportActivated is true

 

I don't follow you.  Non-EBCS APs do not have dot11EBCSSupportActivated equal to true, right?

 

I had revised the text in Table 9-153 and clause 11 based on your previous comments. I may have misunderstood your intention. I have updated the ‘Notes’ column in Table 9-153 as follows:

An AP that has dot11EBCSRelayingServiceSupported equal to true sets the EBCS Relaying Supported field to 1. Otherwise an AP sets the field to 0. A non-AP STA sets the field to 0.

 

The text in clause 11 is updated as follows:

An AP that has dot11EBCSSupportActivated equal to true and provides access to relaying service shall have dot11EBCSRelayingServiceSupported equal to true and shall set the EBCS Relaying Supported field of the Extended Capabilities element to 1. Otherwise dot11EBCSRelayingServiceSupported shall not be true and the EBCS Relaying Supported field of the Extended Capabilities element shall be set to 0.

 

 

- >>> The EBCS UL Service procedure allows a non-AP STA, that is not associated with any AP,[CID 1630, 1631] to transmit an EBCS UL frame

>> So a STA that is associated with a non-EBCS AP is not allowed to use EBCS UL?

> Correct, an associated STA can access the cloud provider via its associated AP.

 

What is "the cloud provider"?  This sounds like an implementation option,

but in the 11bc spec we should not restrict ourselves to particular

implementation options.  And you're assuming the non-EBCS AP provides

access to the Internet/cloud, but that is not necessarily the case.  Why

not allow a non-AP STA that is associated with a non-EBCS AP to do EBCS UL?

 

By cloud provider I mean accessing a service on the cloud. In other words, when a device is associated with an AP, it is able to access any service on the internet (cloud) via its associated AP. It doesn’t need to take advantage of the EBCS relaying service. For example, if the device wants to send some packets to a destination on the internet, it can do so by sending a frame to its associated AP which the associated AP would forward to the DS.

 

 

- > Could you please suggest alternative text? CID 1356 is asking to provide description for all the fields carried in the frame.

How about "The Frame Signature field, if present, is computed as defined in 12.100.2.5 (Signature of the EBCS UL frame)."?

 

The sentence is updated as follows (normative since it is in clause 11):

The Frame Signature field, if present in the EBCS UL frame, shall be computed as defined in 12.100.2.5 (Signature of the EBCS UL frame).

 

 

- > As the name suggests, HLSA provides higher layer authentication. If Frame Signature field is not carried in the frame, an attacker could change the contents of the frame (i.e., replace the Frame Count value with a different (higher value) causing legit frames to be marked as replay. Therefore, the Frame Count field check must be performed only if the frame signature is verified.

 

Sure, but my question was about replay detection with HLSA.  Are you

assuming this will be done by the HL?  If so, I would at least put a

NOTE to that effect.

 

Added NOTE 2 in clause 12 as follows:

NOTE 2 – When Frame Signature Type is HLSA, replay protection is performed by the higher layer and is out of scope of this standard.

 

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: Sunday, 9 May 2021 02:15
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: RE: Feedback Requested for doc 11-21/305r2

 

Hi Mark,


Thank you for reviewing the document and providing feedback.

I have prepared a revised doc (r3) based on your inputs.

In addition, I have also provided a response to each of your comments.

 

Could you please take a look at the attached files?

Regards,
Abhi

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, May 7, 2021 2:37 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: RE: Feedback Requested for doc 11-21/305r2

 

CAUTION: This email originated from outside of the organization.

Thanks, Abhi.  My 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: Thursday, 6 May 2021 22:14
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBC] Feedback Requested for doc 11-21/305r2

 

 

Hi Mark, All,

 

Thank you for the discussion during the previous 11bc calls on replay protection and related topics.

 

I have posted r2 of doc 11-21/305 which reflects the changes based on our discussions.

In addition, the document also resolves all pending comments (in clause 9, 11 & 12) that are assigned to me.

 

https://mentor.ieee.org/802.11/dcn/21/11-21-0305-02-00bc-lb252-resolutions-for-cids-assigned-to-abhi-part-3.docx

 

The document is schedule for discussion during Tuesday’s 11bc slot.

 

I would appreciate if members could please take a look at the document and provide early feedback (if any).

 

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

Attachment: 11-21-0305-03-00bc LB252 resolution for CIDs assigned to Abhi (part 3) v2.docx
Description: 11-21-0305-03-00bc LB252 resolution for CIDs assigned to Abhi (part 3) v2.docx