TGN adhoc MAC subgroup agenda for september 2006 doc.: IEEE 802.11-06/1396r7 September 2006 TGN adhoc MAC subgroup agenda for september 2006 Date: 2006-09-12 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Matthew Fischer (Broadcom) Matthew Fischer (Broadcom)

TGN MAC adhoc Agenda for 9-13 - 9-15 September 2006 doc.: IEEE 802.11-06/1396r7 September 2006 TGN MAC adhoc Agenda for 9-13 - 9-15 Wednesday 9/13 Address EMR comments Return to unaddressed items in MAC list (11-06-0690-28) Thursday 9/14 - 4.0 hours of session time Finish the last remaining EMR item + one new one from General Doc 1363 Adrian’s proposed uncontroversial resolutions Doc 1302r3 Doc 1306 Doc 1347, 1348 (security issues) Friday 9/15 – 4.0 hours of session time Doc 1052 (CID 873), 1054 (CID 7366) RDG Readdress any open EMR issues Doc 1340 (still open) Matthew Fischer (Broadcom) Matthew Fischer (Broadcom)

MAC adhoc comment status as of the start of the Melbourne meeting September 2006 MAC adhoc comment status as of the start of the Melbourne meeting 187 comments resolved, subject of motion 3 – Accept, not subject of motion 79 – Defer 3 – ER 1 – Reject, not subject of motion 93 – not yet addressed by the MAC adhoc Matthew Fischer (Broadcom)

TGN MAC adhoc Agenda for 9/18 – 9/21 September 2006 doc.: IEEE 802.11-06/1396r7 September 2006 TGN MAC adhoc Agenda for 9/18 – 9/21 Monday 9/18 – 0.0 hours of session time Doc 1340 (continued), 1341, 1342, 1343, 1344, 1345, 1346, 1025, (various CID) Return to unaddressed items in MAC list (11-06-0690-28) Tuesday 9/19 – 0.0 hours of session time xxxx Wednesday 9/20 – 0.0 hours of session time Xxx Thursday 9/21 – 0.0 hours of session time xxxxx Matthew Fischer (Broadcom) Matthew Fischer (Broadcom)

MAC adhoc Motion number 1 September 2006 MAC adhoc Motion number 1 Set of 88 “noncontroversial” comments Proposed resolutions originated from doc 11-06/1363r2 Various A, C, R Based on a set of various comments that were deemed relatively uncontroversial Some of the proposed resolutions were pulled from the list found in 1363r2, the remaining ones were unanimously accepted by the MAC adhoc and are presented in the following motion Move to accept comment resolutions in 11-06/0690r34 tab "motion_1_1363” Matthew Fischer (Broadcom)

11-06-1363 Subtraction list September 2006 1803, 1808, 4048, 8110, 1153, 1324, 4079, 7472, 9984, 7477 837, 2770, 3600, 10577, 3375, 9895, 3613, 1053, 1054 7499, 441, 840, 1020, 1021, 1022, 7042, 1023, 4016, 12007 2855, 10519, 7489 2924, 10712, 10713 4529: It says "See resolution to CID 1485" but the one referring to should be CID 65. 7702: The resolution wording seems to be not appropriate for the comment. 8110: I couldn't find the definition of bit 6 in the frame control field. 1153, 1025: I think we should discuss on this. 3375, 1054: There's no resolution. 9895: 11.6 is Higher layer timer synchronization. 9.6? 7499, 441, 840, 1020, 1021, 1022, 7042, 1023, 4016, 12007, 10713, 10712: These refer to CID 2924 but it has not been resolved. 11787: The resolution is pointing itself. The resolution should be "Proposed duplicate of 3152." Matthew Fischer (Broadcom)

MAC adhoc Motion number 2 September 2006 MAC adhoc Motion number 2 11 comments, originating from editor’s difficulties with previous comment resolutions Editor attempted to execute proposed resolutions for TGn-adopted resolutions to various comments (adopted at July meeting) Problems were identified in executing the instructions provided by the TGn Editor sent those comment resolutions back to the MAC adhoc group for reconsideration (labeled as EMR resolution status) MAC adhoc addressed each of these EMR items Move to accept comment resolutions in 11-06/0690r34 tab "motion_2_emr” Matthew Fischer (Broadcom)

MAC adhoc Motion number 3 September 2006 MAC adhoc Motion number 3 A significant set of comments was generated surrounding sublcuase “9.12 Frame exchange sequences” Formal description of frame exchange sequences MAC adhoc found a volunteer to address these comments Results presented to MAC adhoc as 11-06/1306r0 Proposed changes from 11-06/1306r0 unanimously accepted by the MAC adhoc, (70 comments, various A, C, R) Move to accept comment resolutions in 11-06/0690r34 tab "motion_3_912” Matthew Fischer (Broadcom)

MAC adhoc Motion number 4 September 2006 MAC adhoc Motion number 4 Generic Block Acknowledgement comments 5 comments asking for clarification of Block Acknowledgement description MAC adhoc created responses for these comments All proposed resolutions unanimously accepted by the MAC adhoc 4 of 5 comments accepted, 1 countered Move to accept comment resolutions in 11-06/0690r34 tab "motion_4_ba” Matthew Fischer (Broadcom)

MAC adhoc Motion number 5 September 2006 MAC adhoc Motion number 5 Originated from doc 11-06/1347r2 Representing 13 comments that were generated surrounding subclause 8 Security Note: this is a subset of security comments – additional comments are still pending This set of comments generally asked the question of whether there should be restrictions on some security algorithms within the context of the new HT MAC and HT PHY Specifically, should TKIP and WEP NOT be permitted as a security algorithm for HT-HT links MAC adhoc sub-committee was tasked to investigate the issue with security experts Security experts agreed hat WEP and TKIP should be FORBIDDEN as security algorithms for HT-HT links, matching existing base standard statements Changes within 11-06/1347r2 unanimously accepted by the MAC adhoc (7 A, 6 C) Move to accept comment resolutions in 11-06/0690r34 tab "motion_5_weptkip” Matthew Fischer (Broadcom)

Pre-RSNA security statements from the base standard September 2006 Pre-RSNA security statements from the base standard 8.2 Pre-RSNA security methods Except for Open System authentication, all pre-RSNA security mechanisms have been deprecated, as they fail to meet their security goals. New implementations should support pre-RSNA methods only to aid migration to RSNA methods. 8.3 RSNA data confidentiality protocols 8.3.1 Overview NOTE—Use of any of the data confidentiality algorithms depends on local policies. The data confidentiality and integrity mechanisms of TKIP are not as robust as those of CCMP. TKIP is designed to operate within the hardware limitations of a broad class of pre-RSNA devices. TKIP is suitable for firmware-only, hardware-compatible upgrade of fielded equipment. RSNA devices should only use TKIP when communicating with devices that are unable or not configured to communicate using CCMP. Matthew Fischer (Broadcom)