Hi Mark,
My responses in blue:
Regards,
Abhi
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, May 10, 2021 1:45 PM
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,
Please find my responses in-line below (in
green) along with screenshot of corresponding changes in the document:
[I see no screenshot, but in any case I'm not sure screenshots are
the best approach here!]
When I started working on the email, I intended to put screenshots of the updated text – instead, I ended up posting the actual text in-line.
- "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.”
OK.
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.”
I think most of this is duplication of the T9-153 text. All you need is:
“An AP that has dot11EBCSSupportActivated equal to true and provides access to relaying service shall have dot11EBCSRelayingServiceSupported
equal to true. Otherwise
dot11EBCSRelayingServiceSupported shall not be true.”
Updated as suggested.
---
- >>> 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.
I am not sure this is a safe assumption. As far as I can tell, there is no
requirement for an AP to provide access to the Internet, or even to any
non-802.11 network outside the ESS (e.g. a portal is as far as I can tell
optional).
Again, why not allow a non-AP STA that is associated with a non-EBCS AP to do EBCS UL?
I have added you to another email thread that discusses this topic.
- >
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).”
OK (I had assumed the context was clear this was about EBCS UL frames).
- >
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.”
OK. Should be "When the Frame Signature Type subfield indicates HLSA…" and "… by a higher layer …".
Updated as suggested.
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.
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