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 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