Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGAX] TGax Teleconference 2018-03-28 [CID 20548 More Data in CTS]



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

 

--

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

 


On Fri, 22 Mar 2019 at 17:09, Mark RISON <m.rison@xxxxxxxxxxx> wrote:

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:

 

T27-1_CH_BANDWIDTH.png

 

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