Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Working Group Reflector ---
> It seems to me MC-OOK represents the technical details of
TGba much better than 'WUR OOK'. Clause 30 is based on the MC-OOK (using multi-carriers) to generate OOK waveform so I'm not sure it is a good idea to rename that to something unrelated. OK, but the fundamental point remains: What are the actual requirements for WUR waveforms?
Are they required to be generated (not just "based on") as shown in Annex AC (apparently not, since this is informative), or can they be generated in some other way (but in that case we need a specification for what the actual requirements are). The proposal in 22/1035r1 resolves this in the direction of confirming that Annex AC is informative, and that WUR waveforms don't have to be generated using MC-OOK, but just need to have some specific underlying characteristics.
This seems to me to be a reasonable resolution. I would certainly entertain an alternative resolution in which the direction was to make Annex AC normative and clarify that WUR waveforms shall be generated using MC-OOK, but in the absence of such a counterproposal I think 22/1035r1 is a reasonable resolution. > (also not sure if this type of change is in scope of 11me since
TGba already spent a lot of time to get to this consensus). TGme's raison d'être is to fix problems that were not noticed and fixed earlier (well, that and folding in amendments). > Reading the SP and motion results, it seems like there is no consensus in the group so better resolution should be 'REJECTED' and put the reason as 'the group couldn't reach consensus with the SP/motion results' and move on. I'll repeat the comments I made yesterday.
I do not think "the group couldn't reach consensus with the SP/motion results" is an appropriate resolution here. For one, there was an explicit motion to reject, and it failed. 13/0230r5 (802.11 Comment Resolution – a Tutorial) indicates that a "no consensus" resolution can be used when:
–
The CRC has considered one or more other resolutions that attempt to satisfy the comment, but no such resolution has received 75% approval.
–
It should be recorded in the minutes what other resolution(s) have been considered, together with the results of any straw polls or motions on those alternative solutions so that the commenter can
understand that this solution was used after due diligence to satisfy the comment. 11/1625r2 (802.11 Comment Resolution Guide) further clarifies that: “cannot reach consensus” should be a
resolution of last resort. It also fails the “responsiveness” test. It should be used only when other resolutions have been considered and debated and no consensus has been discovered for any other resolution.
It should not be used as a shorthand for “we can’t be bothered to find a proper resolution” or “we don’t want to change the draft and won’t tell you why”.
Over-use of this resolution is likely to lead to increased negative votes and hostile debate in the WG. The WG chair has also confirmed by email that: the “lack of consensus” resolution should be used very sparingly, and typically late in the recirculation process. 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 From:
Minyoung Park <mpark.ieee@xxxxxxxxx> --- This message came from the IEEE 802.11 Working Group Reflector ---
Hello Joseph, Thanks for preparing the comment resolution. It seems to me MC-OOK represents the technical details of TGba much better than 'WUR OOK'. Clause 30 is based on the MC-OOK (using multi-carriers) to generate OOK waveform so I'm not sure it is a good idea to rename that to something unrelated.
(also not sure if this type of change is in scope of 11me since TGba already spent a lot of time to get to this consensus). Regarding the following text, 'should' is a valid normative verb so I don't understand why you consider 'should' is not a typical normative verb. The WUR PHY
uses the multicarrier on-off keying (MC-OOK) modulation for (#1128)WUR-Sync and WUR-Data fields. MC-OOK is defined as an on-off keying, modulated with a multicarrier signal. The multicarrier signal
should be generated using contiguous 13 subcarriers, cantered within a 20 MHz channel, with a subcarrier spacing of 312.5 kHz and the centre subcarrier (#1131)being null. The subcarrier coefficients may take values from
the BPSK, QPSK, 16-QAM, 64-QAM, or 256-QAM constellation symbols. Reading the SP and motion results, it seems like there is no consensus in the group so better resolution should be 'REJECTED' and put the reason as 'the group couldn't reach consensus with the SP/motion results' and move on. Best regards, Minyoung On Wed, Sep 7, 2022 at 5:15 PM Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |