In today's TGax teleconf we discussed:
> - 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.
and I was asked to start a reflector thread about this.
I understand from discussions with Po-Kai that there have been email discussions
(which I was not a party to) about this, and the following points arose:
1) A claim that the baseline already says in 9.2.4.1.8 the More Data bit is
reserved in a CTS frame
I don't see this. In fact, all I see is an implication that the More Data
bit is "invalid", from "The More Data subfield is valid in individually
addressed Data or Management frames transmitted by an AP to a STA in PS mode."
However, even if we accept the implication, there is nothing to say that an
invalid bit is set to 0; indeed, I would treat an invalid bit as "could be
set to anything on tx, ignore on rx".
2) A suggestion that the problem needs to be fixed in TGmd not TGax
I don't see this either. In the baseline it doesn't really matter what the
bit is set to, since the receiver will ignore it (since it's implicitly
invalid). But in TGax it does matter, because the CTSes have to be identical.
So it needs to be fixed in TGax. I don't oppose making a change in TGm,
but until and unless that happens it's a TGax problem.
Given this, I would like to understand the objection to just ACCEPTing
the proposed change, which explicitly and unambiguously states the
requirements, rather than making vague cross-references to poorly-defined
baseline behaviour:
Delete the cited NOTE ["NOTE---The Frame Control field of the CTS frames
sent in response to an MU-RTS Trigger frame are set to the same
value (see Figure 9-19 and 9.2.4.1.8 (More Data subfield))."] and
change the para above to "The Power Management and More Data subfields
in a CTS frame sent in response to an MU-RTS Trigger frame shall be set
to 0."
Thanks,
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre
Innovation Park, Cambridge CB4 0DS Tel: +44 1223 434600
ROYAUME UNI http://www.samsungscsc-careers.com/about-us.php
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
