1. Clause 7 Comment Resolutions
Month Year
doc.: IEEE yy/xxxxr0
March 2006
Clause 7 Comment Resolutions
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
Cam-Winget, Eastlake, Edney
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Comment 58, 59, 60, 61
Comment: “what should we set the bit to if data confidentiality is required but robust management frame protection isn't? From the text it isn't clear.”
Resolution: Accept in principle. The privacy bit is for advertising protection of data frames and potentially the use of RSN to protect such data. The protection of management frames capability is begotten by the RSNIE Robust management frame protection bit(s). The proposed text will be removed so that the existing text in the TGma draft remains unchanged.
Cam-Winget, Eastlake, Edney
John Doe, Some Company

3. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Comment 63, 64
Comment: “This changes the meaning of a reason code. This breaks between 100 million and 200 million deployed devices”
Resolution: Rejected. Existing devices can only protect data so the semantic clarification is there only for TGw-enabled devices. Also, since group ciphers for protecting data versus management frames are different, they should be afforded distinct reason codes.
Cam-Winget, Eastlake, Edney
John Doe, Some Company

4. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Comment 67
Comment: “Is there a problem with extending the RSN IE given that this is sent in associate request before capabilities are negotiated. Will this break legacy implementations?”
Proposed Resolution:
Should we straw poll to see if there are current implementations that will break?
Should we add text specifying behavior for length that exceed the current i implementation to ensure that further extensions like TGw can be safely defined?
Cam-Winget, Eastlake, Edney
John Doe, Some Company

5. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Comment 71
Comment: “Use of AES-128-CMAC is only valid as a management group cipher suite." While I agree that this is the right thing to do, is it justified? It seems like it implies new testing to assure interoperability?”
Commenter’s resolution: “I think the right justification is that permitting it to be used with data would introduce configuration issues that would tax even cryptographers w is meant to be useful by everyone. Vendors can define their own version of AES-128-CMAC that extends the w mechanism to data if this is an important function.”
Should restriction on management frame only be removed or should an informative note be added to justify use of AES-128-CMAC for management frame only?
Cam-Winget, Eastlake, Edney
John Doe, Some Company

6. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Comment 72
Comment: “There is not encryption provided for broadcast Robust management frames. I think this is the right decision, but why is it justificated?”
Commenter’s query: “I think the justification is that broadcast management frames deal with the operation of the WLAN only and do not convey information related to user privacy. Does the w draft therefore need to prohibit the inclusion of data related to user privacy in the spec?”
Cam-Winget, Eastlake, Edney
John Doe, Some Company

7. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Comment 74
Comment: “Not allowing management frame protection for TSN sounds like an arbitrary requirement and extra complexity. Is it really needed? WEP can only be used for broadcast/multicast data frames, so it would not be used for management frames.”
Resolution: Rejected. Protection of management frames in a TSN may imply using WEP for unicast management frames which would be extending bad security practices to the management realm.
Cam-Winget, Eastlake, Edney
John Doe, Some Company

8. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Comment 76, 77, 78, 79,81
One bit to advertise Robust Management Frame Protection should be sufficient.
Document 06/492 provides more details.
Approval for proposal in submission 06/492 proposal will resolve these comments
Cam-Winget, Eastlake, Edney
John Doe, Some Company

9. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Comment 95
Comment: “HC includes DA and SA fields which are already protected by TKIP as part of key generation. Do we really need to copy them into HC?”
Proposed resolution: “Remove HC DA and HC SA from HC.”
Cam-Winget, Eastlake, Edney
John Doe, Some Company

10. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Motion A
Move to accept resolutions for comments 58, 59, 60, 61, 63, 64, 74, 76, 77 ,78, 79, 81, 95
Cam-Winget, Eastlake, Edney
John Doe, Some Company

11. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Motion B
Move to accept resolutions for comments 58, 59, 60, 61, 63, 64, 74, 95
Cam-Winget, Eastlake, Edney
John Doe, Some Company