Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thanks Mark. I’ll add to the agenda. Regards; Osama. From: Mark RISON [mailto:m.rison@xxxxxxxxxxx]
I'd like to put the following on the agenda, please: I've taken a look at the ax/D4.0 comment spreadsheet
19/0292r5, and I'm afraid it's not looking good in terms of meeting the expectations for comment resolution (see e.g.
11/1625r2). Meeting these expectations is important to ensuring the balloting process expeditiously reaches a conclusion. Looking at the first few comments of mine allegedly resolved: - CID 20477:
OK (though I will have to re-raise in D5.0 since the qualifier "global", which I specifically mentioned in my comment as undefined, has been kept) - CID 20478: 19/0394r1 does exactly what the proposed change was. So resolution should have been ACCEPTED not REVISED - CID 20479:
resolution claimed to be "Agree with the comment" but in fact 19/0394r1 does exactly the opposite of the comment. The comment said the stuff in 26.5.5.2 was more behaviour than format, so should be deleted from 9.3.1.22.1. But 19/0394r1 keeps the text in 9.3.1.22.1 (albeit as a "Note" (which should be "NOTE" -- I will have to re-raise in D5.0 unless the editor catches the "Note" and changes it to "NOTE")) and deletes the stuff in 26.5.5.2 [Actually, this now seems broken. Where is the normative requirement to set NSS and iSS to 1?] - CID 20491: it would be desirable to
indicate in the resolution in what way the spec has been clarified - CID 20495: resolution wording is
OK (haven't checked the actual changes yet) - CID 20509: 19/0394r1 does exactly what the proposed change was. So resolution should have been ACCEPTED not REVISED - CID 20530: resolution wording is
OK (haven't checked the actual changes yet) - CID 20540:
resolution claims to agree with commenter, but rather than making the proposed change, it keeps the opaque grammar which was the point of the comment (and keeps the grammatical mistake: the subject is "A combination" so the verb should be "is" not "are") - CID 20548:
resolution claims to agree in principle, but I'm not convinced it does. Reference is made to 9.2.4.1.8 re the More Data bit, but that only says that the bit is only "valid" in Data/Management frames. It is not clear (unless I've missed something) that an "invalid" bit is guaranteed to be set to 0 on transmission. Shall I just re-raise in D5.0? - CID 20557: resolution wording is
OK (actual changes are broken, since there are more than 255 channels across the 5+6 GHz bands, but I will just re-raise this in D5.0) - CID 20569:
resolution doesn't address the comment, which had a large and specific list of places where "NDP" needed to be qualified (also "can not" should be "cannot") - CID 20574: 19/0394r1 does exactly what the proposed change was. So resolution should have been ACCEPTED not REVISED At this point it got too depressing to continue, but I thought I'd also check out the end: - CID 20999/21000: resolution
should have stated that this is the proposed change plus changing "Description" to "RU Index" (which should have been "RU index" -- another D5.0 comment…) in the heading of Table 9-31g - CID 21020:
resolution claims that "The current note for parameter of “CH_BANDWIDTH” for HE_TB PPDU as in Table 27-1 has addressed the comment." but the current NOTE is: which does not have the ", which is in the TXVECTOR parameter RU_ALLOCATION" appended per the proposed change (so needs another D5.0 comment…) - CID 21025:
woo-hoo, an actual ACCEPTED! I suggest we go through the resolutions to date and fix all the ones that need fixing to meet expectations. 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 To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 |