| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
May is normative language. It defines an optional behavior or feature within scope of the standard. It is equivalent to "a conforming implementation may or may not include this". "Shall" is mandatory: an implementation is not conformant without the feature or behavior described.The key is "within the scope of the standard".
"Can" states a possibility out of scope standard. "Will" states a fact that is out of scope of the standard. "Can" and "will" are informative, as they do not define a behavior within the scope of the standard. IEEE-SA differentiates these terms for good reasons. When we have "may" we also need to have a complete definition of the feature or behavior sufficient to support implementation. In the example, I would look to find where conditions and/or details of what when the behavior is to occur, when allowed or not allowed, exactly what occurs when a device performs the optional behavior, and so forth. Without those details, the draft is not technically complete. Also, when preparing a PICS pro-forma "mays" should be included so that a PICS can identify the optional features and behaviors that are included. Incomplete specification of optional features will (statement of fact) frustrate folks trying to write test specs.
One can find many, many examples of "may" being used incorrectly in IEEE standards. In this case repetition doesn't make it right. Some people, when they review a standard during SA balloting, will look at each instance of "shall", "may", and "should" to ensure that these are not misused (i.e. are not describing things out of scope of the standard) and have been known to generate technical comments in support of a "no" vote. And yes, any comment regarding a normative statement (even an unintentional normative statement) is "technical" as misuse of normative language affects the technical content and completeness of the draft. A typical problem is a "may" without sufficient definition of the optional feature to support implementation, which means the draft is not technically complete and thus by rule not ready for SA balloting.
The next question is "does it really matter?" and the answer is yes, it can affect interoperability as it leads to misunderstanding and omissions as well as frustration when writing test specs, none of which promote interoperability. Speaking from experience 🙁
Hope that helpsBen
From: Oscar Au <oscar.au@xxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, February 17, 2022 5:23 PM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBF] Baseline PDT documents for Topic 8, 9, 11 uploadedBenjamin and all,
I thought "may" means may or may not. So "may" means "shall" in 802.11?
Oscar
On Wed, Feb 16, 2022 at 4:52 PM Benjamin Rolfe <ben@xxxxxxxxxxxxxx> wrote:
FWIW...the statement in red contains "may" which makes it normative, not information. So it would be incorrect to be in a note. As is, it is stating a permissible behavior, allowing multiple trigger frames to be sent during a TXOP.
Ben
From: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Sent: Wednesday, February 16, 2022 2:43 PM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBF] Baseline PDT documents for Topic 8, 9, 11 uploadedHi Chris, I believe that is an ‘obvious’ statement, however I would be okay adding it as a NOTE since it is informative.
Ali
From: Chris Beg <chris.beg@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, February 16, 2022 1:38 PM
To: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: Baseline PDT documents for Topic 8, 9, 11 uploaded
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Ali,
Yes, I do agree that both SU and MU operations may be exploited in any order.
What are your thoughts on adding the more generic statement shown in red below?
Thanks and regards,
-Chris
From: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx> On Behalf Of Ali Raissinia
Sent: February 16, 2022 11:04 AM
To: Chris Beg <chris.beg@xxxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: Baseline PDT documents for Topic 8, 9, 11 uploaded
Hi Chris,
In my opinion as long as AP is able to transmit multiple sensing Trigger Sounding frames during the ‘TF sounding phase’, it can exploit it to be for SU and/or MU UL operation in any order (SU, SU…. SU, MU… MU,MU….. MU,SU… ,etc.). MU cascading is undefined and perhaps not necessary. What do you think?
Regards,
Ali
From: Chris Beg <chris.beg@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, February 16, 2022 6:55 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] Baseline PDT documents for Topic 8, 9, 11 uploaded
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Cheng,
Thanks for putting all this material together.
I do have one suggested addition to the second paragraph in section 11.1.4.2.3 (TF Sounding Phase), that I would like to propose to everybody.
My suggestion is to highlight the potential usage of a MU cascading sequence, in the event there are more available STAs than UL resources.
What is everyone’s thoughts on adding the following red text into the paragraph below?
The AP shall transmit a Sensing Sounding Trigger frame to one ore more STAs that are sensing transmitters and that have responded in the polling phase of the TB sensing measurement instance to solict Responder-to-Initiator (R2I) NDP transmission(s). The Sensing Sounding Trigger frame shall allocate uplink resources for one or more STA’s R2I NDP transmission covering the full bandwidth. If the number of available sensing transmitters exceeds the available uplink resources, a MU cascading sequence may be used within the acquired TXOP. Any STA addressed by a User Info field in a Sensing Sounding Trigger frame shall transmit NDP SIFS after receiving the Sensing Sounding Trigger frame.
Thanks and regards,
-Chris
From: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx> On Behalf Of Chen, Cheng
Sent: February 15, 2022 4:18 PM
To: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx
Subject: RE: Baseline PDT documents for Topic 8, 9, 11 uploaded
Hello all,
Revisions for the PDT text documents for Topic 8, 9, and 11 were uploaded based on the feedback/comments received both at the TGbf calls and from offline emails. Let me know if you have any questions or comments.
https://mentor.ieee.org/802.11/dcn/22/11-22-0173-03-00bf-pdt-tb-sensing-measurement-instance.docx
Best,
Cheng
From: Chen, Cheng
Sent: Friday, January 28, 2022 1:19 PM
To: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx
Subject: Baseline PDT documents for Topic 8, 9, 11 uploaded
Hello all,
The baseline PDT documents for Topic 8, 9, and 11 were already uploaded, which can be found through:
https://mentor.ieee.org/802.11/dcn/22/11-22-0173-01-00bf-pdt-tb-sensing-measurement-instance.docx
Best,
Cheng
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
From: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Sent: Wednesday, February 16, 2022 2:43 PM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBF] Baseline PDT documents for Topic 8, 9, 11 uploadedHi Chris, I believe that is an ‘obvious’ statement, however I would be okay adding it as a NOTE since it is informative.
Ali
From: Chris Beg <chris.beg@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, February 16, 2022 1:38 PM
To: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: Baseline PDT documents for Topic 8, 9, 11 uploaded
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Ali,
Yes, I do agree that both SU and MU operations may be exploited in any order.
What are your thoughts on adding the more generic statement shown in red below?
Thanks and regards,
-Chris
From: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx> On Behalf Of Ali Raissinia
Sent: February 16, 2022 11:04 AM
To: Chris Beg <chris.beg@xxxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: Baseline PDT documents for Topic 8, 9, 11 uploaded
Hi Chris,
In my opinion as long as AP is able to transmit multiple sensing Trigger Sounding frames during the ‘TF sounding phase’, it can exploit it to be for SU and/or MU UL operation in any order (SU, SU…. SU, MU… MU,MU….. MU,SU… ,etc.). MU cascading is undefined and perhaps not necessary. What do you think?
Regards,
Ali
From: Chris Beg <chris.beg@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, February 16, 2022 6:55 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] Baseline PDT documents for Topic 8, 9, 11 uploaded
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Cheng,
Thanks for putting all this material together.
I do have one suggested addition to the second paragraph in section 11.1.4.2.3 (TF Sounding Phase), that I would like to propose to everybody.
My suggestion is to highlight the potential usage of a MU cascading sequence, in the event there are more available STAs than UL resources.
What is everyone’s thoughts on adding the following red text into the paragraph below?
The AP shall transmit a Sensing Sounding Trigger frame to one ore more STAs that are sensing transmitters and that have responded in the polling phase of the TB sensing measurement instance to solict Responder-to-Initiator (R2I) NDP transmission(s). The Sensing Sounding Trigger frame shall allocate uplink resources for one or more STA’s R2I NDP transmission covering the full bandwidth. If the number of available sensing transmitters exceeds the available uplink resources, a MU cascading sequence may be used within the acquired TXOP. Any STA addressed by a User Info field in a Sensing Sounding Trigger frame shall transmit NDP SIFS after receiving the Sensing Sounding Trigger frame.
Thanks and regards,
-Chris
From: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx> On Behalf Of Chen, Cheng
Sent: February 15, 2022 4:18 PM
To: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx
Subject: RE: Baseline PDT documents for Topic 8, 9, 11 uploaded
Hello all,
Revisions for the PDT text documents for Topic 8, 9, and 11 were uploaded based on the feedback/comments received both at the TGbf calls and from offline emails. Let me know if you have any questions or comments.
https://mentor.ieee.org/802.11/dcn/22/11-22-0173-03-00bf-pdt-tb-sensing-measurement-instance.docx
Best,
Cheng
From: Chen, Cheng
Sent: Friday, January 28, 2022 1:19 PM
To: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx
Subject: Baseline PDT documents for Topic 8, 9, 11 uploaded
Hello all,
The baseline PDT documents for Topic 8, 9, and 11 were already uploaded, which can be found through:
https://mentor.ieee.org/802.11/dcn/22/11-22-0173-01-00bf-pdt-tb-sensing-measurement-instance.docx
Best,
Cheng
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1
To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1