Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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"? - 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 - 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 - "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 - 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 232 – 1." How can the value not be "less than or equal to 232
– 1", since it's a 32-bit field? - "and which might be collocated with an EBCS AP"
should be "and which might be collocated with
the EBCS AP"
- "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). or
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 232
– 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… 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> Hi Mark, 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.
From: Mark Rison <m.rison@xxxxxxxxxxx>
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 Hi Stephen,
Attached doc incorporates your inputs.
From: Stephen McCann <mccann.stephen@xxxxxxxxx>
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:
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 |