| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Brian, Thanks for your discussion. Please find my response inline. Regards Guogang Huang 发件人: Brian Hart (brianh)
[mailto:brianh@xxxxxxxxx] Hi Guogang Over the years, I’ve listened to lots of 802.11 discussions along the following lines:
In that light, I’m troubled by your choice to reuse the non-AP STA “power save” term for AP power save. I suspect the only way to do this safely is to carefully review
the 3000+ pages in clauses 3-14, 26, and 34 and, every time we find a reference to “power save” in connection with “STA”, decide if this language:
… where in several / many cases, different experts might reasonably disagree about the right way forward. [Guogang Huang] What we are talking about the AP power save should be
AP MLD power save. And I don’t change the baseline, the legacy AP still doesn’t support the power save. For the current text on non-AP STA power save, we don’t need to make any change.
As a random example, consider: 9.6.12.6 “The TDLS Peer Traffic Indication Action field indicates the state of the power save buffer at the STA supporting TPU that is
buffering data for a TDLS peer STA in power save mode.” This probably should be rewritten to apply to non-AP STAs only. [Guogang Huang]For this example, I don’t think the text is ambiguous. Because it is TDLS.
Then there is the dual problem: there is a lot of language that assumes that only one party ? AP or non-AP STA ? needs to perform a task. Would this language need to
be generalized to include the counterparty, with a similarly large potential scope of text needing review and a positive decision to change or not change the text: As another random example, consider: 11.2.1, “A
non-AP STA can be in one of two power management modes: - Active mode …” Here I think you’ll have to rewrite this language to account for both AP and non-AP STAs.
[Guogang Huang]Currently, I think it’s better to add a subclause 35.3.X AP MLD power save.
I haven’t done the work, so I’m not sure if we’re talking one or ten or a hundred or a thousand instances, but I wouldn’t be surprised if it was well over a hundred
instances. I could imagine this might take an extended period of personal review time, then many hours or days of IEEE group time to review and debate the resulting work. In that light, can you share if you’ve started / completed this kind of analysis, and
what is the ballpark ultimate number of pages of change-text that you foresee? The alternative of course is to define a new and narrower term for “AP power save”. That alternative seems to have the benefit of not requiring such a broad and detailed
analysis. [Guogang Huang]It’s better to define as AP MLD power save.
Comments / contrasting opinions? Best wishes Brian From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi all, I have presented my contribution 22/356r5 in the call. But there is no time to take questions. I initiate this email thread to further discussion for doc 22/356. Please let me know your questions and comments. Regards Guogang Huang To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |