|
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 helps
Ben
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 uploaded
Benjamin and all,
I thought "may" means may or may not. So "may" means "shall" in 802.11?
Oscar
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
Hi Chris, I believe that is an ‘obvious’ statement, however I would be okay adding it as a NOTE since it is informative.
Ali
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?
The AP shall transmit a Sensing Sounding Trigger frame to one or 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, multiple sequential trigger frames may be transmitted 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
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
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
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-0172-03-00bf-pdt-sensing-measurement-instance-general.docx
https://mentor.ieee.org/802.11/dcn/22/11-22-0173-03-00bf-pdt-tb-sensing-measurement-instance.docx
https://mentor.ieee.org/802.11/dcn/22/11-22-0174-02-00bf-pdt-non-tb-sensing-measurement-instance.docx
Best,
Cheng
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-0172-01-00bf-pdt-sensing-measurement-instance-general.docx
https://mentor.ieee.org/802.11/dcn/22/11-22-0173-01-00bf-pdt-tb-sensing-measurement-instance.docx
https://mentor.ieee.org/802.11/dcn/22/11-22-0174-00-00bf-pdt-non-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
Hi Chris, I believe that is an ‘obvious’ statement, however I would be okay adding it as a NOTE since it is informative.
Ali
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?
The AP shall transmit a Sensing Sounding Trigger frame to one or 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, multiple sequential trigger frames may be transmitted 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
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
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
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-0172-03-00bf-pdt-sensing-measurement-instance-general.docx
https://mentor.ieee.org/802.11/dcn/22/11-22-0173-03-00bf-pdt-tb-sensing-measurement-instance.docx
https://mentor.ieee.org/802.11/dcn/22/11-22-0174-02-00bf-pdt-non-tb-sensing-measurement-instance.docx
Best,
Cheng
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-0172-01-00bf-pdt-sensing-measurement-instance-general.docx
https://mentor.ieee.org/802.11/dcn/22/11-22-0173-01-00bf-pdt-tb-sensing-measurement-instance.docx
https://mentor.ieee.org/802.11/dcn/22/11-22-0174-00-00bf-pdt-non-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
|