| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mark, For CID 24054, I provide my response below. Best, Po-Kai From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx>
On Behalf Of Mark RISON Hello, •
Motions related to submissions discussed during previous teleconferences, if ready: •
https://mentor.ieee.org/802.11/dcn/20/11-20-0297-00-00ax-cr-for-7-cids.docx - Jarkko Kneckt •
https://mentor.ieee.org/802.11/dcn/20/11-20-0369-02-00ax-cr-cid-24054.docx - Po-Kai
Huang •
https://mentor.ieee.org/802.11/dcn/20/11-20-0352-01-00ax-cr-d6-0-he-phy-service-interface.docx
- Bo Sun •
https://mentor.ieee.org/802.11/dcn/20/11-20-0348-01-00ax-mac-cr-misc-cids-in-clause-3.docx
- Alfred Asterjadhi •
https://mentor.ieee.org/802.11/dcn/20/11-20-0349-00-00ax-mac-cr-misc-cids-in-clause-10.docx
- Alfred Asterjadhi •
https://mentor.ieee.org/802.11/dcn/20/11-20-0315-02-00ax-resolution-for-cids-related-to-multiple-bssid.docx
- Abhishek Patil •
https://mentor.ieee.org/802.11/dcn/20/11-20-0316-02-00ax-resolution-for-cids-related-to-bss-color.docx
– Abhishek Patil •
https://mentor.ieee.org/802.11/dcn/20/11-20-0318-01-00ax-resolution-for-cids-related-to-uora.docx
– Abhishek Patil •
https://mentor.ieee.org/802.11/dcn/20/11-20-0445-01-00ax-mac-cr-misc-cids-in-clause-9.docx
– Alfred Asterjadh •
https://mentor.ieee.org/802.11/dcn/20/11-20-0317-02-00ax-resolution-for-misc-cids.docx
– Abhishek Patil I have some comments on some of the resolutions that are proposed for motion. I will be unable to attend today’s teleconf, so I will make them here and I request that they please be discussed at the relevant point during the motion process, despite my absence. •
https://mentor.ieee.org/802.11/dcn/20/11-20-0297-00-00ax-cr-for-7-cids.docx - Jarkko Kneckt I'm going to assume the motion will be on the stuff in r3, not the stuff in r0. I'm confused re
CID 24457. I thought we had agreed to resolve this during the last teleconf as follows: Straw Poll (Suggestions for changes supporting CID 24457):
Do you accept to resolve CID 24457 as Revised and change the following text: l
At 49.16 change "the 5 to 7.125 GHz bands" [sic] to "the 5 and 6 GHz bands” Result: Y/N/A = 11/2/8 I continue to oppose the resolution shown for
CID 24523. If "the OM parameters that AP uses are not reliable for the STAs" then the feature is useless and should be deleted entirely. Also, for
CID 24124 you need to delete the commas at the start too, otherwise you get "These features can, improve the average throughput". Finally, for
CID 24458, since TB PPDUs are sent in response to triggering frames, I think it would be better to say: An HE STA that is a mesh STA shall not transmit a triggering frame. For
CID 24294: - A design in which a parameter that is N/A is present is not “simple and clean” - The baseline convention is to only pass in parameters that are applicable (that is why we have conditions like “FORMAT is HE_TB” in the TXVECTOR table) - The commenter's proposed change explicitly identifies how the issue can be fixed in a "simple and clean" manner, and should be adopted For
CID 24498: - Calling a parameter SCRAMBLER_INITIAL_VALUE when it does NOT contain the scrambler initial value is, well, completely irrational - There have been interop issues caused by the confusion between the scrambler initial value and the (scrambled) value of the Scrambler Initialization field, so it is even more important to make sure the parameter naming is not misleading - There are only 3 instances of the term, so there is no editorial cost to fixing this - I think a concern was expressed that
SCRAMBLER_INITIALIZATION_FIELD itself was misleading, because it's the value in that field after scrambling. I am happy to change the proposed parameter name to SCRAMBLED_SCRAMBLER_INITIALIZATION_FIELD to address that concern Similarly for
CID 24499, the issue is quite subtle and this has caused interop issues. To minimise the chance of future interop issues, a NOTE is more than justified. •
https://mentor.ieee.org/802.11/dcn/20/11-20-0317-02-00ax-resolution-for-misc-cids.docx
– Abhishek Patil
•
the following CIDs are deferred: 24552, 24311, 24400, 24401, 24352, 24348 For
CID 24349, where it says "parameter STA-ID" it should be "parameter STA_ID". •
https://mentor.ieee.org/802.11/dcn/20/11-20-0369-02-00ax-cr-cid-24054.docx
- Po-Kai Huang CID 24054 As discussed during the last teleconf, there seems to be disagreement as to whether a unicast 1SS Trigger frame will take a STA that supports dynamic
HT SMPS but not HE SMPS out of 1SS-only mode. We need to agree on what the answer is here; we cannot leave this interop issue open. It we agree that it does, then I suggest we make this clear by adding in the HE SMPS subclause: NOTE—A non-AP HE STA in dynamic SM power save mode that does not support HE dynamic SM power save and that receives an individually addressed Trigger frame addressed to it behaves as described in 11.2.6 (SM power save). [Po-Kai]: We discuss in the call that the proposed text does not touch baseline text. Everyone agrees that a STA in HE dynamic SM power save reacts to Trigger frame, the revised text reflect
that. Also, The STA switches to the multiple receive chain mode if it responds to the Trigger frame addressed to it is just duplication of "shall also enable its multiple receive chains if it responds to a Trigger frame [that starts a frame exchange sequence] that satisfies the following conditions" above and should be deleted. (Also "addressed to it" is weird -- a STA is not, I hope, going to respond to a Trigger frame not addressed to it.) I agree the baseline has this duplication too, and I will raise it in TGmd. [Po-Kai]: I think we discuss offline that baseline has similar text, and I receive comments from several people that they want to keep it. That is the reason
why I keep the text. I think you see the reasoning why I keep it as well. •
https://mentor.ieee.org/802.11/dcn/20/11-20-0316-02-00ax-resolution-for-cids-related-to-bss-color.docx
– Abhishek Patil
•
the following CIDs are deferred 24248, 24249, 24250 - I don't think the resolutions to
24242 and
24243 make sense (see attached) - "one of the following condition" needs to be "… conditions" - For
24248,
24249, 24250 the terminology is all over the place (see attached). Also some stuff is in a NOTE but needs to be normative (because it's a definition) - For
the non-CID proposal at the end, why not delete "HE" in the first bullet too? Looks inconsistent otherwise - For
24147 you said you had added "HE" in "so that other STAs can benefit from features relying on BSS color" but it's still missing - For
24515 there are some editorials (see attached) Thanks, Mark -- Mark RISON, Standards Architect, WLAN English/Esperanto/Français 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 |