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

[STDS-802-11-TGM] Resolutions for some comments on 11md/D3.0 (SB1)

--- 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 frames

Change 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 frames

Change 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 MCSes

Change 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 parameter

Delete 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 21270

As 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 field

Delete 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 ProbeTimer

Change 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 measurement

As 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 MPDU

As 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 happen

As 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 RTS

In 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 contexts

As 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 frame

Change 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 field

Change 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 below

Delete 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 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; 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 returned

As 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 column

Ask 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 column

Ask 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.11

Why 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 20

Add 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 locations

As 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 SE

As 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 is

As 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 preferable

Change "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 ResultCodes

As 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 preferable

As 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" part

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

 

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

Attachment: noname
Description: GIF image