Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [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 ---
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

Get BlueMail for Android
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 Required

Discussion:

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


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