| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
> Below are other comments that I would like discussed in the group, typically
> either because I think they can just be accepted, or because I need
> a direction before I generate a resolution. We went through a number of
> these during the ad hoc, but I'm not sure where we got to (I think it
> might have been CID 4457).
--- This message came from the IEEE 802.11 Task Group M Technical Reflector -----As requested by the Chair:
I have generated 20/0435 with proposed resolutions for various comments.
Below are other comments that I would like discussed in the group, typically
either because I think they can just be accepted, or because I need
a direction before I generate a resolution. We went through a number of
these during the ad hoc, but I'm not sure where we got to (I think it
might have been CID 4457).
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: Mark Rison
Sent: 18 February 2020 12:39
To: 'Dorothy Stanley' <dstanley1389@xxxxxxxxx>
Cc: mark.hamilton2152@xxxxxxxxx; M Montemurro (montemurro.michael@xxxxxxxxx) <montemurro.michael@xxxxxxxxx>
Subject: RE: [STDS-802-11] Updated TGmd CRC draft agenda for the 18-20Feb adhoc now posted
Hello Dorothy,
Regarding the comments to go through in my 1-hour slots, I think the ad-hoc
owners might have their way of stepping through them, but otherwise here
are the ones I'd like to discuss:
For MAC (MarkH):
CID
Comment
Proposed Change
Disposition re submission
4194
Subfields should be reserved, not set to 0, to allow for future extension
In 9.4.2.226 Enhanced Beam Tracking element change " Otherwise, the Peer Tx_Sector ID field is set to 0. " to " Otherwise, the Peer Tx_Sector ID field is reserved. " and " Otherwise, the Peer Tx DMG Antenna ID field is set to
0." to " Otherwise, the Peer Tx DMG Antenna ID field is reserved."Why not just ACCEPTED?
4205
Table 9-151--AKM suite selectors has overlapping conditions. For example, 00-0F-AC:3 and 00-0F-AC:5 have the same key derivation, can both use 0 for the auth alg num, have subset key management type (since 12.7.1.6 is a subclause of 12.7) and have subset authentication (since FT authentication
negotiated over IEEE
Std 802.1X is a type of Authentication
negotiated over IEEE
Std 802.1X). Similarly :8 and :9, etc.Make sure each suite selector has no overlap with other suite selectors
Ask Jouni whether he'd take this
Examples of problems:
If I want to do (FT) authentication
over 802.1X with key management as defined in 12.7(.1.6) using SHA-256, then do I
use :5 or :3? If I receive :5, how do I know whether the other side wants to do
FT auth or not (if it used 0 for the auth alg num)?
4206
Table 9-151--AKM suite selectors has overlapping conditions. For example, 00-0F-AC:3 and 00-0F-AC:5 have the same key derivation, can both use 0 for the auth alg num, have subset key management type (since 12.7.1.6 is a subclause of 12.7) and have subset authentication (since FT authentication
negotiated over IEEE
Std 802.1X is a type of Authentication
negotiated over IEEE
Std 802.1X). Similarly :8 and :9, etc.In the auth type for :5 change "Authentication
negotiated over IEEE
Std 802.1X " to "Non-FT authentication
negotiated over IEEE
Std 802.1X "Ask Jouni whether he'd take this
4212
"The Group Data Cipher Suite field contains the cipher suite selector used by the BSS to protect group
addressed frames." -- only Data framesChange the cited text to "The Group Data Cipher Suite field contains the cipher suite selector used in the BSS to protect group
addressed Data frames." (note in not by)Why not just ACCEPTED?
Note that 1099.5 "The Group Management Cipher Suite field contains the cipher suite selector used by the BSS to protect group addressed robust Management frames." should match in any case.
4213
"The Pairwise Cipher Suite List field contains a series of cipher suite selectors that indicate the pairwise
cipher suites." -- only for Data framesChange the cited text to "The Pairwise Cipher Suite List field contains a series of cipher suite selectors that indicate the pairwise
cipher suites used in the BSS to protect individually addressed Data frames."Check with Jouni whether this can just be ACCEPTED (I'm not sure whether, if it contains more than one, they are all used, or are all potentially used, or this can only happen for a STA advertising the cipher suites it supports, or what)
4217
No behaviour is associated with the Antenna Pattern Reciprocity field in the CMMG Capabilities Info field
In Figure 9-754--CMMG Capabilities Info field format change "Antenna Pattern Reciprocity" to "Reserved" and delete the "Antenna Pattern Reciprocity" row in Table 9-313--Subfields of the CMMG Capabilities Info field format
Assign to a CMMG expert, or just ACCEPT
4218
No behaviour is associated with the Antenna Pattern Reciprocity field in the CMMG Capabilities Info field
Add behaviour modelled on that given for DMG in 10.42.6.4.4 Antenna configuration setting during a beam refinement transaction
Assign to a CMMG expert
4229
"A STA is not required to include all mandatory rates in its operational rate set, and a STA starting a BSS is
not required to include all mandatory rates in the basic rate set." -- there should be equivalent statements for MCSesChange the cited text to "A STA is not required to include all mandatory rates/MCSes in its operational rate/MCS set, and a STA starting a BSS is
not required to include all mandatory rates/MCSs in the basic rate/MCS set."Why not just ACCEPTED?
4245
10.2.3.2 HCF contention based channel access (EDCA) says defaults are always used ("When communicating within a BSS, the EDCA parameters used are [...] from the default values for the parameters when [...] when the STA is a mesh STA") but various other parts of the spec say that EDCA parameters are passed around in various frames when a STA is a QoS STA (as all mesh STAs are)
As it says in the comment
Assign to a mesh expert (I think Kaz-san has taken this)
4250
"The actual
duration of the time the STA stays in the listening mode is limited by the aCMMGPPMinListeningTime
parameter." -- no such parameterDelete the cited sentence
Assign to a CMMG expert, or just ACCEPT
4259
"QoS Data frame" is ambiguous. It could mean Type = Data, Subtype has b7 set, or it could mean Type = Data, Subtype = QoS Data
After "QoS CF-Poll frame refers specifically to the QoS CF-Poll frame, subtype 1110." add "Similarly, QoS Data frame refers specifically to the QoS Data frame, subtype 1000.". Also delete the comma in " whereas," in 3.2 and "Whereas " in 9.2.2
Why not just ACCEPTED?
It's the only possible meaning. Otherwise e.g. all the places that talk of QoS Data and QoS Null (e.g. "carry a QoS Data, QoS Null or Management frame […] the corresponding QoS Data or QoS Null frame", "a trigger frame from a STA, which is a QoS Data or QoS Null frame", "by sending a QoS Data or QoS Null frame") wouldn't make sense.
4263
"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" -- also a STA that is operating in such a BSS (cf. 11.14 -- but note that a STA that has not started the BSS it's in has not seen the MLME-START.request). There is some stuff in 10.3.1, but this is about DCF so it's not clear it applies to VHT STAs. See also 11ax CID 21270As it says in the comment
OK -- assign to me if currently unassigned
4267
"The TXOP Duration Requested subfield is present in QoS Data frames sent by STAs associated in
a nonmesh BSS with bit 4 of the QoS Control field equal to 0." -- only non-AP STAs. Even if this is fixed, it just duplicates Table 9-10--QoS Control fieldDelete the cited sentence
Why not just ACCEPTED?
MarkH notes 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
4269
"before the ProbeTimer reaches
MinChannelTime" -- there is no ProbeTimerChange the cited text to "before the ProbeDelay time reaches MinChannelTime"
Why not just ACCEPTED? I think Alfred has taken this
4283
"that contained the Channel Measurement request"-- no such request. Missing "DCS", I presume
Add "DCS " before "Channel" in the cited text
Assign to a CDMG expert, of just ACCEPT
I think DCS some kind of 11aj thing (from "6.3.116 DCS procedure(11aj)"
and "11.48 DCS procedure(11aj)")? This is not incompatible with it
being some kind of DMG feedback stuff, of course.
The instances of Channel Measurement request/report I can find are preceded
(where preceded by something) with either DCS or Multi-relay. And we even have
stuff like "The Channel Measurement Request subelement is used to specify the channel(s) to be measured. The format
of the DCS Channel Measurement Request subelement is shown in Figure 9-904".
So everything seems to me to point at these homeless Channel Measurement things
being DCS Channel Measurement things, though of course I'd be happy to be
corrected by a 60G person.
4284
Should Figure 9-219--Measurement Request field format for Directional Statistics request not allow for optional subelements, like the corresponding report, and like most requests? Ditto Directional Measurement request
As it says in the comment
Discuss in group
4287
"The set has a maximum range of 2^n for at least one n, where 1 <= n <= 46." -- the "at least one n" is not clear
Delete the " for at least one n"
Why not just ACCEPTED?
4292
Referring to fields in binary is not clear as to the ordering of bits.
Delete "The GCR Mode subfield is 10 when the BlockAck
frame is sent in response to a GCR BlockAckReq frame, 01 when the BlockAck frame is sent in response to
a GLK-GCR BlockAckReq, and 00 otherwise." (this just duplicates the table above anyway)Why not just ACCEPTED?
4343
"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 measurementAs it says in the comment
Discuss in group
4345
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
I think Menzo has taken this (note table is actually 9-272)
4353
"c) The Address 3 field of the Management frame is set and determined as follows:
1) In Probe Request frames, the Address 3 field is the BSSID. The BSSID is either a specific
BSSID as described in item 4) below" -- but 4) below is "Otherwise" so is not in scope of c)1)As it says in the comment
OK -- assign to me if currently unassigned
4361
There should not be reason codes for situations that should never arise with compliant devices, since (a) the spec is about compliant devices and (b) then there would be no end of possible reason codes
In Table 9-51--Reason codes make row 35 say "35", "Reserved" and nothing
Why not just REVISED with CID 4362's proposed change?
4362
There should not be reason codes for situations that should never arise with compliant devices, since (a) the spec is about compliant devices and (b) then there would be no end of possible reason codes
In Table 9-51--Reason codes make row 35 say "35", "NONCOMPLIANT" and "Disassociated because STA is not compliant with IEEE Std 802-11"
Why not just ACCEPTED?
4364
"The transmission of the MPDU in the final PPDU transmitted by the TXOP holder during the TXOP
for that AC has completed" -- it is not clear what "completed" means (put on air? acked?)As it says in the comment
Discuss in group
4365
"The transmission of the MPDU in the final PPDU transmitted by the TXOP holder during the TXOP
for that AC has completed" -- it is not clear what "the MPDU" refers to, since a PPDU can contain more than one MPDUAs it says in the comment
Discuss in group
4379
Should define "control response frame" to make it clear that it's a Control frame sent in response to some frame (and not, for example, any response to a Control frame, e.g. a VHT CBR sent in response to an NDPA)
As it says in the comment
OK -- assign to me if currently unassigned
4381
"The responding STA should transmit Fine Timing Measurement frames with the format and bandwidth it
indicated.
For the Fine Timing Measurement frames transmitted during the FTM session:
-- The responding STA shall not use a bandwidth wider than that indicated by the STA in the initial
Fine Timing Measurement frame.
-- The responding STA shall not use a VHT format if the STA indicated HT-mixed or non-HT format
in the initial Fine Timing Measurement frame.
-- The responding STA shall not use an HT format if the STA indicated non-HT format in the initial
Fine Timing Measurement frame." is not clear: which is "the STA". And in first sentence should say where it indicated it (the iFTM frame)Change to "The responding STA should transmit Fine Timing Measurement frames with the format and bandwidth it
indicated in the initial Fine Timing Measurement frame.
For the Fine Timing Measurement frames transmitted during the FTM session:
-- The responding STA shall not use a bandwidth wider than that it indicated in the initial
Fine Timing Measurement frame.
-- The responding STA shall not use a VHT format if it indicated HT-mixed or non-HT format
in the initial Fine Timing Measurement frame.
-- The responding STA shall not use an HT format if it indicated non-HT format in the initial
Fine Timing Measurement frame."Why not just ACCEPTED?
4393
It doesn't make sense to sometimes plonk "(no data)" after the frame name
Delete "(no data)" throughout except in Table 9-1--Valid type and subtype combinations
Why not just ACCEPTED?
If there is concern with the "all three QoS data subtypes with “no data”"
wording, then that could be addressed by changing to
"all three QoS data subtypes whose Frame Body field is empty" or similar.
4400
Constructs of the form "may do X by doing Y" are ambiguous because the might mean "if you do X, then Y might happen" or "if you do X, then Y will happen"
In the referenced subclause change "A non-AP STA with dot11SolicitedPADActivated set to true (#2679)may invoke MAC privacy procedures by
setting dot11MACPrivacyActivated to true" to "A non-AP STA with dot11SolicitedPADActivated set to true (#2679)may set dot11MACPrivacyActivated to true"Why not just ACCEPTED?
4413
"When communicating within a BSS, the EDCA parameters used are from the EDCA Parameter Set element or
from the default values for the parameters when no EDCA Parameter Set element is received from the AP of
the BSS with which the STA is associated" -- the STA always gets EDCA Params Set from AP in association response, so can't happenAs it says in the comment
OK -- assign to me if currently unassigned
4432
"The Address 1 field of the TIM frame shall be set to the broadcast address." -- equivalent statements are needed for other Management frames that are always broadcast e.g. Beacon, FILS Discovery frames
As it says in the comment
Discuss in group
4433
Table 10-22--Applicable HT protection mechanisms only goes up to 40 MHz non-HT dup. However, it also applies to VHT through 10.27.5 Protection rules for VHT STAs ("A VHT STA is subject to all of the rules for HT STAs that apply to its operating band, except that a PPDU
with the TXECTOR FORMAT parameter set to VHT may be substituted for a PPDU with the TXVECTOR
FORMAT parameter set to HT_MF."). Therefore it should also cover the use of 80/80+80/160 non-HT dup for RTSIn Table 10-22 change "40 MHz transmissions use non-HT duplicate frames defined in Clause 19 (High-throughput (HT) PHY
specification)" to "40 MHz, 80 MHz, 160 MHz and 80+80 MHz transmissions use non-HT duplicate frames defined in Clause 19 (High-throughput (HT) PHY
specification) and Clause 21"Why not just ACCEPTED?
4441
"The UL-Sync capable AP should use (M101)an NDP CTS frame as a sync frame.
When a STA receives an NDP CTS frame" -- so what about if the AP does not use an NDP CTS as a sync frame? What does the STA do?Change "should" to "shall" in the cited text
Assign to an 11ah expert, or just ACCEPT
(I think Alfred has taken this)
4443
There is no actual definition of what a "sync frame" is. "The UL-Sync capable AP should use (M101)an NDP CTS frame as a sync frame." is just a serving suggestion
As it says in the comment
REVISE using the proposed change in CID 4441
4444
"When the HC needs access to the WM to start a (#65)TXOP, the HC shall sense the WM. When the WM is
determined to be idle at the TxPIFS slot boundary as defined in 10.3.7 (DCF timing relations), the HC shall
transmit the first frame of any permitted frame exchange sequence, with the duration value set to cover the
TXOP(#65)." -- this seems to allow any AP that claims to support HCCA to always transmit after PIFS, even if the access is not for HCCA. The permission to use PIFS should be constrained to HCCA contextsAs it says in the comment
I think we've allowed to explicitly allow beacons after PIFS (not sure about things like FILS Discovery, though), but discuss in group this comment, which is slightly different
4451
"When an AP supports DL-MU-MIMO, frames from a higher or lower priority AC may be included
in a VHT or S1G MU PPDU with the TXVECTOR parameter(#2639) NUM_USERS > 1 when
these frames do not increase the duration of the VHT or S1G MU PPDU beyond that required for the
transmissions of the frames of the primary AC(#2426)." -- why the not increase duration constraint, given that the previous bullet does allow extension? Maybe special-case for TXOP Limit 0, i.e. only in that case do not extend (since otherwise TXOP Limit is the limit, irrespective of content)?Change to "When an AP supports DL-MU-MIMO, frames from a higher or lower priority AC may be included
in a VHT or S1G MU PPDU with the TXVECTOR parameter(#2639) NUM_USERS > 1 when
the TXOP limit for the primary AC is nonzero."Why not just ACCEPTED?
4457
"+HTC Action No Ack frames carrying a Management Action Body containing an
explicit feedback response or BRP frame." -- the term "Management Action Body" is undefined, and a frame cannot carry a frameChange to "+HTC BRP frames or +HTC Action No Ack frames containing an
explicit feedback response."Assign to a DMG expert, or just ACCEPT
4471
"Indicates short GI support
for the reception of
PPDUs(#1362) transmitted
with the TXVECTOR
parameter(#2639)
CH_BANDWIDTH equal
to HT_CBW20"-- also VHT20, per "Support for short GI for the reception of PPDUs(#1362) with TXVECTOR parameter CH_BANDWIDTH
equal to CBW20 or CBW40 is indicated in the HT Capabilities Info field of the HT Capabilities element." in 9.4.2.157.2 VHT Capabilities Information fieldChange the cited text at the referenced location to "Indicates short GI support
for the reception of
PPDUs(#1362) transmitted
with the TXVECTOR
parameter(#2639)
CH_BANDWIDTH equal
to HT_CBW20 or (for a VHT STA) CBW20". Change cell below to "Indicates short GI support
for the reception of
PPDUs(#1362) transmitted
with the TXVECTOR
parameter(#2639)
CH_BANDWIDTH equal
to HT_CBW40 or (for a VHT STA) CBW40"Why not just ACCEPTED?
4479
"A STA that receives a Probe Request frame shall not respond if [...] c) The STA is a non-AP STA in an infrastructure BSS". Such a STA does not respond due to the rules in a) above, which mean that only an AP, IBSS STA, mesh STA, DMG STA or PCP responds
Delete list item c)
REVISE using the proposed change in CID 4480
4480
"A STA that receives a Probe Request frame shall not respond if [...] c) The STA is a non-AP STA in an infrastructure BSS". Such a STA does not respond due to the rules in a) above, which mean that only an AP, IBSS STA, mesh STA, DMG STA or PCP responds. Hm, or maybe the "DMG STA" case allows this? This needs to be clearer, then
Change "The STA is a non-AP STA in an infrastructure BSS" to "The STA is a non-AP STA in a DMG infrastructure BSS"
Why not just ACCEPTED? Confirm with DMG expert
4486
"The STA is a DMG STA that is not a member of a PBSS and that is performing active scan" makes no sense. Why would a scanning DMG STA respond to probe requests?
Delete list item 4)
Assign to a DMG expert, or just ACCEPT
4494
There are 3 references to "the retryCounter" but such a thing is never defined
Change "the mesh STA shall initialise a retryCounter to 0"
I think Menzo is doing CID 4495, which instead suggests deleting the retryCounter
4505
We now have two Operating Mode Notification frames (9.6.22.4 and 9.6.29.3). So which is intended when the spec talks of "the Operating Mode Notification frame"?
In 9.6.29.3 prepend "CMMG " to "Operating Mode Notification". At the top of 11.41 add "In this subclause, references to an Operating Mode Notification frame or element should be understood as referring to a CMMG Operating Mode Notification frame or element, when transmitted or received by a CMMG STA."
Why not just ACCEPTED?
4508
how used_time is adjusted (if at all) in the case of RD grant by the AP is not clear
After "Frame exchange sequences for Management frames are excluded from the used_time update." add "Any RD transmission granted by the AP is excluded from the used_time update."
Why not just ACCEPTED?
The reason they don't need to count is that they're under control of the AP (though the TXOP duration/TXNAV it sets for the frame exchange sequence with the RDG), so the AP can account for them directly (w.r.t. the Medium Time it specified to the STA).
4510
There should be a general statement that Control frames do not have an Address 3, and some do not have an Address 2 either
As it says in the comment
OK -- assign to me if currently unassigned
4512
"This field is an integer in the range 0 to 3." -- well, duh, it's a 2-bit field, so it can't really be anything else, can it?
Delete the cited text, and also in Table 9-300--Subfields of the S1G Capabilities Information field and in C.3, and "This field is an integer in the range 0 to 7." in Table 9-271--Subfields of the VHT Capabilities Information field and in Table 9-314--Subfields of the A-MPDU Parameters field
Why not just ACCEPTED?
In general we do and need not state that the integer
is in the maximum range allowed by the number of bits, where that is
the case. Two examples picked at random:
The Beacon Interval field represents the number of time units (TUs) between target beacon transmission
times (TBTTs).
Nc Index: Indicates the number of columns in (#2412)the compressed beamforming feedback
matrix minus one.
4516
Should specify that OMN can be broadcast (discussion with Abhi)
As it says in the comment
Discuss in group
4519
"An HT STA may retransmit unacknowledged MPDUs within the same TXOP or in a
subsequent TXOP." -- this is true of non-HT QoS STAs (e.g. DMG, S1G) and duplication of the TXNAV recovery rules belowDelete the cited sentence
Why not just ACCEPTED?
4529
"The Channel Switch Announcement element is optionally present for non-DMG STAs if dot11SpectrumManagementRequired is true." -- so if SM is not *required* you're not allowed to do CS?
As it says in the comment
Discuss in group
4530
"The Channel Switch Announcement element is optionally present for non-DMG STAs if dot11SpectrumManagementRequired is true." -- the "for non-DMG STAs" caveat is not present for Beacon frames
Add the caveat to Beacon frames
I think MarkH has argued this can be REJECTED because a DMG STA uses DMG Beacon frames, not Beacon frames
4531
"bit representation plus 1" (5x) -- it's not clear what "bit representation" is supposed to mean here, and in any case this would be better expressed in the canonical "minus 1" form
As it says in the comment
OK -- assign to me if currently unassigned
4542
"The Label field is a variable length(#183) field containing a text description of the URL." should be "The Label field is a variable length(#183) field containing a text description of the URL suitable for display on a user interface."
As it says in the comment
Why not just ACCEPTED?
I don't quite remember, but I think this is a follow-up to a comment in
the LB to the effect that it was not clear what the purpose of the Label
field was. I think (not sure) StephenMc told me that it was for display
on a UI.
Again from memory, the issue was that there was nothing about what this field was used for.
Are there any other fields whose purpose is unspecified and that are actually just to
be shown on a UI?
4543
"The Power Capability element specifies the minimum and maximum transmit powers with which a STA is capable of transmitting in the current channel." - what is "the current channel" if sent in association?
As it says in the comment
Discuss in group
I think it would be better to refer to the current channel of the BSS
or something like that.
4549
"The RA field of the RTS frame is the address of the STA, on the WM, that is the intended immediate recipient of the pending individually addressed Data, Management, or Control frame." -- what if there's no pending individual frame (e.g. it's to protect a broadcast)? What if it's to protect an Extension frame?
As it says in the comment
Discuss in group
4552
" The fields following the QoS Info field in the EDCA Parameter Set element shall be
included in all Beacon frames occurring within two (optionally more) delivery traffic indication map (DTIM)
periods following a change in AC parameters, which provides all STAs an opportunity to receive the updated
EDCA parameters." has two issues. 1) The fields following the QoS Info field in the EDCA Parameter Set element are not optional, so they are always included if the element is. 2) "(optionally more)" is unclear but appears to be saying it might only be after a million DTIM periods (i.e. it's as good as those "up to 50% off!" advertisements)Change to " The EDCA Parameter Set element shall be
included in all Beacon frames occurring within two delivery traffic indication map (DTIM)
periods following a change in AC parameters, which provides all STAs an opportunity to receive the updated
EDCA parameters."Wording is not clear. Also the point about the
fields always being present in an EDCA PS element stands. How about
something like:
The
fields following the QoS Info field in theEDCA Parameter Set element shall beincluded in all Beacon frames occurring within two
(optionally more)delivery traffic indication map (DTIM)periods following a change in AC parameters, which provides all STAs an opportunity to receive the updated
EDCA parameters; it may optionally be included in more Beacon frames.
4556
"Note that, as for an EDCA TXOP, a multiple frame transmission is granted to an EDCAF, not to a STA, so that
the multiple frame transmission is permitted only for the transmission of a frame of the same AC as the frame
that was granted the EDCA TXOP, unless the EDCA TXOP obtained is used by an AP for a PSMP sequence
or a VHT (11ah)or S1G MU PPDU with the TXVECTOR parameter(#2639) NUM_USERS > 1. " -- there are now other cases where transmission of frames from multiple ACs is permitted"Note that, as for an EDCA TXOP, a multiple frame transmission is granted to an EDCAF, not to a STA, so that
the multiple frame transmission is permitted only for the transmission of a frame of the same AC as the frame
that was granted the EDCA TXOP, except as specified in 10.23.2.7."Why not just ACCEPTED?
4557
"When an AP supports DL-MU-MIMO, frames from a higher or lower priority AC may be included
in a VHT or S1G MU PPDU with the TXVECTOR parameter(#2639) NUM_USERS > 1 when
these frames do not increase the duration of the VHT or S1G MU PPDU beyond that required for the
transmissions of the frames of the primary AC" conflicts with "Frames from a higher priority AC may be included when at least one frame from the primary AC has been transmitted and all frames from the primary AC have been transmitted": can I transmit higher priority AC frames even if the PPDU is thereby made longer?As it says in the comment
Discuss in group
Point is that the wording does not say "okay to transmit higher priority AC frames (as long as you stay within the TXOP Limit for the AC used for channel access)"
for DL MU-MIMO. Instead, it says:
When an AP supports DL-MU-MIMO, frames from a higher or lower priority AC may be included
in a VHT or S1G MU PPDU with the TXVECTOR parameter(#2639) NUM_USERS > 1 when
these frames do not increase the duration of the VHT or S1G MU PPDU beyond that required for the
transmissions of the frames of the primary AC(#2426).
So for DL MU-MIMO you cannot increase the duration of the frame
if that would not be necessary for the primary AC traffic,
even for higher-priority stuff that would fit within the TXOP.
4560
"The Address 3 field of the Management frame is set and determined as follows:". 3) covers OCB and 4) covers infra, IBSS and MBSS, but what about e.g. PBSS and TDLS?
In 4) change "AP" to "AP or PCP" and in 3) after "true" add "or the STA is transmitting the Management frame to a peer TDLS STA"
Why not just ACCEPTED?
4562
Discussions of the Address 2 (or A2) or Address 3 (or A3) fields should not be in Clause 11 since already in 9.3.3.1
As it says in the comment
OK -- assign to me if currently unassigned
4564
"Frame exchange sequences for Management frames [...] are excluded from the used_time update." -- this allows a STA to circumvent admission control by putting an Action No Ack in an A-MPDU together with a bunch of Data frames.
Change to "Frame exchange sequences that do not include any Data frames [...]"
Why not just ACCEPTED?
4566
"The Map Type field value "URL Defined" indicates the Map URL field value has a file extension, defined
as a mime type and is self-descriptive." is not clear. The MAP URL field has a MIME type appended? Exactly how is this appending signalled/encoded? Also, "mime" should be "MIME"As it says in the comment
I have no idea what this is trying to say. Maybe JonathanS or RoyW would know?
4571
Figure 65--Return path of OCT messages based on OCT parame-
ters(M70)(#2634) 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(#2631) of the MLME-OCTunnel.indication primitive.(M70)
and
the Multi-band peer parameter shall be set to the value of the Multi-bandOCT source parameter(#2631) received in the corresponding MLME-OCTunnel.indication primitive.
and
the Multi-band peer parameter set to the value of the Multi-bandOCT source(#2631) parameter of the MLME-OCTunnel.indication primitive."As it says in the comment
OK -- assign to me if unassigned
4572
"(#2620)The DMG Antenna ID subfield indicates the antenna or DMG antenna the transmitter is currently
using for this transmission." should have a NOTE to clarify it's an antenna when used by a CMMG STA. Maybe also needed at the end of 9.5.4?Change to "The DMG Antenna ID subfield indicates the antenna (for a CMMG STA) or DMG antenna (for a DMG STA) the transmitter is currently
using for this transmission."Do we want to do the 9.5.4 change? If not, why not just ACCEPTED?
4636
There are many technical issues with the description of subelements
Fix as suggested in 19/0856
OK -- assign to me if unassigned
4640
"the maximum time allowed to return beam tracking feedback to an initiator before it will be
considered invalid" -- it is not clear what "it" refers to here. It's not the feedback, because it hasn't been returnedAs it says in the comment
I think ChrisH has agreed to take this
4648
The need to qualify BU as DL BL only arises for 11ah; other STAs can only have BUs for DL anyway
In 11.2.3.5.1 change "downlink BUs to" to "BUs to a"
Why not just ACCEPTED?
4655
"with SHA-256" was deleted from the 3rd column but is still there in the fifth, for 00-0F-AC:8
Change "SAE
authentication" to "SAE
authentication with SHA-256" in third columnAsk Jouni which of 4655, 4656 and 4657's proposed changes he prefers
4656
"with SHA-256" was deleted from the 3rd column but is still there in the fifth, for 00-0F-AC:8
Change "SAE
authentication" to "SAE
authentication with SHA" in third columnAsk Jouni which of 4655, 4656 and 4657's proposed changes he prefers
4657
"with SHA-256" was deleted from the 3rd column but is still there in the fifth, for 00-0F-AC:8
Delete "using SHA_256" in fifth column
Ask Jouni which of 4655, 4656 and 4657's proposed changes he prefers
4659
"list of unsigned 16-bit integers" -- the endianness is not clear (security tends to be the other way round to the usual MAC conventions)
As it says in the comment
Assign to Jouni, or discuss in group
4677
Should specify that RA for Beacon frames (and e.g. FILS Discovery frames) is the broadcast address
As it says in the comment
Discuss in group
4687
Should not duplicate requirements already given elsewhere. For ack policy, it's all in Table 9-13--Ack policy
Delete "A recipient STA shall not send any
frame as an immediate response to an F-MPDU with Block Ack ack policy. An originator STA may solicit
an immediate response following an F-MPDU by setting the ack policy of the eliciting F-MPDU to Implicit
BAR.(#1415)". Delete "A STA shall not transmit an Ack or BlockAck frame in response to a QoS Data frame whose ack policy
is No Ack." in 10.3.2.11Why not just ACCEPTED?
4695
11.50 claims that "The Filtered Neighbor AP subfield in the Neighbor AP Information field shall be set to 1 if the AP
determines that the SSID corresponding to every AP in the Neighbor AP Information field matches the SSID of
the transmitting AP's BSS; otherwise it shall be set to 0.". However, 9.4.2.170.2 says that ")When included in a Probe Response frame, it is
set to 1 if the SSID corresponding to every BSS of the APs(#2576)(#341) in this Neighbor AP Information
field matches the SSID in the (11ai)corresponding Probe Request frame. (11ai)When included in a Beacon
or FILS Discovery frame transmitted by a non-TVHT AP, it is set to 1 if the SSID corresponding to every
AP(#341) in this Neighbor AP Information field matches the SSID of the transmitting AP's BSS. It is set to
0 otherwise.". Which is it?As it says in the comment
I think Abhi has agreed to take this one
4696
Do not duplicate length information given in figures in text (e.g. "is x bits/octets in length", "is an x-bit/octet field")
As it says in the comment
OK -- assign to me if currently unassigned (I vaguely thought Payam or MarkH had volunteered for this)
4701
Are you sure it's called null in ASCII? I thought it was called NUL
In 9.4.5.4 and 9.4.5.21 change "null" to "NUL"
Why not just ACCEPTED?
It's remarkably hard to find a copy of ISO 14962:1997. However, http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf does indicate that at least for ASCII the character is the NULL character, referred to as NUL
4707
CID 2308 follow-up. There are lots of rules for things like Acks, CTSes, PS-Polls, etc. The limited extensions to Clauses 10 and 11 to cover the NDP CMAC PPDU flavours of these MPDUs cannot cover all the cases where they are used and the rules that apply in each case. They have to inherit from the non-NDP-CMAC behaviours
At the end of 9.9.1 add "NDP CMAC frames are not MPDUs but NDPs, but they obey the rules for equivalent MPDUs, as shown in Table 9-539." In Table 9-539 add a column "Equivalent MPDU" and then for values 0 to 7 respectively say "CTS or CF-End", PS-Poll, Ack, "Ack to PS-Poll", BlockAck, Beamforming Report Poll, Action, Probe Request
Why not just ACCEPTED?
4727
CID 2548 followup. "The AP verifies that the extracted source MAC address is equal to the source MAC address of the (Re)Association frame. If these are different, the AP shall discard the FILS HLP Container element;" -- so there's no point passing the source MAC address, since the transmitter will always ensure they are the same (why bother sending something you know the other end will discard?). CID 1543 rejected this because "the FILS HLP Container element is reused in other situations, in which the source address field is required. Instead of defining another (new) element, the existing is reused (e.g. see D1.4 P 2461 L55)." This makes no sense as the whole point of this comment is that the source address is necessarily going to match, so adds no value. The rejection of CID 2548 said "The FILS HLP Container element is reused in association responses, in which both the source and destination address fields are required and may not match the addresses of the AP or STA" but surely in the case of the response the destination will necessarily be the STA. In all cases, only one address is needed and useful
Make the changes proposed in CID 1543
Why not just ACCEPTED?
4744
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
OK -- assign to me if currently unassigned
4745
The operation of OCT for scanning is not clear
Add an Annex to describe the sequence of events, and the contents of the primitives/MMPDUs (and where they come from) for an illustrative case like "wildcard scan for APs on channels 42 and 48 of band 5 (60G), tunnelled on 2G4 channels 1, 2 and 3"
OK -- assign to me if currently unassigned
4746
"If a non-AP and non-PCP STA that has an SA with its AP or PCP for an association that negotiated management frame protection receives an unprotected Deauthentication or Disassociation frame with reason code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME from the AP" -- this should be in the clauses dealing with receipt of a Deauthentication/Disassociation frame
As it says in the comment
OK -- assign to me if currently unassigned
For Mike (PHY/security):
CID
Comment
Proposed Change
Disposition re submission
4191
Using the rejected groups list as the salt means the salt can be very short, so it's only a weak salt
Add a mechanism to allow devices to set up a non-weak initial (i.e. before any rejected groups get appended) salt
I think Dan has a REJECTED ready for this
4227
Mark HAMILTON claims we need a definition of "minimum/receive/receiver sensitivity"
As it says in the comment
I think MarkH remembers what this is about and I surmise he's willing to take it on
4260
"existing"/"established" is usually otiose when it refers to agreements, BSSes, etc. since behaviour is generally about the present, not the past or future
As it says in the comment
OK -- assign to me if currently unassigned
4266
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
OK -- assign to me if currently unassigned
4270
Can TDLS be used between two STAs that are in different BSSes of an ESS (since tunnelled)? If not, what happens if a TDLS STA reassociates to a different AP?
As it says in the comment
I think Menzo has resolved this
4271
An AP needs 2 MIB tables for EDCA: one for itself and one for what it will signal to non-AP STAs. The former is dot11QAPEDCATable but the latter is not dot11EDCATable because this is defined as being set from an incoming EDCA Parameter Set element
Update dot11EDCATable so that at an AP it is used to define the EDCA parameters that are signalled to associated STAs
I think Menzo has resolved this
4277
We have all of "BA session" (4x), "block ack session" (17x), "BlockAck session" (4x) (and none are defined)
Change all to "block ack session" and define the term
Discuss in group
4286
It is not clear what the difference between 802.1X authentication and EAP authentication is. Jouni said "In the context of IEEE 802.11 standard, 802.1X authentication is really referring to EAP authentication, so these would also be interchangeable here"
Change "EAP authentication" to "802.1X authentication" throughout, except in the definition of IEEE 802.1X authentication and Extensible Authentication Protocol (EAP) reauthentication protocol (EAP-RP) and in the arrow label in Figure 4-31--IEEE 802.1X EAP authentication and Figure 4-37--Example using IEEE 802.1X authentication. Delete "EAP" in the caption of Figure 4-31--IEEE 802.1X EAP authentication and in Table 9-198--Transition and Transition Query reasons and in last para of 12.6.10.3 Cached PMKSAs and RSNA key management. Change "Successful completion of EAP authentication over IEEE Std 802.1X" to "Successful completion of IEEE Std 802.1X authentication" and "full EAP authentication via IEEE 802.1X authentication." to "full IEEE 802.1X authentication."
Why not just ACCEPTED?
4291
CID 2262 got rid of the PCF, but there are still lots of "+CF-Poll", "QoS CF-Poll", "CF-Ack", etc., which are only used under the PCF. There is also still a CF pollable definition and dot11QosCFPolls* MIB variables. These all need to go
As it says in the comment
I think Menzo has resolved this
4293
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
As it says in the comment
OK -- assign to me if currently unassigned
4298
It is confusing that a non-HT preamble is just STF+LTF while an HT preamble also includes SIG fields
As it says in the comment
Discuss in group
4299
"preamble" should really only be STF+LTF, but the HT one includes SIG fields. Maybe call the one with SIG fields the "PHY header"?
As it says in the comment
Discuss in group
4301
"When MAX-ACCESS is read-only, the MIB attribute value may be updated by the PLME and read from the
MIB attribute by management entities. When MAX-ACCESS is read-write, the MIB attribute may be read
and written by management entities but shall not be updated by the PLME." has some odd numerology; specifically it only appears for PHYs in odd-numbered clauses above 20Add the cited text to the end of the PHY MIB subclause of the other PHYs
Why not just ACCEPTED?
4314
"gives the current message number" (4x) -- the "message number" is not defined
Change "message number" to "TSC or PN" in each case
Why not just ACCEPTED?
4341
There are still a lot of "MCS"es. These need to be qualified with the PHY, to avoid confusion, except in generic contexts (e.g. 10.6.6.5.2 Selection of a rate or MCS)
Throughout, change "S1G MCS" to "S1G-MCS", "CMMG MCS" to "CMMG-MCS"
Why not just ACCEPTED?
4363
The use of "or both" (57x) implies that uses of "or" without and "or both" are exclusive, but this is not the case
Delete "or both" throughout
Discuss in group
4366
Message 1 uses the following values for each of the EAPOL-Key frame fields:" -- "Key Data = "" for the PMK being used during PTK generation(#59)" -- Jouni said in Vienna that it can contain other stuff, and that it should be referring to PMKID KDE. Also, should have general statement for all the Key Data = "" to say this is the minimum set of things that need to be included in the message, but other stuff (e.g. VS) may also be included
As it says in the comment
I think Jouni said he's willing to take, or at least look to take, all the Clause 12 comments
4394
There are ~11 instances of "current ESS", but this is not defined
As it says in the comment
See CID 4395
4395
There are ~11 instances of "current ESS", but this is not defined
Change each to "ESS of which the STA is a member" (if you accept STAs can be members of an ESS, not just of a BSS)
Why not just ACCEPTED?
4399
Constructs of the form "may do X by doing Y" are ambiguous because the might mean "if you do X, then Y might happen" or "if you do X, then Y will happen"
As it says in the comment
OK -- assign to me if currently unassigned
4423
How does a "duration time" or "time duration" differ from a "duration"
Change "duration time" and "time duration" to "duration" throughout
Why not just ACCEPTED?
4453
"The QoS Action field is defined in 9.6.3.1 (General). representing ADDTS Reserve Response.
The (#2110)Higher Layer Stream ID element is defined in 9.4.2.124 (Higher Layer Stream ID element).
The Status Code field is defined in 9.4.1.9 (Status Code field)." is too vague. Needs to refer to specific contents. Similarly in other locationsAs it says in the comment
OK -- assign to me if currently unassigned
4477
PHY-RXEND.ind is defined to be sent after any signal extension (" When a Signal Extension is present, the primitive is
generated at the end of the Signal Extension."; "When receiving a signal extended PPDU, the PHY-
RXEND.indication primitive shall be emitted a period of aSignalExtension after the end of the last symbol
of the PPDU."). So the PHY receive procedures need to show the PHY-RXEND.ind as being after the SEAs it says in the comment
OK -- assign to me if currently unassigned
4513
40 MHz non-HT duplicate and HT-MCS 32 will both achieve 3 dB power gain; typically, non-HT will have better PER performance because the L-LTF density [xxft]
Deprecate HT-MCS 32
Why not just ACCEPTED?
4523
Text about "channel starting frequency" sometimes does not give the units (e.g. in 20.3.1), and is inconsistent as to case of channel, italicisation (e.g. none in 17.3.8.4.2), and presence of article
As it says in the comment
OK -- assign to me if currently unassigned
4525
An ax comment said "W.r.t. dynamic defragmentation, it is mentioned that a recipient STA shall discard incomplete fragments when receiving a BlockAckReq to move the BA window. When the STA receives a DELBA to tear down the BA agreement, the STA should/shall do the same". The requirement to discard incomplete fragments on receiving a BAR that moves the window or a DELBA needs to be captured
As it says in the comment
Discuss in group
4527
The concept of a frame being "protected" is used without being defined
Define a protected frame as a frame that is authenticated and/or encrypted
Discuss in group
4598
Do the rules on permissible transmission using optional feature Foo also need conditioning on dot11FooActivated? An example of where this is done is "An HT STA shall not transmit a frame in a PSDU with the TXVECTOR parameter(#2639) FORMAT
set to HT_MF or HT_GF and TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA
of the frame corresponds to an HT STA for which the LDPC Coding Capability subfield of the HT Capabilities
element received from that STA contained a value of 1 and dot11LDPCCodingOptionActivated is true (if there
is more than one intended receiver, then this requirement applies for each intended receiver)."As it says in the comment
Discuss in group (this might relate to the ARC discussions on dot11FooActivated/
Implemented/whaterver
4602
There is confusion (cf. CID 2137 I think) about the general concept of a temporal key, and the temporal key (TK) in PTKs (Jouni is adamant they are not the same)
As it says in the comment
I think Jouni said he's willing to take, or at least look to take, all the Clause 12 comments. Alternatively, do we agree that the TK in PTKs is a vanilla temporal key
4629
"The RCPI encoding is defined in 15" should be referring directly to Clause 9, as in 16.3.8.6 Received Channel Power Indicator Measurement
Fix in 17.3.10.7 Received Channel Power Indicator Measurement and 20.3.10 Received channel power indicator (RCPI) measurement
Hasn't Dorothy already resolved this?
4630
Actually, the PHY doesn't have to have any particular encoding for the RCPI. It should pass the RCPI in dB to the MAC, and let the MAC worry about how to encode it over the air
In all the PHY Received Channel Power Indicator Measurement subclauses, delete the reference to how the RCPI is encoded. In all the PHY TX/RXVECTOR tables, say that the RCPI is returned with 0.5 dB precision
Discuss in group
4632
CID 2177 follow-up. RSSI RXVECTOR param units should be specified. Some but not all PHYs say "RSSI is
intended to be used in a relative manner, and it shall be a monotonically
increasing function of the received power" but even for those PHYs it is not clear what the use of something that has no units isAs it says in the comment
Discuss in group
4635
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
Discuss in group
4646
It seems possible "beacon interval" has multiple meanings. This needs to be clarified
See 19/0856 discussion and
Discuss in group. See also CID 4697
4654
All references to "element"s (irrespective of case) that are about security objects should be FFE, to avoid confusion with 802.11 elements (9.4.2)
As it says in the comment
OK -- assign to me if currently unassigned
4686
There are multiple references to "the virtual CS mechanism", but there are multiple virtual CS mechanisms for S1G STAs (and maybe also DMG STAs), so which is intended is not clear
As it says in the comment
Discuss in group
4697
CID 2316 follow-up. Re "beacon interval", need to distinguish "from one TBTT to the next" and "from one beacon to the next TBTT" from "a duration equal to the time between TBTTs, that may start at any time"
As it says in the comment
Discuss in group
4698
What is a "SAE exchange" as opposed to "SAE authentication"? Ditto "FILS exchange"
As it says in the comment
See if Jouni will take this
4699
"remaining TXOP duration" is not well-defined. Maybe it's just TXNAV?
As it says in the comment
Discuss in group
4703
There are some places that are poorly worded and suggest the EDCA Parameter Set element is not always provided at association in a QoS BSS
As it says in the comment
OK -- assign to me if currently unassigned
4706
According to 18/1636r0, "There is no reference to dot11STACivicLocation in main body of the standard. The same thing apply to dot11STACivicLocationType.
Furthermore, it seems that dot11STACivicLocationConfigTable is poorly defined and probably does not pass MIB compilation. In description of "dot11RMCivicConfigured", there is a reference to dot11STACivicLocationEntry. However, dot11STACivicLocationEntry is not defined anywhere."As it says in the comment
See if RoyW or JonathanS will take this
4710
There are various references to "NDP frames" and "non-NDP frames". The first is a misnomer because NDPs are NDPs not frames; the second is pleonastic since all frames (MPDUs) are not NDPs
This appears to be some 11ah horror, so change all instances of "non-NDP frame" to "non-NDP-CMAC frame", all instances of "sounding NDP frame" to "sounding NDP", and all remainng instances of "NDP frame" to "NDP CMAC frame". Dieu reconnaitra les siens
Discuss in group
4711
We should not refer to PPDUs as frames, since this is needlessly confusing. "frame" should be a synonym for "MPDU" only
Change all references to "frame"s that are in fact PPDUs to "PPDU"
OK -- assign to me if currently unassigned (I think MarkH might have some locations too)
4712
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"
OK -- assign to me if currently unassigned
4721
The whole "field" v. "subfield" thing is just a big inconsistent mess (e.g. in 9.4.2.171 Reduced Neighbor Report element some things in the Neighbor AP Information field are fields and some are subfields, and the TBTT Information Set [sub!]field contains one or more TBTT Information fields). There is no value in trying to make the distinction, because (a) the distinction is not made reliably and (b) it's not possible to make the distinction, because some things are subfields of X but are also the field that contains subfield Y
Change "subfield" to "field" throughout
Why not just ACCEPTED?
4734
It is confusing to have something called "FILS Shared Key authentication", as it sounds as if this is a special case of "Shared Key authentication" (a.k.a. WEP)
Delete Subclause 12.3.2
I think we did this one in Irvine
4736
CID 1446 clarifies that an operating class defines four things. However, this is not compatible with the resolution of some previous comments related to operating classes
Review previous comments on operating classes and address those whose resolution is not compatible with the definition in E.1
OK -- assign to me if currently unassigned
4739
Some work was done in TGmc to make the description of all the flavours and interactions of CS clearer, but this didn't come to fruition. It should be attempted again
As it says in the comment
OK -- assign to me if currently unassigned
4740
Some of the ResultCodes in the SAP have underscores (e.g. JOIN_FAILURE_TIMEOUT, NOT_SUPPORTED) some not (e.g. AUTH FAILURE TIMEOUT, ANTI-CLOGGING
TOKEN REQUIRED). There is no justification for this inconsistency. Underscores make it easier to find result codes, so are preferableChange "AUTH FAILURE TIMEOUT" to "AUTH FAILURE_TIMEOUT" throughout the document
Why not just ACCEPTED?
4741
Some of the ResultCodes in the SAP have underscores (e.g. JOIN_FAILURE_TIMEOUT, NOT_SUPPORTED) some not (e.g. AUTH FAILURE TIMEOUT, ANTI-CLOGGING
TOKEN REQUIRED). There is no justification for this inconsistency. Underscores make it easier to find result codes, so are preferable, but if the group rejects this, then the alternative is to replace underscores with spaces in all ResultCodesAs it says in the comment
See 4740
4742
Some of the ResultCodes in the SAP have underscores (e.g. JOIN_FAILURE_TIMEOUT, NOT_SUPPORTED) some not (e.g. AUTH FAILURE TIMEOUT, ANTI-CLOGGING
TOKEN REQUIRED). There is no justification for this inconsistency. Underscores make it easier to find result codes, so are preferableAs it says in the comment
See 4740
4743
There are references to "physical carrier sense", "virtual carrier sense" and "physical CS" and "virtual CS" but the terms are never defined.
Use "CS" rather than "carrier sense" except when defined etc.
The terms PHYCS and PHYED are defined but barely used.
There is a zoo of inconsistent terminology for "carrier sense", whch makes it hard to understand exactly what is meant where and how the various PHYs compare: CS, CCA, CS/CCA, energy detect, ED, PHYED, CCA-ED, CCA Mode 1-5.
"CCA-ED" just confuses everyone, because everyone thinks it means CCA using ED, when in fact it means some wacko mode of operation in wacky regulatory domains/bands.
There are also issues of editorial and technical consistency between the PHYs.As it says in the comment
OK -- assign to me if currently unassigned
4747
It is not clear whether the SME picks the Key ID for transmission of encrypted frames (using the Key ID parameter of the MLME-SETKEYS.request) or whether the MAC does so. Additionally there are various issues with the security pseudocode
As it says in the comment
See if Jouni will take this
4749
As a follow-up to CID 7572 in mc, I got the following input from Jouni MALINEN:
In 12.9.2.2, MLME-SETPROTECTION.request is supposed to apply to _all_ keys. The only MSDU that this "transmit without protections" case could apply to is an EAPOL frame that is used to carry either EAP authentication of 4-way handshake prior the initial key configuration in an association. There is no group-addressed MSDU that could be sent out unprotected in a BSS that has RSN enabled.
That said, clearly the GTK cases are not fully covered in the current standard. Interestingly, IGTK is actually covered in 11.13. The last paragraph of 12.6.14 should really point out that MLME-SETPROTECTION.request is used with GTK.
12.7.11.1 (Authenticator key management state machine) Figure 12-52 has interesting MLME-SETPROTECTION.request(TA, Rx_Tx) use in the
REKEYESTABLISHED state for GTK and Figure 12-53 SETKEYSDONE uses MLME-SETPROTECTION.request(Rx_Tx, IGTK), but nothing similar for GTK.
This does not really make any sense for GTK. It should also be covered in SETKEYSDONE and there should be no TA in the parameters (the Address parameter within Protectlist is not used for Key Type = Group case) and ProtectType should be Tx for an AP (and actually, also for IBSS, since there is separate Tx key for each STA). That Rx_Tx for IGTK is also incorrect (should be Tx).Address all the issues raised in the comment in the way described in the comment
I think Jouni said he's willing to take, or at least look to take, all the Clause 12 comments
4750
Discussions related to CID 7592 and 7593 in mc have revealed that the description of legacy PS and U-APSD is hopelessly muddled in terms of things like how PS-Polls operate for U-APSD and duplication of statements and consistency of description
Refactor the wording
OK -- assign to me if currently unassigned
4751
The distinctions made in the specification w.r.t. TS/TC/TSID/TID are incomprehensible
Make the definitions comprehensible. E.g. what does "UP for either TC or TS" mean?
I think Osama is doing a similar comment
4753
The description of the PHYCONFIG_VECTOR is missing for DSSS, HR/DSSS, ERP, DMG and TVHT
Add such a description
OK -- assign to me if currently unassigned
4755
There are millions of MIB variables/tables to do with LCIs and civic locations, and it is not clear which are used in which contexts (TVWS, DSE, FTM, neighbour report, etc.)
Add some words to the parent MIB node to disambiguate them all (including the way in which/why an index is used, where an index is used)
See if RoyW or JonathanS will take this
4756
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
Add "TDLS" or "DMG" before "awake window" where "mesh" is not present there
Discuss in group
4759
It is not clear what a "Receive IGTK SA" is. Such a SA is not described in 12.6.1.1.
Jouni has suggested that "Receive IGTK SA" was trying to refer to the IGTKSA used for receiving frames from the specific peer in MBSS. 12.6.1.1 does not define this, but it does have Mesh GTKSA (and Mesh GTKSA description in 12.6.1.1.10 mentions "transmit mesh GTKSA" and "receive mesh GTKSA"). Maybe a Mesh IGTKSA should be defined similarly to this. Or simply talk about IGTKSA (of which there would be zero or more for each peer). It should be noted that the existing sentence is this paragraph talks about "Receive MGTK SA" (which is not described in 12.6.1.1, but is mentioned in its subclause 12.6.1.1.10). The comment proposed language that is similar to that for the "Receive ... SA" partAs it says in the comment
I think Jouni said he's willing to take, or at least look to take, all the Clause 12 comments
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
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