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



 

Hi Robert, Mark, Osama,

 

As agreed during this morning's call, the attached doc updates the 'Resolution' column to provide more details for some of the CIDs resolved during the March meeting.

As discussed, since there are no changes to the approved spec text, the comments database can be updated to include additional details without requiring a motion.

 

With respect to CID 20479, I will provide a new resolution during the May meeting.

 

Regards,

Abhi

 

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Mark RISON
Sent: Friday, March 22, 2019 10:10 AM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] TGax Teleconference 2018-03-28

 

CAUTION: This email originated from outside of the organization.

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


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

Attachment: Updated 'Resolution' column for various CIDs.docx
Description: Updated 'Resolution' column for various CIDs.docx