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

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

3. General Comment Statistics as of end of the Hillsboro Ad-Hoc
February 2007
doc.: IEEE /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

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

5. Summary of Issues with Frame Formats
February 2007
doc.: IEEE /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

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

7. 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 ( ). 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 and TGs
Need submission with more details to consider alternatives
Status: submission needed
Steven Conner

8. 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 ( ) frames, since existing Action Frames should be sufficient
Suggestion to remove Mesh Management/Mesh Action frames, since Action Encapsulation Frame ( ) 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 ( )
Status: submission needed
Steven Conner

9. 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 modeled after 7.2.2
Status: submission needed
Steven Conner

10. February 2007
Frame Format Issue Details G14: Peer Capacity Value in Mesh Capability IE
Summary:
Peer capacity field in the Mesh Capability IE ( ) 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

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

12. Summary of Issues with Terms and Definitions
February 2007
doc.: IEEE /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

13. Summary of Issues with MIB Variables
February 2007
doc.: IEEE /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

14. Summary of Issues with Clause 5
February 2007
doc.: IEEE /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

15. Summary of Issues with Annex A
February 2007
doc.: IEEE /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

16. Summary of Issues with Unified Channel Graph
February 2007
doc.: IEEE /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

17. Summary of Misc Issues February 2007 Issue Identifier Description
doc.: IEEE /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

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