CID~Commenter~~~~~~DraftVersion~Subclause~Page~Line~CommentType~Comment~SuggestedRemedy~Response~Comment Status~Response Status~CreateDate~~~~~~V 780054~"Park"~" in LB 78"~~~~11k-D3.0~General Hidden~~~TR~The hidden terminal definition and detection mechanism in D2.2 were eliminated. However, manipulating hidden terminals in 802.11 WLAN is important since the hidden terminals can severely degrade the system performance. Accordingly, I would like to see them back to the draft. However, we need a new definition and mechanism since the old ones in D2.2 are not technically correct ones. ~Add a new definition of hidden terminals and detection mechanism.~CURRENT COMMENT RESPONSE: The Hidden Station Request/Report was originally intended to identify hidden nodes by promiscuously monitoring all frames and ACKs and attempting to match frames to missing ACKs or ACKs to missing frames in order to identify a hidden node. The spec wording was cumbersome and obtuse and the TG could not agree on a clear normative spec wording. The Hidden Station Request/Report was removed in Jul05 on a vote (refer to the July 11k minutes 05/0694r6 page 8 motion b). The author is invited to provide clear normative text to put it back in during sponsor ballot. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The hidden node was removed in Jul05 on a vote (refer to the July 11k minutes 05/0694r6 page 8 motion b). The author is invited to provide normative text to put it back in.~R~O~~11/12/2005 00:00:00~~~~~~V 780300~"Amann"~" in LB 78"~~~~11k-D3.0~7.2.3.10~8~5~TR~The definition of the Measurement Pilot frame appears to be very similar to that of a Probe response or Beacon. Why are we defining yet another frame type?~Remove the definition of Measurement Pilot Frame, and add the desired fields to the Probe Response or Beacon frames.~CURRENT COMMENT RESPONSE: Please see additional explanatory information in 11.13 describing the purpose of the Measurement Pilot.---ORIGINAL COMMENT RESPONSE: The purpose of the measurement pilot is to provide a minimal set of information to a client STA in a timely manner for the purpose of BSS discovery, passive neighbor measurement and link margin calculation. Text will be added to section 11.14 describing this.~R~O~~11/12/2005 00:00:00~~~~~~V 780301~"Amann"~" in LB 78"~~~~11k-D3.0~7.2.3.10~9~0~TR~There is a definition of all of the fields in the measurement pilot frame listed at the top of the page, but many of the fields lack any description, or definition.~Remove this clause. The fact that it is not fully documented indicates that it isn't "fully" baked, and lacks sufficient definition to be included in the specification.~The new fields in Measurement Pilot that are not already defined in the base 802.11 spec are all described in clauses 7.3.1.19 - 7.3.1.23~R~O~~11/12/2005 00:00:00~~~~~~V 780302~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.1.18~10~5~TR~This appears to be yet one more method for defining the regulatory country (in addition to the Country Information element defined in 802.11d), and could introduce ambiguity if this information is not consistent with the Country Information element defined by 802.11d.~Remove this clause, and all references to this element, and replace references to this clause with corresponding references to the Country Information Element in order to remove potential ambiguity.~CURRENT COMMENT RESPONSE: As stated there is no ambiguity or duplication in use of the country string.---ORIGINAL COMMENT RESPONSE: This element is not an attempt to define the country IE yet again but rather an IE to capture only the country string part of the Country IE. The country IE is a large IE containing much more than the country string. The country IE is appropriately sized for a Beacon or Probe Response frame but not for the Pilot frame. The Pilot frame must remain small in size. In the Pilot frame it is desired to simply identify the country by its string.~R~O~~11/12/2005 00:00:00~~~~~~V 780303~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.1.20~10~14~TR~This appears to be yet one more method for defining regulatory requirements that are already defined by the Country Information element defined in 802.11d and could result in potential ambiguity.~Remove this clause, and all references to this element, and replace references to this clause with corresponding references to the Country Information Element in order to remove potential ambiguity.~CURRENT COMMENT RESPONSE: As stated there is no ambiguity in the max regulatory power field which is only a shortened version of the regulatory limit in the country information element for the identified regulatory domain.---ORIGINAL COMMENT RESPONSE: This element is not an attempt to define the country IE yet again but rather an IE to capture the max regulatory power for the current channel only. The country IE is a large IE containing much more than the max power for a single channel. The country IE is appropriately sized for a Beacon or Probe Response frame but not for the Pilot frame. The Pilot frame must remain small in size. In the Pilot frame it is desired to simply identify max regulatory power for the current channel.~R~O~~11/12/2005 00:00:00~~~~~~V 780311~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.21~14~24~ER~Table 20a lists 3 "modes", 001/010/011, in which the mode bits themselves were deleted, but the "meaning" is described as "Reserved". If you've deleted them how can they be "reserved"?~"Un-delete" (is that even a word??) the values that are assigned in these cases to make it clear that they are truly reserved values.~Removed all content of rows - not required since row 1 has Request and Report as reserved.~R~O~~11/12/2005 00:00:00~~~~~~V 780313~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.21~14~24~TR~The description for mode 110 indicates that the transmitting STA "may" accept measurement requests. If it isn't going to accept them it seems like it should be using a mode of "101".~Change the word "may" in the description of this mode to "will" or "shall".~A STA can always refuse a specific measurement request - see 11.11.4~R~O~~11/12/2005 00:00:00~~~~~~V 780314~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.21~15~1~TR~The description for mode 111 indicates that the transmitting STA "may" accept measurement requests. If it isn't going to accept them it seems like it should be using a mode of "101".~Change the word "may" in the description of this mode to "will" or "shall".~A STA can always refuse a specific measurement request - see 11.11.4~R~O~~11/12/2005 00:00:00~~~~~~V 780322~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.21.6~18~1~TR~The text states "The BSSID field indicates the BSSID of the particular BSS, or BSSs…". The BSSID field is only 6 octets in length, so how can there be multiple BSSs.~Remove the text ", or BSSs".~In this description the broadcast BSSID is used to indicate a request for measurement for any/all available BSSs. Wording to be clarified as indicated in comment #467.~R~O~~11/12/2005 00:00:00~~~~~~V 780323~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.21.6~18~4~TR~The text states "The SSID element indicates the ESSs, or IBSSs for which…". The plural context here seems inappropriate since you can only define a single ESS or IBSS given the definition of the field.~Remove the plural context. Also, editorially there should be another comma following the text "or IBSSs".~P18L4: Change "The SSID element indicates the ESSs, or IBSSs for which beacon reports are requested. This may be a specific SSID, or may be the zero length SSID, termed the ‘wildcard SSID’.The wildcard SSID shall be used when requesting beacon reports for all SSIDs." to "The SSID element indicates the ESS(s), or IBSS(s) for which a beacon report is requested. When requesting beacon reports for all ESSs on the channel, the SSID field contains the 'wildcard SSID'; otherwise the SSID field contains a specific SSID for a single ESS or IBSS. The 'wildcard SSID' is defined as a zero length (null) SSID used to represent all possible SSIDs."~R~O~~11/12/2005 00:00:00~~~~~~V 780330~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.21.13~21~22-23~TR~The text states "A response to a QoS Metrics Request is a QoS Metrics Report". This is the only request frame that explicitly states what the response is.~Add text to all other clauses that states what the response will be.~This is a bonus here - in general this text is present for all measurements in 11.11.9.x~R~O~~11/12/2005 00:00:00~~~~~~V 780339~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.22.5~27~6-7~TR~What is the purpose of the "Actual Measurement Start Time"? This information appears in several of the reports, but it isn't clear what value it adds. If it is used in some way, how do you account for clock skew between the measuring and "requesting" stations?~Provide some technical justification for inclusion of this field, or remove it from all reports in which it occurs. If it is used, please provide some answer to the clock skew question.~The actual measurement start time in a measurement report indicates when the measurement which is being reported was conducted with respect to the BSS TSF timer. The requesting station (usually an AP) may use this information to time corellate the measurement results from different STAs. Since measurement requests may be broadcast, the AP has a means of measuring , for example, noise and interference levels at all STA locations in the BSS at the same time. But a STA may not be able to measure immediately, so the actiual start time indicates which STAs are reporting later (time skewed) results. The small skews due to TSF synchronization within a BSS are considered negligible. Accuracy for actual start time is being specified in the +/- TU range. ~R~O~~11/12/2005 00:00:00~~~~~~V 780357~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.29~40~12-23~TR~There was work done in this section to explicitly change the information reported in this information element when QoS is enabled. I don't see any reason to provide the distinction.~Modify the text to provide the same information regardless of the state of QoS.~See resolution in comment #1279. AP Service load is modifed to be a generic load metric for non-QAPs. QBSS load is modified to add access delay loading metrics for each Access Category.~R~O~~11/12/2005 00:00:00~~~~~~V 780359~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.29~41~2-4~TR~Given the size of the field, and the fact that the AP has the information anyway, why bother making the Station Count field optional? As an optional field it is actually more work to implement and test for compliance.~Remove the optionality of this field, thus making it mandatory.~Station Count is deleted from BSS Load. See resolution in comment #1279.~R~O~~11/12/2005 00:00:00~~~~~~V 780360~"Amann"~" in LB 78"~~~~11k-D3.0~7.3.2.29~41~12-13~TR~Given the size of the field, why bother making the Channel Utilization field optional? As an optional field it is actually more work to implement and test for compliance.~Remove the optionality of this field, thus making it mandatory.~Channel Utilization is deleted from BSS Load. See resolution in comment #1279.~R~O~~11/12/2005 00:00:00~~~~~~V 780371~"Amann"~" in LB 78"~~~~11k-D3.0~11.9.2~61~10-12~TR~This seems like duplicate information that already exists in the beacon and probe responses as a result of the country information element. ~Remove the Measurement Pilot and all associated text.~An AP is only required to include the Country element if dot11MultiDomainCapabilityEnabled is true. The Max Regulatory Power field that is governed by the dot11MeasurementPilotEnabled parameters is not tied to dot11MultiDomainCapabilityEnabled. So this information is not always redundant and an administrator may decide to include regulatory parameters in either or both locations.~R~O~~11/12/2005 00:00:00~~~~~~V 780372~"Amann"~" in LB 78"~~~~11k-D3.0~11.11.1~61~19-23~ER~These appear to be definitions.~Move to clause 3.~CURRENT COMMENT RESPONSE: Don't use those terms (dedicated and concurrent) anymore (been removed). In D6.0, the references now refer to new definitions of Operating Channel and Non-Operating Channel. ---ORIGINAL COMMENT RESPONSE: The defined terms were unused in the rest of the draft. However, in response to other comments this section has been redrafted.~R~O~~11/12/2005 00:00:00~~~~~~V 780374~"Amann"~" in LB 78"~~~~11k-D3.0~11.11.4~62~18-19~TR~The statement is made "Each separate measurement within the Radio Measurement Request frame shall be performed over a continuous time period". If it is performing these measurements over a continuous time period how does that relate to data on the serving channel? Does the serving channel stop sending data?~Clarify how this continuous measurement is supposed to relate to data on the serving channel. The problem here is not necessarily with regard to the STA sending uplink data, but rather the AP sending downlink data.~CURRENT COMMENT RESPONSE: On page 85, L36-41 of D6.0, the process was clarified . Please review the updated text in 11.10.1 and 11.10.4.---ORIGINAL COMMENT RESPONSE: Such text is already present in 11.11.1 and 11.11.5.~R~O~~11/12/2005 00:00:00~~~~~~V 780376~"Amann"~" in LB 78"~~~~11k-D3.0~11.11.6~62~37-38~TR~The statement is made "A STA may measure one or more channels itself or a STA may request peer STAs in the same BSS to measure one or more channels on its behalf". This seems like it could be used to create a "denial of service" type of effect.~Create some solution that would preclude a rogue STA from causing disruption throughout the network by forcing STAs to go off channel doing measurements.~CURRENT COMMENT RESPONSE: In section 11.10.4 of D6.0, DOS prevention is up to the STA to limit a DOS attack by refusing the request if under a DOS situation. A new task group has been formed (11w) to address the security issues for management frames.---ORIGINAL COMMENT RESPONSE: This text has been edited as a result of other comments. This likely resolves the issue.~R~O~~11/12/2005 00:00:00~~~~~~V 780496~"Marshall"~" in LB 78"~~~~11k-D3.0~General~~~ER~This draft was generated with MSWord, not with FrameMaker. Conversion is required before sending the document to IEEE staff. This conversion will require __thousands__ of copy/paste operations, or significant re-typing of the text. It needs to be reviewed after this conversion is done.~Convert the draft to FrameMaker.~The document will be converted to Framemaker just before the first Sponsor Ballot~R~O~~11/12/2005 00:00:00~~~~~~V 780512~"Marshall"~" in LB 78"~~~~11k-D3.0~7.2.3.1~5~15~TR~Changing the presence of the Country Information Element in the Beacon frames has nothing to do with Radio Resource Measurement. Is it within the PAR of this group?~If this change is desired, it should be made through 11m, not 11k.~This change does not change the behavior for when the Country Information element is included in the Beacon. The paragraph that was deleted was out of date with the notes section in Table 5. With this change the notes section is the only place that indicates inclusion of a particular element.~R~O~~11/12/2005 00:00:00~~~~~~V 780525~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~12~20~ER~Measurement Request element in existing section 7.3.2.21 is Figure 63~Make it Figure 63~Fixed but to Figure 76 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780526~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~13~2~ER~Measurement Request Mode field in existing section 7.3.2.21 is Figure 64~Make it Figure 64~Fixed but to Table 77 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780527~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~13~9~ER~Fix cross reference to Figure~Should be Figure 64, not 46h~Fixed but to Table 77 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780529~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~13~25~ER~Fix cross reference to Table~Should be Table 24, not 20a~Fixed but to Table 28 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780530~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~13~29~ER~Fix cross reference to Table~Should be Table 24, not 20a~Fixed but to Table 28 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780532~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~13~33~ER~Fix cross reference to Table~Should be Table 24, not 20a~Fixed but to Table 28 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780533~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~14~21~ER~Fix cross reference to Table~Should be Table 24, not 20a~Fixed but to Table 28 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780535~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~14~24~ER~This table in existing section 7.3.2.21 is numbered 24, not 20a~Fix the table numbering~Fixed but to Table 28 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780539~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21~15~5~ER~This table in 7.3.2.21 is numbered 25, not 20b~Fix the table numbering~Fixed but to Table 29 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780540~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21.4~16~3~ER~Fix cross reference to Figures, and Figure numbering. Last figure in 7.3.2.21.3 is Figure 67.~Fix the Figure numbering. K7 should be 67A. K8 should be 67B. K9 should be 67C. K10 should be 67D. K11 should be 67E. K12 should be 67F. K13 should be 67G. K14 should be 67H. K15 should be 67I. K16 should be 67J. K17 should be 67K~TGk editor has chosen an alternate and consistent numbering system for new TGk Figures and Tables. These are both preceded by Kn where n is an incrementing number within the draft. Note that Table K1 is distinct from Figure K1.~R~O~~11/12/2005 00:00:00~~~~~~V 780547~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.21.6~17~20~ER~Fix cross references to Tables, and Table numbering. Last Table in 7.3.2.21.3 is Table 25~Fix the Table numbering. K2 should be 25A. K3 should be 25B. K4 should be 25C. K5 should be 25D. K6 should be 25E.~0~R~O~~11/12/2005 00:00:00~~~~~~V 780552~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.22~24~11~ER~Fix cross reference to Figure~Should be Figure 68~Fixed but to Figure 81 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780553~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.22~24~13~ER~This figure in existing section 7.3.2.22 is numbered 68~Should be Figure 68, not 13~Fixed but to Figure 81 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780554~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.22~24~14~ER~This figure in existing section 7.3.2.22 is numbered 69~Should be Figure 69, not 14~Fixed but to Figure 82 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780555~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.22~24~20~ER~Fix cross reference to Figure~Should be Figure 69 ~Fixed but to Figure 82 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780556~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.22~25~6~ER~Fix cross reference to Table~Should be Table 26~Fixed but to Table 30 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780557~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.22~25~25~ER~This table in existing section 7.3.2.22 is numbered 26~Should be Table 26, not 20c~Fixed but to Table 30 in line with 802.11REVma-D5.1~R~O~~11/12/2005 00:00:00~~~~~~V 780560~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.22.4~26~12~ER~Fix numbering of Figures. Last figure in 7.3.2.22.3 was 73~Fix the Figure numbering. K18 should be 73A. K19 should be 73B. K20 should be 73C. K21 should be 73D. K22 should be 73E. K23 should be 73F. K24 should be 73G. K25 should be 73H. K26 should be 73I. K27 should be 73J. K28 should be 73K. K29 should be 73L.~0~R~O~~11/12/2005 00:00:00~~~~~~V 780565~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.22.5~27~16~ER~Fix numbering of Table. Last table in 7.3.2.22.3 was 27.~Fix the Table numbering. K7 should be Table 27A. K8 should be 27B. K9 should be 27C~0~R~O~~11/12/2005 00:00:00~~~~~~V 780573~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.26~36~9~ER~7.3.2.26 already exists. Either add these new clauses as 7.3.2.25A/25B/25C/…, or 7.3.2.27/28/29/…~Fix the editor's instructions~Existing editor instruction is adequate to permit editor to renumber the clauses as requred upon merging ammendment into rollup. Additional detail or changes are not needed.~R~O~~11/12/2005 00:00:00~~~~~~V 780576~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.27~37~10~TR~The definition of the Neighbor Report element makes it impossible to extend to add more fields in the future. Since there is no marker between entries for different neighbors, there is no way to add additional (or optional) fields to the Neighbor list entry. While a complex scheme is required to allow selective support of a subset of amendments, a simple scheme can solve the bulk of the problem.~Add "entry length" in Figure k32 between BSSID and BSSID Information. Adjust the rules at the receiver of the Neighbor Report to skip and ignore any additional octets after the last defined field up through that length. With 11k only, the length will be either 5 or 9 (depending on whether TSF offset is present). If a future amendment adds, for example, a 6-octet field at the end, the length will be either 11 or 15, and a STA that doesn't understand the new amendment will still work and skip the 6 octets of new stuff.~The concept of authenticator is defined in RFC 3748. An EAP or 802.1X authentication may have multiple ports, so that many BSSIDs can have the same authenticator. Many WLAN switches implementing WPA2 support a common PMK cache, with a single authenticator supporting multiple BSSIDs. ~R~O~~11/12/2005 00:00:00~~~~~~V 780577~"Marshall"~" in LB 78"~~~~11k-D3.0~7.3.2.27~38~5~TR~Its not possible that two different APs will have the same authenticator.~Either change it to "authentication server", or leave it to 11r to define~The concept of authenticator is defined in RFC 3748. An EAP or 802.1X authentication may have multiple ports, so that many BSSIDs can have the same authenticator. Many WLAN switches implementing WPA2 support a common PMK cache, with a single authenticator supporting multiple BSSIDs. ~R~O~~11/12/2005 00:00:00~~~~~~V 780589~"Marshall"~" in LB 78"~~~~11k-D3.0~11.9~59~42ff~ER~Editor's instructions here are to "Change". But none of the text is underlined, not strikethrough.~Note the changes that are being requested in the text.~The pilot frame was added in this section. Everywhere that a change was made it was underlined.~R~O~~11/12/2005 00:00:00~~~~~~V 780803~"Nitsche"~" in LB 78"~~~~11k-D3.0~Annex A.4.13~89~~TR~The measurement of a Noise Histogram adds significant complexity to the PHY. There is still no evidence that this complexity is justified for improving network performance.~This is a repeat comment from LB73. Make the Noise Histogram optional in the PICS, similar as in 11h.~A straw-poll taken at the Vancouver 2005 meeting indicated continued support for keeping the noise histogram measurement mandatory (Straw Poll: Should the noise histogram measurement become an optional measurement in 11k? Result: Yes 3, No 9, Abstain 2.)~R~O~~11/12/2005 00:00:00~~~~~~V 780820~"Fischer"~" in LB 78"~~~~11k-D3.0~7.1.3.1.2~5~9~TR~Why not add this to Beacon/Probe Response frames?~Eliminate the Management Pilot Frame. This information can be distributed via the Beacon and Probe Response frames.~See comment 120~R~O~~11/12/2005 00:00:00~~~~~~V 780821~"Fischer"~" in LB 78"~~~~11k-D3.0~7.3.2.21.6~17~2~TR~There are too many measurement modes. This adds unnecessary burden for implementation.~Either justify the different measurement modes with informative text or eliminate them.~See 121~R~O~~11/12/2005 00:00:00~~~~~~V 780822~"Fischer"~" in LB 78"~~~~11k-D3.0~7.3.2.22.5~26~26~TR~The Noise Histogram Measurement provides the same information as the RPI histogram report yet somehow different, because it adds an extra density bin from the 802.11h mechanism but uses the same received power indicator name. A bit of confusion results and there seems to be some redundancy.~Delete this measurement.~0~R~O~~11/12/2005 00:00:00~~~~~~V 780823~"Fischer"~" in LB 78"~~~~11k-D3.0~7.3.2.22.13~33~9~TR~Is it ok to fill in only part of the QOS report? ~Make it explicity acceptable to fill in some fields but provide NULL values for other fields within this report. Basically, define a NULL value for each field and make it ok to use the value NULL at any time for any field. Probably also need to describe the reception behavior - i.e. that a received value of NULL provides NO information.~The problem with allowing a partial report is that the requesting STA has no idea what information it will receive.~R~O~~11/12/2005 00:00:00~~~~~~V 780825~"Fischer"~" in LB 78"~~~~11k-D3.0~11.11.9.10~70~11~TR~I find the following line: A QAP shall refuse measurement requests for traffic to other QSTAs in the BSS -- does this prevent one AP from querying another? Why would we want to prevent this?~Allow one QAP to query another QAP in some manner regarding total QOS traffic load.~AP-AP measurement requests are not allowed within 11k.~R~O~~11/12/2005 00:00:00~~~~~~V 780828~"Fischer"~" in LB 78"~~~~11k-D3.0~11.11.6~62~37~TR~Can a station that is 802.11k compliant refuse all measurements?~The answer shall be yes, but it would be nice to see that somewhere in the document. I.e. a STA not implementing 802.11k would not respond to requests, but a STA which did implement 802.11k could also chooose to not respond to some/all requests.~The PICS clarifies what is mandatory and optional in terms of implementation. A STA can refuse any measurement request as text in 11.11.5 (now 11.11.4) states. It is not within the scope of 11k to write a conformance test specification stating precisely the conditions under which STAs should make, or refuse specific measurements.~R~O~~11/12/2005 00:00:00~~~~~~V 780829~"Fischer"~" in LB 78"~~~~11k-D3.0~15.4.8.5~78~11~TR~RCPI - Range is too great; lower floor (-110 dBm) is below the theoretical noise floor of 802.11 devices. Upper ceiling (0 dBm) is above the maximum input power level of 802.11 devices. 0.5 dB resolution is too fine to be useful. 95% confidence interval is not defined. Dynamic range of receiver is not defined. What is the required performance outside the dynamic range of the receiver? This measurement is not practical.~Reduce the measurement range to the original RPI histogram from 802.11h (7.3.2.22.3), -87 dBm and below to -57 dBm and above.~See resolution in comment #169~R~O~~11/12/2005 00:00:00~~~~~~V 780830~"Fischer"~" in LB 78"~~~~11k-D3.0~17.3.10.6~79~`6~TR~RCPI - Range is too great; lower floor (-110 dBm) is below the noise floor of 802.11 devices. Upper ceiling (0 dBm) is above the maximum input power level of 802.11 devices. 0.5 dB resolution is too fine to be useful. 95% confidence interval is not defined. Dynamic range of receiver is not defined. What is the required performance outside the dynamic range of the receiver? This measurement is not practical.~Reduce the measurement range to the original RPI histogram from 802.11h (7.3.2.22.3), -87 dBm and below to -57 dBm and above.~See resolution in comment #169~R~O~~11/12/2005 00:00:00~~~~~~V 780831~"Fischer"~" in LB 78"~~~~11k-D3.0~18.4.8.5~86~6~TR~RCPI - Range is too great; lower floor (-110 dBm) is below the noise floor of 802.11 devices. Upper ceiling (0 dBm) is above the maximum input power level of 802.11 devices. 0.5 dB resolution is too fine to be useful. 95% confidence interval is not defined. Dynamic range of receiver is not defined. What is the required performance outside the dynamic range of the receiver? This measurement is not practical.~Reduce the measurement range to the original RPI histogram from 802.11h (7.3.2.22.3), -87 dBm and below to -57 dBm and above.~See resolution in comment #169~R~O~~11/12/2005 00:00:00~~~~~~V 780832~"Fischer"~" in LB 78"~~~~11k-D3.0~7.3.2.21~14~20~TR~The meaning of duration mandatory is not completely clear. It seems from the description that the meaning of this bit should really be something like, minimum duration mandatory. I.e. what little bit of discussion exists seems to imply that the mandatory part of the duration is that the measurement is not allowed to be shorter than the specified duration, as opposed to when it is not mandatory, and then allowed to be shorter.~Add text either here or in a more appropriate section that indicates that the duration value is a minimum value, and that when "duration mandatory" is cleared to ZERO, then the minimum duration is simply a recommendation, but otherwise, it is a requirement.~Added a reference to 11.11.3 where there is additional normative text.~R~O~~11/12/2005 00:00:00~~~~~~V 780833~"Fischer"~" in LB 78"~~~~11k-D3.0~7.3.2.27~37~13~TR~BSSID information field has some reserved bits. The description of how to treat these reserved bits is not explicit. Yes, there may be a general statement of ignoring reserved bits on reception, but it probably does not hurt to have that repeated here.~Add some text which explicitly states that upon reception, values of either ONE or ZERO in the reserved bit locations shall be ignored.~The convention for reserved fields is in clause 7.1.1 {rev MA 5.2)~R~O~~11/12/2005 00:00:00~~~~~~V 780903~"Chaplin"~" in LB 78"~~~~11k-D3.0~3.102~2~14~TR~The term being defined is "received power indicator (RPI):", and yet the description of the term is for a power indication when the STA is neither transmitting nor receiving.~Either rename the term to "idle power indicator (IPI)", or change the definition to match the term.~11k has had many discussions about changing the name of RPI and the decision has been to let RPI stay as defined by 11h. The suggested name changes are RIPI, NCPI, IPI, and RINPI. The decision is still to remain with RPI moniker.~R~O~~11/12/2005 00:00:00~~~~~~V 780905~"Chaplin"~" in LB 78"~~~~11k-D3.0~5.2.5~3~6~ER~The sentence "With wireless LAN radio measurements, stations can make measurements locally as well as request measurements from STAs." should probably read "With wireless LAN radio measurements, stations can make measurements locally as well as request measurements from other STAs." Unless, of course, a STA can request itself to make measurements.~Fix the sentence, if indeed it is in error.~The response to 1221 has been accepted which addresses the comment.~R~O~~11/12/2005 00:00:00~~~~~~V 780917~"Chaplin"~" in LB 78"~~~~11k-D3.0~7.3.2.22.6~28~1~TR~The name of this report is "Beacon Report", yet it's also reporting on Probe Responses and Measurement Pilots. This report needs to be renamed to reflect it's more general reporting capabilities.~(No suggested remedy provided by commenter.)~The commenter is correct. Probe Responses and Measurement Pilots are also reported in this Beacon report. TGk has not been able to devise a better name. The commenter has not suggested an alternate name. TGk has nothing to consider here.~R~O~~11/12/2005 00:00:00~~~~~~V 780921~"Chaplin"~" in LB 78"~~~~11k-D3.0~7.3.2.22.13~35~13~ER~"If unused QoS CFPolls Lost count shall be set to 0."~"If the field is unused, the QoS CFPolls Lost count shall be set to 0."~Changed to 'This field shall be set to 0 when QoS CFPolls Lost Count is not returned' in response to another comment.~R~O~~11/12/2005 00:00:00~~~~~~V 780924~"Chaplin"~" in LB 78"~~~~11k-D3.0~7.3.2.26~36~15~TR~"The Length field is dependent on the number of channels reported in the Channel List." And what units is this length field in? Bits? Words? Octets? And what fields does the Length field measure? Just the Channel List? Channel List and Regulatory Class?~Please specify~The description for the length field here is consistent with format currently used in base line specification, though multiple formats are in use. The commenter is welcome to take the issue of consistency in field description to the ma task Group~R~O~~11/12/2005 00:00:00~~~~~~V 780925~"Chaplin"~" in LB 78"~~~~11k-D3.0~7.3.2.27~37~5~TR~"The value of Length field is dependent on the number of Neighbor List Entries representing the neighboring APs being reported." Again, what units is this length field in? Bits? Words? Octets?~Please specify~The Neighbor Report Elelment is a standard IE and therefore is expressed in bytes. The length field is defined as expressed in Neghobor list entries the leght of which is defined further. To define any length other than this will make the report less extensible.~R~O~~11/12/2005 00:00:00~~~~~~V 780926~"Chaplin"~" in LB 78"~~~~11k-D3.0~7.3.2.27~39~10~TR~Is the offset always positive? And is that offset the delay between a serving AP beacon and the immediately following neighbor AP beacon? I'm assuming so, but you know what is said about assumptions….~Document explicitly the measurement.~Since "This offset is given modulo the neighbor AP’s Beacon Interval and rounded to the nearest TU boundary. " and modulo is not a negative number the text is clear in this matter.~R~O~~11/12/2005 00:00:00~~~~~~V 780930~"Chaplin"~" in LB 78"~~~~11k-D3.0~7.3.2.29~40~22~TR~The accuracy of the measurement as averaged over 200 measurements is +/- 200us, and yet the precision of the smallest measurement is 50us? So, any values of 1-4 are useless, and values just above that are suspect.~(No suggested remedy provided by commenter.)~One of the purposes of the access delay metric is to be able to compare AP loading at any AC of interest between two or more roaming candidate APs. As a comparative metric, the resolution needs to be fine enough to evaluate differences between APs operating anywhere along the loading range from 50usec to 5.5msec. Scaling formula for Access Delay as described in 05/1260r0 shall be added to next version of draft.~R~O~~11/12/2005 00:00:00~~~~~~V 780935~"Chaplin"~" in LB 78"~~~~11k-D3.0~7.3.2.29~40~38~TR~The accuracy of the measurement as averaged over 200 measurements is +/- 200us, and yet the precision of the smallest measurement is 50us? So, any values of 1-4 are useless, and values just above that are suspect.~(No suggested remedy provided by commenter.)~0~R~O~~11/12/2005 00:00:00~~~~~~V 780936~"Chaplin"~" in LB 78"~~~~11k-D3.0~7.3.2.29~40~6~TR~There are several optional fields in this structure, and the presense or absence of a particular field is dependent on various internal option flags in the sending STA. However, how in the world is the receiving STA supposed to know how to interpret the structure, since it has no way of knowing the internal state of the sending STA?~Put in explicit flags/whatever so that a receiving STA can parse this structure without any other information.~Optional field have been eliminated. See comments #1279 and #414.~R~O~~11/12/2005 00:00:00~~~~~~V 780941~"Chaplin"~" in LB 78"~~~~11k-D3.0~10.3.25~56~~TR~Missing MLME-LINKMEASURE.indication and MLME-LINKMEASURE.response.~Add these primitives.~There is no MLME-SME interaction at the peer STA for link measure - thus the suggested primitives are not required. This follows the same management model as MLME-TPCADAPT.req/cfm in REVma5.1. Added a note in this section to clarify this.~R~O~~11/12/2005 00:00:00~~~~~~V 780944~"Chaplin"~" in LB 78"~~~~11k-D3.0~11.11.6~64~12~TR~This section talks about STAs that may be unable permanently to process a request. However, one of the example reasons, "The measuring STA cannot support requested parallel measurements due to the requests relating to different channels." is not a permanent failure. If the STA finishes processing the existing off channel requests, it will be then capable of processing the new requests.~(No suggested remedy provided by commenter.)~Parallel measurements means make these measurements at the same time. This may never be possible if the requests are on different channels.~R~O~~11/12/2005 00:00:00~~~~~~V 780954~"Engwer"~" in LB 78"~~~~11k-D3.0~10.3.25~57~1~TR~This clause includes descriptions of the .request and .confirm primitives, but is missing the descriptions of the corresponding .indication and .response primitives. Since the .request generates a request frame and the .confirm is triggered by a response frame then there should be corrseponding .indication and .response primitives at the peer station. Or are you thinking that the response frame can be entirely constructed within the peer entity's MAC and MLME, i.e. *without* involvement of the peer station SME? If so, it might be good to add a note to that effect somewhere in clause 10.3.25.~If the peer SME entity in involved in the LINKMEASURE process, then add the correspinding .indication and.response primitives. Otherwise add a note explaining the non-requirement for those primitives.~There is no MLME-SME interaction at the peer STA for link measure - thus the suggested primitives are not required. This follows the same management model as MLME-TPCADAPT.req/cfm in REVma5.1. Added a note in this section to clarify this.~R~O~~11/12/2005 00:00:00~~~~~~V 780957~"Engwer"~" in LB 78"~~~~11k-D3.0~11.13~72~11~TR~Using incessant RF pinging to gauge the quality of the air is self defeating and doesn't scale. Consider a room full of, say 1500 STAs (e.g. at IEEE 802 plenary meetings), and all 1500 STAs doing this RF pinging - even just wrt their current AP. Suggest removing this feature from 11k, or at least mitigating its use somehow so that the RF pinging itself doesn't adversely affect the peformance of the network. Suggestions: a) use already existing frames that *need* to be exchanged between the STAs and add the LINKMEASUREMENT info appropriately, b) use a scaleable architecture, e.g. appending this information to beacons ensures that all associated (and unassociated) STAs within listening range can obtain the LINKMEASURE info - with only a one-times-per-AP load added to the network, c) limit the duty cycle at which such requests can be sent to mobile STAs - for two reasons to preserve available air bandwidth for real data laden transmissions and to avoid excessive power consumption by the mobile STAs.~Remove the Link Measurement capability.~AP can turn them off. Only means for DLP. Established by TGh and properly nuamed by TGk. Info is STA specific, cannot be appended to beacons. ~R~O~~11/12/2005 00:00:00~~~~~~V 780958~"Engwer"~" in LB 78"~~~~11k-D3.0~11.11.5~62~34~TR~Station should also flush (or be allowed to flush) measurement requests when transitioning (association or reassociation) within the same BSSID bcus it may be using reassociation to change supported link operating characteristics, e.g. data rates and so on.~Allowing flushing of measurement requests when associating or reassociating with the same BSSID.~Not sure why this should cancel a measurement request. It is however possible to flush measurement requests by sending a new measurement request frame (see 11.11.5)~R~O~~11/12/2005 00:00:00~~~~~~V 780963~"Yee"~" in LB 78"~~~~11k-D3.0~7.3.2.21.13, 7.3.2.22, 11.11.9.10~21~21~TR~The whole concept of "QoS Metrics" as defined is out of scope of the Radio Measurement Service. In 5.4.6, it is clear that the Radio Measurement service is intended to measure the channel condition and utilization, not to collect performance or traffic statistics of neighboring STAs. F35If the intention is to define some capability assessment mechanism for the purpose of roaming, I believe there is a separate task group studying amendments for that specific purpose.~Remove all text pertaining to QoS Metrics Request, QoS Metrics Report, and all related MIBs. ~It is not clear why error or delay statistics do not give useful information about the channel condition being experienced by a measuring QSTA~R~O~~11/12/2005 00:00:00~~~~~~V 780964~"Yee"~" in LB 78"~~~~11k-D3.0~11.11.3~61~29~TR~The measurement start time of "as soon as practical" allows a recipient to hold on to requests indefinitely as it takes care of other tasks. Shouldn't some sort of reasonable upper bound be set on when the recipient must reply with a measurement report? ~Include a timeout values associated with all requests. It seems that currently timeout is only defined for neighbor reports.~As soon as practical means that the STA should perform the measurement as soon as practical. Measurements can be refused if the STA is not able to fulfil this.~R~O~~11/12/2005 00:00:00~~~~~~V 780967~"Yee"~" in LB 78"~~~~11k-D3.0~7.3.2.29~40~28~TR~How is "currently providing service" determined? ~Delete the notion of 'currently providing service' and assign AAD=0 if there are no frames for that AC during that measurement period.~Loading access delays for lower priority access categories are impacted and increased by loads in higher priority access categories. For this reason, if an access category has no traffic, the expected access delay for new traffic in this access category will be equal to the access delay of the next higher priority access category. See 05/0079r1 for further details. ~R~O~~11/12/2005 00:00:00~~~~~~V 780968~"Yee"~" in LB 78"~~~~11k-D3.0~11.11.8~65~12~TR~Why is Triggered Autonomous Reporting only defined for the QoS Metrics measurement type? For example, a user might want to impose these measurement overhead only when the channel condition is good. Also, why does this entire clause describe it in general terms rather than specific only to QoS Metrics?~Extend Triggered Autonomous Reporting to work with other measurement types.~The QoS metrics measurement is suitable for triggered measurement as it is non-invasive to normal operation. The mechanism was defined in its own section to differentiate the protocol from the normal requested measurement. Additional use of this protocol is being proposed for management diagnostic alerts in TGv.~R~O~~11/12/2005 00:00:00~~~~~~V 780970~"Barber"~" in LB 78"~~~~11k-D3.0~7.3.2.22.7 ~~~TR~in the frame report entry - you want to know both the average and a variance for the RSNI - in order to be able to better assess fading channels.~include variance measure as well as average for RSNI~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: While it is relarively simple to calculate average value in a pipelined processing fashion (recalculating average with each new input value), the same is not true for variance calculation. Adding a variance calculation for upto 255 samples for upto n different Transmit Addresses in the same frame measurement is relatively complex. However since 1/2 of the frames in a frame report are downlink frames transmitted by the AP, and since the AP to STA link is critical for services, perhaps a variance measure on all frames in which TA=BSSID would be useful and worth the additional complexity. TG should discuss and decide on cost/benefit of such a suggestion. Request the commenter to provide normative text in recirc.~R~O~~11/12/2005 00:00:00~~~~~~V 780971~"Barber"~" in LB 78"~~~~11k-D3.0~7.3.2.22.7~30~24~TR~last para - unicast management frames should be counted separately in order to be able to differentiate associated stations from auth/assoc attempts. ~have a separate counter for management frames vs data frames~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Submission 06/0060r0 attempted to address a similar comment(222) and the task group rejected the proposal(strawpoll yes 5 no 8). ~R~O~~11/12/2005 00:00:00~~~~~~V 780972~"Barber"~" in LB 78"~~~~11k-D3.0~7.3.2.22.7~30~24~TR~last para - does 'frames' here mean MSDUs or MPDUs?~clarify~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Refer to sections 7.2.2 and 7.2.3 for definitions of "Frames"~R~O~~11/12/2005 00:00:00~~~~~~V 780973~"Barber"~" in LB 78"~~~~11k-D3.0~7.3.2.22.7~30~25~TR~last para - limit of 255 here is not high enough - especially as data rates go up with new standards.~increase counts to 4 bytes~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Frame count is a counter that saturates at 255, if an unsaturated value is required in the measurement, the measurement should be repeated with a smaller measurement duration. This solution is preferred, over the added complexity of a larger frame counter size and much more complex statistics on the set of frames~R~O~~11/12/2005 00:00:00~~~~~~V 780974~"Barber"~" in LB 78"~~~~11k-D3.0~7.3.2.22.7~30~25~TR~last para - it's not possible here to remotely determine link quality or hidden node problems~add a separate counter for frames that have the retry bit set, and add a counter for frames where the subsequent ack is not received~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: This measurement is not intended to measure the link between AP and client, if you want to gather statistics between AP and client, please use the STA statistics request. ~R~O~~11/12/2005 00:00:00~~~~~~V 780976~"Barber"~" in LB 78"~~~~11k-D3.0~7.3.2.22.10~31~5~TR~clarify - should say that measurement duration can only be 0 if it was 0 in the request~(No suggested remedy provided by commenter.)~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Clarifying details and procedures for reporting measurement duration are clear and are provided in 11.11.4. ~R~O~~11/12/2005 00:00:00~~~~~~V 780977~"Barber"~" in LB 78"~~~~11k-D3.0~7.3.2.26~36~10~TR~why is this measurement necessary if we have the neighbor report request?~remove it~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Section 7.3.2.26 AP Channel Report element is not a measurement, it is an element description of an optional element which may be present in Beacons and Probe Responses. This element provdes a small subset of information (just the channel numbers) available in the Neighbor Report. AP Channel Report info is thus available to all STA before association and even before initial network authentication. Neighbor Report info is only available to associated STAs.~R~O~~11/12/2005 00:00:00~~~~~~V 780979~"Barber"~" in LB 78"~~~~11k-D3.0~11.11.9.1~67~25~TR~you don't know if a beacon is not reported because it's not heard or because this hardware unit is not capable of listening on a particular channel~add a new measurement to communicate what are the supported channels~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: It is unclear what suggested remedy the commenter is proposing. Additional detail is needed. The commenter is invited to provide a clear suggested remedy during LB recirculation.~R~O~~11/12/2005 00:00:00~~~~~~V 780982~"Barber"~" in LB 78"~~~~11k-D3.0~General~~~TR~there is no general link test provided~this provides an absolute test of link quality, rather than an observed metric - it's an important test. Need to add a new measurement to send a set of test data frames across a link~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The commenter is invited to provide a suggested remedy in the recirc.~R~O~~11/12/2005 00:00:00~~~~~~V 780983~"Barber"~" in LB 78"~~~~11k-D3.0~7.4.5~42~11~TR~measurement requests are not secure, and will require driver changes to implement~make requests and responses into data frames rather than action frames, thus making it automatically secure, and making it easy to implement at least a good measurement subset without requiring any driver changes at all - thus speeding the propagation of 11k implementations~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The task group felt that extending the work for TGh was the appropriate to add new measurements. TGw will provide the required security mechansim.~R~O~~11/12/2005 00:00:00~~~~~~V 780985~"Kim, Youngsoo"~" in LB 78"~~~~11k-D3.0~General Hidden~~~TR~The hidden terminal definition and detection mechanism in D2.2 were eliminated. However, manipulating hidden terminals in 802.11 WLAN is important since the hidden terminals can severely degrade the system performance. Accordingly, I would like to see them back to the draft. However, we need a new definition of a hidden station and mechanism for its detection since the old ones in D2.2 do not constitute a necessary condition for the hidden station.~Add a definition of hidden terminals as "A hidden station to a particular station is a station that is not capable of making CCA busy at the particular station, but, at the same time, the hidden station is capable of making CCA busy at a third party station which is capable of making CCA busy at the particular station.". Details about the hidden terminal detection will be proposed in a separate document. ~CURRENT COMMENT RESPONSE: The Hidden Terminal measurement was removed because there was no definition of hidden terminal we could agree on. As of Dec 06, no normative text was received from the commenter---ORIGINAL COMMENT RESPONSE: The hidden node was removed in Jul05 on a vote (refer to the July 11k minutes 05/0694r6 page 8 motion b). The author is invited to provide normative text to put it back in.~R~O~~11/12/2005 00:00:00~~~~~~V 780986~"Choi"~" in LB 78"~~~~11k-D3.0~General Hidden~~~TR~The hidden terminal definition and detection mechanism in D2.2 were eliminated. However, manipulating hidden terminals in 802.11 WLAN is important since the hidden terminals can severely degrade the system performance. Accordingly, I would like to see them back to the draft. However, we need a new definition of a hidden station and mechanism for its detection since the old ones in D2.2 do not constitute a necessary condition for the hidden station.~Add a definition of hidden terminals as "A hidden station to a particular station is a station that is not capable of making CCA busy at the particular station, but, at the same time, the hidden station is capable of making CCA busy at a third party station which is capable of making CCA busy at the particular station.". Details about the hidden terminal detection will be proposed in a separate document. ~CURRENT COMMENT RESPONSE: The Hidden Terminal measurement was removed because there was no definition of hidden terminal we could agree on. As of Dec 06, no normative text was received from the commenter. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The hidden node was removed in Jul05 on a vote (refer to the July 11k minutes 05/0694r6 page 8 motion b). The author is invited to provide normative text to put it back in.~R~O~~11/12/2005 00:00:00~~~~~~V 780987~"Srinivasan"~" in LB 78"~~~~11k-D3.0~11.11.4~62~15~TR~Why is it that if the target measurement duration is set to 0 only actual measurement duration less than the requested duration can be made? Why not more? After all, it is 'target' and not 'maximum' measurement duration. ~Remove "less than the requested duration".~CURRENT COMMENT RESPONSE: We expect to make a change in LB 90. See resolution to comment LB90 CID 51 which replaces target with maximum to clarify intent. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Duration Mandatory set to 0 allows a STA to measure for a reduced duration. It is not obvious why you would want to measure for a longer duration.~R~O~~11/12/2005 00:00:00~~~~~~V 781142~"Hsu"~" in LB 78"~~~~11k-D3.0~3.102~2~14~TR~Why is RPI being redefined here when it is already defined in 3.59 of the 802.11h amendment? The two definitions are incongruent.~Reconcile the two definitions.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: 11k has had many discussions about changing the name of RPI and the decision has been to let RPI stay as defined by 11h. The suggested name changes are RIPI, NCPI, IPI, and RINPI. The decision is still to remain with RPI moniker.~R~O~~11/12/2005 00:00:00~~~~~~V 781144~"Hsu"~" in LB 78"~~~~11k-D3.0~11.11.9.1~66~22~TR~"At the end of the measurement duration, process" is specifying a specific implementation and not allowing the processing of beacons and other frames as they arrive.~Substitute with "Process".~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The commenter suggests alternate wording for 'process". However the intent of this clause is to describe one way to achieve the required Beacon report results. There are other equally suitable procedures not detailed here. The sction is modified to indicate that alternate equivalent procedures are allowed. P66L20&28: replace "following procedure" with "following procedure (or equivalent procedure)"~R~O~~11/12/2005 00:00:00~~~~~~V 781145~"Hsu"~" in LB 78"~~~~11k-D3.0~3.97~2~1~TR~The term "Received Channel Power Indicator" does not intuitively differentiate with "Received Power Indicator"~Change the name to "Received Signal Power Indicator (RSPI)".~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Alternate name change accepted. Change RPI to Idle Power (IPI) Indicator in all places.~R~O~~11/12/2005 00:00:00~~~~~~V 781146~"Hsu"~" in LB 78"~~~~11k-D3.0~3.102~2~1~TR~The term "Received Power Indicator" is not intuitively associated with noise and interference~Change the name to "Received Interference and Noise Power Indicator (RINPI)".~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: 11k has had many discussions about changing the name of RPI and the decision has been to let RPI stay as defined by 11h. The suggested name changes are RIPI, NCPI, IPI, and RINPI. The decision is still to remain with RPI moniker.~R~O~~11/12/2005 00:00:00~~~~~~V 781147~"Hsu"~" in LB 78"~~~~11k-D3.0~3.99~2~1~TR~The term "Average Noise Power Indicator" is not intuitively associated with interference~Change the name to "Average Interference and Noise Power Indicator (AINPI)".~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The definition of ANPI is clearly defined here to include noise and interference.~R~O~~11/12/2005 00:00:00~~~~~~V 781316~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.1.20~10~14~TR~This appears to be yet one more method for defining regulatory requirements that are already defined by the Country Information element defined in 802.11d and could result in potential ambiguity.~Remove this clause, and all references to this element, and replace references to this clause with corresponding references to the Country Information Element in order to remove potential ambiguity.~CURRENT COMMENT RESPONSE: Current resolution still stands. The country string is derived from the larger country information element and no conflicts or ambiguities are intended in the specification. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: This element is not an attempt to define the country IE yet again but rather an IE to capture the max regulatory power for the current channel only. The country IE is a large IE containing much more than the max power for a single channel. The country IE is appropriately sized for a Beacon or Probe Response frame but not for the Pilot frame. The Pilot frame must remain small in size. In the Pilot frame it is desired to simply identify max regulatory power for the current channel.~R~O~~11/12/2005 00:00:00~~~~~~V 781324~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.21~14~24~ER~Table 20a lists 3 "modes", 001/010/011, in which the mode bits themselves were deleted, but the "meaning" is described as "Reserved". If you've deleted them how can they be "reserved"?~"Un-delete" (is that even a word??) the values that are assigned in these cases to make it clear that they are truly reserved values.~CURRENT COMMENT RESPONSE: Resolution the same. However, as commenter points out, clarification is needed. P19L12 in Table 28 of D6 in the 4th column, change "bits are reserved" to "bits are reserved and set to zero". Correction to be made in D7.0. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Removed all content of rows - not required since row 1 has Request and Report as reserved.~R~O~~11/12/2005 00:00:00~~~~~~V 781326~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.21~14~24~TR~The description for mode 110 indicates that the transmitting STA "may" accept measurement requests. If it isn't going to accept them it seems like it should be using a mode of "101".~Change the word "may" in the description of this mode to "will" or "shall".~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: A STA can always refuse a specific measurement request - see 11.11.4~R~O~~11/12/2005 00:00:00~~~~~~V 781327~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.21~15~1~TR~The description for mode 111 indicates that the transmitting STA "may" accept measurement requests. If it isn't going to accept them it seems like it should be using a mode of "101".~Change the word "may" in the description of this mode to "will" or "shall".~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: A STA can always refuse a specific measurement request - see 11.11.4~R~O~~11/12/2005 00:00:00~~~~~~V 781335~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.21.6~18~1~TR~The text states "The BSSID field indicates the BSSID of the particular BSS, or BSSs…". The BSSID field is only 6 octets in length, so how can there be multiple BSSs.~Remove the text ", or BSSs".~CURRENT COMMENT RESPONSE: Please see revised wording in D6.0 P22L48 for clarification. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: ~R~O~~11/12/2005 00:00:00~~~~~~V 781336~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.21.6~18~4~TR~The text states "The SSID element indicates the ESSs, or IBSSs for which…". The plural context here seems inappropriate since you can only define a single ESS or IBSS given the definition of the field.~Remove the plural context. Also, editorially there should be another comma following the text "or IBSSs".~CURRENT COMMENT RESPONSE: Please see revised wording in D6.0 P23L44 for clarification. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: ~R~O~~11/12/2005 00:00:00~~~~~~V 781343~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.21.13~21~22-23~TR~The text states "A response to a QoS Metrics Request is a QoS Metrics Report". This is the only request frame that explicitly states what the response is.~Add text to all other clauses that states what the response will be.~CURRENT COMMENT RESPONSE: Delete sentence at P26L42 in D6.0. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: This is a bonus here - in general this text is present for all measurements in 11.11.9.x~A~O~~11/12/2005 00:00:00~~~~~~V 781352~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.22.5~27~6-7~TR~What is the purpose of the "Actual Measurement Start Time"? This information appears in several of the reports, but it isn't clear what value it adds. If it is used in some way, how do you account for clock skew between the measuring and "requesting" stations?~Provide some technical justification for inclusion of this field, or remove it from all reports in which it occurs. If it is used, please provide some answer to the clock skew question.~CURRENT COMMENT RESPONSE: Justification asked for has been provided in LB78 # 339 comment resolution. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: ~A~O~~11/12/2005 00:00:00~~~~~~V 781370~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.29~40~12-23~TR~There was work done in this section to explicitly change the information reported in this information element when QoS is enabled. I don't see any reason to provide the distinction.~Modify the text to provide the same information regardless of the state of QoS.~CURRENT COMMENT RESPONSE: Please review current draft D6.0. Clause 7.3.2.29 (QBSS Load) is not modified. QBSS Load may be supplemented with BSS Average Access Delay (7.3.2.39) and BSS AC Access Delay (7.3.2.44). NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: ~R~O~~11/12/2005 00:00:00~~~~~~V 781372~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.29~41~2-4~TR~Given the size of the field, and the fact that the AP has the information anyway, why bother making the Station Count field optional? As an optional field it is actually more work to implement and test for compliance.~Remove the optionality of this field, thus making it mandatory.~CURRENT COMMENT RESPONSE: Clause 7.3.2.29 is not modified in D6.0 and Station Count Field is mandatory. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: ~A~O~~11/12/2005 00:00:00~~~~~~V 781373~"Chris Durand"~" in LB 78"~~~~11k-D3.0~7.3.2.29~41~12-13~TR~Given the size of the field, why bother making the Channel Utilization field optional? As an optional field it is actually more work to implement and test for compliance.~Remove the optionality of this field, thus making it mandatory.~CURRENT COMMENT RESPONSE: Clause 7.3.2.29 is not modified in D6.0 and Channel Utilization Field is mandatory. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: ~A~O~~11/12/2005 00:00:00~~~~~~V 781384~"Chris Durand"~" in LB 78"~~~~11k-D3.0~11.9.2~61~10-12~TR~This seems like duplicate information that already exists in the beacon and probe responses as a result of the country information element. ~Remove the Measurement Pilot and all associated text.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: An AP is only required to include the Country element if dot11MultiDomainCapabilityEnabled is true. The Max Regulatory Power field that is governed by the dot11MeasurementPilotEnabled parameters is not tied to dot11MultiDomainCapabilityEnabled. So this information is not always redundant and an administrator may decide to include regulatory parameters in either or both locations.~R~O~~11/12/2005 00:00:00~~~~~~V 781385~"Chris Durand"~" in LB 78"~~~~11k-D3.0~11.11.1~61~19-23~ER~These appear to be definitions.~Move to clause 3.~CURRENT COMMENT RESPONSE: Don't use those terms (dedicated and concurrent) anymore (been removed). In D6.0, the references now refer to new definitions of Operating Channel and Non-Operating Channel. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The defined terms were unused in the rest of the draft. However, in response to other comments this section has been redrafted.~R~O~~11/12/2005 00:00:00~~~~~~V 781387~"Chris Durand"~" in LB 78"~~~~11k-D3.0~11.11.4~62~18-19~TR~The statement is made "Each separate measurement within the Radio Measurement Request frame shall be performed over a continuous time period". If it is performing these measurements over a continuous time period how does that relate to data on the serving channel? Does the serving channel stop sending data?~Clarify how this continuous measurement is supposed to relate to data on the serving channel. The problem here is not necessarily with regard to the STA sending uplink data, but rather the AP sending downlink data.~CURRENT COMMENT RESPONSE: The current clauses are 11.10.1 and 11.10.5. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: Such text is already present in 11.11.1 and 11.11.5.~A~O~~11/12/2005 00:00:00~~~~~~V 781389~"Chris Durand"~" in LB 78"~~~~11k-D3.0~11.11.6~62~37-38~TR~The statement is made "A STA may measure one or more channels itself or a STA may request peer STAs in the same BSS to measure one or more channels on its behalf". This seems like it could be used to create a "denial of service" type of effect.~Create some solution that would preclude a rogue STA from causing disruption throughout the network by forcing STAs to go off channel doing measurements.~CURRENT COMMENT RESPONSE: TGw provides security of management frames including TGk measurement requests. Clause 11.10.4 indicates that a STA decides when and if it shall respond to any measurement request. Denial of service from measurement requests is not possible. We request that the commenter read the current version of D6.0 Clause 11.10.5 to confirm the current resolution. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: This text has been edited as a result of other comments. This likely resolves the issue.~A~O~~11/12/2005 00:00:00~~~~~~V 781414~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~3.99~2~8~TR~"3.99 average noise power indicator (ANPI): An indication of the average noise plus interference power measured on a channel when NAV is equal to 0 (when virtual CS mechanism indicates idle channel)except during frame transmission or reception." is slightly confusing because it does not indicate that it is the STA that is either transmitting or recieving (especially recieving)~change "except during frame transmission or reception." to "while the STA is neither transmitting nor receiving a frame. "~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: See resolutin in comment #1477.~R~O~~11/12/2005 00:00:00~~~~~~V 781417~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.1.21~7~3~TR~" When set by an STA, it provides an upper limit, in units of dBm, " Is confusing because in this case it is only set by an AP. ~Change "STA" to "AP"~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: By definition an AP is an entity that connects a STA to the DS. In this case it is the STA portion of the AP that is setting the power so this is accurate. ~R~O~~11/12/2005 00:00:00~~~~~~V 781419~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.1.23~11~17~TR~"used by the STA transmitting the measurement pilot frame" only an AP can transmit this frame~Change "STA" to "AP"~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: By definition an AP is an entity that connects a STA to the DS. In this case it is the STA portion of the AP that is setting the power so this is accurate. ~R~O~~11/12/2005 00:00:00~~~~~~V 781421~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.21.11~20~21~TR~Since E911 service has determined that the location of the AP is good enough for WLAN, what is the justification of having latitude and longitude transmitted over the air?~Remove Lat and long from location request, or provide an accuracy of 1000 feet, or take out location from TGk specification.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The IEEE 802 Contention-Based Protocol effort, in 11-05/1039r3 points to an Objective to address operation near National Borders per 47.CFR 90.1337~R~O~~11/12/2005 00:00:00~~~~~~V 781425~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.22.4~26~23~TR~"Channel busy time shall be the time during which either the physical carrier sense or NAV indicated channel busy, as defined in 9.2.1." may be misleading in certain situations where virutal carrier sense is used to hold traffic off (for reasons that may, or may not be, outside the scope of thecurrent specification or future specifications that may need to interoperate with the current one). Additionally the requestor may get two different results for a request in the same BSS, from tow STA's that are using the different tecniques. Right now it's impossible to tell which is which.~Provide a bit in the report that indicate whether physical or virual carrier sense was used in the calculation. As a side note I do not believe it is appropriate to mandate one or the other in the request, but a sugguestion may be worth considering. However, for a given HW architecture usually one or the other will be easier.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Channel busy does not depend on a choice of physical vs. virtual CS. All STAs are defined to have both physical CS and virtual CS, as detailed in 9.2.1. In this measurement report, channel busy measurement requires monitoring both physical and virtual CS simultaneously. If EITHER physical or virtual mechanism indicates busy, the channel time is counted as busy time. The sentence beginning at P26L23 is clarified to read, "Channel busy time shall be the time during which either the physical carrier sense or the virtual carrier sense (NAV) or both indicates that the channel is busy. See 9.2.1 for description of carrier sense mechanism." New clarified wording to be moved to 11.11.9.3 as indicated in resolution #1049.~R~O~~11/12/2005 00:00:00~~~~~~V 781427~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.22.7~30~20~TR~"Last RCPI indicates the received channel power of the most recently measured frame in this Frame Report entry. Last RCPI is reported in dBm, as defined in the RCPI measurement clause for the PHY Type." What is the value of this when you have the average RCPI?~Justify, remove, add this byte field to the actual frame count making it a 16 bit field.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The Last RCPI value provides the power level of the most recently received frame counted in this frame reporte element, The 8 bit field for counted frames saturates at 255. If a more accurate relative measure of usage is desired, the measurement may be repeated with a shorter measurement duration.. TGk has discussed the suggested remedy and decided that the 8 bit value is adequate. ~R~O~~11/12/2005 00:00:00~~~~~~V 781428~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.22.7~30~~TR~Since the measuement duration is expressed in TU's and is a 2 byte field, having a max value of 255 for a frame count seems inadaquate.~Remove last RCPI value for this entry and add that byte to the frame count.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Frame count is a counter that saturates at 255, if an unsaturated value is required in the measurement, the measurement should be repeated with a smaller measurement duration. This solution is preferred, over the added complexity of a larger frame counter size and much more complex statistics on the set of frames~R~O~~11/12/2005 00:00:00~~~~~~V 781429~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.22.10~31~9~TR~"shall be the same units used for the statistic in the MIB." What is a MIB?~MIB is undefined. Use the term Database or data structure~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: MIB is defined in the Acronym list, is detailed in Annex D and is referred to in numerous places in the baseline draft and in the latest ma rollup. No change is needed. ~R~O~~11/12/2005 00:00:00~~~~~~V 781430~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.22.10~31~9~TR~"shall be the same units used for the statistic in the MIB." This implies that there actually is a data structure that is separate from the "connection table" that contains these statistics in such a form that SNMP can read them out. This is not the case and it should not be implied in the specification, as it has nothing to do with the protocol.~Use the term database or data structure. Indicate that definitions can be found in annex d.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: ~R~O~~11/12/2005 00:00:00~~~~~~V 781431~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.22.11~32~6~TR~"IETF RFC 3825, “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information” " has nothing to do with IEEE802.11~Remove reference provide pertanent information in this document, or remove LCI command, ~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: In resolving LB78 comments, the draft text proposed is "This structure and information fields are little-endian, per conventions defined in 7.1.1, and are based on the LCI format described in IETF RFC 3825, “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information”. " This clarifies that it is the LCI and field formats that are being referred to.~R~O~~11/12/2005 00:00:00~~~~~~V 781432~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.22.13~35-36~~TR~Average delay measures delay with the following;"Delay shall be measured from the time the MSDU is passed to the MAC until the point at which the first, or only fragment is ready for transmission and shall be expressed in TUs." but measured delay measures delay with the following "Transmit Delay shall be measured from the time the MSDU is passed to the MAC until the point at which the entire MSDU has been successfully transmitted, including receipt of the final ACK from the peer QSTA if the QoSAck service class is being used." Why must this be measured differently?~Make the measurements the same way for both average and measured.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: It is assumed that the comment refers to average transmit delay on P35 L18-22 and Transmit Delay on P36 L4-8. These seem to be the same.~R~O~~11/12/2005 00:00:00~~~~~~V 781434~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.28~39~20~TR~"The RCPI element is used in the active scan procedure as described in 11.1.3.2.2 and elsewhere. The RCPI Information element is also used in the Association and Reassociation Response frame to indicate the received power level of the corresponding Association or Reassociation Request frame." Saying where the RCPI element is used with the clause "and elsewhere adds nothing to the draft amendment except lines that could possibly be misinterpreted.~Change "The RCPI element is used in the active scan procedure as described in 11.1.3.2.2 and elsewhere. The RCPI Information element is also used in the Association and Reassociation Response frame to indicate the received power level of the corresponding Association or Reassociation Request frame." to "he RCPI Information element is uaed to indicate the received power level at the recieving STA"~"CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Replace sentence at P39 L16 with ""The RCPI element indicates the received frame power level at receiving STA."" Delete P39 Lines 19-21. Delete P40 Lines 1-2."~R~O~~11/12/2005 00:00:00~~~~~~V 781435~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.29~40~17~TR~" If dot11QoSOptionImplemented is false: the values between 0 and 254 shall be a logarithmically scaled representation of the average medium access delay for DCF transmitted packets measured from the time the DCF packet is ready for transmission (i.e. begins CSMA/CA access) until the actual packet transmission start time. A value of 1 shall represent a 50 us delay while a value of 253 shall represent a 5.5 ms delay or any delay greater than 5.5 ms. The value 254 shall indicate that DCF services are currently blocked. The AP shall measure and average the medium access delay for all transmit packets using DCF access mechanism over a continuos thirty second measurement window. The accuracy for the average medium access delay shall be +/- 200 usec or better when averaged over" Besides sounding like a complicated measurement, if dot11QoSOptionImplemented is falsewould likely mean a legacy device. Very few, if any legacy devices can make this calculation because the hardware does not keep the access start time, only the time the packet was transmitted, or time ack was received, or time of ack timeout.~Remove this clause.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: See resolution in comment #1279. AP Service load is modifed to be a generic load metric for non-QAPs. QBSS load is modified to add access delay loading metrics for each Access Category. Access delay is a TGk amendment item which applies to TGk terminals not legacy terminals. Doc 05/0079r1 show that average access delay measurements do not require hardware. Transmission and queuing records in the MAC layer are adequate.~R~O~~11/12/2005 00:00:00~~~~~~V 781436~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.29~41~16~TR~"The Channel Utilization field is defined as the percentage of time the AP sensed the medium busy, as indicated by either the physical or virtual carrier sense mechanism. "Physical and virtaul carrier sense can report very different values. It is important to know if physical carrier sense is used or not~Add a bit on the report to indicate whether physical or virual carrier sense was used.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Channel Utilization is deleted from BSS Load. See resolution in comment #1279.~R~O~~11/12/2005 00:00:00~~~~~~V 781439~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.4.5.5~45~19~TR~"Neighbor TSF offset Request – This bit is set to 1 to request TSF offset information be provided in neighbor list entires if available. When this bit is set to 0 the TSF Info field shall not be included in any neighbor list entries. " has no value. The reason why (which is dubious to begin with) the fields were optional is to not allow wasted time on the air would be from an administrator's perogative. Why would a STA care? It's not worh the effort involved in keeping this straight. If the administrator does not care it should be included to not care while configuring the device~Remove the option. Delete it from the service primitive in 10.3.24.3.2.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: When an AP does not support a TSF offset then this extra field is 4 bytes per SSID per neighbor and could result in considerable extra traffic over the air. The field was made optional at the request of many TG members.~R~O~~11/12/2005 00:00:00~~~~~~V 781441~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.1.3.2.1~58~15~TR~"If the DS Parameter Set information element is present in the probe request, a STA where dot11RadioMeasurementEnabled is true shall respond only if the channel number from the DS Parameter Set element matches the channel in use by the STA. " Why is this behavior mandatory?~Give the reponder the option of returning the returning the response if the channel is not correct via configuration option, or remove the whole thing, including adding the DS parameter set to the probe request, or any part thereof.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: TG straw polls on this issue shows a majority decision to mandate the behaviour inidicated in this clause for STA with dot11RadioMeasurementEnabled=true~R~O~~11/12/2005 00:00:00~~~~~~V 781442~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.1.3.2.1~59~7~TR~"When a probe response frame is returned in response to a probe request frame which contains Requested information elements, any of the requested elements which appear as individual items in the ordering list of Table 12 shall appear both in their individual ordered location as specified in Table 12 and in the ordered location reserved for the list of requested elements, where the requested elements appear in increasing numerical element ID order. " This statement does not appear to be within the scope of the draft amendment. Since there is no extra frames besides the DS parameter set there is no reason for this text that I can see as it pertains to TGk. ~Provide justification as to why this paragraph must be added to 11.1.3.2.1. Note that TGg ran into trouble with the rates IE because there were particular expectations implied in the 1997 draft that were along these lines.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The text clarifies the operation of probe request containing a Request element as asked for by comment #198 in doc 05/0191r70. The Probe Request/Response mechanism is used for several of Tgk measurments, therefore it is important that it's operation is clearly understood.~R~O~~11/12/2005 00:00:00~~~~~~V 781443~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.1.3.2.2~59~16~TR~"RCPI value shall be included in the RCPIMeasurement parameter of the BSSDescription in the MLME-SCAN.confirm." How can you reference informative text in this manner in a normative section? This implies that there must be an MLME-SCAN.confirm in the implementation.~Change text to "RCPI value shall be included in the probe request."~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Proposed resolution is incorrect as RCPI is only included in response frames, such as probe-response, association-response etc.~R~O~~11/12/2005 00:00:00~~~~~~V 781444~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.1.3.2.2~59~19~TR~"An AP may measure RCPI on the received Probe Request frame and include the result in the RCPI element of the Probe Response." I assume what you really mean here in this sentence, given the previous sentence is when dot11RadioMeasurementEnabled is false the AP may send the response. If true you should explicitly say this. If false you need to clarify this statement..~prepend "If dot11RadioMeasurementEnabled is false" to sentence "An AP may measure RCPI on the received Probe Request frame and include the result in the RCPI element of the Probe Response." or clarify.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The sentence as written in the current draft is clearly describing that the probe-response shall contain RCPI when dot11RadioMeasurementEnabled is true.~R~O~~11/12/2005 00:00:00~~~~~~V 781445~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.9~60~25~TR~"ERC/DEC/(99)23 requires RLANs operating in the 5GHz band" RLAN is not defined in this specification, or the 2003 standard.~Define RLAN~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: RLAN was added as an abbreviation.~R~O~~11/12/2005 00:00:00~~~~~~V 781446~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.1~61~19~TR~"11.11.1 Dedicated versus concurrent measurements" Concurrent is confusing in regards to parallel. ~Change dedicated to serving channel and concurrent to non-serving channel measurements.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Removed these terms in a cleanup of this section.~R~O~~11/12/2005 00:00:00~~~~~~V 781448~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.5~61~20~TR~Since this is the responsibility section, it should also be noted that a STA's refusal to take a measuremnt may have an impact on the BSS, or ESS.~append sentence to one ending on line 31 that says "It should be noted that the overall performance of the BSS or ESS may be negativly affected by consistant refusal of measurements being taken of the participants of the BSS and ESS with dot11RadioMeasurementEnabled set to true. ~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: It was felt that an informative statement of this type did not add sufficiently to what is already within the draft.~R~O~~11/12/2005 00:00:00~~~~~~V 781450~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.6~64~9~TR~"Measurement Report elements shall be returned to the requesting STA in one or more Radio Measurement Report frames. Each Radio Measurement Report frame shall contain the same Dialog Token field value as the corresponding Radio Measurement Request frame." How does the reciever of a measurement report know it got the complete report, only got a partial report?~Add a" more data" field to the report.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: It is not always possible to know that there are more results to come, e.g. when reporting partial results during a long beacon measurement.~R~O~~11/12/2005 00:00:00~~~~~~V 781451~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.9.1~66~3~TR~"If only Measurement Pilot frames were received in the measurement duration and the Measurement Mode was Passive Pilot, the contents of the Beacon Report shall be based on the latest Measurement Pilot frame received. " should be more explcit~Change to "If the Measurement Mode was Passive Pilot, the Beacon Report can be based on Beacons, Probe Responses, or Pilot Frames."~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: See resolution in comment #114.~R~O~~11/12/2005 00:00:00~~~~~~V 781452~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.9.1~67~8~TR~"In Active mode, this shall be regardless of whether a received Probe Reponse frame was triggered by the measuring STAs Probe Request." Is confusing as to whther the cache of BSS's that is maintained from normal scanning should be used as well as being superfluos to the point of the paragraph~Delete the Sentence~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: See clarification in comment#1097~R~O~~11/12/2005 00:00:00~~~~~~V 781453~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.9.1~67~18~TR~"For iterative beacon measurements, the measurement duration applies to the measurement on each channel. Measurements shall be made within the specified Measurement Interval with the time between each consecutive measurement as defined in 11.11.2. Measurements shall cease either when all supported channels have been measured, or the measurement interval has expired. " Why is this only for meausrements of 255? Isn't this behavior for all multichannel beacon measurements?~If this is true place this statement in an appropriate paragraph. If this is not true explain the behavior in the other options for channel numbers.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: See reolution in comment #1524~R~O~~11/12/2005 00:00:00~~~~~~V 781456~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~Figure k49~68~~TR~The figure only mentions RCPI, but the text mentions RCPI or RSSI~change RCPI to RCPI/RSSI~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: At P67L42, the text clearly states that Figure k49 provides examples for reporting conditions 5 and 6. In the figure the threshold crossing events are clearly labeled for reporting conditions 5 and 6. In Table k3, reporting conditions 5 and 6 are clearly listed as RCPI conditions. The text and figure are both correct. The text in P67L31-42 is a general paragraph, but the figure is a particular example. No draft changes are needed. ~R~O~~11/12/2005 00:00:00~~~~~~V 781457~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~Figure k49~68~~TR~It's unclear what this figure is actually trying to communciate. What do the red dots mean? What to the arrows that intersect the curves mean?~clarify~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: As indicated in Figure k49, the "red dots" are repeated RCPI measurements. The dashed line indicates the reporting condition level. For condition 6, a measurement report is issued when the measured RCPI (the second dot) crosses below the indicated reporting condition level. For condition 5, a measurement report is issued when the measured RCPI (the second dot) crosses below the indicated reporting condition level. The figure is clearly so labelled. It is unclear from the comment what the commenter would suggest as a remedy to his perceived need for clarification.~R~O~~11/12/2005 00:00:00~~~~~~V 781459~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.9.8~69~22~TR~"An LCI request may indicate a location request for the local STA or the remote STA by setting the LCI request Location Subject octet to indicate a Local or Remote request respectively. For a Local Request, the reporting STA shall send a LCI Report that indicates the location of the requesting STA. For a Remote Request, the reporting STA shall send a LCI Report that indicates the location of the reporting STA. " The LCI information goes over the air in a management frame which is unencrypted, and probably will be unencrypted in a public network even after TGw finishes. There are many dangerous scenarios that come to mind using this feature (possibly without the person who's location is ascertained). This is a security issue on many levels. As I understand it, the E911 requirements are only for the location of the AP. THere is no need for this in a Standard other than to facilitate a vendor's invention.~Remove LCI~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The IEEE 802 Contention-Based Protocol effort, in 11-05/1039r3 points to an Objective to address operation near National Borders per 47.CFR 90.1337. E-911 requirements are being addressed in TGu and TGv. ~R~O~~11/12/2005 00:00:00~~~~~~V 781460~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.9.10~70~10~TR~" A QAP shall refuse measurementrequests for traffic to other QSTAs in the BSS. " Caon't this be gotten around by spoofing a proxy measurment packet~Remove the ability for the STA to proxy packets~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: It is not clear what functionality is being commented on here - please resubmit with further detail if there is still an issue in the next draft.~R~O~~11/12/2005 00:00:00~~~~~~V 781461~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.9.10~70~26~TR~"The measuring non AP-QSTA shall not send further triggered QoS reports until the Trigger Timeout period specified in the request has expired, or new trigger conditions have been requested. " is unclear. IF the desired effect is to have it follow the normal request precidence rules explicitly state this.~Change paraghraph to ""The measuring non AP-QSTA shall not send further triggered QoS reports until the Trigger Timeout period specified in the request has expire. Normal precidence rules shall be followed as defined in 11.11.6."~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The desired affect is to have a timeout period to prevent report flooding.~R~O~~11/12/2005 00:00:00~~~~~~V 781462~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.11.9.10~70~44~TR~"Once accepted by a measuring non-AP QSTA, a triggered QoS measurement continues to be active until: " request precidence is not mentioned here.~Add a bullet that says "until another measurement is received with a higher precidence than the current one." Change sentance on line 4 pg 71 to "All triggered QoS measurements shall be terminated at a measuring non-AP QSTA by receiving a triggered QoS metrics measurement request with the Enable bit set to 1 and the Report bit set to 0, or another measurment with a higher precidence is recieved" ~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Triggered measurements are active unless these conditions are true. They escape the normal presedence rules though this text: 'Measurement Request elements that have the Enable bit set to 1 shall be processed in all received Radio Measurement Request frames regardless of these precedence rules.'~R~O~~11/12/2005 00:00:00~~~~~~V 781463~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.12~71~12~TR~"The Neighbor Report contents shall be derived from the MIB table dot11RRMNeighborReportTable." implies that there is a table called "dot11RRMNeighborReportTable." and has the structure as defined in Annex D. The fact of the matter is that SNMP is typically implented as a collection of access routines that append the information on the space provided in the request. In other words the design of SNMP is such that this information is abstracted from SNMP. There may be a dot11RRMNeighborReportTable in the manager, but to imply that this table actually needs to be in the AP is an uncessary design constraint.~Changefollowing sentences to "The Neighbor Report contents shall be derived from an internal data structure that contains information necessary to create all the required neighbor list entries. The mechanism by which the contents of this data structure"~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Replace sentence beginning on P71L12 “The Nieghbor Report contents are derived from the NeighborListSet parameter of the MLME-NEIGHBORREPRESP.request.”~R~O~~11/12/2005 00:00:00~~~~~~V 781467~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.14.1~72~29~TR~"In case the medium is determined by the carrier-sense mechanism (see 9.2.1) to be unavailable, the AP shall delay the actual transmission of a Measurement Pilot frame according to the basic medium access rules specified in Clause 9 for a maximum period of one dot11MeasurementPilotPeriod and drop the Measurement Pilot frame at the next TMPTT." What happens if the NAV is set for longer than two TMPTT? Will the AP send the pilot frame out? This may happen in the case of 2 point coordinators in a frequency reuse scenario.~Clarify the behavior?~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: ~R~O~~11/12/2005 00:00:00~~~~~~V 781469~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~3.101~2~12~TR~Whereas other references to IETF work in 802.11 are referenced because there is a connection, or reliance on, the IETF work in question, RFC 3825 has no relationship with 802.11k. It is only an example. This will be extrememly confusing.~Remove any reference to RFC3825 create an IEEE LCI, or remove location from the specification and provide an API to the IETF to do the location aware work across different IEEE medium ~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: It is important that the definition be referenced in the source. RFC 3825 is not going to change and therefore is a valid definition source. ~R~O~~11/12/2005 00:00:00~~~~~~V 781470~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~5.2.5~3~5~TR~in 5.2.5 the current first sentence says "Wireless LAN Radio Measurements enable the stations of the BSS and the ESS to automatically adjust to the radio environment in which they exist." yet this is not listed as a service in 5.4.5~While "Providing information about neighbor APs." is an extremely important concept I would suggest generalizing this to "giving STA's the ability to assess their environment."~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The response to 1221 has been accepted which addresses the comment.~R~O~~11/12/2005 00:00:00~~~~~~V 781472~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7, 11, general~~~TR~The way this draft amendment is written a STA that has associated but has not (RSNA) authenticated can retrieve information from the (I)BSS. A STA participating in an RSNA that can not 802.1x authenticate should get nothing from the (I)BSS..~Change Clauses 7 and 11 to enable this behavior.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: TGk is only defining Management Frames which are unprotected and not controlled by RSNA. TGw will address the protection of management frames.~R~O~~11/12/2005 00:00:00~~~~~~V 781473~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.26~36~24~TR~"The AP Channel Report contents shall be derived from dot11APChannelReportTable. An AP Channel report shall only include channels that are valid for the regulatory domain in which the AP transmitting the element is operating and consistent with the Country element in the frame in which it appears." mplies that there is a table called "dot11APChannelReportTable." and has the structure as defined in Annex D. The fact of the matter is that SNMP is typically implented as a collection of access routines that append the information on the space provided in the request. In other words the design of SNMP is such that this information is abstracted from SNMP. There may be a dot11APChannelReportTable in the manager, but to imply that this table actually needs to be in the AP is an uncessary design constraint.~Delete sentence "The AP Channel Report contents shall be derived from dot11APChannelReportTable." It only confuses.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Counter: Delete first sent\enc at P36L24. P128L8: add new sentence to MIB description of dot11APChannelReprotChannelList, "This list of channels is the Channel List in the AP Channel Report element described in 7.3.2.26."~R~O~~11/12/2005 00:00:00~~~~~~V 781474~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11~~~TR~Give the STA the ability to do a "Fast Scan" This allows the STA to only get RSSI data very quickly in a deterministic manner This is different, and faster than the pilot frame since it can be done in a millisecond or two if you know you can be active on a channel~adopt 11-03-0834, or something like it.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The group's decision was to adopt the Pilot Frame to provide this functionality~R~O~~11/12/2005 00:00:00~~~~~~V 781475~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~11.12.2~71~29~TR~Since the neighbor report is used to facilitate a better and possibly faster roaming candidate selection, and since disassociation (implicit or explicit) is part of the roaming process, and that the disassociation is bi-directional, allow the AP to send the neighbor report before dissassociation. IT should also be noted that TGk's "formal" vote as aluded to in comment sheet for letter ballot 73, was out of order, since, according to the minutes from FLA '04 the text was not on the server for 4 hours prior to the vote. In this light the chair has the perogative to just put the text back in with editorial discression due to the possibliity of the some text changing.~Put dissassociate Imminent back into the draft amendment. This is within the scope of this par since the disassociate message is part of the 1997-2003 draft. This is giving the STA more/up to date information before it gets booted off the bss by a disassociate message (which has been present in the 802.11 standard since 1997)~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: TGv is looking to provide similar functionality to "Disassociate Imminent" in the Load Balancing capability. TGv is amore appropriate venue for this function.~R~O~~11/12/2005 00:00:00~~~~~~V 781476~"Lefkowitz"~" in LB 78"~~~~11k-D3.0~7.3.2.27~37~~TR~Preauthentication - there is currently no mechanism to determine if the key has been dropped by the Neighbor due to resource issues.~Include an information element in the beacon that indicates the last time the Neighbor flushed it's cache such that the STA would know that all keys after a particular time are no longer kept by this AP. Indicate uptime in this IE for the event that the AP has reboot since the preauth. Since this is a measurement of the key cache it is in the scope of 802.11k~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: ~R~O~~11/12/2005 00:00:00~~~~~~V 830043~"Marshall"~" in LB 83"~~~~11k-D4.0~7.2.3.9~7~15~TR~The order of requested information elements in a Probe Response is specified in the second paragraph of 7.2.3.9 (not being changed by this amendment). However, that unchanged text conflicts with the last sentence of the new text being added to the first paragraph.~make consistent with previous rules.~Replace "where the requested elements appear in increasing numerical element ID order" by "where the requested elements appear in the same order as requested in the Request information element." Editor to incorporate next paragraph of 11ma into the document, and then delete the last sentence in this new paragraph "In the probe response frame, the STA shall return the requested information elements in the same order as requested in the Request information element."~R~O~~03/31/2006 00:00:00~~~~~~V 830153~"Fischer"~" in LB 83"~~~~11k-D4.0~7.3.2.27~39~1~TR~Do you mean QBSS load?~Change "BSS Load" to "QBSS Load"~CURRENT COMMENT RESPONSE: Please see current definition of Access Delay in D6.0.---ORIGINAL COMMENT RESPONSE: Commenter is correct. Other comments indicate preferred solution which is to remove this TGk modification to QBSS load. All changes here to be removed. See comment #355 and #550. New beacon element called QBSS Access Delay will be added in next draft.~R~O~~03/31/2006 00:00:00~~~~~~V 830154~"Fischer"~" in LB 83"~~~~11k-D4.0~7.3.2.27~39~10~TR~Missing reference? I assume that you mean "Access Category Service Load" ….~Change "the for this AC" to "the Access Category Service Load field for this AC"~CURRENT COMMENT RESPONSE: See current description in 7.3.2.44 of D6.0.---ORIGINAL COMMENT RESPONSE: Alternat wording has been suggested. See comment #641.~R~O~~03/31/2006 00:00:00~~~~~~V 830186~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~3~1~25~TR~" AP reachablility: An AP is reachable by a STA if pre-authentication messages as defined in clause 8.4.6.1 can be exchanged between the STA and the target AP via the DS." This is not the case. It is merely if the AP is reacable by the STA. It does not have to be for pre-auth~Change to "AP reachablility: An AP that can forward data messages from this STA to the desired destination. This includes the Preauthentication process as described in clause 8.4.6.1"~"CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The definition was drafted by Aboba and Walker and IS related to pre-authentication. Per discussion on 07/19/06 at with Bernard Aboba the definition should reamin the same. Need a joint meeting with 11r since AP reacability is the same in both tasks decline. "~R~O~~03/31/2006 00:00:00~~~~~~V 830188~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~3~2~19~TR~ "neighbor AP: Any AP that is a potential transition candidate." This is not the defintion of Neighbor AP since Neighbor AP's in the Neighbor List can only be validated. (How many times must we go over this?)~Give specific instructions to the editor - Change Neighor AP back to " Any validated AP that is a potential transition candidate." Change Validated Neighbor AP to "3.161A validated AP: an AP that has either been explicitly configured as a Neighbor in the MIB, or learned through a mechanism like the Beacon Report and confirmed through trusted mechanisms such as a secure Inter-Access Point Protocol (IAPP)." Replace any occurance of "validated Neighbor AP" with "Neighbor AP"~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The intent of the definition in the draft was to use common english interpretation of the word 'neighbor'. Any AP within the radio range of a STA is considered a neighbor AP. Modified "Validated Neighbor AP" to "Validated AP" as suggested.~R~O~~03/31/2006 00:00:00~~~~~~V 830190~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~7.2.3.9A~9~1~TR~"5 RSN Capabilities The RSN Capabilities field is defined in 7.3.2.25.3." Why is this being singled out? Why not add a reference for beacon interval, and everything else?~Remove the note~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: This comment is related to Table 15A - PG changed clause from 15A to 7.2.3.9A. The entire RSN Capabilities IE is deleted from the Measurement Pilot. See comment #635.~R~O~~03/31/2006 00:00:00~~~~~~V 830191~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~11.1.3.2.1~70~19~TR~"STAs receiving Probe Request frames shall respond with a probe response only if the SSID in the probe request is the broadcast wildcard SSID or matches the specific SSID of the STA." I belive this should be the SSID of the (I)BSS~Change "SSID of the STA." to "SSID of the (I)BSS." ~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Invalid reference - PG changed to P70 L19. Both usages of SSID are correct and are reaffirmed in 11maRev-D7.09. This is a correct usage in this context. No change is needed.~R~O~~03/31/2006 00:00:00~~~~~~V 830193~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~7.3.1.21~11~5~TR~" When set by an STA, it provides an upper limit, in units of dBm, " Is confusing because in this case it is only set by an AP. ~Change "STA" to "AP"~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: p11, line 5, Replace ". When set by a STA, it provides" with ", providing"~R~O~~03/31/2006 00:00:00~~~~~~V 830194~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~7.3.1.23~12~3~TR~"by the STA transmitting the measurement pilot frame" only an AP can transmit a pilot frame.~Change "STA" to "AP"~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: By definition an AP is an entity that connects a STA to the DS. In this case it is the STA portion of the AP that is setting the power so this is accurate. Additionally, in an IBSS, STAs can transmit beacons and measurement pilots, so this wording is appropriate.~R~O~~03/31/2006 00:00:00~~~~~~V 830197~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~11.11.8.3~81~14~TR~"Channel busy time shall be the time during which either the physical carrier sense or NAV indicated channel busy, as defined in 9.2.1." may be misleading in certain situations where virutal carrier sense is used to hold traffic off (for reasons that may, or may not be, outside the scope of thecurrent specification or future specifications that may need to interoperate with the current one). Additionally the requestor may get two different results for a request in the same BSS, from tow STA's that are using the different tecniques. Right now it's impossible to tell which is which.~Provide a bit in the report that indicate whether physical or virual carrier sense was used in the calculation. As a side note I do not believe it is appropriate to mandate one or the other in the request, but a sugguestion may be worth considering. However, for a given HW architecture usually one or the other will be easier. The previous ballot resoluton to clarify the wording that it is either the virtual or physical is not good enough, and show a misunderstanding of the differences between the two. In the case of PBCC OFDMCCK options in the base standard there would be no virtual carrier sense since the phy header determines a signal and service that is not readable by those stations that do not support those options. This situation may also happen in future amendments.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Irrespective of how (physical or virtual) the channel is determined to be busy, as far as the device is concerned the channel is busy. Hence this definition of channel busy time is correct. It does not matter if the NAV was used to artificially render the channel busy. If the commentor has a better resolution, the commenter is urged to propose a complete normative text for the suggested change.~R~O~~03/31/2006 00:00:00~~~~~~V 830199~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~7.3.2.22.9~35~4~TR~"IETF RFC 3825, “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information” " has nothing to do with IEEE802.11~Copy the definitions into the draft amendment (possibly a separate annex that references 3825 as the source for the definition.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: LB73 ballot comments (1143) directed reference to RFC 3825 for field descriptions that are defined there. ~R~O~~03/31/2006 00:00:00~~~~~~V 830200~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~11.1.3.2.1~70~20~TR~"If the DS Parameter Set information element is present in the probe request, a STA where dot11RadioMeasurementEnabled is true shall respond only if the channel number from the DS Parameter Set element matches the channel in use by the STA. " Why is this behavior mandatory?~Give the reponder the option of returning the returning the response if the channel is not correct via configuration option, or remove the whole thing, including adding the DS parameter set to the probe request, or any part thereof. The declination on LB78 was specius since the comment was not considered in the presentation the owner of the clause gave because of a clearical error on the comments therefore any vote was out of order. Let the administrator do what he see's fit to do in this case.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Discuss with TG. Suggestion is to DECLINE. Invalid reference - should be 11.1.3.2.1 PG change clause. Per resolution of LB78 #1441: "TG straw polls on this issue shows a majority decision to mandate the behaviour inidicated in this clause for STA with dot11RadioMeasurementEnabled=true." TGk needs to discuss and reaffirm this decision to fix the problem described in 03/952r1. Marty's reccomendation will undo the this fix which was intentionally incorporated 3 years ago. Furthermore, a basic assumption of half-duplex radio communication is that a single channel is used. STAs should not expect nor should they rely on replies being transmitted on channels other than the current channel. Official Vote in San Diego confirm to decline this comment~R~O~~03/31/2006 00:00:00~~~~~~V 830201~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~11.1.3.2.2~71~17~TR~"An AP may measure RCPI on the received Probe Request frame and include the result in the RCPI element of the Probe Response." I assume what you really mean here in this sentence, given the previous sentence is when dot11RadioMeasurementEnabled is false the AP may send the response. If true you should explicitly say this. If false you need to clarify this statement..~prepend "If dot11RadioMeasurementEnabled is false" to sentence "An AP may measure RCPI on the received Probe Request frame and include the result in the RCPI element of the Probe Response." or clarify. The response from the lb78 was "The sentence as written in the current draft is clearly describing that the probe-response shall contain RCPI when dot11RadioMeasurementEnabled is true." yes, but it is not describing the behavior if dot11RadioMeasurementEnabled is false.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The wording of the second sentence is clumsy and leads to confusion. P71L16: replace first sentence of paragraph with "If dot11RadioMeasurementEnabled is true and if the Request Information element of the Probe Request includes the RCPI element ID, the STA shall include in the Probe Response an RCPI element containing the measured RCPI value of the received Probe Request frame." P71L17-19: delete second sentence of this paragraph.~R~O~~03/31/2006 00:00:00~~~~~~V 830203~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~11.11.5~76~14~TR~"Measurement Report elements shall be returned to the requesting STA in one or more Radio Measurement Report frames. Each Radio Measurement Report frame shall contain the same Dialog Token field value as the corresponding Radio Measurement Request frame." How does the reciever of a measurement report know it got the complete report, only got a partial report?~Add a" more data" field to the report. This was declined in lb78 with the comment "It is not always possible to know that there are more results to come, e.g. when reporting partial results during a long beacon measurement." This is puzzling since there is no indication in the document that partial results should be returned in the middle of a measurement, only that( the more likely case )results may be returned in multiple frames.~"CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The receiver can keep track of request tokens returned in the reports to determine if there are more reports pending. The measuring STA does not know if there is more data to report when reporting interim measurement results. TGk draft requires timely reporting of measurement results without “undue delay”. For very long measurement durations interim measurement reports will be generatedand transmitted. Since the amount of measurement report data depends on medium events which are sensed and measured aafter interim measurement reports are transmitted, the measuring station cannot know if therer will be additional measurement data."~R~O~~03/31/2006 00:00:00~~~~~~V 830204~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~11.11.8.1~80~~TR~The figure only mentions RCPI, but the text mentions RCPI or RSSI~change RCPI to RCPI/RSSI~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Changed clause from Figure 205a to 11.11.8.1. P80L12: change "RSSI" to RSNI".~R~O~~03/31/2006 00:00:00~~~~~~V 830205~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~11.11.8.1~80~~TR~It's unclear what this figure is actually trying to communciate. What do the red dots mean? What to the arrows that intersect the curves mean?~clarify by adding a key~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Changed clause from Figure 205a to 11.11.8.1. Explicit callouts and labels are used in the figure instead of a key. All items on figure are defined. A key is unnecessary.~R~O~~03/31/2006 00:00:00~~~~~~V 830206~"Lefkowitz"~" in LB 83"~~~~11k-D4.0~11.11.8.6~80~1~TR~"An LCI request may indicate a location request for the local STA or the remote STA by setting the LCI request Location Subject octet to indicate a Local or Remote request respectively. For a Local Request, the reporting STA shall send a LCI Report that indicates the location of the requesting STA. For a Remote Request, the reporting STA shall send a LCI Report that indicates the location of the reporting STA. " The LCI information goes over the air in a management frame which is unencrypted, and probably will be unencrypted in a public network even after TGw finishes. There are many dangerous scenarios that come to mind using this feature (possibly without the person who's location is ascertained). This is a security issue on many levels. As I understand it, the E911 requirements are only for the location of the AP. THere is no need for this in a Standard other than to facilitate a vendor's invention.~Remove LCI. The resolution in lb78 "The IEEE 802 Contention-Based Protocol effort, in 11-05/1039r3 points to an Objective to address operation near National Borders per 47.CFR 90.1337. E-911 requirements are being addressed in TGu and TGv. " indicates that this is out of scope for TGk and should be taken up in the CBP task group.~"CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Based on group vote Motion Move to decline LB83 comments that request to remove the LCI measurement (145, 176, 206, 263, 367, 378, 482, 522, 538, 630, 700 and 708). Moved: Peter Ecclesine Second: Brain Hart For: 21 Against: 0 Abstain: 1 Peter addressed this comment as a decline as well."~R~O~~03/31/2006 00:00:00~~~~~~V 830210~"Nitsche"~" in LB 83"~~~~11k-D4.0~Annex A~100~12~TR~The measurement of a Noise Histogram adds significant complexity to the PHY. There is still no evidence that this complexity is justified for improving network performance.~This is a repeat comment from LB78. Make the Noise Histogram optional in the PICS, similar as in 11h. I am not willing to accept the comment rejection based on a straw poll with just 14 from over 500 voters.~See motion in Jacksonville minutes (692/r3 page 9 bullet 10). TGk deemed Noise Histogram an important measure and to keep it Mandatory.~R~O~~03/31/2006 00:00:00~~~~~~V 830382~"Barber"~" in LB 83"~~~~11k-D4.0~0~ii~~TR~text is excessively verbose~remove thing just duplicated from the rest of the document, make it a more concise summary of what the measurements are for, and how to use, not a repeat of the description of the measurement~CURRENT COMMENT RESPONSE: The verbose text was moved to Section 5.4 and we expect to reduce the verbose nature of the text when dealing with LB 90 comments. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The introduction is removed from the document before submission for sponsor ballot and is therefore will not persist and is not consequential to the progress of the document.~R~O~~03/31/2006 00:00:00~~~~~~V 830384~"Barber"~" in LB 83"~~~~11k-D4.0~7.3.2.21~13~17~TR~The QoS measurements are not sufficient to support low latency periodic traffic with powersaving.~Add a measurement to support this (normative text to be supplied by commenter).~CURRENT COMMENT RESPONSE: As of Dec 06, no normative text was received from the commenter. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Commenter is invited to provide normative text in next recirc.~R~O~~03/31/2006 00:00:00~~~~~~V 830385~"Barber"~" in LB 83"~~~~11k-D4.0~7.3.2.21~13~17~TR~There are no measurements to support accounting for DLS traffic in a BSS.~Add measurement support for this (normative text to be supplied by commenter).~CURRENT COMMENT RESPONSE: As of Dec 06, no normative text was received from the commenter. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Commenter is invited to provide normative text in next recirc.~R~O~~03/31/2006 00:00:00~~~~~~V 830386~"Barber"~" in LB 83"~~~~11k-D4.0~7.3.2.21~13~17~TR~The measurements do not sufficiently support a client's decision to use DLS.~Add measurement support for this (normative text to be supplied by commenter).~CURRENT COMMENT RESPONSE: As of Dec 06, no normative text was received from the commenter. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Commenter is invited to provide normative text in next recirc.~R~O~~03/31/2006 00:00:00~~~~~~V 830387~"Barber"~" in LB 83"~~~~11k-D4.0~7.2.3.9A~8~2~TR~Measurement pilot does not give sufficient benefit in the real world and may cause excessive collisions on the medium.~Remove it.~CURRENT COMMENT RESPONSE: The vote was taken in 7/06 to decline 387. See the minutes 06/1037r6 P3 from the San Diego meeting. The vote was unanimous (6/0/3) to decline this comment. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Discuss with TG. Suggestion is to DECLINE. There is considerable support for Measurement Pilot for power saving and to rapidly track roaming candidate link conditions. Any manufacturer may choose not to implement any TGk PICS item he feels is not useful, whether or not it is indicated as mandatory. Many have already voiced their support. Should we move and vote to remove Measurement Pilot? Straw Poll? Other? TGk adhoc discussion decided to do TGk vote on this issue. Official Vote to decline passes in San Diego.~R~O~~03/31/2006 00:00:00~~~~~~V 830388~"Barber"~" in LB 83"~~~~11k-D4.0~A.4.13~100~12~TR~There are "shall"s in the document that do not have a PICS entry.~Ensure there is a PICS entry for each shall and v.v.~CURRENT COMMENT RESPONSE: Please review the Group's LB 83 Comment Resolution. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The PICS entries are for high-level features and not for individual options/alternatives within a feature. As a result there is no requirement that every use of shall in the document has a matching entry in the PICS table.~R~O~~03/31/2006 00:00:00~~~~~~V 830389~"Barber"~" in LB 83"~~~~11k-D4.0~7.1.3.1.2~4~34~TR~(No comment provided by commenter.)~(No suggested remedy provided by commenter.)~CURRENT COMMENT RESPONSE: The null suggested remedy has been incorporated without any change to the draft. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: Comment has not problem or suggested resolution~A~O~~03/31/2006 00:00:00~~~~~~V 830390~"Barber"~" in LB 83"~~~~11k-D4.0~general~~~TR~there is no general link test provided~this provides an absolute test of link quality, rather than an observed metric - it's an important test. Need to add a new measurement to send a set of test data frames across a link~CURRENT COMMENT RESPONSE: As of Dec 06, no normative text was received from the commenter. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Link measurement request and report provide the means for a layer 2 wireless link test. Prior TG discussions have concluded that more elaborate link diagnostic tests are more appropriate for implementation in higher layers. Mover: Ganesh Second: Hart Vote: 6/1/1 to accept the comment resolution.~R~O~~03/31/2006 00:00:00~~~~~~V 830391~"Barber"~" in LB 83"~~~~11k-D4.0~7.3.2.22.7~32~3~TR~last para - limit of 255 here is not high enough - especially as data rates go up with new standards.~increase counts to 4 bytes~CURRENT COMMENT RESPONSE: As rates go up, relative MAC overhead goes up and therefore aggregation will be used and this will limit the number of frames. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The Frame count field has been made 2 bytes to accommodate upto 65635 frames.~R~O~~03/31/2006 00:00:00~~~~~~V 830392~"Barber"~" in LB 83"~~~~11k-D4.0~11.11.8.1~78~17~TR~you don't know if a beacon is not reported because it's not heard or because this hardware unit is not capable of listening on a particular channel~add a new request/report to communicate what channels a particular STA implementation can support~CURRENT COMMENT RESPONSE: We do have text to cover a STA's inability to make a measurement. The STA sends an "incapable" response. The text for "incapable" is in D6.0, P87L22. We do have the capability to send individual measurement requests for each channel. An unsupported channel would result in an "incapable" response. This is one mechanism to implement the suggested functionality. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: While there may be use cases for such capability signalling, such a provision has never been a part of the TGk draft. It is unclear what suggested remedy the commenter is proposing. Additional detail would be needed to address this comment. The commenter is invited to provide a clear suggested remedy during next LB recirculation.~R~O~~03/31/2006 00:00:00~~~~~~V 830394~"Barber"~" in LB 83"~~~~11k-D4.0~7.4.5~46~3~TR~measurement requests are not secure, and will require driver changes to implement~make requests and responses into data frames rather than action frames, thus making it automatically secure, and making it easy to implement at least a good measurement subset without requiring any driver changes at all - thus speeding the propagation of 11k implementations~CURRENT COMMENT RESPONSE: TGw is making good progress in securing action frames. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The task group felt that extending the work for TGh was the appropriate way to add new measurements. TGw will provide the required security mechansim.~R~O~~03/31/2006 00:00:00~~~~~~V 830396~"Barber"~" in LB 83"~~~~11k-D4.0~7.2.1.3~80 in REVma5.2~34~TR~Requesting a measurement is an unnecessarily complex way to communicate RCPI and RSNI information.~Add RCPI and RSNI or other quality measure to a new ACK and CTS frame format. Now the sender of the frame being acked can compile this information as it needs to perform rate control and other link optimizations. Make this new ACK format optional to support legacy hardware.~CURRENT COMMENT RESPONSE: Invalid comment. Also does not comment on changed text. Requested submission which was never received in LB86. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Discuss with TG. Suggestion is to DECLINE this and invite paper in recirc. While the suggested remedy seems like a simple change, it has profound consequences which ripple throughout the spec. Defining an alternate CTS and ACK which are 2 bytes longer than a normal CTS and ACK requires an "either/or" rewrite for all occurences of ACK and CTS in the spec. The spec language for value of Duration in the header of all frames needs to be modified. All the frame exchange sequences using CTS or ACK will need to be modified. Issues of compatibility when legacy STAs exchange frames with RRM STAs need to be thought through thoroughly. However, the concept of using RCPI and RSNI in every ACK to facilitate transmit rate and power control for unicast transmissions is an appealing and very useful idea. Discuss with TG and decide on how to proceed. TGn seems to have incorporated a similar feature to the one proposed here, and so this is not needed in TGk draft.~R~O~~03/31/2006 00:00:00~~~~~~V 830397~"Barber"~" in LB 83"~~~~11k-D4.0~7.3.2~12~11~TR~Element IDs are incorrect~Fix them to the ANA allocated values~CURRENT COMMENT RESPONSE: The editor will insert the correct ANA numbers when they are received.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: The ANA numbers have been requested and the returned values are what need to be inserted.~A~O~~03/31/2006 00:00:00~~~~~~V 830398~"Barber"~" in LB 83"~~~~11k-D4.0~7.3.2.21.4~16~15~TR~Channel Load Request, Noise Histogram Request, Beacon Request, Frame Request all have regulatory class, channel number, randmoization interval and measurement duration fields in the request. This leads to much repetition in the specification. In addition STA statistics and QoS metrics share the randomization interval and measurement duration fields.~Make a new radio measurement request type and subtype - the type has the measurement randomization field and duration and the subtype the rest. Make all these measurements subtypes of these 2 types. This will remove much duplicated text in the document, and simplify understanding and implementation.~CURRENT COMMENT RESPONSE: As of Dec 06, no normative text was received from the commenter. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Discuss with TG. Suggestion is to DECLINE. Further suggest commenter provide document specifiying the details of the seggested remedy. Doc can be discussed and approved at meeting. Commenter will bring normative text to San Diego meeting.~R~O~~03/31/2006 00:00:00~~~~~~V 830399~"Barber"~" in LB 83"~~~~11k-D4.0~general~~~TR~There is no measurement to report co-located APs (Virtual APs)~Add a new requested information element (that can be request in a probe request) that lists all the BSSIDs that are co-located with identical RF characteristics.~CURRENT COMMENT RESPONSE: TGv has accepted a submission that was adopted into their specification that addresses colocated Aps (Virtual Aps). Multiple BSSID and Multiple BSSID-Index are the IEs in 11v (11-05/1120r6). NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Remedy is not a complete solution to the virtual AP problems. The suggested remedy is not a measurement. The commenter is encouraged to provide normative text for a complete solution.~R~O~~03/31/2006 00:00:00~~~~~~V 830400~"Barber"~" in LB 83"~~~~11k-D4.0~7.3.2.35~40~6~TR~why is this measurement necessary if we have the neighbor report request? This does not provide significant performance improvement, and adds complexity. The same effect can be got by associating quickly and requesting a neighbor report.~remove it~CURRENT COMMENT RESPONSE: This is not a TGk measurement, but is a configured item of very low complexity and is distinct from the Neighbor Report. It will be a significant benefit for low power devices. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Discuss with TG. The AP Channel list is the only network discovery item which is included in the Beacons. Neighbor report contains the channel list but is only available after association. Both are useful and needed.~R~O~~03/31/2006 00:00:00~~~~~~V 830425~"Chaplin"~" in LB 83"~~~~11k-D4.0~General~83~17~TR~This paragraph was changed as a result of my comment with the comment ID of 129 from the previous ballot, but now the grammar is even worse. "A QSTA may request that a measuring QSTA send a QoS metrics report be sent when the number of MSDUs for a specified TID that are discarded, or delayed reaches a specified threshold."? Let's try this again.~"A QSTA may request that a measuring QSTA send a QoS metrics report when the number of MSDUs for a specified TID that are discarded or delayed reaches a specified threshold."~Applied the suggested remedy and added a comma after the word delayed.~R~O~~03/31/2006 00:00:00~~~~~~V 830427~"Chaplin"~" in LB 83"~~~~11k-D4.0~General~44~10~TR~My comment with the ID 934 from the previous ballot was accepted, but the resolution was not implemented in the updated draft.~Should be, "values between 0 and 253" 254 has a different meaning.~See resolution in comment #85.~R~O~~03/31/2006 00:00:00~~~~~~V 830440~"Chaplin"~" in LB 83"~~~~11k-D4.0~7.3.2.38~44~31~TR~My comment on the previous ballot with a comment ID of 930 I argued that having a measurement accuracy of +/- 200us means that measurements with values of 50us really cannot be trusted. As an example, suppose I get an Access Delay measurement of 1 = 50-51us from AP1, and I get an Access Delay measurement of 70 = 181-184us from AP2, I need to be aware that the measurement accuracy is +/- 200us, which means that the actual Access Delay at AP1 could be anywhere between 0 and 250us, while the actual Access Delay at AP2 could be anywhere between 0 and 384us, which means that it is quite possible that the actual Access Delay at AP2 is less than the actual Access Delay at AP1. This is useless to me to make a roaming determination. I have no information as to how accurate the measurements are at AP1 and AP2, and in fact if the two APs are different models or from different manufacturers, the comparison would be meaningless.~(No suggested remedy provided by commenter.)~Discuss with TG. Change accuraccy to +/- 100usec. It is still a reasonable number since this is an average over 200 individual measurement. Systematic errors can be taken out by design/test.~R~O~~03/31/2006 00:00:00~~~~~~V 830441~"Chaplin"~" in LB 83"~~~~11k-D4.0~7.3.2.27~40~2~TR~My comment on the previous ballot with a comment ID of 935 I argued that having a measurement accuracy of +/- 200us means that measurements with values of 50us really cannot be trusted. As an example, suppose I get an Access Delay measurement of 1 = 50-51us from AP1, and I get an Access Delay measurement of 70 = 181-184us from AP2, I need to be aware that the measurement accuracy is +/- 200us, which means that the actual Access Delay at AP1 could be anywhere between 0 and 250us, while the actual Access Delay at AP2 could be anywhere between 0 and 384us, which means that it is quite possible that the actual Access Delay at AP2 is less than the actual Access Delay at AP1. This is useless to me to make a roaming determination. I have no information as to how accurate the measurements are at AP1 and AP2, and in fact if the two APs are different models or from different manufacturers, the comparison would be meaningless.~(No suggested remedy provided by commenter.)~Discuss with TG. Change accuraccy to +/- 100usec. It is still a reasonable number since this is an average over 200 individual measurement. Systematic errors can be taken out by design/test.~R~O~~03/31/2006 00:00:00~~~~~~V 830445~"Chaplin"~" in LB 83"~~~~11k-D4.0~A.4~100~8~TR~Incorrect PICs version referenced.~Should be, "PICS proforma—IEEE Std 802.11, 2006 Edition"~The referred annex heading is not part of .11k draft. The text is there just as a reference to the editor when the .11k draft is merged with 802.11. The correct version of 802.11 will get referenced at that time.~R~O~~03/31/2006 00:00:00~~~~~~V 830446~"Chaplin"~" in LB 83"~~~~11k-D4.0~11.11.5~76~28~TR~"A STA that has indicated an incapable response to a requesting STA may discard further requests of the same type from that STA." How does the responding STA know that the requesting STA got the incapable response? There is no acknowledegement. I see a case where the responding STA sends back an incapable response to the first request, the requesting STA doesn't get it, the requesting STA keeps requesting the measurement, and the responding STA is silent forever....~I suggest that the STA continues to send incapable responses to all subsequent requests.~The measurement incapable response is unicast from the device that received the measurement request and is subject to ACK rules. The measurement incapable response will be resent till an ACK is received.~R~O~~03/31/2006 00:00:00~~~~~~V 830451~"Chaplin"~" in LB 83"~~~~11k-D4.0~11.11.5~75~14~TR~"Broadcast addressed"~"Wildcard addressed"~Although broadcast address and wildcard BSSID are defined as all 1s they are not synonymous. Refer to section 7.1.3.3.3 in 802.11ma Draft 7.0 for more clarifications.~R~O~~03/31/2006 00:00:00~~~~~~V 830452~"Chaplin"~" in LB 83"~~~~11k-D4.0~11.11.8.8~83~10~TR~"broadcast address"~"wildcard address"~Although broadcast address and wildcard BSSID are defined as all 1s they are not synonymous. Refer to section 7.1.3.3.3 in 802.11ma Draft 7.0 for more clarifications.~R~O~~03/31/2006 00:00:00~~~~~~V 830453~"Chaplin"~" in LB 83"~~~~11k-D4.0~11.14.1~85~31~TR~"broadcast address"~"wildcard address"~The text is correct as is. 11ma rev-D7.0 indicates that the correct terms are "broadcast address", "wildcard BSSID", and "wildcard SSID".~R~O~~03/31/2006 00:00:00~~~~~~V 830506~"HSU"~" in LB 83"~~~~11k-D4.0~3.120A~2~24~TR~The RCPI as '… measured at the antenna connector' implies a wideband measurement, including the frequency bands out of interest. (In general the channel selection filter is not implemented in the RF)~recommend to remove the text of 'antenna connector' and change the RCPI definition to '… measured within the frequency band of interest'. This allows the measurement to be performed in intermediate frequency or baseband frequency.~CURRENT COMMENT RESPONSE: The 'antenna connector' is a virtual point of reference for the RCPI measurement. Power may be measured anywhere in the receive chain, but must be referred to the power at the antenna connector for RCPI within the specified bandwidth. Please see current definition for antenna connector in D6.0. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The intent is to specify "at the antenna connector" to remove any ambiguity like what is prevalent with RSSI~R~O~~03/31/2006 00:00:00~~~~~~V 830507~"HSU"~" in LB 83"~~~~11k-D4.0~3.121A~2~28~TR~The RSNI as '… measured at the antenna connector' implies a wideband measurement, including the frequency bands out of interest. (In general the channel selection filter is not implemented in the RF)~recommend to remove the text of 'antenna connector' and change the RSNI definition to '… measured within the frequency band of interest'. This allows the measurement to be performed in intermediate frequency or baseband frequency.~CURRENT COMMENT RESPONSE: The 'antenna connector' is a virtual point of reference for the RCPI measurement. Power may be measured anywhere in the receive chain, but must be referred to the power at the antenna connector for RCPI within the specified bandwidth. Please see current definition for antenna connector in D6.0. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The intent is to specify "at the antenna connector" to remove any ambiguity like what is prevalent with RSSI~R~O~~03/31/2006 00:00:00~~~~~~V 830664~"Palm"~" in LB 83"~~~~11k-D4.0~7.3.2.21.10~23~11~TR~The term "QoS" is used in the clause heading and text without clear relationship to QoS as specified in 802.11e.~Rename or clearly define relationship to 802.11e~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: QoS, QAP, QSTA, QBSS definitions and the use of these terms in .11k draft will all be part of one 802.11 document eventually. Why is there a specific need to refer/relate to .11e?~R~O~~03/31/2006 00:00:00~~~~~~V 830665~"Palm"~" in LB 83"~~~~11k-D4.0~7.3.2.21.10~23~16~TR~Does "triggered QoS" refer to starting a SP in U-APSD part of QoS?~Don't user the word trigger~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: trigggered' refers to the report being generted due to a trigger. ~R~O~~03/31/2006 00:00:00~~~~~~V 830668~"Raissinia"~" in LB 83"~~~~11k-D4.0~A.4.13~~~TR~"As commented by a large number of other commenters, implementation of Noise Histogram is extremely complex. Furthermore, the following outcomer does not justify its inclusion in the specification- Straw Poll: Should the noise histogram measurement become an optional measurement in 11k? Result: Yes 3, No 9, Abstain 2. In August, it has barely received 75% and is quite appropriate to say that conesnsus has not been reached to include the mechanism."~Remove noise histogram.~See motion in Jacksonville minutes (692/r3 page 9 bullet 10). TGk deemed Noise Histogram an important measure and to keep it Mandatory.~R~O~~03/31/2006 00:00:00~~~~~~V 830669~"Soomro"~" in LB 83"~~~~11k-D4.0~A.4.13~114~~TR~The use of Noise Histogram measurement is not clear. It requires PHY to have complex circuitry to measure and report the results.~Remove the measurement from the standard, or at least, make it optional to be implemented.~CURRENT COMMENT RESPONSE: For decades communication theory has recognized the important effect of noise on error rate and communication efficiency. Measuring noise is a fundamental radio measurement and TGk has discussed the need for a noise measurement dozens of times since the initial TG meeting. The Noise Histogram measurement is the only noise measurement in the TGk draft and should remain mandatory. The histogram nature of the measurement has been discussed many times and it is clear that it is a straightforward, effective quantitative measurement of the underlying noise perceived by a STA on an operating 802.11 channel. Since 802.11 signals mask underlying noise levels, measuring noise on an operating 802.11 channel is discontinuous and the available noise measurement time is decreased as channel utilization increases. Noise measurement on an operating channel will naturally store periodic samples of noise power collected on the idle channel. Using the stored samples to calculate a noise histogram is a trivial task. The TG has discussed and understands the limited complexity involved with the noise histogram measurement and has reaffirmed the decision to keep the measurement as mandatory as noted in minutes for 3 different meetings. In JUL05 in San Francisco, TGk voted to remove Noise Histogram; vote failed 3/18/6, as documented in 05/694r6. In NOV05 in Vancouver, TGk again discussed the Noise Histogram and took a straw poll to make the Noise Histogram optional in the PICS; the straw poll failed 3/9/2 as documented in 05/1177r4. And again in MAY06 in Jacksonville, TGk wanted to take an official vote on the same issue of Noise Histogram as optional in the PICS. A vote to decline all LB86 comments suggesting to make the Noise Histogram optional in the PICS passed 9/1/2. These many discussions and deliberations together strongly reaffirm the need for the Noise Histogram measurement in the TGk draft.---ORIGINAL COMMENT RESPONSE: See motion in Jacksonville minutes (692/r3 page 9 bullet 10). TGk deemed Noise Histogram an important measure and to keep it Mandatory.~R~O~~03/31/2006 00:00:00~~~~~~V 830670~"Kandala"~" in LB 83"~~~~11k-D4.0~General~~~ER~A large number of changes have been made to the draft but the draft has been recirculated only for two weeks. Given that most of us have day jobs not nearly enough time has been made available to the volunteers of the WG who review the draft.~Extend the ballot for another 15 days. If the ballot has closed by the time this comment is read, please restart another ballot.~There will be one or several recircs that are not in conjunction with other big Letter Ballots. ~R~O~~03/31/2006 00:00:00~~~~~~V 830671~"Kandala"~" in LB 83"~~~~11k-D4.0~0~i~~ER~It is very interesting that in the top part of the Introduction, the draft says, "This introduction is not part of IEEE Std 802.11-2005, IEEE Standard for Information Technology – Telecommunications and Information Exchange Between Systems – LAN/MAN Specific Requirements – Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications." , yet it goes on to describe what 11k is.~Move the introduction of "11k" to Overview or even better to description of services (clause 5).~The Introduction was requested by multiple comments to introduce the amendment. The introduction will be removed when the TGk draft goes to Sponsor Ballot.~R~O~~03/31/2006 00:00:00~~~~~~V 830672~"Kandala"~" in LB 83"~~~~11k-D4.0~0~i~~ER~There will not be a 11k once the standard is rolled into the base standard. The draft should not refer to something that will not exist.~Remove all references to 11k in introduction. Use appropriate descriptor to refer to this amendment (RRM does appear to be appropriate)~The Introduction was requested by multiple comments to introduce the amendment. The introduction will be removed when the TGk draft goes to Sponsor Ballot.~R~O~~03/31/2006 00:00:00~~~~~~V 830673~"Kandala"~" in LB 83"~~~~11k-D4.0~0~ii~5~ER~The standard should avoid making abstract statements such as, "Radio Resource Measurement (RRM) is a key enabler to the next generation of WLANs"~Rephrase appropriately~The Introduction was requested by multiple comments to introduce the amendment. The introduction will be removed when the TGk draft goes to Sponsor Ballot.~R~O~~03/31/2006 00:00:00~~~~~~V 830674~"Kandala"~" in LB 83"~~~~11k-D4.0~0~iii~20~ER~It sounds like a marketing pamphlet and not something that is written in a technical standard, especially the first page~Delete up to the description of each of the requests. Then move the descriptions to clause 5 and 11. ~The Introduction was requested by multiple comments to introduce the amendment. The introduction will be removed when the TGk draft goes to Sponsor Ballot.~R~O~~03/31/2006 00:00:00~~~~~~V 830675~"Kandala"~" in LB 83"~~~~11k-D4.0~3.7A~1~25~TR~"What if the security mode is ""open"". Shouldn’t the definition be independent of the security mode? Also, the word ""target"" appears to be redundant."~"Define it as: An AP is reachable by a STA if authentication is completed by the AP and the STA."~The suggested definition for AP Reachability actually indicates that a STA has authenticated to the AP. The intent of AP Reachability is to indicate the capability to authenticate with the AP.~R~O~~03/31/2006 00:00:00~~~~~~V 830676~"Kandala"~" in LB 83"~~~~11k-D4.0~3.15A~1~~TR~"Refer to comment ID 267: The resolution does not appear to have any relation to the comment made. Further, it is not clear what and where the paragraph has been added and how this would be construed as accepting the comment. Does nor consider case where more than 1 antenna is used to receive frame. This will become pertinent when 11n is approved."~"Reconsider the comment for resolution. Describe how ANPI is to be calculated if multiple receive antenna's are used. Average, Minimum Maximum, or is RCPI defined as a vector. "~The paragraph addition referred to in the resolution of LB78 #267 iis the addition to clause 11.11.8.4 Noise Histogram Report. ANPI and RCPI are not vectors. The commentor is urged to read clause 11.11.8.4.~R~O~~03/31/2006 00:00:00~~~~~~V 830679~"Kandala"~" in LB 83"~~~~11k-D4.0~4~2~41~ER~Would it be possible to reabbreviate "RSNI" - I tend to be reading it as RSN Information Element. To make things worse there is also RSNI Information Element.~Please consider an alternat acronym~The acronym "RSNI" is modeled on the ancient term RSSI which has been used successfully in the draft for many years. These are both indicators for the RF receiver.~R~O~~03/31/2006 00:00:00~~~~~~V 830680~"Kandala"~" in LB 83"~~~~11k-D4.0~7.2.3.8~7~3~TR~The phrase, "with dot11RadioMeasurementEnabled set to true." is confusing (2 occurences).~Rephrase it a, "when dot11RadioMeasurementEnabled is set to 0" or "if dot11RadionMeasurementEnabled is set to 0".~Replace "with" by "if", twice. True and false are left as true and false in accordance with other tables in this section.~R~O~~03/31/2006 00:00:00~~~~~~V 830689~"Kandala"~" in LB 83"~~~~11k-D4.0~11.11.8.3~81~14~TR~The definition of channel load is very close to channel utilization in the QBSS Load element. Harmonize the two (from what I understand you can make changes to QBSS load element as you have rightly done elsewhere).~As suggested.~It is inappropriate to change the length of the existing IE which is fixed in .11ma or to add additional fields to the existing IE that has the fixed fields in .11ma. It violates backward compatible requirement. It will cause parsing error for a non-802.11k device (but it is an .11e device) when this device receives QBSS Load from a .11k/11e AP. Changes to QBSS Load referred to in the comment has been removed.~R~O~~03/31/2006 00:00:00~~~~~~V 830690~"Kandala"~" in LB 83"~~~~11k-D4.0~A.4.13~~~TR~"As commented by a large number of other commenters, implementation of Noise Histogram is extremely complex and enough justification has never been provided. Furthermore, the following is not justification enough to include it: (Straw Poll: Should the noise histogram measurement become an optional measurement in 11k? Result: Yes 3, No 9, Abstain 2.) EVen in such an August company, it has barely received 75% and is quite appropriate to say that conesnsus has not been reached to include this mechanism"~Remove noise histogram.~See motion in Jacksonville minutes (692/r3 page 9 bullet 10). TGk deemed Noise Histogram an important measure and to keep it Mandatory.~R~O~~03/31/2006 00:00:00~~~~~~V 830691~"Kandala"~" in LB 83"~~~~11k-D4.0~General~45~2~TR~It appears that the resolution of comment 1543 agrees with the comment (that antenna ID is not needed for various measurements). It is almost as if it is strenghtening the reasoning for its removal, yet the ultimate disposition is to decline the comment.~Justify the contradiction or remove the field.~TGk has added several quantitative receiver measurements whose value depends directly on the antenna gain and orientation. RCPI, RSNI, and ANPI reported values vary depending on which antenna is used for reception. As a consequence, whenever either RSNI, ANPI or RSNI are reported in a measurment, the measurement must include the antenna ID to qualify the reported measurement. No change to the text is needed.~R~O~~03/31/2006 00:00:00~~~~~~V 830694~"Kandala"~" in LB 83"~~~~11k-D4.0~7.3.2.22.7~32~1~TR~It appears the only one antenna can be identified through the Antenna ID, yet in the beacon report frame format, the field appears to indicate the identify of multiple Antennas. Clarify how this can be done in the draft.~As suggested.~Antenna ID value of 255 indicates the frame was received on multiple antennas~R~O~~03/31/2006 00:00:00~~~~~~V 830696~"Kandala"~" in LB 83"~~~~11k-D4.0~7.3.2.36~41~12~TR~Reachability should not be based on the preauthentication frame but on "authentication" frame (or "probe response" frame if active scanning is allowed). This draft should not assume that some form of security is always going to be used. While we may desire that, this is beyond the scope of this PAR.~Change all instances of preauthentication to a more suitable frame.~"The definition was drafted by Aboba and Walker and IS related to pre-authentication. Per discussion on 07/19/06 at with Bernard Aboba the definition should reamin the same. Need a joint meeting with 11r since AP reacability is the same in both tasks decline. "~R~O~~03/31/2006 00:00:00~~~~~~V 830697~"Kandala"~" in LB 83"~~~~11k-D4.0~7.3.2.39~29~3~ER~Remove the extra column in figure 112~As suggested.~Invalid Reference - I think this should be P45 L3, which is the proper location from 7.3.2.39, but the figure looks correct. Comment seems misplaced or at least does not have a correct reference and description. Figure 112 does not seem to have an extra column either in draft 3.7 or 4.0. Commenter is invited to provide correct reference in next recirc.~R~O~~03/31/2006 00:00:00~~~~~~V 830714~"Yee"~" in LB 83"~~~~11k-D4.0~3.31A, 3.120A~2~23~TR~The definition of RCPI here is a bit circular and is inconsistent with the RCPI description in clause 15.4.8.5 and elsewhere. Where as by its name and by most description RCPI is meant for measuring the received power per frame per channel, by pegging the measurement point at the "antenna connector" it is implied that the measurement can be wideband and not just the channel of interest. Measuring at the antenna connector as defined here implies a particular implementation and is vague. I don't know what 'logical measurement point of reference" means, and the definition tells me nothing about if only the channel of interest is seen at the antenna connector. "Antenna connector" appears 14 times in the draft, but it does not appear in the context of RCPI after this section. Therefore, it is clearly not a necessary concept for describing RCPI.~Remove the reference to "antenna connector" and make the definition less circular. For instance, change the definition of RCPI to "An indication of the total power (signal, noise, and interference) of a received IEEE 802.11 frame in the channel of interest."~0~R~O~~03/31/2006 00:00:00~~~~~~V 830715~"Yee"~" in LB 83"~~~~11k-D4.0~3.121A~2~26~TR~Similar to in the RCPI definition, the description of RSNI uses the vague concept of "antenna connector". It is not clear whether measurement is only taken in the channel of interest.~Remove reference to "antenna connector" in the description of RSNI everywhere in this document.~Same as 506~R~O~~03/31/2006 00:00:00~~~~~~V 830716~"Yee"~" in LB 83"~~~~11k-D4.0~7.3.2.21.10~36~~TR~My comment 963 for LB78 questioned the need for the QoS Metric. It was decliend for the reason of "It is not clear why error or delay statistics do not give useful information about the channel condition being experienced by a measuring QSTA". I still contend that the amount of measurement required to support this feature is too application specific and excessive and out of scope. Further, TS/TID performance can be determined by much more than channel condition (e.g., power save, burstiness of traffic which can not be easily compared) so the measurement results may be misleading. ~"Remove the measurement. This relates to both 21 & 22."~"06/1003r0 and 04/1202r2 are references for keeping the QoS Metric in. There was a vote in the San Diego meeting on declining the comment and the vote was 6/3/2. The motion to decline did not pass with 75%. The reason for not declining the comment was it is excessive. There was a great deal of debate on this comment in SD."~R~O~~03/31/2006 00:00:00~~~~~~V 830719~"Engwer"~" in LB 83"~~~~11k-D4.0~7.3.2.27~~~TR~Many clauses (the first instance is in clause 7.3.2.27) use the term "packet". This term has no meaning in the context of 802.11. Only the terms MSDU and MPDU are within the scope of 802.11. This is a technical comment because every instance of the use of the word "packet" must be checked to determine whether the correct replacement term is "MSDU" or "MPDU". The selection of which term to use makes a substantial difference.~Clarify the precise meaning intended by replacing every instance of the word "packet" with either "MSDU" or "MPDU".~Replace "packet" with "frame" in all places in the TGk draft, except in 2 places, P39L15 and P44L11 where "packet" is changed to "MPDU".~R~O~~03/31/2006 00:00:00~~~~~~V 860002~"Nitsche"~" in LB 86"~~~~11k-D5.0~Annex A~106~RRM7~TR~The measurement of a Noise Histogram adds significant complexity to the PHY. There is still no evidence that this complexity is justified for improving network performance.~This is a repeat comment from LB83. Make the Noise Histogram optional in the PICS, similar as in 11h. I am not willing to accept the comment rejection based on a vote with just 12 from 514 voters. Would it be possible to bring up this vote again in the working group?~"CURRENT COMMENT RESPONSE: For decades communication theory has recognized the important effect of noise on error rate and communication efficiency. Measuring noise is a fundamental radio measurement and TGk has discussed the need for a noise measurement dozens of times since the initial TG meeting. The Noise Histogram measurement is the only noise measurement in the TGk draft and should remain mandatory. The histogram nature of the measurement has been discussed many times and it is clear that it is a straightforward, effective quantitative measurement of the underlying noise perceived by a STA on an operating 802.11 channel. Since 802.11 signals mask underlying noise levels, measuring noise on an operating 802.11 channel is discontinuous and the available noise measurement time is decreased as channel utilization increases. Noise measurement on an operating channel will naturally store periodic samples of noise power collected on the idle channel. Using the stored samples to calculate a noise histogram is a trivial task. The TG has discussed and understands the limited complexity involved with the noise histogram measurement and has reaffirmed the decision to keep the measurement as mandatory as noted in minutes for 3 different meetings. In JUL05 in San Francisco, TGk voted to remove Noise Histogram; vote failed 3/18/6, as documented in 05/694r6. In NOV05 in Vancouver, TGk again discussed the Noise Histogram and took a straw poll to make the Noise Histogram optional in the PICS; the straw poll failed 3/9/2 as documented in 05/1177r4. And again in MAY06 in Jacksonville, TGk wanted to take an official vote on the same issue of Noise Histogram as optional in the PICS. A vote to decline all LB86 comments suggesting to make the Noise Histogram optional in the PICS passed 9/1/2. These many discussions and deliberations together strongly reaffirm the need for the Noise Histogram measurement in the TGk draft.---ORIGINAL COMMENT RESPONSE: PG - This relates to removing Noise Histogram. The TG voted on this topic again (motion-4 10/10/1). The motion failed (change Noise Histogram PICS category from mandatory to optional)"~R~O~~09/16/2006 00:00:00~~~~~~V 860003~"Nitsche"~" in LB 86"~~~~11k-D5.0~General~~~TR~There are several inconsistencies between the approved LB83 comment resolution and the actual draft 5.0, e.g. where the editor was not able to implement the change.~These inconsistencies should be resolved during LB83 comment resolution.~CURRENT COMMENT RESPONSE: New editor has resolved all inconsistencies.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: The inconsistencies are in what the editor could or couldn't do in LB83. The TGk editor has changed and the new editor will resolve the unresolved LB83 comments. They have been added back into LB86 comments and are being addressed in LB86.~A~O~~09/16/2006 00:00:00~~~~~~V 860056~"Stephens"~" in LB 86"~~~~11k-D5.0~7.2.3.9~~~TR~"""In an improperly formed Request information element, a STA may ignore the first information element requested that is not ordered properly and all subsequent information elements requested."" You can't say this. The specification only needs to define how compliant implementations interact. If we started specifying how to respond to all possible non-compliant implementations we'd never finish. A manufacturer is well advised to program a device defensively, or it becomes a candidate for a Darwin award. We don't need to point this out in this document."~Remove the quoted sentence.~CURRENT COMMENT RESPONSE: We are addressing this comment in LB90 (comment#19).---ORIGINAL COMMENT RESPONSE: The commenter refers to base 802.11 text unchanged by TGk. As well, this is text that has been in 802.11 for many years and is (so far) found to be acceptable by the 11ma review process. The commenter is urged to take their comment to TGma.~R~O~~09/16/2006 00:00:00~~~~~~V 860057~"Stephens"~" in LB 86"~~~~11k-D5.0~7.3.1.20~~~TR~"that a STA is allowed to transmit on the current channel...". I'm not sure that "current channel" is well enough defined. I'd recommend relating it to the MLME SAP primitives and their parameters.~Replace "current channel" with something more related to defined interfaces.~P2L25, replace "current channel" by "Current Channel"; P10L16, replace "indicate the maximum … as permitted." by "indicate the upper limit, in units of dBm, on the transmit power to be used by a transmitting STA on its operating channel, as permitted"; P11L7 replace "used by … the current channel" by "used by the transmitting STA on its operating channel. The maximum tolerance for the value reported in Max Transmit Power field shall be ± 5 dB. The value of the Max Transmit Power field shall be less than or equal to the value of the Max Regulatory Power field for the operating channel of the transmitting STA"; P41L16 replace "Current Channel" by "Channel Number"; P50L14, replace "the current" by "its operating"; P70L1 (last table row) replace "the current" by "its operating"; P76L9 replace "the current" by "its operating"; P76L10 replace "the current" by "their operating"; P76L14, replace "the current" by "its operating"~R~O~~09/16/2006 00:00:00~~~~~~V 860074~"Stephens"~" in LB 86"~~~~11k-D5.0~11.11.8.4~~~TR~"NAV is equal to one...". NAV is a time value. This is not what was intended.~I think it intended to say if the NAVBUSY value is equal to the duration of the Measurement report.~CURRENT COMMENT RESPONSE: P84L25: This has been changed in D6.0 (P92L43) to read: "If either the NAV is non-zero, or if there is frame transmission, or if there is frame reception throughout the entire measurement duration period" .---ORIGINAL COMMENT RESPONSE: The referenced sentence is clumsy and not clear. It has been clarified. See resolution in CID46.~R~O~~09/16/2006 00:00:00~~~~~~V 860117~"Chaplin"~" in LB 86"~~~~11k-D5.0~0~~~TR~"QSTA" is no longer an acceptable term in IEEE 802.11ma. You need to change all 57 instances of "QSTA" into something like "QoS Enabled STA"~Change all 57 instances of "QSTA" into an acceptable term.~CURRENT COMMENT RESPONSE: We implemented the suggested remedy and incorrectly marked the commment as counter instead of accepted.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: Globally change QSTA and QAP to QoS STA and QoS AP respectively~A~O~~09/16/2006 00:00:00~~~~~~V 860118~"Chaplin"~" in LB 86"~~~~11k-D5.0~0~~~TR~"QAP" is no longer an acceptable term in IEEE 802.11ma. You need to change all 19 instances of "QAP" into something like "QoS Enabled AP"~Change all 19 instances of "QAP" into an acceptable term.~CURRENT COMMENT RESPONSE: We implemented the suggested remedy and incorrectly marked the commment as counter instead of accepted.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: Globally change QSTA and QAP to QoS STA and QoS AP respectively~A~O~~09/16/2006 00:00:00~~~~~~V 860125~"Chaplin"~" in LB 86"~~~~11k-D5.0~Annex A~109~~TR~LB83 Comment 139 Resolution was not incorporated into Draft 5.0~Incorporate LB139 Comment 98 Resolution into draft~CURRENT COMMENT RESPONSE: They are no longer always required and are only required when the conditions in the status column are true … added conditions when RRM20 is mandatory: (CF2 AND NOT CF12 AND CF13)---ORIGINAL COMMENT RESPONSE: PG LB 83 Comment - BSS Load elements should be optional. Although the LB83 Comment Resolution for 139 Editor Status reads "can't do", the resolution is incorporated in Draft5.0. See Page 109 RRM20.1~R~O~~09/16/2006 00:00:00~~~~~~V 860126~"Chaplin"~" in LB 86"~~~~11k-D5.0~7.3.2.37~~~TR~LB83 Comment 187 Resolution was not incorporated into Draft 5.0~Incorporate LB187 Comment 98 Resolution into draft~First, we acknowledge the incorrectly documented comment resolution. Comment 187 was not resolved, yet incorrectly documented as resolved with resolution "Accept". Therefore the draft is correct and the comment should not be incorporated. Second, we reconsider the comment. The definition of Reachability is tracking the 11r definition. That is a bit of a moving target, so 11k is inserting their best estimate, with fine-tuning to be deferred to the 11r LB. The definition was drafted by Aboba and Walker and IS related to pre-authentication. Per discussion on 07/19/06 at with Bernard Aboba the definition should remain the same.~R~O~~09/16/2006 00:00:00~~~~~~V 860139~"Chaplin"~" in LB 86"~~~~11k-D5.0~7.3.2.37~41~4~ER~"only provide less security than the current association, as defined by clause 8 or the information is not"~"only provide less security than the current association, as defined by clause 8, or the information is not"~Accepted in principle but superseded by the comment resolution to comment 60. ~R~O~~09/16/2006 00:00:00~~~~~~V 860154~"Marshall"~" in LB 86"~~~~11k-D5.0~General~~~TR~This amendment will need to be based on 11ma D8.0 before going to Sponsor Ballot, not D7.0.~All occurrances of "QSTA", "QAP", "QBSS", and "QIBSS" were changed in 11ma D8.0 to remove the "Q". Similar changes need to be made to this amendment throughout.~CURRENT COMMENT RESPONSE: We implemented the suggested remedy and incorrectly marked the commment as counter instead of accepted.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: Globally change QSTA and QAP to QoS STA and QoS AP respectively~A~O~~09/16/2006 00:00:00~~~~~~V 860159~"Marshall"~" in LB 86"~~~~11k-D5.0~7.3.2.39~43~19~TR~(Comment #79) The intent of comment #79 in previous letter ballot was not addressed. The calculation given here is overly complex, and requiring all STAs to be able to calculate logarithms base 1.018826 is totally unreasonable. Merely changing "0.081/10" to "0.0081" doesn't address the complexity of the calculation.~Simplify the calculation of this measurement. Consider adding a Table with the range of values for each value of the Access Delay, instead of giving a formula.~CURRENT COMMENT RESPONSE: -----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: The commenter seems to misunderstand the role of the standard. The noted expression on P43L19 is a matematical representation of the scaling requirement for AP Service Load. The scaling description does not require or imply any implementation. The expression defines the range of measured delay values which is represented by the integer values in this IE. The mathematical representation is equivalent to a tabular representation which the commenter suggests. The use of a mathematical representation for the scaling does not imply or require any particular implementation. The statement of the scaling requirement is completely separate from the implementation which is chosen by the STA implementer. Moreover, 802.11 standards are loathe to specify implementations and do so only rarely. Specifying the scaling using a mathematical expression does not require any STA to be able to calculate logarithms base 1.018826. Though this is a possible implementation, the table lookup method is simpler and equivalent, as the commenter notes. Likewise, a tabular representation of the scaling requirement would not prevent any implementer from choosing to enable the STA to calculate logarithms base 1.018826.~A~O~~09/16/2006 00:00:00~~~~~~V 860162~"Marshall"~" in LB 86"~~~~11k-D5.0~7.3.2.44~47~22~TR~(Comment #79) The intent of comment #79 in previous letter ballot was not addressed. The calculation given here is overly complex, and requiring all STAs to be able to calculate logarithms base 1.018826 is totally unreasonable. Merely changing "0.081/10" to "0.0081" doesn't address the complexity of the calculation.~Simplify the calculation of this measurement. Consider adding a Table with the range of values for each value of the Access Delay, instead of giving a formula.~CURRENT COMMENT RESPONSE: -----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: ~A~O~~09/16/2006 00:00:00~~~~~~V 860205~"Engwer"~" in LB 86"~~~~11k-D5.0~General~~~ER~The term "QSTA" is deprecated (by 802.11ma D8.0)~Replace "QSTA" with "STA" throughout the 11k draft.~CURRENT COMMENT RESPONSE: Please review the Group's LB 83 Comment Resolution.---ORIGINAL COMMENT RESPONSE: Globally change QSTA and QAP to QoS STA and QoS AP respectively~R~O~~09/16/2006 00:00:00~~~~~~V 860206~"Engwer"~" in LB 86"~~~~11k-D5.0~General~~~ER~The term "QBSS" is deprecated (by 802.11ma D8.0)~Replace "QBSS" with "BSS" throughout the 11k draft.~CURRENT COMMENT RESPONSE: Please review the Group's LB 83 Comment Resolution.---ORIGINAL COMMENT RESPONSE: Globally change QBSS to QoS BSS~R~O~~09/16/2006 00:00:00~~~~~~V 860208~"Yee"~" in LB 86"~~~~11k-D5.0~7.3.2.21.10~23~~TR~My comment 716 for LB83 questioned the need for the QoS Metric. It was withdrawn so that the group can proceed to ballot without further delay. I am resubmitting it here for consideration by the TG again. My original comment made in LB78 was decliend for the reason of "It is not clear why error or delay statistics do not give useful information about the channel condition being experienced by a measuring QSTA". I still contend that the amount of measurement required to support this feature is too application specific and excessive and out of scope. Further, TS/TID performance can be determined by much more than channel condition (e.g., power save, burstiness of traffic which can not be easily compared) so the measurement results may be misleading. ~Remove the QoS Metric measurement.~Motion-6 in Melbourne failed to pass. Hence QoS Metrics will remain in the next draft of TGk.~R~O~~09/16/2006 00:00:00~~~~~~V 860211~"Kandala"~" in LB 86"~~~~11k-D5.0~General~~~TR~There are about 12 comments for which the editor is tasked to perform specific tasks. However, these tasks are not completed and thus the draft is not ready to be recirculated and the motion to recirculate the draft itself is out of order~"Complete the required tasks before sending the draft to another recirculation ballot "~CURRENT COMMENT RESPONSE: Editor has completed the carried forward comments in LB90.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: The inconsistencies are in what the editor could or couldn't do in LB83. The TGk editor has changed and the new editor will resolve the unresolved LB83 comments. They have been added back into LB86 comments and are being addressed in LB86.~A~O~~09/16/2006 00:00:00~~~~~~V 860213~"Kandala"~" in LB 86"~~~~11k-D5.0~7.2.3.1~5~12~TR~Two occurences of, "element shall be present only in a QAP"~Not clear if it should always be present or if it is optional. Clarify~Replace "only in a QAP and if " by "in a QAP where". Ditto, in p5, line 12, table8, order 26, replace "only in a QAP" by "in a QAP"~R~O~~09/16/2006 00:00:00~~~~~~V 860216~"Kandala"~" in LB 86"~~~~11k-D5.0~General~~~TR~I am confused by the response to commen ID 691 which was made in response to 1543 in the previous LB. Either antenna ID is needed or not needed. A boiler plate response to the comment is not very helpful.~Please review the issue and provide an appropriate resolution.~Relates to ... antenna ID is not needed for various measurements). TGk has added several quantitative receiver measurements whose value depends directly on the antenna gain and orientation. RCPI, RSNI, and ANPI reported values vary depending on which antenna is used for reception. As a consequence, whenever either RSNI, ANPI or RSNI are reported in a measurment, the measurement must include the antenna ID to qualify the reported measurement. As the commenter points out for Noise Histogram Measurements for long durations the Antenna ID may indicate multiple antennas. For shorter measurement durations for Noise Histogram the Antenna ID will specify an individual antenna and in these cases the reported power values may be adjusted to consider the antenna gain. No change to the text is needed.~R~O~~09/16/2006 00:00:00~~~~~~V 860217~"Kandala"~" in LB 86"~~~~11k-D5.0~7.3.2.37~~~TR~"Resolution to 696 is strange - Mr X crafted the definition and thinks that it is correct, so we cant change is not a technical reason :) If the definition is not changed, please address the issue raised in the comment"~As suggested~CURRENT COMMENT RESPONSE: AP Reachability is defined in context of a STA roaming. See current 11r draft to understand the context. Pre-authentication is still a valid mechanism whether or not security is used.---ORIGINAL COMMENT RESPONSE: The chosen definition of Reachability is the best estimate from 11r. (Per a discussion on 07/19/06 with Bernard Aboba, the definition should remain the same.) Any fine-tuning should be deferred to the 11r LB. ~R~O~~09/16/2006 00:00:00~~~~~~V 860218~"Kandala"~" in LB 86"~~~~11k-D5.0~A.4.13~105~~TR~Comment 690. Please provide adequate justification. I have checked the quoted 692r3 and all I see is a motion result. While I am glad that the group is reaching consensus in deeming such a complex mechanism as necessary. The onus on the group is still to provide adquate justification.~"Please revisit the resolution and at least provide a technical reason instead of saying ""we think it is needed"". "~"CURRENT COMMENT RESPONSE: For decades communication theory has recognized the important effect of noise on error rate and communication efficiency. Measuring noise is a fundamental radio measurement and TGk has discussed the need for a noise measurement dozens of times since the initial TG meeting. The Noise Histogram measurement is the only noise measurement in the TGk draft and should remain mandatory. The histogram nature of the measurement has been discussed many times and it is clear that it is a straightforward, effective quantitative measurement of the underlying noise perceived by a STA on an operating 802.11 channel. Since 802.11 signals mask underlying noise levels, measuring noise on an operating 802.11 channel is discontinuous and the available noise measurement time is decreased as channel utilization increases. Noise measurement on an operating channel will naturally store periodic samples of noise power collected on the idle channel. Using the stored samples to calculate a noise histogram is a trivial task. The TG has discussed and understands the limited complexity involved with the noise histogram measurement and has reaffirmed the decision to keep the measurement as mandatory as noted in minutes for 3 different meetings. In JUL05 in San Francisco, TGk voted to remove Noise Histogram; vote failed 3/18/6, as documented in 05/694r6. In NOV05 in Vancouver, TGk again discussed the Noise Histogram and took a straw poll to make the Noise Histogram optional in the PICS; the straw poll failed 3/9/2 as documented in 05/1177r4. And again in MAY06 in Jacksonville, TGk wanted to take an official vote on the same issue of Noise Histogram as optional in the PICS. A vote to decline all LB86 comments suggesting to make the Noise Histogram optional in the PICS passed 9/1/2. These many discussions and deliberations together strongly reaffirm the need for the Noise Histogram measurement in the TGk draft.---ORIGINAL COMMENT RESPONSE: PG - Invalid reference pointing to D4.0. Changed from A4.13 to A4.117 This relates to removing Noise Histogram"~R~O~~09/16/2006 00:00:00~~~~~~V 860219~"Raissinia"~" in LB 86"~~~~11k-D5.0~A.4.13~105~~TR~Please provide adequate justification for this requirement. I reviewed document 692r3 and noticed that there was a motion taken with more people wanting to keep the requirements. Although that is an interesting information but group needs to provide an adequate technical reason(s) for such a complex requirement. ~"Please provide a technical reason instead of just voting on the issue. "~"CURRENT COMMENT RESPONSE: For decades communication theory has recognized the important effect of noise on error rate and communication efficiency. Measuring noise is a fundamental radio measurement and TGk has discussed the need for a noise measurement dozens of times since the initial TG meeting. The Noise Histogram measurement is the only noise measurement in the TGk draft and should remain mandatory. The histogram nature of the measurement has been discussed many times and it is clear that it is a straightforward, effective quantitative measurement of the underlying noise perceived by a STA on an operating 802.11 channel. Since 802.11 signals mask underlying noise levels, measuring noise on an operating 802.11 channel is discontinuous and the available noise measurement time is decreased as channel utilization increases. Noise measurement on an operating channel will naturally store periodic samples of noise power collected on the idle channel. Using the stored samples to calculate a noise histogram is a trivial task. The TG has discussed and understands the limited complexity involved with the noise histogram measurement and has reaffirmed the decision to keep the measurement as mandatory as noted in minutes for 3 different meetings. In JUL05 in San Francisco, TGk voted to remove Noise Histogram; vote failed 3/18/6, as documented in 05/694r6. In NOV05 in Vancouver, TGk again discussed the Noise Histogram and took a straw poll to make the Noise Histogram optional in the PICS; the straw poll failed 3/9/2 as documented in 05/1177r4. And again in MAY06 in Jacksonville, TGk wanted to take an official vote on the same issue of Noise Histogram as optional in the PICS. A vote to decline all LB86 comments suggesting to make the Noise Histogram optional in the PICS passed 9/1/2. These many discussions and deliberations together strongly reaffirm the need for the Noise Histogram measurement in the TGk draft.---ORIGINAL COMMENT RESPONSE: PG - Invalid reference pointing to D4.0. Changed from A4.13 to A4.117 This relates to removing Noise Histogram"~R~O~~09/16/2006 00:00:00~~~~~~V 860235~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~general~~~TR~While I appreciate and understand the goal of getting a draft amendment out for measurement quickly. The recient statement that recirc comments that have incorrect references brings up the issue of moving too fast and actually taking longer to get an amendment out to the base standard. I beleive that technincally the rules for recirc *may* have been followed, the spirit of recirc has not been followed. The fact that there are so many incorrect references is evidence of this. Additionally voting enmasse on an Excel spreadsheet (as opposed to using the minutes and motions embedded in specific presentations) as offical changes to the amendment does not lead to a better draft amendment. In fact it leads to a worse and disorganized one. The fact that the draft went out for vote and there were any accepted resultions with a comment in the excel spreadsheet that says "Editor can't do" means that you are sending out an amendement to the 1500+ members of the 802.11 working group who have to collectively spend time on this amendment when it is clear that it was not ready to be voted on as an amendment. This is in violation of the working groups procedures and collectivly wates 100's if not 1000's of man hours.~Stop wasting everyones time.~CURRENT COMMENT RESPONSE: This is not a comment, so TG prefers to mark this accepted. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.-----Editor included in draft 11k-D7.0--------ORIGINAL COMMENT RESPONSE: This is not a comment.~A~O~~09/16/2006 00:00:00~~~~~~V 860236~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~3.86a~2~22~TR~ "neighbor AP: Any AP that is a potential transition candidate." This is not the defintion of Neighbor AP since Neighbor AP's in the Neighbor List can only be validated. (How many times must we go over this?)~Counter from commnet 188 lb83 "The intent of the definition in the draft was to use common english interpretation of the word 'neighbor'. Any AP within the radio range of a STA is considered a neighbor AP. Modified "Validated Neighbor AP" to "Validated AP" as suggested." This was not the intent of neighbor AP. Rogue AP's are not supposed to be on the list. In the current definition a rogue can be a neighbor~CURRENT COMMENT RESPONSE: In D5.0 and in D7.0, Neighbor AP is a general term and is any potential roaming candidate, including rogues. The Neighbor List contains only validated APs, excluding rogues. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Neighbor list (as contained in the Neighbor Report) includes only validated neighbor APs. Rogue APs are not part of the neighbor list contained in the Neighbor Report. A 'neighbor AP' is a more general term and may include rogue APs.~R~O~~09/16/2006 00:00:00~~~~~~V 860237~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~7.3.2.22.9~4~35~TR~Since E911 service has determined that the location of the AP is good enough for WLAN, what is the justification of having latitude and longitude transmitted over the air?~Leave in the means of getting location within the device (MIB element). Take out the transmission of location in management frame, or specifically determine how it can be encrypted such that a person with a sniffer can not retrive this information in a life and death situation (i.e. that location only goes to who it is intended to go to). Optionally take out location completely and let other 802, IETF or ITU bodies handle it.~"CURRENT COMMENT RESPONSE: E911 requirements, municipal mesh, and location-based services for WLANs are the reasons for including location information. STA's that cannot do this just have to provide the input that they cannot provide location. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The same comment was made in LB83 (comment 195 on clause 7.3.2.21.9) . E911 regulations for WLAN are not defined in US or other regulatory domains to our knowledge. E911 has been assigned to TGv and Tgu as ongoing issues for futher resolution. TGk voted to keep LCI in draft in Jacksonville. 'Who', 'what', 'where' and 'when' are attributes of measurements and other information."~R~O~~09/16/2006 00:00:00~~~~~~V 860238~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~11.11.8.3~83~1~TR~"Channel busy time shall be the time during which either the physical carrier sense or NAV indicated channel busy, as defined in 9.2.1." may be misleading in certain situations where virutal carrier sense is used to hold traffic off (for reasons that may, or may not be, outside the scope of the current specification or future specifications that may need to interoperate with the current one). Additionally the requestor may get two different results for a request in the same BSS, from tow STA's that are using the different tecniques. Right now it's impossible to tell which is which.~Provide a bit in the report that indicate whether physical or virual carrier sense was used in the calculation. Optionally, and less desirable, would be to have the station indicate what it supports as part of some sort of interrogation procedure. As a side note I do not believe it is appropriate to mandate one or the other in the request, but a sugguestion may be worth considering. However, for a given HW architecture usually one or the other will be easier. The response of the task group in the last lb was "Irrespective of how (physical or virtual) the channel is determined to be busy, as far as the device is concerned the channel is busy. Hence this definition of channel busy time is correct. It does not matter if the NAV was used to artificially render the channel busy. If the commentor has a better resolution, the commenter is urged to propose a complete normative text for the suggested change." This is not true. It is only the perception of a device as to whether it believes the channel is busy or not, not whether it is actually busy. Please update this draft amendment such that any legacy device at any point in time (i.e. not today, but possibly months or years from now g or n devices may not be able to hear new technoloies, or this MAC may be "ported" to a completely different phy/baseband). Thinnk about the future and the past as examples PBCC, or 802.11g vs 802.11b in a hidden node situation where the protection mechanisms may not be working completely.~CURRENT COMMENT RESPONSE: Any future PHY and any future TGk enhancements will be handled by a new PAR that may amend the TGk draft, if required. No new comment resolution, old one is sufficient. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: PG - Invalid reference changed from P86 L1 to P83 L1. Both Channel Load and Channel Utilization use the same mechanism to determine when the channel is busy. Both NAV and Physical carrier sense(PCS) must be used together to determine if the channel is busy. The boolean OR of the NAV busy and the PCS busy determines when the channel is busy. One cannot choose either NAV or PCS. Choosing only NAV or only PCS will not indicate a busy channel. No text change is needed. The commenter is invited to present a paper at the Dallas meeting explaning the motivation and benefit of changing this measurement as the commenter suggests. ~R~O~~09/16/2006 00:00:00~~~~~~V 860239~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~11.1.3.2.1~73~17~TR~"Furthermore, a STA receiving a probe request with a DS Parameter Set element containing a Current Channel field value that is not the same as the value of dot11CurrentChannelNumber shall not respond with a probe response. " Why is this behavior mandatory?~This breaks alorithms that are currently deployed! Give the site administrator the option of returning the returning the response if the channel is not correct via configuration option, or remove the whole thing, including adding the DS parameter set to the probe request, or any part thereof. In the LB83 comment form it states "Marty's reccomendation will undo the this fix which was intentionally incorporated 3 years ago. Furthermore, a basic assumption of half-duplex radio communication is that a single channel is used. STAs should not expect nor should they rely on replies being transmitted on channels other than the current channel. " First off I know of implementations on the market that use the fact that there is channel overlap in sending probe requests. The fist part of this response does has not considered the fact that you are breaking algorithms that depend upon this. The second part of the response should have been specified in either the 1997 or the 1999 standard, but were not. Giving an upgrade path for site admins is what I am asking for. The config option can be defaulted to the behavior specified in draft amendment. Don't make people throw their old equipment away.~CURRENT COMMENT RESPONSE: Please review the Group's LB 83 Comment Resolution. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Per resolution of LB78 #1441: "TG straw polls on this issue shows a majority decision to mandate the behaviour inidicated in this clause for STA with dot11RadioMeasurementEnabled=true." The justification for this feature is found in 03/952r1. The commenter's reccomendation will undo the this fix which was intentionally incorporated 3 years ago. Furthermore, a basic assumption of half-duplex radio communication is that a single channel is used. STAs should not expect nor should they rely on replies being transmitted on channels other than the current channel. Official Vote in San Diego ws taken in July 06 to confirm decision to decline this comment. Finally, no objections from any attendee representing the chip manufacturers have emerged regarding this fix. It is perceived as a benefit by most voters who have examined the issue. ~R~O~~09/16/2006 00:00:00~~~~~~V 860240~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~11.1.3.2.1~76~7~TR~"Requested information elements, any of the requested elements which appear as individual items in the ordering list of Table 15 shall appear both in their individual ordered location as specified in Table 15 and in the ordered location reserved for the list of requested elements, where the requested elements appear in the same order as requested in the Request information element" Since these responses are of TLV, I do not understand the ordering restriction. I am concerned that including a statement like this will lead to implementations that do not parse the TLV (as has happened with the supported rate field during when TGg changed the maximum number of fields. This is why the ERP field has been separated. Additionally this cost 1 LB revolution if I remember correctly).~Remove the strictly ordered TLV restriction.~CURRENT COMMENT RESPONSE: Please review the Group's LB 86 Comment Resolution. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: PG - Invalid reference changed from P76 L7 to P74 L7. The text which the commenter is suggesting to change was drafted in accordance with the 11ma baseline requirement for ordered IEs in management frames. See the last paragraph of clause 7.2.3. This requiremen applies to beacons, probe responses and all management frames. TGk will not modify this fundamental requirement for ordered IEs.~R~O~~09/16/2006 00:00:00~~~~~~V 860241~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~11.11.5~78~2~TR~"A STA may measure one or more channels itself or a STA may request peer STAs in the same BSS to measure one or more channels." A STA in a BSS does not have the kind of relationship (or really any relationship for that matter) to give it the authority to proxy measurement reports. This is dangerous from a security standpoint since in a BSS it does not have a trust relationship with another STA within a BSS~Remove this ability~CURRENT COMMENT RESPONSE: The term "peer" was dropped from D5.0 to D6.0. The primary intended mechanism is between APs and STAs in a BSS and to a lesser extent between STAs in an IBSS. In a BSS, there is no way for peer STAs to exchange management frames. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Table 85 describes conditions under which a STA (in a BSS) can have a peer STA perform 11k measurements (when they have a DLS setup between them). Modify the first sentence in 11.11.5 to read as follows: " A STA may perform radio measurements on one or more channels itself or STA may request STAs in the same BSS to perform the measurements."~R~O~~09/16/2006 00:00:00~~~~~~V 860242~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~7,11~~~TR~The way this draft amendment is written a STA that has associated but has not (RSNA) authenticated can retrieve information from the (I)BSS. A STA participating in an RSNA that can not 802.1x authenticate should get nothing from the (I)BSS..~Change Clauses 7 and 11 to enable this behavior.~CURRENT COMMENT RESPONSE: Furthermore, TGw defines the protection of management frames which prevents unauthorized access to radio measurement information. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Comment needs to be more explicit. It is unclear what the commenter is suggesting. The commenter is invited to provide a normative text document at the Dallas meeting in NOV06 to describe his suggested change.~R~O~~09/16/2006 00:00:00~~~~~~V 860243~"Lefkowitz"~" in LB 86"~~~~11k-D5.0~11.12~~~TR~Since the neighbor report is used to facilitate a better and possibly faster roaming candidate selection, and since disassociation (implicit or explicit) is part of the roaming process, and that the disassociation is bi-directional, allow the AP to send the neighbor report before dissassociation. IT should also be noted that TGk's "formal" vote as aluded to in comment sheet for letter ballot 73, was out of order, since, according to the minutes from FLA '04 the text was not on the server for 4 hours prior to the vote. In this light the chair has the perogative to just put the text back in with editorial discression due to the possibliity of the some text changing. Furthermore it was determined by the chair, vice chair secretary and task chair that the March '04 vote was out of order in March 05~Put disassocate imminet back into the specification~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: In the San Diego meeting, Jul 07, there was another vote on Disassociate Imminent with the invitation to all of the WG to participate. That vote was 7/19/4 to put it back in the TGk draft. The vote rejected putting Disassociate Imminent back in the text.~R~O~~09/16/2006 00:00:00~~~~~~V 900019~"Stephens"~" in LB 90"~~~~11k-D6.0~7.2.3.9~~~TR~"""In an improperly formed Request information element, a STA may ignore the first information element requested that is not ordered properly and all subsequent information elements requested."" You can't say this. The specification only needs to define how compliant implementations interact. If we started specifying how to respond to all possible non-compliant implementations we'd never finish. A manufacturer is well advised to program a device defensively, or it becomes a candidate for a Darwin award. We don't need to point this out in this document."~"Remove the quoted sentence. Note, this is comment 56 from LB86. Additional comment: If TGk is modifying text in a subclause, it is entirely reasonable to fix up other issues in that subclause. The response that this text comes from the baseline is no reason to hold it sacrosanct and does not satisfy me."~The commenter refers to base 802.11 text unchanged by TGk. The statement that the STA "may ignore" an information element or a request occurs several times in the 11ma draft. There are 20 occurences of "ignore" used in this way. TGk will not endeavor to make a uniform set of changes within 11ma to improve this commonly used term. In addition, this is text that has been in 802.11 for many years and is (sofar) found to be acceptable by the 11ma review process. "ignore" is used to indicate the special circumstances under which an exception may be made to a requirement stated elsewhere. The commenter is encouraged to take his comment to TGmb. A vote was taken by TGk to accept this resolution and the result is: 8/0/2.~R~O~~11/16/2006 00:00:00~~~~~~V 900077~"Watanabe"~" in LB 90"~~~~11k-D6.0~7.3.2.39~50~20~TR~BSS load is changed to the BSS Average Access Delay. In order to have more precise information, AC(access category) level information is needed besides average access delay. Since AC average access delay IE is defined in D6.0, it is better to focus on the "inaccuarte info" instead of "general average access delay".~AC Station Count and AC Channel Utilization can be used instead of BSS average access delay.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Discussion with the commenter has revealed a misunderstanding. BSS Average Access Delay does not replace QBSSLoad (now BSSLoad in 11ma), but supplements it.~R~O~~11/16/2006 00:00:00~~~~~~V 900078~"Watanabe"~" in LB 90"~~~~11k-D6.0~7.2.3.1~9~32~TR~Related to 7.3.2.30 change, the number of stations for each AC traffic shows the constitution of current BSS load more precisely. ~Add "AC Station Count" and "AC Channel Utilization" information element specifying the number of STAs currently associated with the QBSS corresponding to the requested access categories (AC). ~CURRENT COMMENT RESPONSE: The current 11v draft does this. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: This comment does not relate to changed text nor does it relate to a carried-forward no vote comment. This is an invalid comment.~R~O~~11/16/2006 00:00:00~~~~~~V 900079~"Watanabe"~" in LB 90"~~~~11k-D6.0~7.3.2.22.8~40~11~TR~Related to 7.3.2.39 change, the number of stations for each AC traffic shall be included for non-AP STAs to learn about the AC contribution in this QBSS, which facilitates the QoS-aware AP (re)selection. ~Change "dot11STAStatisticsStationCount" to "dot11STAStatisticsACStationCount"~CURRENT COMMENT RESPONSE: The current 11v work is considering providing access category level information for Sta count. NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: This comment does not relate to changed text nor does it relate to a carried-forward no vote comment. This is an invalid comment.~R~O~~11/16/2006 00:00:00~~~~~~V 900080~"Watanabe"~" in LB 90"~~~~11k-D6.0~7.3.2.22.8~40~12~TR~Related to 7.3.2.39 change, the channel utilization for each AC traffic shall be included for non-AP STAs to learn about the relative channel occupancy in this QBSS.~Change "dot11STAStatisticsChannelUtilization" to "dot11STAStatisticsACChannelUtilization"~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: This comment does not relate to changed text nor does it relate to a carried-forward no vote comment. This is an invalid comment.~R~O~~11/16/2006 00:00:00~~~~~~V 900081~"Watanabe"~" in LB 90"~~~~11k-D6.0~10.3.2.2.2~61~14~TR~Related to 7.3.2.39 change, the number of stations for each AC traffic shall be included in the BSSDescription table for non-AP STAs to learn about the AC contribution in this QBSS.~Insert a new row describing "AC Station Count" at the end of the BSSDescription table.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: This comment does not relate to changed text nor does it relate to a carried-forward no vote comment. This is an invalid comment.~R~O~~11/16/2006 00:00:00~~~~~~V 900082~"Watanabe"~" in LB 90"~~~~11k-D6.0~10.3.2.2.2~61~15~TR~Related to 7.3.2.39 change, the channel utilization for each AC traffic shall be included the BSSDescription table for non-AP STAs to learn about the relative channel occupancy in this QBSS.~Insert a new row describing "AC Channel Utilization" at the end of the BSSDescription table.~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: This comment does not relate to changed text nor does it relate to a carried-forward no vote comment. This is an invalid comment.~R~O~~11/16/2006 00:00:00~~~~~~V 900083~"Amann"~" in LB 90"~~~~11k-D6.0~7.3.2.43~52~35~TR~(NOTE: This comment was originally CID #298 on letter ballot #78) There is a BSS load element that is defined by this standard. How does this differ from the QBSS load element, and why are we not modifying [the QBSS load] element to include additional information rather than creating another element?~"Original Recommended Change: Modify the existing QBSS load element to incorporate the required information from the BSS load element, or vice versa. Response to Resolution:The resolution for this comment stated that this resolution had been accepted, but then pointed to revision 0 of the comment resolution spreadsheet, which contained no additional information stating how the comment was resolved. In examining the text it appears that neither of the courses of action recommended was taken (i.e. merging the information within these two information elements into a single information element), so I do not believe this comment has been adequately satisfied. In order to rectify this situation I have created a submission, document 11-06-1821-00-000k-bss-load-element-consolidation, that includes editing instructions which would satisfy the recommended change as originally stated. This comment could be resolved by adopting the relevant editing instructions contained in the latest revision of document 11-06-1821 into the draft."~The comment was accepted and then withdrawn by TGk because the TG could not modify a term because there is already legacy meaning. It is inappropriate to change the length of the existing IE which is fixed in .11ma or to add additional fields to the existing IE that has the fixed fields in .11ma. It violates backward compatible requirement. It will cause parsing error for a non-802.11k device (but it is an .11e device) when this device receives QBSS Load from a .11k/11e AP. Mover: Kwak, Seconder: Gray. Motion passes 3/1/0.~R~O~~11/16/2006 00:00:00~~~~~~V 900084~"Amann"~" in LB 90"~~~~11k-D6.0~7.2.3.9a~12~29~TR~(NOTE: This comment was originally CID #300 on letter ballot #78) The definition of the Measurement Pilot frame appears to be very similar to that of a Probe response or Beacon. Why are we defining yet another frame type?~"Remove the definition of Measurement Pilot Frame, and add the desired fields to the Probe Response or Beacon frames. Response to Resolution: After examining draft 6.0 I am still not satisfied with the resolution as I still don't see the technical justification for adding more management overhead to an already congested medium. As a result, I am continuing to carry this comment forward. Given that the above resolution was based on an early draft please consider the following recommended change as a new resolution that would satisfy this comment: Remove clauses 7.2.3.9a, 10.3.33, 11.13, and any other references to ""Measurement Pilot"" in order to make the text self consistent with the removal of said concept."~New text has been added to P97L3-12 clarifying the purpose and justification for Measurement Pilot. Mover: Kwak, Second: Gray 3/1/0~R~O~~11/16/2006 00:00:00~~~~~~V 900085~"Palm"~" in LB 90"~~~~11k-D6.0~5.2.7~25~16~TR~The term "QoS" is used in the clause heading and text (and other places) without clear relationship to the QoS Functionality nor QoS Service as specified in 802.11e now part of 802.11ma. ~Choose a different word than "QoS" since this measurement is unrelated to the QoS functionality~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The term "QoS Metrics" is directly related to quality of service facility in 11ma (Clause 3.1.20). QoS Metrics is a specific measurement to quantify the performance of a TS or TC which is a QoS facility that was added by TGe. ~R~O~~11/16/2006 00:00:00~~~~~~V 900086~"Engwer"~" in LB 90"~~~~11k-D6.0~7.2.3.1~9~37~TR~The first paragraph has been modified to remove some text, which is shown in strikethru form. The second sentence of the paragraph has effectively been moved to the corresponding entry in Table 8. That is acceptable. However, the third, fourth and fifth sentences, which refer to the FH Parameters and FH Pattern Table elements have been removed without providing equivalent text. This results in a change to the normative specifications and requirements of the base standard (802.11ma). The affected text is not covered in any other clause in the base standard (802.11ma) and hence the removal of that material results in a complete loss of the cited requirements.~"Restore the sentences related to the FH Parameters and FH Pattern Table elements. Alternatively, the third sentence could be removed since the option condition is already covered in the corresponding entries in Table 8. The fourth sentence could be added to both of the corresponding entries in Table 8. The fifth sentence could be removed since the presence of these elements in the probe response is cited in clause 7.2.3.9."~Specification style recommendations from the 802.11ma editor removed the referenced information. Section 7 shall only contain frame format descriptions. The stricken sentences are primarily informative and do not belong in Section 7. Clause 9.8.2.1 is a more appropriate place for the only normative sentence in the stricken clause. Editor shall move the requirement sentence located at P8 L48 to 802.11ma D9.0 P285L25. ~R~O~~11/16/2006 00:00:00~~~~~~V 900127~"Marshall"~" in LB 90"~~~~11k-D6.0~7.3.1.11~14~10~TR~Code 4 for Category Values doesn't match the Assigned Number spreadsheet~Change to code 5, matching the allocation from ANA~Editor to verify assigned numbers spreadsheet and correct accordingly. Number 5 may not be correct either.~R~O~~11/16/2006 00:00:00~~~~~~V 900156~"Marshall"~" in LB 90"~~~~11k-D6.0~7.3.2.44~54~36~TR~Followup on my comments in previous letter ballots. This calculation is too complex for real implementations. Most likely that it will be a pre-compiled table. And its unlikely that every implementation will pre-compile the same values for the break points.~Add a table in this clause with the values that you compute.~See revised scaling in comments #42 and 46.~R~O~~11/16/2006 00:00:00~~~~~~V 900188~"Chaplin"~" in LB 90"~~~~11k-D6.0~7.3.2.39~51~~TR~What exactly is the difference between "20,000uS <= Access Delay" and "Service unable to access channel"? Since this is for DCF or EDCA frames, and the description for category 254 is "continuous carrier sense mechanism deferral", category 254 is now essentially equivalent to category 253.~Revert back to the old description in Draft 5.0~253 indicates at least one frame transmission and 254 indicates no frame transmissions. P51L17 add new sentence "The values 0-253 indicate Average Access Delay when one or more frames are transmitted during the measurement window."~R~O~~11/16/2006 00:00:00~~~~~~V 900189~"Chaplin"~" in LB 90"~~~~11k-D6.0~7.3.2.44~55~~TR~What exactly is the difference between "20,000uS <= Access Delay" and "Service unable to access channel"? Since this is for DCF or EDCA frames, and the description for category 254 is "continuous carrier sense mechanism deferral", category 254 is now essentially equivalent to category 253.~Revert back to the old description in Draft 5.0~0~R~O~~11/16/2006 00:00:00~~~~~~V 900192~"Palm"~" in LB 90"~~~~11k-D6.0~5.2.7~25~15~TR~Several paragraphs in this subclause have a few words in the first line. But it is not clear what they represent.~If these are essential bullats, please have an intoductory sentence that describes the following bullets~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: The current draft has modified the text so that each bulleted item has a numbered subclause to describe in summary fashion the request/response pair, per IEEE style guideline.~R~O~~11/16/2006 00:00:00~~~~~~V 900195~"Yee"~" in LB 90"~~~~11k-D6.0~7.3.2.39~50~38~TR~The BSS average access delay as applied to QoS AP overlaps with the measurement defined in 7.3.2.44. The former is just an averaged value of the latter. A STA will know if the AP is QoS or non-QoS, therefore it is only meaningful to define this for non-QoS APs.~Define "BSS Average Access Delay" only for non-QoS AP and rename the IE in 7.3.2.44 "BSS Average AC Access Delay". Or, delete 7.3.2.44.~BSS Average Access Delay is available in both QoS and non-QoS Aps and is an average of all transmitted frames regardless of access category. BSS AC Access Delay is available only in QoS Aps and indicates the average access delay for frames in each of the four ACs. The overall average in the BSS Average Access Delay cannot be derived from the information in the BSS AC Access Delay. Both measurements are meaningful and unique.~R~O~~11/16/2006 00:00:00~~~~~~V 960002~"Engwer"~" in LB 96"~~~~11k-D7.0~7.2.3.5~10~8~TR~Clauses 7.2.3.5 and 7.2.3.7 show the addition of the RCPI and RSNI to the information included in the association response and reassociation response frames respectively. Presumbly these are the RCPI and RSNI measured on the corresponding association request and reassociation request frames received by the AP, but this is only described in clause 10 (10.3.6.4.2 and 10.3.7.4.2) whereas I would expect a description in cluase 11 of how these values are actually used, but I can't find where this is described in clause 11. Further, clauses 10.3.6.4.2 and 10.3.7.4.2 expose the RCPI and RSNI values from the AP STA's MLME to the AP STA's SME, presumably so that the AP SME can include those factors in it's decision to grant association/ reassociation or not. It makes sense that the values are exposed as part of the associate/ reaasociate .indication primitives, but the values are also returned to the MLME as part of the .response primitive. This in turn allows inclusion of the RCPI and RSNI values in the association response and reassociation response frames respectively. But again the purpose in doing so is never revealed. Is the information intended for the associating STA's MLME or SME? If the answer is the MLME then a description of how this MLME utilizes this information is needed in clause 11. If the intended receipient of the RCPI and RSNI values is the associating STA's SME then the RCPI and RSNI values should also be included in the associate and reassociate .confirm primitives.~"Clarify the purpose of including the RCPI and RSNI values in the association and reassociation response frames and align that with the appropriate changes to the associate and reassociate .response and .confirm primitives as needed. Suggestion: add text to clause 11 to define and describe the purpose and specific instances under which this information is used, and leave clause 10 unchanged in this regard. Or, remove the RCPI and RSNI values from the association response frames since no description is provided for how it is to be used. Or, add the RCPI and RSNI values to the association/ reassociation .confirm primitives which will push the corresponding responsibility for intrepreting and acting upon these values to the SME (on both ends of the link)."~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to add the RCPI and RSNI values to the association/ reassociation .confirm primitives which will push the corresponding responsibility for intrepreting and acting upon these values to the SME (on both ends of the link).~R~O~~02/13/2007 00:00:00~~~~~~V 960003~"Engwer"~" in LB 96"~~~~11k-D7.0~7.2.3.7~10~32~TR~Clauses 7.2.3.5 and 7.2.3.7 show the addition of the RCPI and RSNI to the information included in the association response and reassociation response frames respectively. Presumbly these are the RCPI and RSNI measured on the corresponding association request and reassociation request frames received by the AP, but this is only described in clause 10 (10.3.6.4.2 and 10.3.7.4.2) whereas I would expect a description in cluase 11 of how these values are actually used, but I can't find where this is described in clause 11. Further, clauses 10.3.6.4.2 and 10.3.7.4.2 expose the RCPI and RSNI values from the AP STA's MLME to the AP STA's SME, presumably so that the AP SME can include those factors in it's decision to grant association/ reassociation or not. It makes sense that the values are exposed as part of the associate/ reaasociate .indication primitives, but the values are also returned to the MLME as part of the .response primitive. This in turn allows inclusion of the RCPI and RSNI values in the association response and reassociation response frames respectively. But again the purpose in doing so is never revealed. Is the information intended for the associating STA's MLME or SME? If the answer is the MLME then a description of how this MLME utilizes this information is needed in clause 11. If the intended receipient of the RCPI and RSNI values is the associating STA's SME then the RCPI and RSNI values should also be included in the associate and reassociate .confirm primitives.~"Clarify the purpose of including the RCPI and RSNI values in the association and reassociation response frames and align that with the appropriate changes to the associate and reassociate .response and .confirm primitives as needed. Suggestion: add text to clause 11 to define and describe the purpose and specific instances under which this information is used, and leave clause 10 unchanged in this regard. Or, remove the RCPI and RSNI values from the association response frames since no description is provided for how it is to be used. Or, add the RCPI and RSNI values to the association/ reassociation .confirm primitives which will push the corresponding responsibility for intrepreting and acting upon these values to the SME (on both ends of the link)."~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to add the RCPI and RSNI values to the association/ reassociation .confirm primitives which will push the corresponding responsibility for intrepreting and acting upon these values to the SME (on both ends of the link).~R~O~~02/13/2007 00:00:00~~~~~~V 960004~"Engwer"~" in LB 96"~~~~11k-D7.0~10.3.6.4.2~64~1~TR~Clauses 7.2.3.5 and 7.2.3.7 show the addition of the RCPI and RSNI to the information included in the association response and reassociation response frames respectively. Presumbly these are the RCPI and RSNI measured on the corresponding association request and reassociation request frames received by the AP, but this is only described in clause 10 (10.3.6.4.2 and 10.3.7.4.2) whereas I would expect a description in cluase 11 of how these values are actually used, but I can't find where this is described in clause 11. Further, clauses 10.3.6.4.2 and 10.3.7.4.2 expose the RCPI and RSNI values from the AP STA's MLME to the AP STA's SME, presumably so that the AP SME can include those factors in it's decision to grant association/ reassociation or not. It makes sense that the values are exposed as part of the associate/ reaasociate .indication primitives, but the values are also returned to the MLME as part of the .response primitive. This in turn allows inclusion of the RCPI and RSNI values in the association response and reassociation response frames respectively. But again the purpose in doing so is never revealed. Is the information intended for the associating STA's MLME or SME? If the answer is the MLME then a description of how this MLME utilizes this information is needed in clause 11. If the intended receipient of the RCPI and RSNI values is the associating STA's SME then the RCPI and RSNI values should also be included in the associate and reassociate .confirm primitives.~"Clarify the purpose of including the RCPI and RSNI values in the association and reassociation response frames and align that with the appropriate changes to the associate and reassociate .response and .confirm primitives as needed. Suggestion: add text to clause 11 to define and describe the purpose and specific instances under which this information is used, and leave clause 10 unchanged in this regard. Or, remove the RCPI and RSNI values from the association response frames since no description is provided for how it is to be used. Or, add the RCPI and RSNI values to the association/ reassociation .confirm primitives which will push the corresponding responsibility for intrepreting and acting upon these values to the SME (on both ends of the link)."~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to add the RCPI and RSNI values to the association/ reassociation .confirm primitives which will push the corresponding responsibility for intrepreting and acting upon these values to the SME (on both ends of the link).~R~O~~02/13/2007 00:00:00~~~~~~V 960005~"Engwer"~" in LB 96"~~~~11k-D7.0~10.3.7.4.2~66~25~TR~Clauses 7.2.3.5 and 7.2.3.7 show the addition of the RCPI and RSNI to the information included in the association response and reassociation response frames respectively. Presumbly these are the RCPI and RSNI measured on the corresponding association request and reassociation request frames received by the AP, but this is only described in clause 10 (10.3.6.4.2 and 10.3.7.4.2) whereas I would expect a description in cluase 11 of how these values are actually used, but I can't find where this is described in clause 11. Further, clauses 10.3.6.4.2 and 10.3.7.4.2 expose the RCPI and RSNI values from the AP STA's MLME to the AP STA's SME, presumably so that the AP SME can include those factors in it's decision to grant association/ reassociation or not. It makes sense that the values are exposed as part of the associate/ reaasociate .indication primitives, but the values are also returned to the MLME as part of the .response primitive. This in turn allows inclusion of the RCPI and RSNI values in the association response and reassociation response frames respectively. But again the purpose in doing so is never revealed. Is the information intended for the associating STA's MLME or SME? If the answer is the MLME then a description of how this MLME utilizes this information is needed in clause 11. If the intended receipient of the RCPI and RSNI values is the associating STA's SME then the RCPI and RSNI values should also be included in the associate and reassociate .confirm primitives.~"Clarify the purpose of including the RCPI and RSNI values in the association and reassociation response frames and align that with the appropriate changes to the associate and reassociate .response and .confirm primitives as needed. Suggestion: add text to clause 11 to define and describe the purpose and specific instances under which this information is used, and leave clause 10 unchanged in this regard. Or, remove the RCPI and RSNI values from the association response frames since no description is provided for how it is to be used. Or, add the RCPI and RSNI values to the association/ reassociation .confirm primitives which will push the corresponding responsibility for intrepreting and acting upon these values to the SME (on both ends of the link)."~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to add the RCPI and RSNI values to the association/ reassociation .confirm primitives which will push the corresponding responsibility for intrepreting and acting upon these values to the SME (on both ends of the link).~R~O~~02/13/2007 00:00:00~~~~~~V 960006~"Engwer"~" in LB 96"~~~~11k-D7.0~10.3.2.2.2~61~30~TR~In the scan.confirm primitive parameters the RCPIMeasurement description states that the RCPI informaiton is derived from fields in the "RCPI element present in the received Probe Response", but there is no RCPI field defined in the Probe Response frame format. I suspect the intent was to provide the RCPIMeasurement value for the received ProbeResponse frame itself rather than a field within the frame.~As appropriate either add the RCPI field to the ProbeResponse frame format, or change "This parameter shall be present within a BSSDescription returned in an MLME-SCAN.confirm primitive when an RCPI element was present in the received Probe Response. Present only when the MIB attribute dot11RadioMeasurementEnabled is true." to "This parameter shall be present within a BSSDescription returned in an MLME-SCAN.confirm primitive when when the MIB attribute dot11RadioMeasurementEnabled is true.".~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot as follows: We will delete all new rows of the BSS description table except for power constraint and TPC Report. We will add a new row for requested information elements. We shall further modify the MLME-SCAN.request primitive to include a row for requested information elements. All new TGk information elements may be requested in a scan request and probe request as requested information elements.~R~O~~02/13/2007 00:00:00~~~~~~V 960014~"Chaplin"~" in LB 96"~~~~11k-D7.0~7.3.2.22~30~28~ER~"shall be"~"is"~CURRENT COMMENT RESPONSE: Reclassified to editorial by vote (motion 1) at March meeting (Orlando). Declined by motion 2 in vote in TG at meeting in Orlando.---ORIGINAL COMMENT RESPONSE: Reclassified to editorial by vote (motion 1) at March meeting (Orlando). Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960015~"Chaplin"~" in LB 96"~~~~11k-D7.0~7.3.2.22~30~46~ER~"shall be"~Delete "shall be"~CURRENT COMMENT RESPONSE: Reclassified to editorial by vote (motion 1) at March meeting (Orlando). Declined by motion 2 in vote in TG at meeting in Orlando.---ORIGINAL COMMENT RESPONSE: Reclassified to editorial by vote (motion 1) at March meeting (Orlando). Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960019~"Palm"~" in LB 96"~~~~11k-D7.0~5.2.7.10~20~8~TR~What is the meaning of "QoS-type" The usage of "QoS" in this sentence is not consistent with the QoS Facility nor QoS Service as specified in 802.11e now part of 802.11ma. ~Choose a different word than "QoS" since this measurement is unrelated to the QoS functionality~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Reference should be P6L8 for this comment. For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to change the last sentence to "This enables understanding instantaneous quality of a link."~R~O~~02/13/2007 00:00:00~~~~~~V 960020~"Palm"~" in LB 96"~~~~11k-D7.0~5.2.7.10~20~8~TR~Where are "requirements" defined or specified?~Delete sentence~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Reference should be P6L8 for this comment. For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to change the last sentence to "This enables understanding instantaneous quality of a link."~R~O~~02/13/2007 00:00:00~~~~~~V 960021~"Palm"~" in LB 96"~~~~11k-D7.0~5.2.7.10~20~7~ER~"is like an" is colloquial~Reword to specification quality language~CURRENT COMMENT RESPONSE: Reclassified to editorial by vote (motion 1) at March meeting (Orlando). P6L8. Change "is like" to "resembles". NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Reclassified to editorial by vote (motion 1) at March meeting (Orlando). P6L8. Change "is like" to "resembles". Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960022~"Palm"~" in LB 96"~~~~11k-D7.0~5.2.7.10~20~6~TR~What is an "RF ping"? ~Define or delete~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Reference should be P6L6 for this comment. For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to change "RF ping" to "ping sent on the wireless medium."~R~O~~02/13/2007 00:00:00~~~~~~V 960023~"Palm"~" in LB 96"~~~~11k-D7.0~5.2.7.10~20~7~TR~A measurement does enable "understaning"... It's just a measurement~Delete sentence~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Reference should be P6L7 for this comment. For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to replace "enables understanding" with "measurement indicates"~R~O~~02/13/2007 00:00:00~~~~~~V 960024~"Palm"~" in LB 96"~~~~11k-D7.0~5.2.7.11~29~13~TR~"transmit-side performance metrics" is not clear from the context. Why transmit and not received or unmodified?~Clarify~CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Reference should be P6L13 for this comment. This comment does not request any change to the text. This is intended to be a high level summary suitable for Clause 5. The details are provided in Clause 11.10.8.8. This measurement is defined to be implemented only on the transmit side of a stream. Transmit stream measurement does include receive side error detection indirectly by using the ACK/Retransmit mechanism. Consideration will be given in sponsor ballot to change P6L13 from "measured traffic stream" to "measured traffic stream including error detection using the ACK/Retransmit mechanism."~R~O~~02/13/2007 00:00:00~~~~~~V 960025~"Palm"~" in LB 96"~~~~11k-D7.0~11.10~99~35~TR~There are too many varied procedures here. It is unlikely that implementations will implement all of the procedures. Each of the supported procedures/reports should be seperately indicated and negotiated~Add a capabilities field so that each procedure/report may be seperately indicated and negotiated~"CURRENT COMMENT RESPONSE: NOTE: As of MAY07 this commenter is no longer an 802.11 voting member.---ORIGINAL COMMENT RESPONSE: Reference should be P85L35 for this comment. For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to this comment. "~R~O~~02/13/2007 00:00:00~~~~~~V 960034~"Stephens"~" in LB 96"~~~~11k-D7.0~General~~~TR~"I suspect no two manufacturers would interpret the structure of figure 85l in the same way. For example it shows three lattitude fields. The text clearly states that fields are little endian, but it does not state if the first of these three fields is the more or less significant. There is no need for this confusion."~Redraw 85l using the conventions elsewhere in this document - i.e. show each field in a single box and number the bits at its left and right edges. (you can use figure 85m as an example). Do not split fields across multiple boxes.~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to revise figure 85l.~R~O~~02/13/2007 00:00:00~~~~~~V 960035~"Stephens"~" in LB 96"~~~~11k-D7.0~10.3.11~~~TR~I'm confused. Figure 184 shows a radio measurement process that works perfectly happily without any MIB involvement. Having just waded through pages and pages of MIB variables that appear to represent the various reports, I'm now totally confused about what is communicated as a parameter to a primitive or what is communicated through the MIB.~"Add to Figure 184 MLME get and set primitives showing where the MIB variables defined in TGk are essentially used. Remove any MIB variables that are not essentially used. (i.e. I suspect that the MIB variables duplicate the TGk measurement primitive parameters, and I would like any duplication removed)."~CURRENT COMMENT RESPONSE: WITHDRAWN---ORIGINAL COMMENT RESPONSE: Commenter withdrew his commment.~R~O~~02/13/2007 00:00:00~~~~~~V 960036~"Marshall"~" in LB 96"~~~~11k-D7.0~General~~~TR~Numerous comments from D6.0 are marked in the comment resolution spreadsheet as "Accepted", but the changes were not made in D7.0. They are accompanied in the spreadsheet by a comment from the Editor, disagreeing with the accepted resolution. The Technical Editor is only one member of the Task Group, and only has one vote. This is NOT veto power. When 75% of the Task Group approve a resolution to a comment, the Technical Editor is directed to "incorporate all such resolutions therein into the TGk draft" (as stated in 11-07-0109-03-000k-tgk-london-minutes.doc); it doesn't say that the Technical Editor is to "consider incorporating the changes...".~Editor to incorporate all the approved resolutions to D6.0 comments into the draft.~For LB 96 purposes this comment is not a technical comment and was noted as invalid and affirmed by discussion and vote in TG meeting in Orlando. This comment only refers to editorial comments in LB90. The task group, in order to conserve meeting time, has accepted all editorial comments and assigned them to the editor for implementation. If the editor feels that the suggested remedy is incorrect, he will implement the accepted change, then use his editorial authority to edit the text back into an editorially correct format and so note in the editors notes column. In these cases, the suggested remedy may not be implemented or may be implemented differently. It remains the TG's responsibility to approve the draft, so edited, for Working Group submission.~R~O~~02/13/2007 00:00:00~~~~~~V 960037~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~i~10~ER~D6.0 comment #88 was marked as "Accepted" but not implemented in the draft.~Change to "Amendment 1"~Please read editor's note for comment 88 of LB90~R~O~~02/13/2007 00:00:00~~~~~~V 960038~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~i~15~ER~Copyright statement needs to be updated for 2007~Change year to "2007"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960039~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~iii~2~ER~Copyright statement needs to be updated for 2007~Change year to "2007"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960040~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~iii~99~ER~Copyright in page footer needs to be updated for 2007~Change year to "2007"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960041~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~iii~28~ER~missing text for "Errata" ~Add it, use 802.11ma D9.0 as model~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960042~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~iii~31~ER~missing text for "Interpretations"~Add it, use 802.11ma D9.0 as model~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960043~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~xi~4~ER~Figure numbers in the List of Figures don't match the figure numbers in the draft. In particular, they are shown here with upper case letters, but appear in the draft correctly with lower case letters (53A should be 53a, etc).~Make consistent~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960044~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~xiii~4~ER~Table numbers in the List of tables don't match the table numbers in the draft. In particular, they are shown here with upper case letters, but appear in the draft correctly with lower case letters (15A should be 15a, etc).~Make consistent~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960045~"Marshall"~" in LB 96"~~~~11k-D7.0~Boilerplate~xiii~34~ER~TableTable~Table~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960046~"Marshall"~" in LB 96"~~~~11k-D7.0~0~1~22~ER~D6.0 comment #92 marked as "Accepted" but not implemented indraft.~Change to "Amendment 1"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960047~"Marshall"~" in LB 96"~~~~11k-D7.0~0~1~28~ER~D6.0 comment #93 marked as "Accepted" but not implemented in draft~Change to 2007~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960048~"Marshall"~" in LB 96"~~~~11k-D7.0~0~1~51~ER~Copyright in page footer needs to be updated for 2007~Change year to "2007"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960049~"Marshall"~" in LB 96"~~~~11k-D7.0~3~2~3~ER~New definitions are inserted by their number, not alphabetically~Delete "in alphabetical order" from editing instructions~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960050~"Marshall"~" in LB 96"~~~~11k-D7.0~3~2~5~ER~Authorative Dictionary of IEEE Standard Terms is already being cited for all IEEE documents through the 2005 Style Guide. Reference to it in individual drafts is not needed.~Delete the paragraph starting at line 5~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960051~"Marshall"~" in LB 96"~~~~11k-D7.0~3~2~5~ER~This paragraph is not a definition, and does not belong in a clause of definitions~Delete the paragraph starting at line 5~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960052~"Marshall"~" in LB 96"~~~~11k-D7.0~3~2~8~ER~Numbering for definition of "access point reachability" incorrect~change to "3.4a"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960053~"Marshall"~" in LB 96"~~~~11k-D7.0~5.2.7~3~47~ER~D6.0 comment #102 marked as "Accepted" but not implemented in draft.~Change "specification" to "service" to better integrate this to the base standard~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960054~"Marshall"~" in LB 96"~~~~11k-D7.0~5.4~7~3~ER~Instead of inserting a sentence into an existing paragraph, this should be done as a "change" and show the new sentence using underlining.~Show the complete first paragraph of 5.4, and show the new sentence at the end with underlining.~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960055~"Marshall"~" in LB 96"~~~~11k-D7.0~7.1.3.1.2~8~12~ER~Table is 1, not 11.~Change to Table 1~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960056~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.1.4~13~36~ER~Normative statements don't belong in clause 7. ~Change "shall set" to "sets" and "shall be set" to "sets"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960057~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.1.11~13~44~ER~Changes to table 24 don't match the base standard. Reserved row currently says "4-126" and not "5-126". Also, "5" should not be both underlined and strikethrough.~Insert a row "4 Reserved -" and change the "56" to "46"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960058~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.21~18~26~ER~D6.0 comment #132 marked as "Accepted" but not implemented in draft~Underline the new text~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960059~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.21~19~40~ER~D6.0 comment #135 marked as "Accepted" but not implemented in draft~Underline "Measurement Use", and add an Editor's Note below Table 29 stating that the addition of a column can't be shown with underline/strikethrough.~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960060~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.22~31~11~ER~D6.0 comment #139 marked as "Accepted" but not implemented in draft~Underline "Measurement Use", and add an Editor's Note below Table 30 stating that the addition of a column can't be shown with underline/strikethrough.~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960061~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.22.8~40~22~ER~D6.0 comment #145 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960062~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.22.8~41~1~ER~D6.0 comment #146 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960063~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.22.8~41~19~ER~font wrong on this line~fix~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960064~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.22.8~41~23~ER~D6.0 comment #147 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960065~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.22.8~41~45~TR~Normative statements don't belong in clause 7. ~change "shall set" to "sets" ~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to this comment.~R~O~~02/13/2007 00:00:00~~~~~~V 960066~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.22.8~42~2~ER~D6.0 comment #148 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960067~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.22.10~43~33~ER~D6.0 comment #149 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960068~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.37~48~30~TR~Normative statements don't belong in clause 7. ~Change "shall have" to "have", and "shall be" to "are"~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to this comment.~R~O~~02/13/2007 00:00:00~~~~~~V 960069~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.37~48~44~ER~Normative statements don't belong in clause 7. ~Change "shall be" to "are"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960070~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.39~51~15~ER~Multiple lines here for entry "n" need to show the valid range for each.~Delete the lines "and so on where" and delete the line "where n is the integer value (step) used to incidate the measured Access Delay". Change "n:" at start of line 15 to "2<=n<=14". Similar change on line 24 and 32.~CURRENT COMMENT RESPONSE: Reclassified to editorial by the chair with the concurrence of unanimous consent of the TG at the March meeting (Orlando). Declined by motion 2 in vote in TG at meeting in Orlando. Consideration will be given in Sponsor Ballot to this comment. ---ORIGINAL COMMENT RESPONSE: Reclassified to editorial by the chair with the concurrence of unanimous consent of the TG at the March meeting (Orlando). Declined by unanimous consent at the Orlando meeting, 2007-03-13. Consideration will be given in Sponsor Ballot to this comment.~R~O~~02/13/2007 00:00:00~~~~~~V 960071~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.39~51~15~ER~Rows for "n" don't show the units of measurement~Add "us" for upper and lower bound on each~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960072~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.44~54~37~ER~bad cross reference~Should be "Figure 112n"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960073~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.44~54~48~ER~bad cross reference~Should be "Figure 112o"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960074~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.44~55~11~ER~Multiple lines here for entry "n" need to show the valid range for each.~Delete the lines "and so on where" and delete the line "where n is the integer value (step) used to incidate the measured Access Delay". Change "n:" at start of line 15 to "2<=n<=14". Similar change on line 20 and 28.~CURRENT COMMENT RESPONSE: Reclassified to editorial by the chair with the concurrence of unanimous consent of the TG at the March meeting (Orlando). Declined by motion 2 in vote in TG at meeting in Orlando. Consideration will be given in Sponsor Ballot to this comment. ---ORIGINAL COMMENT RESPONSE: Reclassified to editorial by the chair with the concurrence of unanimous consent of the TG at the March meeting (Orlando). Declined by motion 2 in vote in TG at meeting in Orlando. Consideration will be given in Sponsor Ballot to this comment. ~R~O~~02/13/2007 00:00:00~~~~~~V 960075~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.44~55~11~ER~Rows for "n" don't show the units of measurement~Add "us" for upper and lower bound on each~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960076~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.44~55~50~ER~Normative statements don't belong in clause 7. ~change "shall measure" to "measures"~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960077~"Marshall"~" in LB 96"~~~~11k-D7.0~7.3.2.44~56~2~TR~Normative statements don't belong in clause 7. ~change "shall be" to "is"~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to this comment.~R~O~~02/13/2007 00:00:00~~~~~~V 960078~"Marshall"~" in LB 96"~~~~11k-D7.0~10.3.6~62~29~ER~D6.0 comment #159 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960079~"Marshall"~" in LB 96"~~~~11k-D7.0~10.3.6.3.2~62~38~ER~Vendor Specific was deleted from the table~Would be acceptable to delete most of the table in 10.3.6.3.2, keeping only the new rows, and change the editing instruction to "Insert". But if the editing instruction is kept as "Change", then include the Vendor Specific line in the table as you did all the other existing lines. Similar change needed to 10.3.6.4.2, 10.3.7.3.2, 10.3.7.4.2, 10.3.12.1.2, 10.3.12.3.2, 10.3.14.1.2, 10.3.14.3.2.~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960080~"Marshall"~" in LB 96"~~~~11k-D7.0~10.3.12~69~28~ER~D6.0 comment #162 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960081~"Marshall"~" in LB 96"~~~~11k-D7.0~10.3.12.1.2~69~36~ER~Formatting is inconsistent with original document. Also, "Number of Repetitions" and "Measurement Category" is new text and should be underlined.~as in comment~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960082~"Marshall"~" in LB 96"~~~~11k-D7.0~10.3.12.3.2~70~32~ER~Formatting is inconsistent with original document. Also, "Number of Repetitions" and "Measurement Category" is new text and should be underlined.~as in comment~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960083~"Marshall"~" in LB 96"~~~~11k-D7.0~10.3.32.2.2~79~39~ER~Editor instruction is "insert", so no underlining needed~Remove underlining under the comma~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960084~"Marshall"~" in LB 96"~~~~11k-D7.0~11.8~84~15~ER~With the change in lines 16-19, the text on line 15 is no longer introducing a list.~Delete the text on line 15.~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960085~"Marshall"~" in LB 96"~~~~11k-D7.0~11.8~84~21~ER~New text should be underlined~Underline this paragraph of new text~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960086~"Marshall"~" in LB 96"~~~~11k-D7.0~17.2.3~105~33~ER~TableTable~Table~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960087~"Marshall"~" in LB 96"~~~~11k-D7.0~17.5.4.2~107~46~ER~TableTable~Table~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960088~"Marshall"~" in LB 96"~~~~11k-D7.0~18.3.5~110~45~ER~TableTable~Table~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960089~"Marshall"~" in LB 96"~~~~11k-D7.0~18.4.4.2~111~17~ER~TableTable~Table~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960090~"Marshall"~" in LB 96"~~~~11k-D7.0~19.2~112~45~ER~TableTable~Table~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960091~"Marshall"~" in LB 96"~~~~11k-D7.0~19.9.4.2~113~8~ER~TableTable~Table~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960092~"Marshall"~" in LB 96"~~~~11k-D7.0~19.9.4.3~113~18~ER~TableTable~Table~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960094~"Marshall"~" in LB 96"~~~~11k-D7.0~Annex D~169~38~ER~underlining of "dot11SMTbase7" is not correct. This is changing "dot11SMTbase6" to "dot11SMTbase7"~remove underlining of "dot11SMTbase", show "6" with strikethrough, keep "7" underlined~Declined by motion 2 in vote in TG at meeting in Orlando.~R~O~~02/13/2007 00:00:00~~~~~~V 960095~"Marshall"~" in LB 96"~~~~11k-D7.0~Annex D~172~24~TR~dot11Groups 35 is already in use, for dot11OFDMComplianceGroup2~Change this to dot11Groups 36, adjust the other dot11Groups (page 171 line 39, page 174 line 26, and page 174 line 49)~For LB96 purposes, this comment is invalid because it is not based on changed text from D6.0 and D7.0. However, consideration will be made in Sponsor Ballot to this comment.~R~O~~02/13/2007 00:00:00~~~~~~V 103005~"Stephens"~" in LB103"~~~~11k-D7.0~7.1.3.1.2~~~ER~The editing instruction and table caption disagree~Correct one of them~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment.~R~O~~05/05/2007 00:00:00~~~~~~V 103006~"Stephens"~" in LB103"~~~~11k-D7.0~7.3.2.21.10~~~ER~"""Transmit stream Measurement"" is a poor name. A transmit stream specifically refers to Data sent with TIDs in the range 8-15 - i.e. for which a TSID exists. Also note that the T in TID stands for traffic, not transmit. FYI: ""3.154 traffic stream (TS): A set of medium access control MAC) service data units (MSDUs) to be delivered subject to the quality of service (QoS) parameter values provided to the MAC in a particular traffic specification (TSPEC). TSs are meaningful only to MAC entities that support QoS within the MAC data service. These MAC entities determine the TSPEC applicable for delivery of MSDUs belonging to a particular TS using the TS identifier (TSID) value provided with those MSDUs at the MAC service access point (MAC_SAP)."""~Replace with a name that does not exclude TIDs 0-7.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment.~R~O~~05/05/2007 00:00:00~~~~~~V 103011~"Marshall"~" in LB103"~~~~11k-D7.0~General~~~TR~Numerous comments from D6.0 are marked in the comment resolution spreadsheet as "Accepted", but the changes were not made in D7.0. They are accompanied in the spreadsheet by a comment from the Editor, disagreeing with the accepted resolution. The Technical Editor is only one member of the Task Group, and only has one vote. This is NOT veto power. When 75% of the Task Group approve a resolution to a comment, the Technical Editor is directed to "incorporate all such resolutions therein into the TGk draft" (as stated in 11-07-0109-03-000k-tgk-london-minutes.doc); it doesn't say that the Technical Editor is to "consider incorporating the changes...".~Editor to incorporate all the approved resolutions to D6.0 comments into the draft.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103012~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~i~10~ER~D6.0 comment #88 was marked as "Accepted" but not implemented in the draft.~Change to "Amendment 1"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103013~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~i~15~ER~Copyright statement needs to be updated for 2007~Change year to "2007"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103014~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~iii~2~ER~Copyright statement needs to be updated for 2007~Change year to "2007"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103015~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~iii~99~ER~Copyright in page footer needs to be updated for 2007~Change year to "2007"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103016~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~iii~28~ER~missing text for "Errata" ~Add it, use 802.11ma D9.0 as model~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103017~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~iii~31~ER~missing text for "Interpretations"~Add it, use 802.11ma D9.0 as model~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103018~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~xi~4~ER~Figure numbers in the List of Figures don't match the figure numbers in the draft. In particular, they are shown here with upper case letters, but appear in the draft correctly with lower case letters (53A should be 53a, etc).~Make consistent~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103019~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~xiii~4~ER~Table numbers in the List of tables don't match the table numbers in the draft. In particular, they are shown here with upper case letters, but appear in the draft correctly with lower case letters (15A should be 15a, etc).~Make consistent~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103020~"Marshall"~" in LB103"~~~~11k-D7.0~Boilerplate~xiii~34~ER~TableTable~Table~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103021~"Marshall"~" in LB103"~~~~11k-D7.0~0~1~22~ER~D6.0 comment #92 marked as "Accepted" but not implemented indraft.~Change to "Amendment 1"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103022~"Marshall"~" in LB103"~~~~11k-D7.0~0~1~28~ER~D6.0 comment #93 marked as "Accepted" but not implemented in draft~Change to 2007~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103023~"Marshall"~" in LB103"~~~~11k-D7.0~0~1~51~ER~Copyright in page footer needs to be updated for 2007~Change year to "2007"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103024~"Marshall"~" in LB103"~~~~11k-D7.0~3~2~3~ER~New definitions are inserted by their number, not alphabetically~Delete "in alphabetical order" from editing instructions~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103025~"Marshall"~" in LB103"~~~~11k-D7.0~3~2~5~ER~Authorative Dictionary of IEEE Standard Terms is already being cited for all IEEE documents through the 2005 Style Guide. Reference to it in individual drafts is not needed.~Delete the paragraph starting at line 5~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103026~"Marshall"~" in LB103"~~~~11k-D7.0~3~2~5~ER~This paragraph is not a definition, and does not belong in a clause of definitions~Delete the paragraph starting at line 5~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103027~"Marshall"~" in LB103"~~~~11k-D7.0~3~2~8~ER~Numbering for definition of "access point reachability" incorrect~change to "3.4a"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103028~"Marshall"~" in LB103"~~~~11k-D7.0~5.2.7~3~47~TR~D6.0 comment #102 marked as "Accepted" but not implemented in draft.~Change "specification" to "service" to better integrate this to the base standard~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103029~"Marshall"~" in LB103"~~~~11k-D7.0~5.4~7~3~ER~Instead of inserting a sentence into an existing paragraph, this should be done as a "change" and show the new sentence using underlining.~Show the complete first paragraph of 5.4, and show the new sentence at the end with underlining.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103030~"Marshall"~" in LB103"~~~~11k-D7.0~7.1.3.1.2~8~12~ER~Table is 1, not 11.~Change to Table 1~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103031~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.1.4~13~36~TR~Normative statements don't belong in clause 7. ~Change "shall set" to "sets" and "shall be set" to "sets"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103032~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.1.11~13~44~TR~Changes to table 24 don't match the base standard. Reserved row currently says "4-126" and not "5-126". Also, "5" should not be both underlined and strikethrough.~Insert a row "4 Reserved -" and change the "56" to "46"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103033~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.21~18~26~ER~D6.0 comment #132 marked as "Accepted" but not implemented in draft~Underline the new text~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103034~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.21~19~40~ER~D6.0 comment #135 marked as "Accepted" but not implemented in draft~Underline "Measurement Use", and add an Editor's Note below Table 29 stating that the addition of a column can't be shown with underline/strikethrough.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103035~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.22~31~11~ER~D6.0 comment #139 marked as "Accepted" but not implemented in draft~Underline "Measurement Use", and add an Editor's Note below Table 30 stating that the addition of a column can't be shown with underline/strikethrough.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103036~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.22.8~40~22~ER~D6.0 comment #145 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103037~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.22.8~41~1~ER~D6.0 comment #146 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103038~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.22.8~41~19~ER~font wrong on this line~fix~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103039~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.22.8~41~23~ER~D6.0 comment #147 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103040~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.22.8~41~45~TR~Normative statements don't belong in clause 7. ~change "shall set" to "sets" ~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103041~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.22.8~42~2~ER~D6.0 comment #148 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103042~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.22.10~43~33~ER~D6.0 comment #149 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103043~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.37~48~30~TR~Normative statements don't belong in clause 7. ~Change "shall have" to "have", and "shall be" to "are"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103044~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.37~48~44~TR~Normative statements don't belong in clause 7. ~Change "shall be" to "are"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103045~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.39~51~15~TR~Multiple lines here for entry "n" need to show the valid range for each.~Delete the lines "and so on where" and delete the line "where n is the integer value (step) used to incidate the measured Access Delay". Change "n:" at start of line 15 to "2<=n<=14". Similar change on line 24 and 32.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103046~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.39~51~15~TR~Rows for "n" don't show the units of measurement~Add "us" for upper and lower bound on each~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103047~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.44~54~37~TR~bad cross reference~Should be "Figure 112n"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103048~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.44~54~48~TR~bad cross reference~Should be "Figure 112o"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103049~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.44~55~11~TR~Multiple lines here for entry "n" need to show the valid range for each.~Delete the lines "and so on where" and delete the line "where n is the integer value (step) used to incidate the measured Access Delay". Change "n:" at start of line 15 to "2<=n<=14". Similar change on line 20 and 28.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103050~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.44~55~11~TR~Rows for "n" don't show the units of measurement~Add "us" for upper and lower bound on each~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103051~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.44~55~50~TR~Normative statements don't belong in clause 7. ~change "shall measure" to "measures"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103052~"Marshall"~" in LB103"~~~~11k-D7.0~7.3.2.44~56~2~TR~Normative statements don't belong in clause 7. ~change "shall be" to "is"~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103053~"Marshall"~" in LB103"~~~~11k-D7.0~10.3.6~62~29~ER~D6.0 comment #159 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103054~"Marshall"~" in LB103"~~~~11k-D7.0~10.3.6.3.2~62~38~TR~Vendor Specific was deleted from the table~Would be acceptable to delete most of the table in 10.3.6.3.2, keeping only the new rows, and change the editing instruction to "Insert". But if the editing instruction is kept as "Change", then include the Vendor Specific line in the table as you did all the other existing lines. Similar change needed to 10.3.6.4.2, 10.3.7.3.2, 10.3.7.4.2, 10.3.12.1.2, 10.3.12.3.2, 10.3.14.1.2, 10.3.14.3.2.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103055~"Marshall"~" in LB103"~~~~11k-D7.0~10.3.12~69~28~ER~D6.0 comment #162 marked as "Accepted" but not implemented in draft~Make the change agreed by the TG~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103056~"Marshall"~" in LB103"~~~~11k-D7.0~10.3.12.1.2~69~36~ER~Formatting is inconsistent with original document. Also, "Number of Repetitions" and "Measurement Category" is new text and should be underlined.~as in comment~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103057~"Marshall"~" in LB103"~~~~11k-D7.0~10.3.12.3.2~70~32~ER~Formatting is inconsistent with original document. Also, "Number of Repetitions" and "Measurement Category" is new text and should be underlined.~as in comment~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103058~"Marshall"~" in LB103"~~~~11k-D7.0~10.3.32.2.2~79~39~ER~Editor instruction is "insert", so no underlining needed~Remove underlining under the comma~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103059~"Marshall"~" in LB103"~~~~11k-D7.0~11.8~84~15~TR~With the change in lines 16-19, the text on line 15 is no longer introducing a list.~Delete the text on line 15.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103060~"Marshall"~" in LB103"~~~~11k-D7.0~11.8~84~21~ER~New text should be underlined~Underline this paragraph of new text~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103061~"Marshall"~" in LB103"~~~~11k-D7.0~17.2.3~105~33~ER~TableTable~Table~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103062~"Marshall"~" in LB103"~~~~11k-D7.0~17.5.4.2~107~46~ER~TableTable~Table~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103063~"Marshall"~" in LB103"~~~~11k-D7.0~18.3.5~110~45~ER~TableTable~Table~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103064~"Marshall"~" in LB103"~~~~11k-D7.0~18.4.4.2~111~17~ER~TableTable~Table~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103065~"Marshall"~" in LB103"~~~~11k-D7.0~19.2~112~45~ER~TableTable~Table~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103066~"Marshall"~" in LB103"~~~~11k-D7.0~19.9.4.2~113~8~ER~TableTable~Table~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103067~"Marshall"~" in LB103"~~~~11k-D7.0~19.9.4.3~113~18~ER~TableTable~Table~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103069~"Marshall"~" in LB103"~~~~11k-D7.0~Annex D~169~38~ER~underlining of "dot11SMTbase7" is not correct. This is changing "dot11SMTbase6" to "dot11SMTbase7"~remove underlining of "dot11SMTbase", show "6" with strikethrough, keep "7" underlined~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103070~"Marshall"~" in LB103"~~~~11k-D7.0~Annex D~172~24~TR~dot11Groups 35 is already in use, for dot11OFDMComplianceGroup2~Change this to dot11Groups 36, adjust the other dot11Groups (page 171 line 39, page 174 line 26, and page 174 line 49)~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103. However, consideration will be made in Sponsor Ballot to satisfy this comment as documented in 11/253r7.~R~O~~05/05/2007 00:00:00~~~~~~V 103071~"Chaplin"~" in LB103"~~~~11k-D7.0~7.3.2.22~30~28~ER~"This comment is specifically about CID 14 of the comment resolution spreadsheet 11-07-0253-07-000k-4th-recirc-comment-resolution-worksheet.xls: the term ""shall be"" is normative, while ""is"" is not normative. Changing a term from ""shall be"" to ""is"" is changing the text from normative to non-normative. That sort of change is technical, and not just editorial. Thus, I strenously object to the group's arbritrary reclassification of my comment from ""Technical"" to ""Editorial"": the comment is clearly technical in nature, and calling it ""editorial"" doesn't change the fact that it's actually technical. Since this comment was indeed technical in nature, it should have been addressed in the last recirculation. Since it was not addressed then, it must be addressed now. "~Resolve CID 14 of the comment resolution spreadsheet 11-07-0253-07-000k-4th-recirc-comment-resolution-worksheet.xls~"This comment is a repeat of editorial comment CID14 from LB96. This is not a new comment. Since the referenced LB96 comment is editorial, this LB103 comment is also reclassified as editorial. Section 7.0 contains normative frame format descriptions, and should not contain functional requirements. Shalls are editorially removed from section 7 for two reasons: 1) Intentional functional requirements using ""shall"" in section 7 are to be editorially moved to sections 9 or 11, as appropriate, 2) Unintentional (careless wording) use of ""shall"" in format descriptions are to be editorially replaced with the present tense, which does not modify the resulting format description. The instance of ""shall"" referenced by LB96 CID14 falls into the latter category. The referenced changed text is not a technical change since any implementation designed from the text before the change would interoperate (operate identically) to an implementation designed from the text after the change. Please review the referenced page and line text and the resolution for CID14 from LB96 as documented in 11/253r7."~R~O~~05/05/2007 00:00:00~~~~~~V 103072~"Chaplin"~" in LB103"~~~~11k-D7.0~7.3.2.22~30~46~ER~"This comment is specifically about CID 15 of the comment resolution spreadsheet 11-07-0253-07-000k-4th-recirc-comment-resolution-worksheet.xls:the term ""shall be"" is normative, while ""is"" is not normative. Dropping a term ""shall be"" is changing the text from normative to non-normative. That sort of change is technical, and not just editorial. Thus, I strenously object to the group's arbritrary reclassification of my comment from ""Technical"" to ""Editorial"": the comment is clearly technical in nature, and calling it ""editorial"" doesn't change the fact that it's actually technical. Since this comment was indeed technical in nature, it should have been addressed in the last recirculation. Since it was not addressed then, it must be addressed now. "~Resolve CID 15 of the comment resolution spreadsheet 11-07-0253-07-000k-4th-recirc-comment-resolution-worksheet.xls~"This comment is a repeat of editorial comment CID15 from LB96. This is not a new comment. Since the referenced LB96 comment is editorial, this LB103 comment is also reclassified as editorial. Section 7.0 contains normative frame format descriptions, and should not contain functional requirements. Shalls are editorially removed from section 7 for two reasons: 1) Intentional functional requirements using ""shall"" in section 7 are to be editorially moved to sections 9 or 11, as appropriate, 2) Unintentional (careless wording) use of ""shall"" in format descriptions are to be editorially replaced with the present tense, which does not modify the resulting format description. The instance of ""shall"" referenced by LB96 CID15 falls into the latter category. The referenced changed text is not a technical change since any implementation designed from the text before the change would interoperate (operate identically) to an implementation designed from the text after the change. Please review the referenced page and line text and the resolution for CID15 from LB96 as documented in 11/253r7."~R~O~~05/05/2007 00:00:00~~~~~~V 103073~"Nitsche"~" in LB103"~~~~11k-D7.0~A.4.17~116~22~TR~The measurement of a Noise Histogram adds significant complexity to the PHY. There is still no evidence that this complexity is justified for improving network performance.~This is a repeat comment from LB83. Make the Noise Histogram optional in the PICS, similar as in 11h.~For LB103 purposes this comment is invalid because it is not based on changed text from D7.0 in LB96 to D7.0 in LB103.~R~O~~05/05/2007 00:00:00~~~~~~V