1. TGN adhoc MAC subgroup agenda for september 2006
doc.: IEEE /1396r7
September 2006
TGN adhoc MAC subgroup agenda for september 2006
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Matthew Fischer (Broadcom)
Matthew Fischer (Broadcom)

2. TGN MAC adhoc Agenda for 9-13 - 9-15
September 2006
doc.: IEEE /1396r7
September 2006
TGN MAC adhoc Agenda for
Wednesday 9/13
Address EMR comments
Return to unaddressed items in MAC list ( )
Thursday 9/ 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)

3. 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)

4. TGN MAC adhoc Agenda for 9/18 – 9/21
September 2006
doc.: IEEE /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 ( )
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)

5. 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)

6. 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, , 10519, , 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)

7. 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)

8. 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)

9. 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)

10. 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)

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