Summary of Unresolved General Comments for 2/14 TGs Telecon February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 Summary of Unresolved General Comments for 2/14 TGs Telecon Date: 2007-02-14 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>. Steven Conner Steven Conner

February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 Abstract Summary of unresolved General comments (based on 07/0023r19) for discussion on 2/14 TGs telecon Steven Conner Steven Conner

General Comment Statistics as of end of the Hillsboro Ad-Hoc February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 General Comment Statistics as of end of the Hillsboro Ad-Hoc Total Open Comments: 739 (including duplicates) Proposed Resolutions: Accept/Counter: 397 (54%) Reject 58 ( 8%) Defer: 284 (38%) Note: All deferred comments have been categorized with issue identifiers Steven Conner Steven Conner

Summary of Deferred General comments February 2007 Summary of Deferred General comments Category Topic IDs Frame Formats G9, G11, G13, G14, G16, G21, G22, G23, G28 Terms and Definitions G10 MIB Variables G8 Clause 5 G20 Annex A G7 UCG G15, G18, G25 Misc G17, G24, G27, G29, G30 Steven Conner

Summary of Issues with Frame Formats February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 Summary of Issues with Frame Formats Issue Identifier Description CID Count G9 Details of MAC Frame Format, Body Size 24 G11 New extended frame type vs. reusing existing frame types vs. SNAP header 23 G13, G22 Mesh Management Frame, Mesh Action Data Unit, Action Encapsulation Frame 22 G16 Incomplete frame definitions 10 G14 Peer capacity value needs to be clarified in Mesh Capability IE 7 G21, G23, G28 Need to reduce beacon bloat 6 Steven Conner Steven Conner

Frame Format Issue Details G9: MAC Frame Format, Body Size issues February 2007 Frame Format Issue Details G9: MAC Frame Format, Body Size issues Summary: Many comments point out apparent conflict between text in 7.1.2 and Figure 19, also question whether body length should be changed due to addition of Mesh Header Discussion in General subgroup at Hillsboro Ad-Hoc: Clause 7.1.2 states: “When present, the Mesh Header Field is prepended to the Frame Body and handled identically to the contents of the body with respect to MPDU processing.” The figure should be updated to avoid showing the mesh header as a separate field from the body. Suggest illustrating an expansion of the body and show two example configurations: the normal body and the body divided into mesh header and payload. Body length should be left unchanged in Figure 19 relative to baseline. Status: submission needed Steven Conner

February 2007 Frame Format Issue Details G11: New extended frame type vs. reusing existing frame type vs. SNAP header Summary: Many comments question the use of reserved frame type bits to enable mesh frames (7.1.3.1.2). Several comments claim that this approach precludes the use of MAC functions such as EDCA, HCF, HT, etc. since these functions are mapped to existing frame types. Alternative recommendation #1: Use existing frame types with some other signaling mechanism to indicate presence of Mesh Header Alternative recommendation #2: Encode Mesh Header as a SNAP header or LLC header Discussion in General subgroup at Hillsboro Ad-Hoc: Encoding Mesh Header as SNAP/LLC header appears to be beyond scope of IEEE 802.11 and TGs Need submission with more details to consider alternatives Status: submission needed Steven Conner

February 2007 Frame Format Issue Details G13, G22: Mesh Management Frame, Mesh Action Data Unit, Action Encapsulation Frame Summary: Suggestion to remove Mesh Management/Mesh Action (7.3.1.18) frames, since existing Action Frames should be sufficient Suggestion to remove Mesh Management/Mesh Action frames, since Action Encapsulation Frame (7.4.6.13) should be sufficient Suggestion to disallow forwarding of action frames across multiple hops (removing need for either Mesh Management/Mesh Action frames or Action Encapsulation Frame) Suggestion to use the RRB mechanism from .11r to support multi-hop action frames Confusion over the term Mesh Action Data Unit (7.2.4.3) Status: submission needed Steven Conner

Frame Format Issue Details G16: Incomplete Frame Definitions February 2007 Frame Format Issue Details G16: Incomplete Frame Definitions Summary: UCG Switch Announcement frame referenced (11A.1.7.5) but not defined Mesh Data Frame fields not described. Need to add text to Clause 7.2.4.2 modeled after 7.2.2 Status: submission needed Steven Conner

February 2007 Frame Format Issue Details G14: Peer Capacity Value in Mesh Capability IE Summary: Peer capacity field in the Mesh Capability IE (7.3.2.36) is referenced by clause 11A.1.4 Neighbor Discovery, but not clearly defined Discussion in General subgroup at Hillsboro Ad-Hoc: Need discussion on whether peer capacity is related only to memory constraints or other factors, and update text to describe how this value is set Status: submission needed Steven Conner

Frame Format Issue Details G21, G23, G28: Need to reduce beacon bloat February 2007 Frame Format Issue Details G21, G23, G28: Need to reduce beacon bloat Summary: Complaints that draft defines too many IEs Suggestion to remove SSID from beacons sent by non-AP MPs Suggestion to combine fields in Mesh Capability IE to reduce the length of the IE Status: submission needed Steven Conner

Summary of Issues with Terms and Definitions February 2007 doc.: IEEE 802.11-07/0250r1 Summary of Issues with Terms and Definitions February 2007 Issue Identifier Description CID Count G10 Need to clean up terms and definitions General Observation on Terms and Definitions: Clause 3 not consistent with rest of draft ESS Mesh vs WLAN Mesh vs Mesh BSS vs WDS Association vs Establishing a Peer Link Retransmission vs Rebroadcasting vs Forwarding Broadcast vs Flooding MP, MAP, MPP, LWMP, NFMP defined as separate entities vs MP defined as the only mesh entity and using variables to describe supported functionality Neighboring MP vs Peer MP vs Candidate Peer MP Superordinate/Subordinate terms 91 Steven Conner Steven Conner

Summary of Issues with MIB Variables February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 Summary of Issues with MIB Variables Issue Identifier Description CID Count G10 Many missing MIB variables in Annex D Define new variables to facilitate description of MPs that support different functions 38 Steven Conner Steven Conner

Summary of Issues with Clause 5 February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 Summary of Issues with Clause 5 Issue Identifier Description CID Count G20 Need to clean up the introductory/overview text in Clause 5 Suggestion to describe mesh in more abstract manner Suggestion to avoid use of the term “client” Suggestion to describe logical entities rather than devices 19 Steven Conner Steven Conner

Summary of Issues with Annex A February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 Summary of Issues with Annex A Issue Identifier Description CID Count G7 Annex A is Missing from the Draft 17 Steven Conner Steven Conner

Summary of Issues with Unified Channel Graph February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 Summary of Issues with Unified Channel Graph Issue Identifier Description CID Count G15 Need to introduce regulatory class in addition to channel number in UCG Channel Switch, harmonize with 11REVma and 11k, and clarify whether scanning should be limited to single channel or multiple channels 12 G25 Suggestion to remove UCG from the draft 3 G18 Clarify behavior of UCG channel switch protocol for multiple PHYs and cases where an MP cannot switch to the indicated channel 2 Steven Conner Steven Conner

Summary of Misc Issues February 2007 Issue Identifier Description doc.: IEEE 802.11-07/0250r1 February 2007 Summary of Misc Issues Issue Identifier Description CID Count G27 Update figure s110 and associated text for consistency with current draft 6 G24 Clarify constraints on active mesh profiles 2 G17 Insufficient normative text 1 G29 Assign variable names to timers G30 Add state machine showing interaction between peer link protocols, routing, frame transport, etc. Steven Conner Steven Conner

February 2007 doc.: IEEE 802.11-07/0250r1 February 2007 References doc.: IEEE 802.11-07/0023r19 – Resolution of comments received during IEEE 802.11 Letter Ballot 93 Steven Conner Steven Conner