Comment Resolution Actions Month 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 Comment Resolution Actions Simon Black Nokia simon.black@intalk2k.com Black, Nokia John Doe, His Company

July 2004 Comments #6 Should MLME primitive parameters be linked to MIB attributes? BSSMeasurementSet in MLME-SCAN.confirm It seems that previous amendments have chosen to do this IEEE802.11h (additions to MLME-SCAN.confirm) Draft IEEE802.11e Propose to follow the convention as recommended in the comment Include ‘Present only when dot11RadioMeasurementEnabled is true’ for BSSMeasurementSet Black, Nokia

July 2004 Comment #11 Clause 11.1.3.2.2 does not describe returning BSSMeasurementSet for a .11k STA Propose to add text to 11.1.3.2.2 ‘If dot11RadioMeasurementEnabled is true, a BSSMeasurementSet shall be returned with the BSSDescriptionSet.’ Black, Nokia

Comment #17 Mandatory response if STA incapable of making measurements July 2004 Comment #17 Mandatory response if STA incapable of making measurements Replace paragraph 12 of 11.7.5 with Where a STA is permanently unable to make a requested measurement, e.g. because the requested measurement type in not supported, the STA shall respond to such a unicast Measurement Request with an indication that it is incapable of completing the measurement request. A STA shall not respond to broadcast and multicast requests in this manner. A STA may refuse to make any requested measurement and may respond to such a unicast Measurement Request with an indication that it is refusing the measurement request. A STA shall not respond to broadcast and multicast requests in this manner. Black, Nokia

Comments #74, 75, 76 Clean up of the notes column of Table 12 July 2004 Comments #74, 75, 76 Clean up of the notes column of Table 12 Used ‘The <element_name> information element shall be present’ since this is the only place in the draft inclusion is linked to a specific MIB attribute Power constrain element made optional for radio measurements by use of ‘may be present’ Also fixed this in clause 11.5 and item RRM17 of the MIB AP channel report optional if there are no channels to report Included the text ‘The AP Channel Report element may be omitted if there are no channels to report’ Changed in Table 5 also (Beacon) Black, Nokia

Comment #96 Rewording of BSSID field in beacon request July 2004 Comment #96 Rewording of BSSID field in beacon request During the May meeting discussion of this comment concluded that the proposed resolution was inaccurate Unable to determine any inaccuracy and therefore propose reconsideration of the suggested resolution in the comment Black, Nokia

July 2004 Comments #191, 194 Issue raised by the editor in the preparation of D0.16 Comment 194 undoes the accepted resolution of 191 Review found that these comments revise the first and second sentence of 7.3.2.27 in a non-conflicting manner Recommend no change Black, Nokia

Comment #221 TSFType Definition missing? July 2004 Comment #221 TSFType Definition missing? No, just a typographical error Replace TSFtype ::= OCTET STRING (SIZE(8)) with TSFType ::= OCTET STRING (SIZE(8)) Editorial error also corrected in editing instruction Black, Nokia

July 2004 Motion To instruct the editor to apply the comment resolutions in document 11-04-757r0 when preparing the next version of the IEEE802.11k draft. Moved: Black Second: Y: N: A: Black, Nokia