July 2010doc.: IEEE 802.11-10/0830r0
IEEE P802.11
Wireless LANs
Date: 2010-07-12
Author(s):
Name / Affiliation / Address / Phone / email
Jon Rosdahl / CSR / 10871 N 5750 W
Highland, UT84003 / +1-801-492-4023 /
TGmb Monday AM1 slot
1.1Called to order at 1:30pm by Dorothy Stanley – 16 attendees.
1.2Review proposed agenda
1.3Announcement of officers and affiliations.
1.4Patent Policy reviewed
1.4.1No patents or LOA requests noted
1.5Review other WG Rule slides.
1.6Review of Agenda in 11-10-0722r0
1.7Review of Attendance recording procedures
1.7.1See 11-09/0246r0
1.8Documentation
1.8.1
1.8.2Use “TGm” for documents relating to the Revision PAR
1.9Review of Last LB:
1.9.1Results from LB163 (REVmb-D4.0)
1.9.2164 affirmative (89%), 20 negative (11%), with 28 abstentions
1.9.3Change from LB 162: -3 affirmative, +0 negative, +3 abstain
1.9.4This was a recirculation ballot; all comments must be against changed text
1.9.598 comments received (57 technical), stored in 11-09/0706r13 as CIDs 4000 to 4097
1.10Current TGmb Plan of Record
1.10.1May 2008 – Issue Call for Comment/Input
1.10.2July 2008 – begin process input and old Interpretation requests
1.10.3 Acknowledge previous Task Group referrals
1.10.4Sept 2008 – PAR revision process started
1.10.5Nov 2008 – close receipt of new input
1.10.6Nov 2008 – WG/EC approval of PAR Revision
1.10.7Dec 2008 – NesCom/SASB approval PAR Revision
1.10.8May 2009 – First WG Letter ballot
1.10.9Nov 2009 – Recirc start
1.10.10July 2010 – Conditional Sponsor Ballot Approval from EC
1.10.11August 2010 – Form Sponsor Pool (45 days)
1.10.12September 2010 – Sponsor Ballot start
1.10.13December 2010 – Sponsor Recirc. start
1.10.14March 2011 – WG/EC Final Approval
1.10.15June 2011 – RevCom/SASB Approval
1.11Approval of minutes of prior meetings
1.11.1May 2010 minutes: 11-10/0629r0
1.11.2Teleconference Minutes: 11-10/0707r1
1.11.3No matters were noted:
1.11.4Minutes approved by acclamation
1.12Review of Draft Update & Editor’s Report (Adrian Stephens)
1.12.1See 11-10-0002r3
1.12.2Adrian to send out an editorial update to the AdHoc Chairs.
1.13Review Sept 2010 Meeting plan:
1.14Review Conditional approval packagel for the EC approval to go to Sponsor ballot.
1.14.1Need to have outstanding Commentors state which comments were still outstanding.
1.14.2There is more work to address outstanding comments not satisfied.
1.14.3Current no-voters are being contacted
1.14.4Unsatisfied comments will need to be included in the EC package
1.15Proposed TGmb Agenda
1.15.1Monday PM1
1.15.1.1Chair’s Welcome, Status, Review of Objectives, Approve Agenda
1.15.1.2Comment Resolution
1.15.1.3Motions
1.15.2Tuesday PM1
1.15.2.1Comment Resolution
1.15.2.2Key Info/Key Descriptor Field use – Dan Harkins
1.15.2.3Motions
1.15.3Tuesday PM2
1.15.3.1Comment Resolution – Clause 11.3 (Assoc/Reassoc)
1.15.3.2Motions
1.15.4Wednesday PM1
1.15.4.1Comment Resolution
1.15.4.2Motions
1.15.5Wednesday PM2
1.15.5.1Comment Resolution
1.15.5.2Motions
1.15.6Thurs PM 2
1.15.6.1Comment Resolution
1.15.6.2Request for conditional approval for SB
1.15.6.3Motions
1.15.6.4Plans for September
1.15.6.5Adjourn
1.15.7No objection to the proposed Agenda – approved.
1.15.8See 11-10-0722r1 for updated agenda.
1.16Editorial change report and motion are documented in 11-10/02r3.
1.16.1The 09/956r8 has the proposed resolutions this has been used to spectulative edit D4.01.
1.16.2Discuss CID 4074
1.16.2.1 Review the comment
1.16.2.2Action fields vs Action Frames….
1.16.2.3The group agreed with the proposal of “Action Frames” for consistency.
1.16.3CID 4075
1.16.3.1Review the comment
1.16.3.2Disagree with commentor to make a change
1.16.4CID 4058
1.16.4.1Review the comment
1.16.4.2 Agree that QoS to be “Qos” in the cited text, there may be other instances of Qos but in dot11Qos cases we only had this one case missed. In other instances, we have not been consistent with the Qos vs QoS, so we may want to revisit it in a new comment in the future if needed.
1.16.5MOTION #93: Approve comment Resolution in 09/0956r8 on the “LB163 Editorals Tab”.
1.16.5.1Moved Adrian Stephens, Michael Montumorro
1.16.5.2 Count: 11-0-2 motion passes.
1.17MAC Comments:
1.17.1CID 4028
1.17.1.1Review comment and context
1.17.1.2 Acronym and full title not the same in the normative text and the figures. Do we add an acronym after the full title, or change the figure?
1.17.1.3The editor would rather have the figure just have the full name.
1.17.1.4Proposed Resolution: Agree in Principle, Replace “Pwr MGT” with Power Management” and “More Frag” with “More Fragments” in figure 7-2..
1.17.1.5No objection, move to ready to motion
1.17.2CID 4026
1.17.2.1Review the comment and context
1.17.2.2QoS versions of the protected frames fields.
1.17.2.3 Proposed Resolution: Agree in Principle: Modify the cited sentence to include “QoS Null (no data), QoS CF-Poll (no data), and QoS CF-ACK+CF-Poll (no data)”
1.17.2.4Concern that we are making a actual change, but the clause is redundant and sets or clears the Protected bit.
1.17.2.5After discussion we found it was ok.
1.17.2.6No objections, move to ready for motion
1.17.3CID 4027
1.17.3.1 Review comment and context
1.17.3.2 Clause 7.4a.3 says that the ESOP is the same in the A-MSDU, but there is not description of how to set the field.
1.17.3.3The cited location has some description, but not complete. There should be a general description and then reference the 7.4a.3 with the additional text added.
1.17.3.4Concern that compliant devices would become non-compliant if we were to do this, so we may not want to do this change.
1.17.3.5 The comment is only finding a bit that was missing, are there other parts missing?
1.17.3.6 The ESOP bits only exist for the frames transmitted by the HC, and for frames sent by station, the bits are now something else.
1.17.3.7Bit ESOP is not contained in bit 8-15 defintions, so while we may be ok with the comment for ESOP, we are not in agreement in 8-15 bits.
1.17.3.8Need more time to think about this problem.
1.17.4CID 4025
1.17.4.1 Review the comment and context
1.17.4.2Discussion on what it should be, and looked at 6.1.1.3 as a explaination.
1.17.4.3 Proposed Resolution: Disagree: The setting of the ACK policy is defined in Clause 6.1.1.3. Further 6.1.1.3 clarifies that MSDUs of different service classes be sent using MPDUs with different ACK policy. This means that an A-MSDU can only contain MSDUs of the same service class and no additional specification is needed to describe how to combine different service classes in an A-MSDU.
1.17.4.4No objection, mark ready for motion.
1.17.5CID 4024
1.17.5.1 Review the comment and context.
1.17.5.2Proposed Resolution: Disagree: The setting of the ACK policy is defined in Clause 6.1.1.3. Further 6.1.1.3 clarifies that MSDUs of different service classes be sent using MPDUs with different ACK policy. This means that an A-MSDU can only contain MSDUs of the same service class and no additional specification is needed to describe how to combine different service classes in an A-MSDU.
1.17.5.3Basically a duplicate of 4025
1.17.5.4No objection, mark ready for motion
1.17.6CID 4062
1.17.6.1Review the comment and context
1.17.6.2 Proposed resolution Agree in Principle: Change “ADDBA Request” to “ADDBA Request and Response”.
1.17.6.3No objection , mark ready for motion
1.17.7CID 4034
1.17.7.1Review the comment and context
1.17.7.2Proposed Resolution: Agree
1.17.7.3No objection, mark ready for motion
1.17.8CID 4059
1.17.8.1Review comment and context
1.17.8.2 Check to ensure that RCPI is described in 19 and 20.
1.17.8.3 Proposed Resolution: Agree
1.17.8.4No objection, Mark ready for motion
1.18Gen AdHoc comments:
1.18.1Mike Take notes while Jon is projecting
1.18.2Discussion on GEN Adhoc comments
1.18.3CID 4001
- The task group agreed to mark the text deprecate and allow 11mc to remove.
- Agreed resolution: "Disagree. The object was already marked "Deprecated" will be considered for removal in a futurerevision."
- Mark the comment "Ready for Motion".
1.18.4CID 4031
- The temp type was intentionally retained to allow vendors to mark temperature clause.
- debate on whether the "*" was required.
- Agreed resolution: "Agree in Principle. Change "Radio type (temperature range)" to "Which temperature type is supported?"Remove the "CFxx:" in the 4th column of the CFxx section. Also remove the "*" from the "*CFxx"in the first column.
1.18.5CID 4000
- Agreed Resolution: "Disagree. CFxx is included to provide manufacturers a way to indicate the temperature type."
1.18.6CID 4031
- Discussion on the additional details on the comment.
-Update the resolution with" Also remove the "*" from CF5."
1.19Recessed at 3:30pm
2.0TGmb Tuesday PM1
2.1Meeting called to order at 1:35pm Dorothy Stanley – 13 attendees
2.2Proposed agenda for this block:
2.2.1Key Info/Key Descriptor Field use – Dan Harkins
2.2.2Comment Resolution
2.2.3Motions
2.3Doc 11-10/856r0 -- Key Info/Key Descriptor Field
2.3.1Not posted yet due to Microsoft PowerPoint 2010 issue. Adrian to assist to get it fixed and posted right after this time slot.
2.3.2Reviewed Presentation.
2.3.3EAPOL Key Frame Key Descriptor Version
2.3.3.1Describe what the version number determines today.
2.3.4Discussion on how useful the Key Descriptor version is.
2.3.4.1Clause 8 seems to indicates usage.
2.3.4.2Question on how to use the proposal in a backward compatible way?
2.3.4.3Vendor Specific use would not be effected by this, as they would be using it the same way they are, the version is not indicative of the AKM being used.
2.3.4.4As TKIP is deprecated, so we should deprecate version 1 at the minimum.
2.3.4.5The Pair-wise cipher, the use of TKIP required to use a specific key wrapping method.
2.3.5This presentation was informational for a proposal that will be coming later and a text submission and a comment in the first sponsor ballot time frame may be submitted.
2.4Comment Resolution – MAC AdHoc
2.4.1825r1 was posted with the current status of the MAC AdHoc
2.4.2CID 4063
2.4.2.1Review Comment and context
2.4.2.2Proposed Accept in Principle ADDBA Response frame was included in 7.3.1.15 as part of the resolution to CID 4062
2.4.2.3No objection, mark ready to motion in group 2
2.4.3CID 4093
2.4.3.1Review comment and Context
2.4.3.2Proposed Accept in Principle: The same issue exists for the Neighbor Report. One way to solve this issue is to modify the second paragraph in clause 11.10.5, changing: “and the corresponding report shall have the Incapable bit in the Measurement Report Mode….” To “and the corresponding report shall include a Measurement Report IE with the Incapable bit in the Measurement Report Mode Field set to 1. Measurement requests for radio measurements that the STA has advertised is not capable of shall be rejected, and the corresponding report shall include a Measurement report IE with the Incapable bit in the Measurment Report Mode Field set to 1.”
2.4.3.3Concern on how to fix this and remain backward capatible. Also backward compatible with something that is incapable, is nonsense. So for this case, the change would be for one field.
2.4.3.4This seems to be underspecified., but maybe not. More effort to look at this may be needed.
2.4.3.5The proposed change is thought to be an improvement.
2.4.3.6Opitonal SubElements are different from IE, so this is not quite correct. See page 295 for list of Optional Subelements IDs for Linke Measurement Report Frame.
2.4.3.7Add to the Proposed Resolution:
2.4.3.7.1“Instruct the editor to add the Measurement Report IE as an Optional sub-element to all sub-element ID tables in 7.4.6.2, and 7.4.6.4.
2.4.3.8We were not able to find a good solution, as there is not an easy fix.
2.4.3.9The incapable bit in the Measurement field in 7.4.6.2.
2.4.3.10In 7.4.6.4, there is no sub-element.that would be allowed.
2.4.3.117.4.6.2 does not seem to have a problem.
2.4.3.12Only 7.4.6.4 and 7.4.6.6 have the issue.
2.4.3.13Measurement Report Mode field definition is in 7.3.2.22.
2.4.3.14We could define a sub-element with the same name and definition that contains this same fields. We already have several uses that would conflict.
2.4.3.15Proposed Resolution: Disagree – The group considered the commentor’s solution, but does not believe it resolves the issue. The first proposed alternative attempts to add an information element to a structure which is parsed in terms of sub-elements, causing a clash of name-spaces. The second proposed change would break backward compatibility.
2.4.3.16No Objection – Move Ready for Motion in Group 2
2.4.4CID 4038
2.4.4.1Review comment and context
2.4.4.2Proposed Resolution: Accept in Principle. We Define FTO (Fast BSS- Transition Originator) to refer to the STA in this case. Replace “STA’s” with “FTO’s” in the cited locations. Change STA to FTO in 7.4.8.3 (p309.17).
2.4.4.3No objection move to ready for motion in Group 2
2.4.5CID 4097
2.4.5.1Review comment and context
2.4.5.2There seems to be a nested iff that was missing
2.4.5.3Proposed Resolution: Agree
2.4.5.4No objection move to ready for motion in group 2
2.4.6CID 4060
2.4.6.1Review comment and context
2.4.6.2Proposed Resolution: Accept.
2.4.6.3Some concern on backward compatibility
2.4.6.4More review of context
2.4.6.5No objection to the Resolution move to ready for motion in group 2
2.4.7CID 4064
2.4.7.1Review comment and context
2.4.7.2The definitions are going to be moved to clause 3, so the change would not be necessary, so instead leave as is, and move to clause 3.
2.4.7.3CID 4023 moves the definitions for BU to 3.2 and the abbreviation in 3.3.
2.4.7.4Proposed Resolution: Agree in Principle: CID 4023 moves the cited definition to clause 3.2
2.4.8CID 4066
2.4.8.1Reviewed Comment
2.4.8.2Proposed Resolution: Disagree – Commenter withdraws comment.
2.4.8.3Move to ready for motion in group 2
2.4.9CID 4030
2.4.9.1Review Comment and context
2.4.9.2Proposed resolution: Accept in Principle: Modify the paragraph changing “ACK” to “ACK frame or BA frame”. Change “The Power Management bit in the Frame Control field of the frame” to “The Power Management bit(s) in the Frame Control field of the frame(s)”.
2.4.9.3No objection move ready to motion in group 2
2.4.10CID 4027
2.4.10.1 Review the comment again. It would be better to ensure that the bits are sent the exact same in all the frames in the A-MSDU.
2.4.10.2So if we say that bit 4 shall be the same, nothing bad happens. That would be ok.
2.4.10.3Proposed Resolution: Accept in Principle Add the following to clause 9.7d, “When an A-MPDU contains multiple QoS control fields ,buts 4 and 8-15 of the QoS control fields shall be identical.” In Clause 7.1.3.5.0a, add the following: “See 9.7d.1. for constraints on the contents of the QoS Control Field when present in an A-MPDU.”
2.4.10.4No objection move ready to motion in group 2
2.4.11CID 4040
2.4.11.1Review comment and context
2.4.11.2The PS-Poll if you are a non-QoS then it is clear. If you are a QoS STA, you can use the appropriate AC for the PS-Poll. PS-Poll ACK has no clear definition for the Control Frames. but the discussion was lost and did not really have anything to do with the comment here.
2.4.11.3Proposed Resolution: Accept.
2.4.11.4No objection, move ready to motion in group 2
2.4.12CID 4050
2.4.12.1Review Comment and context
2.4.12.2Proposed Resolution: Accept in Principle, Make the cited changes as indicated. Remove“’s MAC” in the caption of Figure 11-9 (801.43).
2.4.12.3No objection, move ready to motion in group 2
2.5Recess at 3:28pm
3.0TGmb Tuesday PM2
3.1Called to order at 4:02
3.2There was a request from David Cypher to review the temperature comments.prior to moving to the 11.3 comments.
3.3Mike Montemurro to take minutes the rest of this time block. (THANKS).
3.4Temperature comments:
3.4.1CID 4031 - Discussion on Previous Resolution.s
3.4.1.1- There can't be a temperature reference in the PICS because there is nothing to reference to in the standard.
3.4.1.2- There can be no normative text in the PICS that is not in the base standard.
3.4.1.3- There's no reference for CF3, CF4, and CF5. However the reference could be added - the reference exists.
3.4.1.4- CF1 gives a reference to Clause 5.2. Clause 5.2 is a non-normative clause which is against the IEEE style guide.
3.4.1.5- There is an IEEE 802.11 style manual.
3.4.1.6- This clause cannot be interpreted using the IEEE Standards style guide.
3.4.1.7- One way to resolve this is to add an informative statement in Clause 5 and point the row in the PICS.
3.4.1.8- The purpose of indicating the temperature range in the PICS was for a vendor to indicate their operational temperature range.
3.4.1.9- We could add a statement in clause A.2
3.4.1.10- The operating temperature could be put in a box by itself.
3.4.1.11- There should not be an individual row because there is no reference.
3.4.1.12- There is no ambiguity with what is currently written. It could be improved by changing "O.4" to "O".
3.4.1.13- The commentor is asked to propsed alternatives to providing this information in the PICS according to existing ot ISO standards.
3.4.1.14- There is other information about a device that is not included in the PICS.
3.4.1.15- We should re-consider removing the 4 rows.
3.4.2- CID 4000. Change the comment resolution to "Accept"
3.4.3- CID 4031. Change the comment resolution to "Accept in Principle. Remove CFxx and the "*" from "CF5"
3.4.4- Leave CID 4001 is unchanged.
3.5Discussion on Clause 11.3 – Non-Architecture comments:
3.5.1CID 4055. Agree and mark "Ready for Motion".
3.5.2CID 4045 - move to Clause 11.3 - Architecture.
3.5.3CID 4041 - The figure shows states and state changes for an originating STA.
3.5.4 - perhaps we could add a statement referring to the figure that "not all state changes are shown".
3.5.5 - there can be different behaviour for an AP versus a STA under certain conditions.
3.5.6CID 4053 - Skip
3.5.7CID 4044 - We should remove the paragraph.
3.5.8CID 4051 - This resolution is dependent on the resolution to CID 4044.
3.5.9CID 4044 - The proposed resolution to 4044 cleans up a corner case with MFP. We can reject the comment and simply leave the FT exception. However we still have an MFP corner case to address.
3.5.10Discussion on document 11-10/826r1 - Proposed changes to clause 11.3
3.5.10.1- Assign CID 4044 to Mark Hamilton with an updated version of document 11-10/826r1.
3.5.10.2- Assign CID 4051 to Mark Hamilton with an updated version of document 11-10/826r1
3.5.10.3- This document is built on the assumption that the Task Group accepts the changes in document 11-10/728r1
3.5.11CID 4043 - Document 11-10/826r1 addresses this comment.
3.5.11.1- The originating STA moves to state 1 if the authentication fails.
3.5.11.2- The AP does not change state if authentication fails.
3.5.11.3- In the FT case, the STA and the AP remain in their previous state if FT-Auth fails.
3.5.12CID 4054 - document 11-10/826r1 addresses this comment.
3.5.13CID 4042 - document 11-10/826r1 addresses this comment.
3.6Recess at 6pm
4.0TGmb Wednesday July 14, 2010 -- PM1 – 1:30pm
4.1Meeting called to order by Dorothy Stanely at 1:33pm.
4.2Gen AdHoc comments:
4.2.1Notes taken by Mark Hamilton
4.2.2CID #4077:
4.2.2.1Yongho e-mailed Dorothy. He is withdrawing this comment, based on discussion with Peter E.
4.2.2.2Proposed Resolution: “Disagree. Commenter has withdrawn the comment”
4.2.3CID #4076: Same as above.
4.2.4CID #4035:
4.2.4.1Proposed Resolution: Agree
4.2.5CID #4052:
4.2.5.1Discussion: Is the concept “WDS” used or defined by the Standard, just not explicitly? It is believed there are implementations that are called compliant, which implies the concept does exist in the Standard. Noted that 802.11s describes the 4-address frame format as “formerly known as WDS”. “WDS” was removed as a term, in 802.11-2007. It seems three instances were left in (ignoring Annex C): Definitions, Figure 8-38, and Annex D. Dorothy will do an archeological dig for the history of this change in TGma, and report back.
4.2.6CID #4067:
4.2.6.1This topic was considered in CID #3083 in Beijing. This comment has a more specific proposed resolution, in response to the reject done in Beijing. Dorothy will contact Venko, Eldad and Youhan to get more expert opinions, and will report back.
4.2.7CID #4095:
4.2.7.1Look at Figure 9-14 and Figure 9-20. Note CID #1648 was done in Draft 2.0. Discussion that the equation in question is a duration that starts after the initial SIFS. Thus, the commenter is correct that the SIFS term should not be included in the equation. This is not agreed. Will be discussed off-line.
4.2.8CID #4029:
4.2.8.1Disagree. The delivery of group-addressed frames cannot overlap with a service period since the frame exchange must complete prior to a DTIM beacon, which would trigger the delivery of group-addressed frames. See clause 11.1.2.1.
4.2.9CID #4065:
4.2.9.1Principle: Change cited text as indicated by the commenter to the proposed change text.
4.2.10CID #4096:
4.2.10.1Principle: Change “incapable” bit to “refused” bit at the cited location in 11.10.8.6 (40.28).
4.3MacAdhoc Comments:
4.3.1CID 4095
4.3.1.1Review comment and context
4.3.1.2Review Page 476 figure 9-14
4.3.1.3Review page 511 figure 9-20
4.3.1.4Review CID 1648 for context
4.3.1.5Some believe that we should remove, other say maybe not.
4.3.1.6Need to draw it out on paper to help come to consensus.
4.3.2CID 4029
4.3.2.1Review comment and context
4.3.2.2Proposed Resolution: Reject. The delivery of group-addressed frames cannot overlap with a service period since the frame exchange must complete prior to a DTIM beacon, which would trigger the delivery of group-addressed frames. See clause 11.1.2.1
4.3.2.3No objection, move ready to motion in group 3
4.3.3CID 4065
4.3.3.1Review comment and context
4.3.3.2Proposed Agree in Principle: Change cited text as indicated by the commentor to the proposed change text.
4.3.3.3No objections move ready to motion in group 3
4.3.4CID 4096
4.3.4.1Review comment and context
4.3.4.2Proposed resolution: Agree in Principle, change the “Incapable bit” to “refuse bit” at cited location in 11.10.8.6 (line 28).
4.3.4.3No objection, move ready to motion in group 3
4.4Recess at 3:pm
5.0TGmb Wed PM2 4-6pm Molly A
5.1Meeting called to order by Dorothy Stanley at 4pm with 16 attendees.
5.2Start with Doc 11-10-728r1 by Adrian for review
5.2.111.3.1.2.d, do not make this change. The SME and MLME are both involved in the 8.2.2 algorithms. Leave this as “STA” to cover both entities.