| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello Adrian, I presume, presumptuously, that I am the Mark you hailed. I have taken a look at 15/1010r7 and have the following comments: CID 6235: I am not convinced the case of "9.7.4 Basic Rate Set and Basic MCS Set for mesh STA" is correct; ditto at 2655.43 (and shouldn't "VHT Basic MCS Set" be "basic VHT-MCS and NSS set" anyway?), 3049.47, 3049.48. Also, the "BSS" in "BSS basic VHT-MCS and NSS set" and "BSS basic rate set" and "BSS basic HT MCS set" is superfluous (and the last of these should be "basic HT-MCS set" CID 6461: It should be "implicit block ack request in the future" (addition of the word "request") since the thing the recipient gets is the request for ack, not the ack itself CID 6252: Note that if there is in fact a direct normative limit on the DMG MPDU size, this needs to be shown in Table 8-19 CID 6055: "The contents of an A-MSDU sent using GCR is described in 9.24.10.3." has the wrong verb conjugation (needs to be "are", since the subject is plural) CID 6351: I don't think the "equal to" is needed or desirable. The other rows don't say "equal to". In fact, given CID 5083, maybe the cells should just say "REJECTED_BLAH" or "Not REJECTED_BLAH" CID 5083: Will need some definite articles too. Also, for the ones which won't be touched by CID 6351, shouldn't "Status" in the third column be something like "Any"? CID 6343: It may be the case that at present all Action No Acks carry information such as beamforming that is of time critical but transient value, but this is not a requirement of the frame subtype per se. If we want to say that this is the case for <all the current ANA flavours>, and so they don't need a MICE (or AMPEE), fine, but we should in principle allow these in ANAs CID 6336: I had previously suggested 6335 to 6339 all be assigned to Carlos CID 5955: I don't understand "My interpretation is that any STA can “support” this frame type, but only the VHT and TVHT STAs can transmit an operating mode notification frame with defined contents." CID 6226: If we decide to do 2 (add a new Extended Request element), we need to somehow indicate how this will interwork with existing devices (which won't understand this) CID 6068: There are 6 instances of "This string is not null terminated." in Clause 8. 5 are for ASCII strings, so would be duplication. 1 is for an UTF-8 string, which arguably should be added to the general statement. There are also 4 instances in the MIB, which arguably should be left as-is. Also, at 968.2 there is "“ES_ALERT” is treated as a sequence of ASCII-encoded octets without a terminating null" which could just become "“ES_ALERT” is an ASCII string" and in Clause 11 there are 5 instances of "terminating null", which arguably should be left as-is CID 5054: It is nice that you agree with the sentiment of your comment CID 6476: JOOI, why is the bit set to 0 when sent in a non-AP STA's beacon, even if it it supports PSMP (and indicates so when it sends a probe response)? This seems very odd (and would leave a device which does passive scanning with the wrong understanding) CID 6470: You mean you want some examples of how the medium time is significantly different depending on whether aggregation is used? CID 5071: See (resolution to) CID 6651 CID 5027: Missing the canonical "and is not present otherwise" CID 6669: Because they're merged for non-HT duplicate PPDUs (middle case) CID 6668: I don't think "PPDU" should be deleted, otherwise the definition ends up being "A Clause 21." CID 6667: Needs "or", otherwise the definition ends up being "A Clause 20 Clause 22 PPDU" CID 6819: The resolution is in 15/0762 CID 6531: I'd be happier with some words which more clearly indicate that the scope of the definition of "WLAN system" is this annex only CID 6396: Missing comma at start of proposed insertion. But should the change explicitly reference TVHT? There are lots of definitions which mention VHT but not TVHT; do they also need tweaking? Also, are we saying that a Clause 16-19 PPDU is not a "non-HT PPDU"? CID 6297: Disagree with the discussion text. "information in a frame" is not the same thing as "information in any frame". I dislike giving explicitly lists of frame types, because such lists become out-of-date (the usual problem with duplication). I think just saying that a non-transmitted BSSID is one that is not transmitted (duh) but can be derived from the info in a frame is better CID 6525: Is this correct? Does the "off-channel" have to be entirely non-overlapping, or only non-overlapping as regards the primary channel? (However, the commenter is lying: there is a definition of "base channel") CID 6323: There is a proposed resolution in 15/0762 CID 6565: The "CS zoo" comments I am working on (out for review by SMEs (not the entities or enterprises but the experts)) will address the "CCA mode 5" thing. However, I think the 2468.21 thing does need addressing, because it clashes with the definition of "HT PPDU" CID 6477: FAOD, I think we agreed (in Cambridge) the proposed resolution as stated was completely bogus CID 6433: I think calling things which are some kind of index "index" is a very good idea CID 6802, 6803: We had discussed this by email, and I had provided you a list of suspect locations, and you had said "I’ll give it a bit more thought. […] I need time to study this to produce a proportionate response. At least you’ve made a (hopefully mostly found) initial analysis." Is this now reassigned to me then? CID 6789: a) The first half of the comment, namely the space character inconsistency, is not addressed by the proposed resolution. Also, I'm fine if we follow ISO and use colons, but then we need to fix "ISO-14962-1997" (2x), "ISO-639" (Also, do we have comments for all the instances of "ISO -1" and "ISO -2" (6 in total)?) CID 6787: Think should also
delete the two pairs of parens around 11 / 8 at 2203.34 CID 6747: Please assign to me CID 6720: Please assign to me CID 6737: I don't understand "180-4 specifies SHA-1, which is why 180-3 was referenced" 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: ***** IEEE stds-802-11-tgm
List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Stephens, Adrian P --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello Mark, I’m slowly working my way through the unassigned Clause 8 comments (I’m currently up to Page 836), and managing to propose resolutions to about 90% of them. I say this to avoid duplication of effort with you or anybody else who is taking these comments. If you look in 11-15/1010r6, you’ll see what I’ve been up to. Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office) ---------------------------------------------- _______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |