Here is a list of REVme CIDs that I believe are planned or likely to be Rejected, for Insufficient Details during the November plenary, so that we can move on to the first WG LB.
The second list is CIDs that are being worked, but we are running out of time. These are “on the chopping block” to also be Rejected.
If anyone has a CID on this list (you filed it, or your assigned to it) that you believe is incorrectly on this list, please let me know, asap.
CID | Commenter | Assignee | Comment | Proposed Change |
43 | David Goodall | David GOODALL | Use of Length/type encoding via the EPD feature (Ethertype protocol decrimination) would save an additional 6 octets per data frame for 802.11ah STAs. This would be very useful particularly in regulatory domains with duty cycle requirements since it would save 320 usecs per data frame at the MCS10 rate. | Define an EPD bit in the S1G Capability Element to signal support for Length/Type encoding when set to 1. |
44 | David Goodall | David GOODALL | The following statement appears to be incorrect for an announced TWT agreement where the NDP Paging field is not present: "If the NDP Paging field was not present in the TWT response corresponding to a TWT agreement, the TWT requesting STA shall be in the awake state following each TWT start time associated with each TWT agreement for the AdjustedMinimumTWTWakeDuration associated with that TWT agreement even if no PS-Poll frame, NDP PS-Poll frame, or U-APSD trigger frame has been transmitted by the STA or until it has received an EOSP field equal to 1 from the TWT responding STA, whichever occurs first." That seems to be in contradiction to how an announced TWT agreement works since the AP can't know that the STA is awake until a frame is received that indicates the STA is either in Active state or no longer in power save state. | Maybe this whole section should be rewritten. The TWT section 26.8 in 11ax is much clearer although the feature is not quite the same. |
120 | Kazuyuki Sakoda | Mark HAMILTON | 802.11ah introduced a lot of subclauses directly under clause 10, i.e., from 10.46 (S1G BSS Operation) to 10.63 (S1G BSS type and STA type). Many of them are only applicable to S1G STAs. It will be more reader friendly, if these subclauses are grouped as a family of S1G STA features. | Create a subclause under clause 10 that groups miscellaneous S1G operations, and relocate many of the subclauses 10.46~10.63 to it, making these subclauses to be level3 subclauses such as 10.46.1~10.46.18. |
122 | Kazuyuki Sakoda | Mark HAMILTON | Subclause 10.41 (CDMG AP or PCP clustering) is talking about MLME rather than MAC. Entire subclause should be relocated to somewhere under clause 11. MLME. | As in comment |
123 | Kazuyuki Sakoda | Mark HAMILTON | Subclause 10.40 (DMG and CMMG AP or PCP clustering) is talking about MLME rather than MAC. Entire subclause should be relocated to somewhere under clause 11. MLME. | As in comment |
173 | Mark RISON | Mark RISON | Sometimes fields described as "(optional)" in their defining figure don't say ", if present," in their description | Add ", where present," where missing |
198 | Mark RISON | Mark HAMILTON | "A-MSDU frame" is not clear | Either change each of the ~12 instances to "MPDU that contains an A-MSDU" or define the term in 3.2 |
242 | Mark RISON | Mark RISON | Either update the stuff on DCF to match the way the stuff on EDCA was updated (e.g. retry counts) or deprecate DCF | As it says in the comment |
243 | Mark RISON | Mark HAMILTON | Separate the stuff on DCF from the stuff on EDCA. At the moment some EDCA stuff is buried in the middle of subclauses ostensibly about DCF | As it says in the comment |
272 | Mark RISON | Mark RISON | "If a CTS or Ack frame is carried in a non-HT PPDU, the primary rate is defined to be the highest rate
in the BSSBasicRateSet parameter that is less than or equal to the rate (or non-HT reference rate;
see 10.6.11 (Non-HT basic rate calculation)) of the previous frame. If no rate in the
BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest
mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate;
see 10.6.11 (Non-HT basic rate calculation)) of the previous frame. [...] The STA shall transmit the non-HT PPDU CTS or Ack frame at [...] the primary rate" but also "If the PSDU containing the received frame is of the modulation class HT or VHT and the control
response frame is carried in a non-HT PPDU, the control response frame shall be transmitted in a
PSDU using one of the ERP-OFDM or OFDM modulation classes." So say the basic rate set is 1, 2 Mbps but not 6 Mbps, and a control response frame is sent for an HT-MCS 0 frame, what rate is used? The first rule says 2 Mbps, but the second rule says it can't be that | As it says in the comment |
281 | Mark RISON | Mark RISON | "A non-VHT and non-S1G STA that is addressed by an RTS frame or a VHT STA that is addressed by
an RTS frame carried in a non-HT or non-HT duplicate PPDU that has a nonbandwidth signaling TA or a
VHT STA that is addressed by an RTS frame in a format other than non-HT or non-HT duplicate behaves as
follows:
-- If the NAV indicates idle, the STA ***shall*** respond with a CTS frame after a SIFS.
-- Otherwise, the STA shall not respond with a CTS frame." contradicts the second half of"A STA that receives an RTS frame addressed to it considers the NAV in determining whether to respond
with CTS, ***unless*** the NAV was set by a frame originating from the STA sending the RTS frame (see
10.23.2.2 (EDCA backoff procedure))." | As it says in the comment |
282 | Mark RISON | Mark HAMILTON | There are still residual issues with "remaining TXOP duration" (see 11md CIDs 5058+5061; also from MarkH:
- "remaining duration of the TXOP", in NOTE 2 of 9.2.5.2, and last line of 9.2.5.2.
- "remaining duration of the TXOP", in 9.2.5.4 (a)(2), (b)(2) and (c)(1).
- "remaining duration of the TXOP", in 9.3.1.13
- "expiration of the TXOP duration", in 10.3.2.10.1
- "remaining duration of the TXOP", in 10.3.2.10.1
- "remaining TXOP duration", in 10.3.2.10.1
- "time remaining in the TXOP", in 10.23.3.2.3 (2x)
- "remaining TXOP duration", in 10.23.3.3
- "remaining duration of the GCR TXOP" (is that different?), in 10.25.9.4
- "remaining TXOP or SP duration", in 10.29.4
- "time remaining in the TXOP", in 10.39.7.3.
- "the remaining TXOP or SP duration", in 10.50.2
- "duration of the remaining TXOP", in 10.53.4
- "expiration of the current TXOP" in G.3
- "expiration of TXOP" in G.3
- "the remaining duration of the TXOP", in O.3 (a), (e), and (g)
- "Remaining TXOP Duration" in Figure O-2 (3x)
There are about a jillion "TXOP duration" occurrences, throughout. Are those okay? It is just the 'remaining' part of such a duration that gives you pause? (I'm not sure why...) How about "expiration" (per a couple of the above)?
There are a lot of the same issues with "SP" as for "TXOP" also. Are those the same problem?) | As it says in the comment |
284 | Mark RISON | Mark RISON | There is a lack of clarity on TCs and TCLASes: what a TC is for, whether User Priority in TCLAS element is input or output, whether it classifies MSDUs or MPDUs or MMPDUs or what (or "it depends"), whether UP > 7 is only for TFS, why the field called User Priority not UP | As it says in the comment |
295 | Mark RISON | Mark HAMILTON | There is stuff in Clause 4 about HCCA involving reserving the medium, but it doesn't have any shalls and it's not particularly visible. Better to put in Clause 10 with some shalls | As it says in the comment |
302 | Mark RISON | Mark RISON | "The Retry subfield is set to 1 in any Data or Management frame that is a retransmission of an earlier frame." is not true for non-DMG under BA (per 10.3.4.4 Recovery procedures and retransmit limits "All retransmission attempts for an MPDU with the Type subfield equal to Data or Management that
has failed the acknowledgment procedure one or more times shall be made with the Retry subfield set to 1.
These rules do not apply for frames sent by a non-DMG STA under a block agreement.") | Add an exclusion for "frames sent by a non-DMG STA under a block agreement" |
305 | Mark RISON | Mark HAMILTON | 10.3.4.4 Recovery procedures and retransmit limits says "All retransmission attempts for an MPDU with the Type subfield equal to Data or Management that
has failed the acknowledgment procedure one or more times shall be made with the Retry subfield set to 1.
These rules do not apply for frames sent by a non-DMG STA under a block agreement." and then 10.23.2.12.1 General says it again "All retransmission attempts by a non-DMG STA for an MPDU with the Type subfield equal to Data or
Management that is not sent under a block ack agreement and that has failed the acknowledgment procedure
one or more times shall be made with the Retry subfield set to 1. " | The stuff that is common to DCF and EDCA should be pulled out to a common subclause |
348 | Mark RISON | Mark RISON | Why is Nr for beamforming called the number of space-time streams (see definition of Beamformee STS Support subfield)? There's no time expansion (assuming STBC isn't being used). Ditto for S1G | As it says in the comment |
363 | Mark RISON | Mark HAMILTON | The claimed distinction between "collocated" and "co-located" is a fantasy, and it is guaranteed to lead to immediate spec rot. Alternatively, at least define the distinction in the spec. (See CID 4800 in REVmd) | As it says in the comment |
377 | Mark RISON | Mark RISON | "The optional TCLAS element is used to identify the destination non-AP and non-PCP DMG STA of the ADDTS Request frame. If a TSPEC element is not present, then the TCLAS element is not present. There can be one or
more TCLAS elements in the DMG ADDTS Request frame. The TCLAS Processing element is present if
there is more than one TCLAS element." -- implies that if there is more than one TCLAS element there has to be a TSPEC, but this doesn't seem to be stated | As it says in the comment |
398 | Mark RISON | Mark RISON | Re the transmit MSDU/MMPDU timer, for EDCA it's "The transmit MSDU/MMPDU timer shall be started when the MSDU/
MMPDU is passed to the MAC." (which I assume means the MA-UNITDATA.request) but for DCF, it's "The timer starts on the initial attempt to transmit the MSDU/MMPDU, or first fragment of
the MSDU/MMPDU if the MSDU/MMPDU is fragmented." Is this intentional? | As it says in the comment |
428 | Mark RISON | Mark RISON | "The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 9.4.2.37 (RCPI element)."; "The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 17.3.10.7 (Received Channel Power Indicator Measurement)." and whatever 25.3.13 Received channel power indicator (RCPI) measurement ends up saying -- the RCPI parameter in the PHY SAP should just be a power in dB with a resolution of 0.5 dB, without any particular encoding | As it says in the comment |
436 | Mark RISON | Mark RISON | Should the permission to use PIFS for Beacon and TIM frames be extended to other similar frames, e.g. DMG Beacon and FILS Discovery frames? | As it says in the comment |
437 | Mark RISON | Mark RISON | Is the Measurement Duration the total duration across all channels (channel number=0 or 255) in the operating class, or the duration of only one channel scan? [xxgc] | As it says in the comment |
451 | Mark RISON | Mark RISON | "each MSDU, A-MSDU, or
MMPDU that belongs to a TC that requires acknowledgment" -- an MMPDU does not below to a TC. Whether an MMPDU requires ack depends on its subtype (Action No Acks don't) and addressing (group-addressed ones don't) | As it says in the comment |
452 | Mark RISON | Mark RISON | Beacons have been Balkanised, with DMG Beacons and S1G Beacons going their own way. However, a lot of the rules for Beacons have not been fully extended to the separatists, e.g. "If the multiple BSSID capability is supported, Beacon frames shall be transmitted using any basic rate valid for all of the BSSs supported.", "An IBSS STA that sent a Beacon or DMG Beacon frame shall remain in the awake state", "All Beacon frames shall be submitted to this service for protection processing." | As it says in the comment |
459 | Mark RISON | Mark RISON | Should be clearer that EDCA sharing is done by a single EDCAF, not by multiple EDCAF somehow sharing the TXOP | As it says in the comment |
460 | Mark RISON | Mark HAMILTON | In the context of REVmd CID 4267, MarkH noted that there are other entries in Table 9-10 (such as the TPU rows a couple down from the RXOP Duration Requested row) that have QoS Data frames in nonmesh BSS with bit 4 equal to 0. I forget the significance of this right now, but maybe we can reverse-engineer it | As it says in the comment |
461 | Mark RISON | Mark Rison | " If no MLME-SA-QUERY.confirm primitive for the STA is received within the dot11AssociationSAQueryMaximumTimeout period, the SME shall allow a subsequent association process with the STA to be started without starting an additional SA Query procedure" -- should it allow this indefinitely? It might be better to have some kind of timeout, though it's not clear what this should be. Ditto in 11.3.5.5 | As it says in the comment |
468 | Mark RISON | David GOODALL | "When a STA receives an NDP CTS frame with the RA/Partial BSSID field equal to the S1G partial AID of the STA from the UL-Sync capable AP with which the STA is associated, the STA shall transmit a Data frame to the AP an SIFS after the reception of the NDP CTS frame if the STA has a Data frame to transmit to the AP and has requested the AP for a sync frame transmission. When a STA receives an NDP CTS frame with the RA/Partial BSSID field not equal to the S1G partial AID of the STA, the STA shall follow the NAV setting rules defined in 10.3.2.4 (Setting and resetting the NAV). After transmitting the NDP CTS frame, the AP shall wait for an AckTimeout interval (as defined in 10.3.2.11 (Acknowledgment procedure)), starting at the PHY-TXEND.confirm primitive. If a PHY-RXSTART.indication primitive does not occur during the AckTimeout interval, the AP may transmit a CF-End frame or an NDP CF-End frame to reset the NAV provided that the remaining duration is long enough to transmit this frame." -- no resetting of NAV if the sync frame is not an NDP CTS frame and no RXSTART appears within AckTimeout (c.f. vanilla CTS behaviour)? | As it says in the comment |
480 | Mark RISON | Mark RISON | "A responder may ignore a
request for beam tracking within an allocation if no PPDUs with an MCS index greater than 0 are
transmitted from the responder to the initiator within the allocation." -- is this basically saying that a device can avoid supporting beam tracking by always sending stuff under MCS 0? | As it says in the comment |
483 | Mark RISON | Mark RISON | "If the SU Beamformee Capable field is set to 1, set to
maximum number of space-time streams that the STA can
receive in a VHT NDP minus 1." -- should say cannot be set to 0 (i.e. max NSTS must be at least 2). Also say must be at least 3 (i.e. max NSTS must be at least 4) if MU BFee supported | As it says in the comment |
491 | Mark RISON | Mark RISON | Are there any Management frames that can be transmitted from an AP to another AP? If so, what is put in A3, the BSSID of the transmitter or that of the receiver or what? And can such frames be broadcast, i.e. A1 is all-ones? | As it says in the comment |
492 | Mark RISON | Mark RISON | We have a ProbeDelay in the SCAN.req and a NAVSyncDelay in the START.req and JOIN.req. The former should only be used for scanning; the latter should be used not just when changing from doze to awake but also when changing to a new channel | In Clause 6 describe the NAVSyncDelay as also being used after switching channel. In 10.39.7.1 refer to the NAVSyncDelay not the ProbeDelay. In 11.2.3.2 say the NAVSyncDelay is also used after switching channel |
499 | Mark RISON | Mark RISON | Referring to fields in binary is not clear as to the ordering of bits. E.g. it is not clear what PPDU Type = 10 or 01 refers to, but there are other instances | Clarify e.g. what "PPDU Type = 10" means at 3481.14 |
504 | Mark RISON | Mark RISON | "The Antenna ID field(M101) is set to the identifying number for the antenna(s) used for this measurement.
The antenna ID(#1516) is defined in 9.4.2.39 (Antenna element)." but for things like 9.4.2.21.6 Noise Histogram report then (a) 9.4.2.39 only allows for a single DMG antenna ID but a noise histogram might involve multiple DMG antennas (b) 9.4.2.39 talks of the (DMG) antenna(s) used to receive an earlier frame" but no frame is being received during IPI measurement | As it says in the comment |
505 | Mark RISON | Mark RISON | It is not clear that the requirements in the NOTEs in Table 9-273--Setting of the Supported Channel Width Set subfield and Extended NSS BW Support subfield at a STA transmitting the VHT Capabilities Information field are normatively stated or implied elsewhere | Add the missing normative requirements somewhere |
512 | Mark RISON | Mark RISON | Figure 65--Return path of OCT messages based on OCT parameters says MBp=OSp but this is a type violation. Also "the Multi-band peer parameter shall be set to the value of the Multi-bandOCT source parameter of the MLME-OCTunnel.indication primitive.
and
the Multi-band peer parameter shall be set to the value of the Multi-bandOCT source parameter received in the corresponding MLME-OCTunnel.indication primitive.
and
the Multi-band peer parameter set to the value of the Multi-bandOCT source parameter of the MLME-OCTunnel.indication primitive." | As it says in the comment |
520 | Mark RISON | Mark RISON | Many places that refer to Action frames should also refer to Action No Ack frames (e.g. AC setting) | As it says in the comment |
521 | Mark RISON | Mark RISON | There is lots of duplication between 10.3.3 Random backoff time and 10.3.4.3 Backoff procedure for DCF | Merge the two subclauses |
526 | Mark RISON | Mark HAMILTON | The CMMG rules being separated (in 10.6.8) causes the exclusion rules structure of 10.6.5.x to be confusing or broken. DMG started it with 10.6.7. | Merge 10.6.7 and 10.6.8 into 10.6.5. I think perhaps the other Mark has some ideas about this |
529 | Mark RISON | Mark RISON | QLRC and QSRC have been deleted from the spec, because they were not clearly specified and not actually implemented, but LRC and SLRC and SRC and SSRC, which suffer from the same problem, are still there. Note: DCF is not deprecated | Delete LRC and SLRC and SRC and SSRC from the spec in the same way QLRC and QSRC were deleted |
530 | Mark RISON | Mark RISON | QLRCs and QSRCs have been deleted from the spec, but there are still references to short/long retry count(er) in
10.3.3: "The SSRC shall be incremented when any short retry count (SRC)" "The SLRC shall be incremented when any long retry count (LRC)" and in
11.8.3 "The short retry counter and long retry counter for the MSDU or A-MSDU are not affected."
Also "A STA shall maintain a SRC and an LRC for each MSDU or MMPDU awaiting transmission." "The SRC for an MPDU [...]. This SRC and the SSRC shall be reset when [...]. The LRC for an MPDU [...]. This LRC and the SLRC shall be reset when" "Retries for failed transmission attempts shall continue until the SRC for the MPDU [...] or until the LRC for the MPDU [...]" in 10.3.4.4. Note: DCF is not deprecated | Delete all references to short/long retry count(er)s throughout |
533 | Mark RISON | Mark RISON | It should be possible to use the ChannelList when doing OCT scanning to specify the peer NT-MLME channels. Currently, the Multi-band local in the MLME-SCAN.req is not used for anything except
identifying the local TR-MLME(s) -- it does not go on the air or anything.
We should therefore replace it with a list of { band ID, channel, MAC address }
tuples (or a single band ID parameter and a list of { channel, MAC address } tuples
if the TR-MLMEs have to be all on the same channel) and then OCT scanning will
just be a clear extension to normal scanning. I think you wouldn't need the
Multi-band peer because it would be implicit in the combination of the local
NT-MLME the SME sends to (which identifies an NT band and channel)
and the BSSID parameter. Then you'd be able to say "I want to find APs on
5G channels 36, 40 or 44, tunnelling over 2G4 channels 1, 2, 3" by setting
in the MLME-SCAN.req:
Channel List = 36, 40, 44
BSSID = wildcard
Local TRs = { 2G4, 1, MAC address for 1 }, { 2G4, 2, MAC address for 2 }, { 2G4, 3, MAC address for 3 }
and sending to an NT-MLME on the 5G band. | As it says in the comment |
538 | Mark RISON | Mark RISON | The multirate rules are an impenetrable mess. It's impossible to determine whether they are complete, let alone whether they are correct | As it says in the comment |
540 | Mark RISON | Mark RISON | There seem to be at least three flavours of awake window: mesh, TDLS and DMG (and there has been a suggestion in TGmd that there are also IBSS awake windows, though the term does not appear). The first seems to be so denoted, but the others not | As it says in the comment |
547 | Michael Montemurro | Mike MONTEMURRO | There is a feature that was added to the specification to allow an AP to signal a system information update, described as a "Critical Update". A list of critical update events are given in clause 11.2.3.15 (TIM broadcast). However some of the parameters in the critical update list (DSSS Parameter Set, HT Operation, VHT Operation) would require an MLME-Start primitive to be changed. It looks as though the MLME primitives are not consistently defined with the feature. | Define a new MLME primitive to change the AP configuration when a critical update occurs. Move the critical update text out of the TIM Broadcast clause and provide a complete description on how an AP performs a criticial update. |
582 | Subir Das | Subir DAS | National Security and Emergency Preparedness (NSEP) priority access feature is introduced in .11be amendment. Within United States, National Security and Emergency Preparedness Priority Service is deployed over Cellular and Wireline networks. While many of the existing deployment infrastructure includes Wi-Fi as last mile access, it lacks the priority access support. Therefore, it is important that NSEP priority access is also supported (e.g.. when the service is offloaded to Wi-Fi access). This will help service providers to provide a seamless NSEP service experience to the users while maintaining the priority and quality of service. The proposal is to add the NSEP priority feature in REVme. Since NSEP priority access is a MAC layer feature, no hardware changes are required. | Proposed changes will be submitted in due course |
593 | Thomas Derham | Thomas Derham | Post-association mgmt exchanges such as ADDBA Request, SCS Request etc create pverhead and delay in establishing expected connectivity/QoS when roaming (reassoc). | At least for cases where reassoc frames are protected (e.g. FILS, maybe FT), enable request/response for SCS and ADDBA (and others if desired) to be carried within those frames. |
CID | Commenter | Assignee | Comment | Proposed Change |
1 | Abhishek Patil | Menzo WENTINK | Based on the description, the text applies to a Data frame sent from a TDLS peer STA to another TDLS peer STA over the TDLS direct link. | Clarify that 0,0 applies to Data frames sent over a TDLS direct link |
2 | Abhishek Patil | Menzo WENTINK | This FTE is also used for TDLS authentication. | Add TDLS authentication to the list |
8 | Abhishek Patil | Menzo WENTINK | The responder should not blindly set the TDLS Responder STA Address to the one that was carried in the TDLS Discovery (or Setup) Request frame. It needs to verify that the Address matches its address. | As in comment |
9 | Abhishek Patil | Menzo WENTINK | What is the TDLS Initiator STA Address and TDLS Responsder STA Address fields of the Link Identifier element set to when the TDLS Discovery Response frame is sent unsolicited? In addition, what are the values carried in this field when a STA responds to an unsolicited TDLS Discovery Response frame with a TDLS Discovery Response frame? | As in comment |
102 | Joseph Levy | Joseph Levy | The power save mode should describe the behavior of the AP, e.g. when it buffers frames, when it is allowed to transmit, and what it is allowed to transmit. A STA that has activated PS mode is not required to be any given state, as the STA can choose to transmit PPDUs at any time and can be in either awake or doze state as it chooses, independent of the agreed scheduled PS state (awake or doze). A typical STA will follow its awake and doze schedule because its user expects to receive the traffic sent by the AP to the STA. | As described in the comment. Detailed proposed changes will be supplied in a contribution. |
103 | Joseph Levy | Joseph Levy | It is impossible to require a STA to receive a PPDU. Hence, the STA behavior of "listening" or "receiving" should not be specified. The specification should only specify: when the AP shall/may transmit to a STA, what the AP shall/may transmit, and what a STA does when it receives a transmission. Also the specification should define AP behavior regarding what the AP should do if a STA in PS mode does not respond to PPDUs transmitted by the AP during the STA's scheduled awake time. | As described in the comment. Detailed proposed changes will be supplied in a contribution. |
108 | Joseph Levy | Joseph Levy | The specification currently uses PS mode to describe two concepts: A STA that has activated PS mode requiring the AP to buffer PPDUs for the STA in accordance with the agreed Awake and Doze schedule and to define the type of PS that has been configured for the STA and AP pair during association/reassociation in a BSS or between STAs in an IBSS. These two concepts are not the same and should not use the same term. I suggest that the PS mode should be used to describe the particular PS setting negotiated between the STA and AP or between STAs and that a different term be used to describe a STA that has activated its PS mode and requires the AP or other STA to buffer PPDUs and only transmit them as defined by the agreed PS mode. Statements such as setting the PS bit to 1 activates the PS mode and setting it to 0 de-activates the PS mode would make. Hence the statement "a STA in PS mode" should be replaced by "a STA with PS active" or something similar. | As described in the comment. Detailed proposed changes will be supplied in a contribution. |
118 | Jouni Malinen | Menzo WENTINK | FTE description in Clause 9 covers only the FT and FILS cases while this element is used also with TDLS. In particular, the rules for setting the MIC for TDLS setup exchange are missing. | Add the needed references for the rules on how MIC field is set for TDLS setup frames. At minimum, this should reference 12.7.8.4.3 and 12.7.8.4.4 for MIC calculation in TPK handshake messages 2 and 3. Please also note that this may end up getting resolved as a related change in P802.11be, so potential REVme edits should be coordinated with that effort. These edits would likely include following: Replace
"When the Element Count subfield has a value greater than 0, the MIC field contains a MIC that is calculated using the algorithm specified in 13.8.4 (FT authentication sequence: contents of third message) and 13.8.5 (FT authentication sequence: contents of fourth message). Otherwise, the MIC field is set to 0."
with
"When the Element Count subfield has a value greater than 0, the MIC field contains a MIC that is calculated using the algorithm specified in 13.8.4 (FT authentication sequence: contents of third message), 13.8.5 (FT authentication sequence: contents of fourth message), 12.7.8.4.3 (TPK handshake message 2), and 12.7.8.4.4 (TPK handshake message 3). Otherwise, the MIC field is set to 0." |
168 | Mark RISON | Mark RISON | "QoS Data frame" means different things in different places. See 21/0448 | I don't know how to fix this! |
169 | Mark RISON | Mark RISON | "beacon interval" is ambiguous. See 21/0448 | I don't know how to fix this! |
177 | Mark RISON | Mark RISON | "CMMG NDP Announcement frame" -- no such frame | Refer to a frame that exists |
182 | Mark RISON | Menzo WENTINK | direct link v direct path v TDLS direct link v TDLS link -- it is not clear how these differ. There aren't many instances of "direct path". A TDLS link is by definition a direct link, otherwise it's not a TDLS link it's a normal infrastructure BSS link going via the DS | Change "direct path" to "direct link" throughout. Change "TDLS direct link" to "TDLS link" throughout |
228 | Mark RISON | Mark RISON | Can single protection be used with A-MPDUs/BA/TXOP bursts? If so then
"5) In Management frames, non-QoS Data frames (i.e., with bit 7 of the Frame Control field equal
to 0), and individually addressed Data frames with an ack policy other than No Ack or Block
Ack(#1415), the Duration/ID field is set to one of the following:
i) If the frame is the final (#1452)frame of the TXOP, the estimated time required for the
transmission of one Ack frame (including appropriate IFSs)
" is wrong because it might not be an Ack frame, it might be a BlockAck frame | As it says in the comment |
232 | Mark RISON | Mark HAMILTON | "individually addressed A-MSDU" -- (a) this is not defined; only addressing of MPDUs and MSDUs is defined and (b) assuming it means the MPDU the A-MSDU is in is unicast, it's the only permitted option anyway (except for GLK transmissions by an AP) per 10.11 fourth para | Delete "individually addressed" in this construct throughout (9x) except where a GLK transmission by an AP is possible, where instead replace with "A-MSDU in an individually addressed MPDU" |
280 | Mark RISON | Mark RISON | "A VHT beamformer may use the worst case for various parameters to estimate the duration of the
expected frame(s) that contain(s) the feedback response(s), such as the lowest rate in basic rate, HT-MCS or
VHT-MCS set, no grouping and the highest precision codebook." cf. "An HT beamformer may use the following worst-case parameters to estimate the duration of the expected
frame that contains the feedback response: lowest rate in basic HT-MCS set, HT-mixed format, no grouping." is inconsistent (hyphen in worst case, references to rate as well as MCS, etc.) and should be consitentificated | As it says in the comment |
316 | Mark RISON | Mark RISON | DMG beacons should be like normal beacons, i.e. you have exactly one of QoS Cap or EDCA Param Set | As it says in the comment |
351 | Mark RISON | Mark RISON | "Section 3.3 IANA registers acceptable URI schemes" doesn't say what this is a section of | Add a reference to the document of which this is a section |
370 | Mark RISON | Mark RISON | "drop" is not clear in the context of a frame | Change all instances of "drop"ping a frame dropping to "ignore"ing it, in 6.3.24.1 (3x), 10.8, 11.9.3.2, 11.10.5.2 (2x), 11.22.3.2.3, 11.22.3.2.4 (6x), 12.4.8.6.1 (2x), 12.4.8.6.4, 12.5.2.1.1, 12.5.2.6, 12.5.4.6 (2x), 12.10.2, 14.3.5 (2x), C.3 (16x). Delete "dropped and" in 12.7.10.3. Change "STA dropped" to "stream dropped" in K.3.2.2 |
405 | Mark RISON | Mark RISON | The distinctions between basic, operating and mandatory rates/MCSes are not clear | State that basic ones are ones that can be transmitted to or received from all STAs in the BSS, operational ones are ones that can be received by a given STA, and mandatory ones are a PHY concept that does not equal basic or operational |
412 | Mark RISON | Mark RISON | "a Probe Response frame with its current AP-CSN, the information fields, and elements as defined
in 9.3.3.10 (Probe Response frame format)." -- what are "the information fields"? | As it says in the comment |
421 | Mark RISON | Mark RISON | The A-MSDU subframe header in an MBSS has Mesh DA and Mesh SA fields, not DA and SA fields, which is problematic in those locations which refer to the latter fields (unless those locations are not applicable to MBSS -- e.g. can MBSS be used with S1G or GCR?) | Either rename the fields to just DA and SA, or look at the references to DA and SA fields and add "or Mesh DA" and "or Mesh SA" where relevant |
498 | Mark RISON | Mark RISON | It should be clearer that it is not possible to change the basic rate/MCS set for the lifetime of the BSS | As it says in the comment |
528 | Mark RISON | David GOODALL | There are approximately 100 instances of "relay STA", of which approximately 58 are "S1G relay STA". This seems to falsely suggest that the others are or can be non-S1G relay STAs | Change all instances of "relay STA" and "Relay STA" that are not preceded by "S1G" or "DMG" to "S1G relay STA" throughout, adjusting the preceding indefinite article "a" if present to "an". Change all instances of "relay AP" and "Relay AP" that are not preceded by "S1G" or "DMG" to "S1G relay AP" throughout, adjusting the preceding indefinite article "a" if present to "an" |