Hello Jon,
CID 164 is a comment from me on "shall be capable", with "shall be able to" also mentioned in the proposed changes.
CID 181 is also a comment from me on "shall be capable" and "shall be able to".
CIDs 164 and 181 are essentially the same comment.
CID 546 is a comment by Mike on "shall be capable".
We've resolved CID 546. But it only addresses "shall be capable",
not "shall be able".
Below I'm proposing changes to address the "shall be able to"
part of CIDs 164 and 181, given that the "shall be capable" part
has already been addressed in CID 546.
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: Jon Rosdahl <jrosdahl@xxxxxxxx>
Sent: Thursday, 11 November 2021 21:16
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] GEN AdHoc - CID 164 "Shall be capable of:"
SO let me correct my email.
Mark,
As I worked on your answers below, they seemed awfully familiar to me, then I realized tht they are the changes in CID 181.
So I have to ask why we have 3 comments that while similar are overlapping.
I think that rejecting CID 164 as the changes requested in CID 546 and CID 181 have made this CID moot, or at least revised, the changes have been made by the resolutions of CID 546 and 181.
What do you think?
Jon
-----------------------------------------------------------------------------
Jon Rosdahl Engineer, Senior Staff
IEEE 802 Executive Secretary Qualcomm Technologies, Inc.
office: 801-492-4023 10871 North 5750 West
cell: 801-376-6435 Highland, UT 84003
A Job is only necessary to eat!
A Family is necessary to be happy!!
On Thu, Nov 11, 2021 at 1:38 PM Jon Rosdahl <jrosdahl@xxxxxxxx> wrote:
Mark,
As I worked on your answers below, they seemed awfully familiar to me, then I realized tht they are the changes in CID 181.
So I have to ask why we have 3 comments that while similar are overlapping.
I think that rejecting CID 240 as the changes requested in CID 546 and CID 181 have made this CID moot, or at least revised, the changes have been made by the the resolutions of CID 546 and 181.
What do you think?
Jon
-----------------------------------------------------------------------------
Jon Rosdahl Engineer, Senior Staff
IEEE 802 Executive Secretary Qualcomm Technologies, Inc.
office: 801-492-4023 10871 North 5750 West
cell: 801-376-6435 Highland, UT 84003
A Job is only necessary to eat!
A Family is necessary to be happy!!
On Thu, Nov 11, 2021 at 5:50 AM Jon Rosdahl <jrosdahl@xxxxxxxx> wrote:
Thanks Mark for all the work in this,,
I wish you would have included page and line number as you went so this could be completely done..
Thanks again
Jin
On Nov 11, 2021, at 2:15 AM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Hello Jon,
We already fixed the "shall be capable of"s under CID 546. What we
discussed yesterday was the "shall be able to"s. And as for CID 546
I think "shall support" is the best term if it's really something that
needs to be supported rather than actually done at that point (which
should be just "shall"). So I suggest:
9.1
A STA shall be able to properly construct a subset
of the frames specified in this clause for transmission and to decode a (potentially different) subset of the
frames specified in this clause upon validation following reception. The particular subset of these frames
that a STA constructs and decodes is determined by the functions supported by that particular STA. A STA
shall validate every received frame using the frame check sequence (FCS) and interpret certain
fields from the MAC headers of all frames.
->
A STA shall properly construct a subset
of the frames specified in this clause for transmission and decode a (potentially different) subset of the
frames specified in this clause upon validation following reception. The particular subset of these frames
that a STA constructs and decodes is determined by the functions supported by that particular STA. A STA
shall validate every received frame using the frame check sequence (FCS) and interpret certain
fields from the MAC headers of all frames.
10.3.1
To support the proper operation of the RTS/CTS by non-DMG STAs, RTS/DMG CTS by DMG STAs, and the
virtual CS mechanism, a non-DMG STA shall be able to interpret Control frames with the Subtype subfield
equal to RTS or CTS, and a DMG STA shall be able to interpret Control frames with the Subtype
subfield equal to RTS or DMG CTS.
->
To support the proper operation of the RTS/CTS by non-DMG STAs, RTS/DMG CTS by DMG STAs, and the
virtual CS mechanism, a non-DMG STA shall interpret Control frames with the Subtype subfield
equal to RTS or CTS, and a DMG STA shall interpret Control frames with the Subtype
subfield equal to RTS or DMG CTS.
10.23.3.1
A non-AP QoS STA that is a non-S1G STA shall be able to respond to QoS (+)CF-Poll frames received from
an HC with the Address 1 field matching their own addresses.
->
A non-AP QoS STA that is a non-S1G STA shall respond to QoS (+)CF-Poll frames received from
an HC with the Address 1 field matching their own addresses.
10.23.3.5.1
A QoS STA shall be able to receive QoS +CF-Ack frames.
->
A QoS STA shall support reception of QoS +CF-Ack frames.
;
A QoS STA shall be able to
process received QoS Data frames with subtypes that include +CF-Ack when the STA to which the
acknowledgment is directed is the same as the STA addressed by the Address 1 field of that Data frame.
->
A QoS STA shall
process received QoS Data frames with subtypes that include +CF-Ack when the STA to which the
acknowledgment is directed is the same as the STA addressed by the Address 1 field of that Data frame.
10.23.5.1
A non-AP STA with dot11RAWOperationImplemented equal to true shall be able to follow the RAW
procedure, as described in this subclause.
->
A non-AP STA with dot11RAWOperationImplemented equal to true shall follow the RAW
procedure, as described in this subclause.
10.24.3.3
A mesh STA with dot11MCCAActivated equal to true shall be able to track at least
dot11MCCATrackStatesActive MCCAOP reservations, including its own reservations. If the number of
tracked MCCAOP reservations is less than dot11MCCATrackStatesActive, the mesh STA shall be able to
track, set up, and accept additional reservations. In this case, the mesh STA shall set the Accept Reservations
subfield in the Flags field to 1 in the MCCAOP Advertisement Overview elements it transmits.
->
A mesh STA with dot11MCCAActivated equal to true shall support tracking
dot11MCCATrackStatesActive MCCAOP reservations, including its own reservations. If the number of
tracked MCCAOP reservations is less than dot11MCCATrackStatesActive, the mesh STA shall support
tracking, setting up, and accepting additional reservations. In this case, the mesh STA shall set the Accept Reservations
subfield in the Flags field to 1 in the MCCAOP Advertisement Overview elements it transmits.
10.30.2.2
During a PSMP sequence, a STA shall be able to receive frames during its scheduled PSMP-DTT and is not
required to be able to receive frames at other times.
->
During a PSMP sequence, a STA shall support receiving frames during its scheduled PSMP-DTT; it is not
required to support receiving frames at other times.
10.46.1
An S1G STA that is starting a BSS shall be able to receive and transmit at each of the <S1G-MCS, NSS>
tuple values indicated by the Basic S1G-MCS and NSS Set field of the S1G Operation parameter of the
MLME-START.request primitive and shall be able to receive at each of the <S1G-MCS, NSS> tuple values
indicated by the Supported S1G-MCS and NSS Set field of the S1G Capabilities parameter of the MLME-
START.request primitive.
->
An S1G STA that is starting a BSS shall support receiving and transmitting at each of the <S1G-MCS, NSS>
tuple values indicated by the Basic S1G-MCS and NSS Set field of the S1G Operation parameter of the
MLME-START.request primitive and shall support receiving at each of the <S1G-MCS, NSS> tuple values
indicated by the Supported S1G-MCS and NSS Set field of the S1G Capabilities parameter of the MLME-
START.request primitive.
10.53.4
A Sectorized beam capable AP supporting
TXOP-based sectorization operation shall be able to transmit or receive through both the omnidirectional
beam or the sectorized beams.
->
A Sectorized beam capable AP supporting
TXOP-based sectorization operation shall support transmitting or receiving through both the omnidirectional
beam or the sectorized beams.
11.14
An HT STA that is starting or joining a BSS shall be able to receive and transmit at each of the MCS values
listed in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive
or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-
JOIN.request primitive.
->
An HT STA that is starting or joining a BSS shall support receiving and transmitting at each of the MCS values
listed in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive
or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-
JOIN.request primitive.
11.26.3
An HCCA AP for which dot11PublicTXOPNegotiationActivated is true or
dot11ProtectedTXOPNegotiationActivated is true shall be able to maintain one or more dot11APCEntry(s) for
each collaboration candidate in the dot11APCTable.
->
An HCCA AP for which dot11PublicTXOPNegotiationActivated is true or
dot11ProtectedTXOPNegotiationActivated is true shall maintain dot11APCEntry(s) for
each collaboration candidate in the dot11APCTable.
11.38.1
A STA that is starting a VHT BSS shall be able to receive and transmit at each of the <VHT-MCS, NSS> tuple
values indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter of the MLME-
START.request primitive and shall be able to receive at each of the <VHT-MCS, NSS> tuple values indicated
by the Supported VHT-MCS And NSS Set field of the VHT Capabilities parameter of the
MLME-START.request primitive.
->
A STA that is starting a VHT BSS shall support receiving and transmitting at each of the <VHT-MCS, NSS> tuple
values indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter of the MLME-
START.request primitive and shall support receiving at each of the <VHT-MCS, NSS> tuple values indicated
by the Supported VHT-MCS And NSS Set field of the VHT Capabilities parameter of the
MLME-START.request primitive.
11.41
The STA that is starting a TVHT BSS shall be able to receive and transmit at each of the <VHT-MCS, NSS>
tuple values indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter of the
MLME-START.request primitive and shall be able to receive at each of the <VHT-MCS, NSS> tuple values
indicated by the Supported VHT-MCS and NSS Set field of the VHT Capabilities parameter of the MLME-
START.request primitive.
->
A STA that is starting a TVHT BSS shall support receiving and transmitting at each of the <VHT-MCS, NSS>
tuple values indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter of the
MLME-START.request primitive and shall support receiving at each of the <VHT-MCS, NSS> tuple values
indicated by the Supported VHT-MCS and NSS Set field of the VHT Capabilities parameter of the MLME-
START.request primitive.
11.48.1
A STA that is starting a CMMG BSS shall be able to receive and transmit at each of the <CMMG-MCS, NSS>
tuple values indicated by the Basic CMMG-MCS and NSS Set field of the CMMG Operation parameter of the
MLME-START.request primitive and shall be able to receive at each of the <CMMG-MCS, NSS> tuple
values indicated by the Supported CMMG-MCS and NSS Set field of the CMMG Capabilities parameter of the
MLME-START.request primitive.
->
A STA that is starting a CMMG BSS shall support receiving and transmitting at each of the <CMMG-MCS, NSS>
tuple values indicated by the Basic CMMG-MCS and NSS Set field of the CMMG Operation parameter of the
MLME-START.request primitive and shall support receiving at each of the <CMMG-MCS, NSS> tuple
values indicated by the Supported CMMG-MCS and NSS Set field of the CMMG Capabilities parameter of the
MLME-START.request primitive.
19.1.4
HT-greenfield format (HT_GF): HT packets of this format do not contain a non-HT compatible
part. Support for HT-greenfield format is optional. An HT STA that does not support the reception
of an HT-greenfield format packet shall be able to detect that an HT-greenfield format packet is an
HT transmission (as opposed to a non-HT transmission). In this case, the receiver shall decode the
HT-SIG and determine whether the HT-SIG cyclic redundancy check (CRC) passes.
->
HT-greenfield format (HT_GF): HT packets of this format do not contain a non-HT compatible
part. Support for HT-greenfield format is optional. An HT STA that does not support the reception
of an HT-greenfield format packet shall detect that an HT-greenfield format packet is an
HT transmission (as opposed to a non-HT transmission). In this case, the receiver shall decode the
HT-SIG and determine whether the HT-SIG cyclic redundancy check (CRC) passes.
19.3.19.7
The receiver shall be able to decode a PPDU that was transmitted with a RIFS separation from the previous
PPDU.
->
The receiver shall support receiving a PPDU that was transmitted with a RIFS separation from the previous
PPDU.
Bonus (other "be able to"s):
9.4.2.130
NOTE—The delay between the moment a STA receives a DMG Wakeup Schedule element over the air and the moment
the STA interprets the value of the BI Start Time field in the element can be large, to the extent that the beacon interval
during which the BI Start Time filed is interpreted is different from the beacon interval during which the DMG Wakeup
Schedule element is received. Excluding an interval from the range of BI Start Time field values at transmission enables
the receiving STA to be able to correctly interpret any received value for the BI Start Time field of the DMG Wakeup
Schedule element belonging to a STA in PS mode
->
NOTE—The delay between the moment a STA receives a DMG Wakeup Schedule element over the air and the moment
the STA interprets the value of the BI Start Time field in the element can be large, to the extent that the beacon interval
during which the BI Start Time filed is interpreted is different from the beacon interval during which the DMG Wakeup
Schedule element is received. Excluding an interval from the range of BI Start Time field values at transmission enables
the receiving STA to correctly interpret any received value for the BI Start Time field of the DMG Wakeup
Schedule element belonging to a STA in PS mode
Table 9-271
However, a STA that sets MU Beamformee Capable to 0 is not
required to be able to demodulate a VHT MU PPDU with only one nonzero RXVECTOR parameter NUM_STS[p],
for 0 £ p £ 3.
->
However, a STA that sets MU Beamformee Capable to 0 might
not demodulate a VHT MU PPDU with only one nonzero RXVECTOR parameter NUM_STS[p],
for 0 £ p £ 3.
10.5
The STA may implement additional timers to be able to receive
additional concurrent MSDUs or MMPDUs.
->
The STA may implement additional timers to receive
additional concurrent MSDUs or MMPDUs.
10.23.3.5.1
STAs are not required to be able to transmit QoS Data frames with subtypes that include +CF-
Ack.
->
STAs are not required to transmit QoS Data frames with subtypes that include +CF-
Ack.
10.23.4.3
A STA may have an operational rate lower than the minimum PHY rate due to varying conditions on the
channel for a short time and still may be able to sustain the TS without changing the minimum PHY rate in the
TSPEC.
->
A STA may have an operational rate lower than the minimum PHY rate due to varying conditions on the
channel for a short time and still sustain the TS without changing the minimum PHY rate in the
TSPEC.
10.28.6
NOTE—It is not necessary to be able to parse the vendor-specific content to locate the MME.
->
NOTE—It is not necessary to parse the vendor-specific content to locate the MME.
10.47.2
STAs need to be able to predict the duration of response transmissions for Duration field calculations and in
addition, TWT requesting STAs might need TWT start times delivered in response frames.
->
STAs need to predict the duration of response transmissions for Duration field calculations and in
addition, TWT requesting STAs might need TWT start times delivered in response frames.
10.54.5.3
The AP shall determine the PARTIAL_AID of the next hop non-AP STA as described in 10.21
(Group ID, partial AID, Uplink Indication, and COLOR in S1G PPDUs) using the BSSID of the
S1G relay AP’s BSS and the AID of the next hop non-AP STA to be able to use the implicit Ack
procedure.
->
The AP shall determine the PARTIAL_AID of the next hop non-AP STA as described in 10.21
(Group ID, partial AID, Uplink Indication, and COLOR in S1G PPDUs) using the BSSID of the
S1G relay AP’s BSS and the AID of the next hop non-AP STA that can [TBC intent here -- need S1G SME] use the implicit Ack
procedure.
11.2.3.5.2
A non-AP STA that uses U-APSD might not be able to receive all AP transmitted frames during the service
period due to interference observed at the non-AP STA.
->
A non-AP STA that uses U-APSD might not receive all AP transmitted frames during the service
period due to interference observed at the non-AP STA.
11.7.5
STAs that are extended spectrum management capable and have dot11RadioMeasurementActivated equal to
true should be able to reduce their EIRP to 0 dBm.
->
STAs that are extended spectrum management capable and have dot11RadioMeasurementActivated equal to
true should support reducing their EIRP to 0 dBm.
11.11.4
The licensed
operator may be able to use these reports to identify interfering STAs or map overlapping coverage in a
multiple BSS situation.
->
The licensed
operator might use these reports to identify interfering STAs or map overlapping coverage in a
multiple BSS situation.
11.22.9
The AP’s SME causes the QoS mapping to be available to higher layer
protocols or applications so they will be able to set the correct priority in an MA-UNITDATA.request
primitive.
->
The AP’s SME causes the QoS mapping to be available to higher layer
protocols or applications so they can set the correct priority in an MA-UNITDATA.request
primitive.
;
Upon
receiving the QoS Map element, the non-AP STA’s SME causes the QoS mapping to be available to higher
layer protocols or applications so they will be able to set the correct priority in an MA-UNITDATA.request
primitive.
->
Upon
receiving the QoS Map element, the non-AP STA’s SME causes the QoS mapping to be available to higher
layer protocols or applications so they can set the correct priority in an MA-UNITDATA.request
primitive.
11.40
NOTE 8—It might take a long time for a STA to change its operating mode following the transmission of the Operating
Mode Notification frame and during that time it might not be able to receive frames resulting in frame loss.
->
NOTE 8—It might take a long time for a STA to change its operating mode following the transmission of the Operating
Mode Notification frame and during that time it might not receive frames, resulting in frame loss.
18.1.2
NOTE—A Class 2 ERP STA will not be able to operate in a BSS whose AP includes in the basic rate set, and uses for
transmission of group-addressed frames, only rates that the STA does not support.
->
NOTE—A Class 2 ERP STA cannot operate in a BSS whose AP includes in the basic rate set, and uses for
transmission of group-addressed frames, only rates that the STA does not support.
19.1.1
NOTE—A Class 2 HT STA will not be able to operate in a BSS whose AP includes in the basic rate/HT-MCS set, and
uses for transmission of group-addressed frames, only rates/HT-MCSs that the STA does not support.
->
NOTE—A Class 2 HT STA cannot operate in a BSS whose AP includes in the basic rate/HT-MCS set, and
uses for transmission of group-addressed frames, only rates/HT-MCSs that the STA does not support.
P.1
Furthermore, the device’s clock frequency typically does not match the
clock frequency of the synchronized sensors, and so the device should transmit on the same channel multiple
widely spaced times in order for the sensors to estimate the device’s clock frequency relative to themselves
and to be able to suitably scale the device’s advertised times of departure.
->
Furthermore, the device’s clock frequency typically does not match the
clock frequency of the synchronized sensors, and so the device should transmit on the same channel multiple
widely spaced times in order for the sensors to estimate the device’s clock frequency relative to themselves
and suitably scale the device’s advertised times of departure.
R.2.2
Since the laptop’s SME now knows it should be able to successfully authenticate with the network,
the STA associates to the AP.
->
Since the laptop’s SME now knows it can authenticate with the network,
the STA associates to the AP.
R.5.1
The second and third features provide the means for a client without proper security credentials to be able to
place an emergency call.
->
The second and third features provide the means for a client without proper security credentials to
place an emergency call.
R.5.2
In the latter case, the non-AP STA will be able to gain access to the network without using security
credentials and make an emergency call.
->
In the latter case, the non-AP STA can gain access to the network without using security
credentials and make an emergency call.
S.8.4
Note, since the PREQ element is sent in an individually addressed frame, every sender of the individually
addressed PREQ element will be able to determine whether the next mesh STA toward the root mesh STA
has received the PREQ element.
->
Note, since the PREQ element is sent in an individually addressed frame, every sender of the individually
addressed PREQ element can determine whether the next mesh STA toward the root mesh STA
has received the PREQ element.
S.8.5
Note that since the PREP element is sent in an individually addressed frame, every sender of the PREP
element will be able to determine whether the next mesh STA has received the PREP element.
->
Note that since the PREP element is sent in an individually addressed frame, every sender of the PREP
element can determine whether the next mesh STA has received the PREP element.
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: Jon Rosdahl <jrosdahl@xxxxxxxx>
Sent: Thursday, 11 November 2021 03:23
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] GEN AdHoc - CID 164 "Shall be capable of:"
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
CID
Page
Clause
Comment
Proposed Change
164
“shall be capable of” is not clear. It might allow a device to be capable of doing something, but not actually do it
Change to “shall” in each case. Ditto “shall be able to”
AdHoc Notes:
GEN: 2021-10-01 15:33:36Z – status set to: Submission Required
GEN: 2021-05-12 22:27:19Z – status set to: Submission RequiredDiscussion:
28 Instances of “shall be capable of”
The first instance at P1745.5 “A STA shall be capable of receiving MPDUs, containing all or part of an MSDU, of arbitrary length that is less than or equal to the maximum MSDU size as defined in 9.2.4.7 (Frame Body field), plus any security encapsulation overhead, plus MAC header and FCS.
Changing as requested:
A STA shall receive MPDUs, containing all or part of an MSDU, of arbitrary length that is less than or equal to the maximum MSDU size as defined in 9.2.4.7 (Frame Body field), plus any security encapsulation overhead, plus MAC header and FCS.
Does not read correctly.
This is similar to the other 27 instances.
Proposed Resolution:
Reject: The change of “shall be capable of” to “shall” does not provide a complete sentence. While making a more extensive change to the sentence to some other form may be done, the sentence is not wrong or ambiguous.
Input?
Jon
-----------------------------------------------------------------------------
Jon Rosdahl Engineer, Senior Staff
IEEE 802 Executive Secretary Qualcomm Technologies, Inc.
office: 801-492-4023 10871 North 5750 West
cell: 801-376-6435 Highland, UT 84003
A Job is only necessary to eat!
A Family is necessary to be happy!!
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1