1.1.Called to Order at 1:33Pm by Dorothy Stanley

Sept 2011doc.: IEEE 802.11-11/1241r0

IEEE P802.11
Wireless LANs

1.0 TGmb Monday Sept 19, 2011 PM1

1.1.Called to order at 1:33pm by Dorothy Stanley

1.2.Welcome and affiliation of officers announced.

1.3.7 slots this week

1.4.Proposed Agenda for this slot:

1.4.1.Chair’s Welcome,

1.4.2.Patent Policy

1.4.3.REVmb Status,

1.4.4.Review of Objectives,

1.4.5.Approve Agenda, prior minutes

1.4.6.Editor’s report(42r5)

1.4.7.Interpretation Requests (if any)

1.4.8.Comment resolution – editorials

1.5.Patent Policy reviewed

1.5.1.No items identified.

1.6.Approve the Proposed Agenda:

1.6.1.See slide 3 of 11-11/1174r2 for proposed agenda for the week

1.6.2.Review the agenda.

1.6.3.No objection to the proposed agenda as proposed.

1.7.Prior Meeting meetings:

1.7.1.11-11/999r0 July Minutes

1.7.2.11.11/1182r0 Sept Telcon minutes

1.7.3.No objection to adopt the minutes as noted.

1.8.Editor’s Report (11-11/42r5)

1.8.1.Slight reduction in approval level :: 1 new No voter and 3 new yes voters

1.8.2.LB1004 is the 4th Recirc

1.8.3.Review the number of comments.

1.8.4.Status of 802.11s – it has been published.

1.8.4.1.There were some small things between the final version and the published version that the Editor will have to fix up as result.

1.8.5.Review the balloting plan

1.8.5.1.15 day ballot and comment resolution

1.8.5.2.Nov is still plan for Conditional EC approval

1.8.5.3.Expect D11 to be the final document.

1.8.6.Review the Editor Motion that will be made later

1.8.6.1.Review the 14 Trivial Technical comments included in the motion.

1.8.6.1.1.CID 14010 – editor notes and coloring

1.8.6.1.1.1.Publication Editor will pull the final 4 editor notes.

1.8.6.1.2.CID 140132 – change may to might

1.8.6.1.2.1.Mesh definition that was added, need to correct.

1.8.6.1.3.CID 14151 – proper use of comma vs “;”

1.8.6.1.3.1.Run-on sentence fixed with “;”

1.8.6.1.4.CID 14104 – Wording approved missing

1.8.6.1.4.1.MLME-Start.request -- ProbeDelay – definition was not updated correctly

1.8.6.1.5.CID 14044 – Editor note correction

1.8.6.1.5.1.Duplicated text to be removed

1.8.6.1.6.CID 14196 – MBSS active synch

1.8.6.1.6.1.Fix active synch method name where necessary

1.8.6.1.7.CID 14211 – Run-on Sentence

1.8.6.1.7.1.Discussion on when measurements can be done not when the request can be done.

1.8.6.1.8.CID 14220 – comma between clauses

1.8.6.1.8.1.Add comma as noted.

1.8.6.1.9.CID 14069 – 10.3 vs 10.3.1

1.8.6.1.9.1.Update the reference

1.8.6.1.10.CID 14238 – Shall missing in phrase

1.8.6.1.10.1.Rejected comment – not necessary

1.8.6.1.10.2.Shall statements are for single STAs not groups of STAs

1.8.6.1.10.3.Change proposed resolution to Revised: Replace “and all the mesh STAs in an MBSS uses the same synchronization method” with “. All mesh STAs in an MBSS uses the same synchronization method; see 13.2.7 item a).”

1.8.6.1.11.CID 14239 – extra comment

1.8.6.1.11.1.Marked editorial, but really a trivial technical

1.8.6.1.12.CID 14242 – too main sub clauses in sentence

1.8.6.1.12.1.Redo sentence to be more readable in multiple sentences.

1.8.6.1.12.2.Change resolution: Revised: Replace cited text with ….”(text given in the resolution file.)”

1.8.6.1.13.CID 14109 – Frame body number disagreements

1.8.6.1.13.1.Make both of them “0-7951”

1.8.6.1.13.2.There was discussion on which number is correct.

1.8.6.1.13.3.The W-1 figure seems to be wrong as well.

1.8.6.1.13.4.What is the Max size of an A-MSDU in the Mesh case.

1.8.6.1.14.CID 14230 –run-on sentence

1.8.6.1.14.1.There are about 60 instances of this string, but not all are a problem.

1.8.6.1.14.2.Removes sentence within a sentence.

1.8.6.1.14.3.There are 27 changes in 10.1 that have been made.

1.8.6.1.15.CID 14256 is a MAC comment

1.9.Presentation of 11-11/116r1

1.9.1.Addresses 4 CIDs from Stephen

1.9.1.1.1.CIDs addressed CID14077, 14078, 14079, 14080

1.9.2.The roll-in of TGu causes some ambiguities that needed to be addressed

1.9.3.Abstract: This submission contains editorial corrections concerning the ANQP features from 802.11u. The changes include:

• Typographical error corrections
• Consolidation of “ANQP list”, “ANQP information”, “ANQP message” into “ANQP-elements”
• Consolidation of “ANQP request”, “ANQP query”, “ANQP query request” into “ANQP query”
• Cross-reference corrections
• Removal of repeated redundant phrases from each element
• Clarification of ambiguous text

1.9.4.Review the changes described for the ANQP text changes.

1.9.5.Every field has been checked to have the length is described.

1.9.6.Discussion on the name of ANQP-element names

1.9.6.1.Consensus of the group to change ANQP Query List to Query ANQP-element etc

1.9.6.2.All of the names and the clauses cited would be consistent.

1.9.7.Discussion on changes found so far.

1.9.8.Proposed Resolution for CID 14077-1480

1.9.8.1.“Revised: adopt changes in 11-11/116r2.”

1.9.9.Move CID to Comment Group MAC Motion A

1.10.Presentation of 11-11/1224r1

1.10.1.Abstract: There was some functionality missing in the 11s draft that causes certain action frames that should be encrypted to go out with integrity protection only. This submission addresses that problem and resolves CIDs 14083 through 14088 (inclusive) from the sponsor ballot on draft 10.0.

1.10.2.Discussion on when the encryption is not applied when it should.

1.10.3.In Mesh networks there are group addresses that are broadcast in the clear.

1.10.3.1.BIP integrity protects, but not a privacy protect

1.10.3.2.IGTK info was missing in Mesh Networks.

1.10.3.3.So this has to be added to the Authenticated Mesh Peering Exchange element.

1.11.Recessed 3:30pm

2TGmb Monday PM2

2.1.Called to order at 4:05pm by Dorothy Stanely.

2.2.Agenda for this slot time:

2.2.1.Finish presentation of 11-11/1224r1

2.2.2.Review Editorial comment concerns from Mark Rison

2.3.Continue the presentation of 11-11/1224r1

2.3.1.Review concerns and changes made

2.3.2.Question the importance of accepting this proposal at this time.

2.3.2.1.You will not be able to protect your Mesh traffic without this solution.

2.3.2.2.Implementation of TGw and TGs would not work, but there is really a problem with TGs whether or not you have used TGw.

2.3.3.Is this a community of interested problem that is really an issue, or is this something that can be done differently or another behind the scenes solutions?

2.3.3.1.We do not want to perpetuate the problem, and fixing it sooner would better.

2.3.3.2.Using BIP would not encrypt the data properly. Vendor A to Vendor B is not a guaranteed standard way to communicate.

2.3.4.Technical errors may be inherit in this proposal, and may cause us an extra recirc to get REVmb to completion.

2.3.5.The feature is MESH Security, but it is broken. It is not adding a new feature, but is something that was added by TGs and it is in need of being fixed.

2.3.6.Using the same key by two cryptographic protocols is not supposed to happen, so defining how to pass the ITGK data.

2.3.7.The new feature is the Privacy protection, and the thing that is broken is the integrity protection.

2.3.7.1.This is not true. It is something that was supposedly included in the TGs Mesh definition, and we do not have a complete solution for allowing the securing the MESH.

2.3.8.Some of the Routing frames are sent as Unicast, are encrypted, and are ok, but those that are sent by broadcast, cannot be sent encrypted unless we fix this problem. Question: where is the need for this equal level of privacy?

2.3.8.1.To hide the info in a consistent method.

2.3.9.Long discussion on what the alternatives are.

2.3.9.1.summary:

2.3.9.1.1.Is this really a bug in TGs or is this a nice to have?

2.3.9.1.2.Does this need to be done sooner than later?

2.3.10.Dorothy asks that Adrian, Jon and Michael sit down and ensure we are working to a good schedule. Currently it is set for a March 2012 approval. We are trying to pull this into a Jan/Feb, but are not going to slip March. The Chair is adamant that we are not going to slip March. We are realizing that all the changes we are making right now may cause a d12 or not, but we have to resolve all of the comments this week if we are going to keep to our schedule.

2.3.11.If there are concerns on the technical solution that Dan presented, please contact him. The Chair asked that Dan circulate and vet his proposal with others in the security community to try to ensure we have the best proposal.

2.3.11.1.CIDs that are covered: 14084-14088.

2.4.Editorial comments issues from Mark Rison.

2.4.1.CID 14105 –

2.4.1.1.the text in the resolution was missing “change “through” to “to”too.

2.4.1.2.look for blockaack – found in 2508 .48 fix typo of BlockAack to BlockAck.

2.4.1.3.on 2512.39 – missed bolding of CTS “change CTS to Bold”

2.4.2.CID 14106 –

2.4.2.1.explanation of why the comment was rejected

2.4.2.2.upper case is used for proper nouns

2.4.3.CID 14107

2.4.3.1.Ceiling and floor characters are not available easily for this time.

2.4.4.CID 14113

2.4.4.1.Consistency was used with many of the sentences. There are still places that there may be an inconsistent of “’”.

2.4.4.2.“**” are being used in 2792.61 for example

2.4.4.3.“**” also at 2793.23…but this is not really a problem worth fixing

2.4.4.4.Add to the resolution:: Change “bps” to “b/s”

2.4.4.5.Add to the resolution: 912.44 – delete a comma

2.4.5.CID 14114

2.4.5.1.Comment was withdrawn by commenter.

2.4.5.2.Move CID to Comment Group Gen Motion A

2.4.6.CID 14110

2.4.6.1.There is two instances of “superscript” that need to be corrected.

2.4.6.2.Editor had searched for something else…will un-reject and address CID.

2.5.MAC Comment Review

2.5.1.CID 14119

2.5.1.1.Listen Interval discussion

2.5.1.1.1.Is this a zero based counter?

2.5.1.1.2.Is this the number of Beacons a STA is asleep?

2.5.1.1.3.Is the unit of time Beacon intervals or wait for number of Beacons.

2.5.1.2.Discussion on the difference of “number of beacons” vs Beacon Interval.

2.5.1.3.The Listen Interval is unit of times, and relative to the beacon interval.

2.5.1.4.Look at the suggested changes for value aside from the main stated problem.

2.5.1.5.The question of is there an ambiguity as to whether 1 and 0 really means?

2.5.1.5.1.Listen Interval: is the time that the STA can sleep

2.5.1.5.1.1.0 = no time to sleep

2.5.1.5.1.2.1 = one beacon Interval

2.5.1.5.2.The question is still hard to figure out …ask the group to go discuss further offline.

2.5.2.CID 14047

2.5.2.1.review comment

2.5.2.2.Looking for what happens in the “True” case.

2.5.2.3.Look at the context from the TGs amendment.

2.5.2.4.The difference in QoS Null when dot11MCCAActivated is true.vs the use of group addressed QoS Null (no data) Frames when dot11MCCAActived is false

2.5.2.5.Proposed Resolution: Revised: Change "If dot11MCCAActivated is false, this
is the only permissible value for the Ack Policy subfield for QoS Null (no data)frames."
to "For individually addressed QoS Null (no data) frames, this is
the only permissible value for the Ack Policy subfield.”

2.5.2.6.Move CID to Comment Group MAC Motion A

2.5.2.7.Discussion on non-QoS STA vs QoS STA and how they handle the transmission.

2.5.2.8.Action item for Mark Hamilton will look into the consistency and clarity of this issue.

2.5.3.Recess at 6pm until 8am tomorrow

3TGmb Tuesday, September 19, 2011 - AM1

3.1.Called to order by Dorothy at 8:01am

3.2.Agenda: Comment Resolution

3.2.1.start with Mark Hamilton, and then return to MAC comments list

3.3.11-11/1280r0 – proposed resolution for CID 14022

3.3.1.CID 14022

3.3.1.1.review the submission

3.3.1.2.Proposed Resolution: Revise: In Table 8-6, in the row for values [0,0], change “If dot11MCCAActivated is false, this is the only permissible value for the Ack Policy subfield for QoS Null (no data) frames.” to “This is the only permissible value for the Ack Policy subfield for individually addressed QoS Null (no data) frames.”

In Table 8-6, in the row for values [1,0], change, “If dot11MCCAActivated is true this value is permissible for the Ack Policy subfield for group addressed QoS Null (no data) frame.” to “This is the only permissible value for the Ack Policy subfield for group addressed QoS Null (no data) frames”.

3.3.1.3.Question if the ACK for Group Address QoS Data frames?

3.3.1.3.1.It was described in the first row of the table.

3.3.1.4.Agreement on the proposal

3.3.1.5.Adopt the changes and Moved to MAC A

3.4.MAC Comment Resolution:

3.4.1.CID 14023

3.4.1.1.Review comment

3.4.1.2.Proposed Resolution: Agree

3.4.2.CID 14048

3.4.2.1. Review comment

3.4.2.2.Same issue as 14023

3.4.2.3.Proposed Resolution: REVISED (MAC: 2011-09-19 23:18:47Z) At 448.40, delete "(binary)" and convert the cells in this column to their integer values, 0, 1, 2, 3.
At 448.30, 449.29, 449.33, replace the quoted binary values with their integer equivalents.

3.4.2.4.Move CID to Comment Group MAC Motion A

3.4.3.CID 14024

3.4.3.1.Review comment

3.4.3.2.Proposed Resolution: Accept.

3.4.3.3.Move CID to Comment Group MAC Motion A

3.4.4.CID14029, 14171

3.4.4.1.Review comment

3.4.4.2.similar to 14024

3.4.4.3.proposed resolution: Accept see 14024

3.4.4.4.Move CID to Comment Group MAC Motion A

3.4.5.CID14173, 14050, same as Editor CID 14025

3.4.5.1.Review comment

3.4.5.2.Editor note

3.4.5.3.Proposed Resolution Accept (and note in 14173 similar comment)

3.4.5.4.Question on why “If and only If” is not good to use here?

3.4.5.4.1.review context

3.4.5.4.2.The proposed resolution is going to be inconsistent with the changes that the editor made with some editorial comments. See CID 14025.

3.4.5.5.New Proposed Resolution: REVISED (MAC: 2011-09-19 23:28:08Z) - At 465.60 replace: "(if and only if the frame is transmitted by a mesh STA and the Mesh Control Present subfield of the QoS Control field is 1),"
with: "(present if the frame is transmitted by a mesh STA and the Mesh Control Present subfield of the QoS Control field is 1, otherwise absent),"
and at 465.62 and 465.64 replace: "(and only if the Protected Frame subfield in the Frame Control field is 1)"
with "(present if the Protected Frame subfield in the Frame Control field is 1, otherwise absent)

3.4.5.6.Move CID 14173 and 14050 to Comment Group MAC Motion A

3.4.6.CID 14089 and 14082

3.4.6.1.Review comment

3.4.6.2.Similar comment 14082

3.4.6.3.Jon had discussed this with Vinko and Mathew ahead of the meeting.

3.4.6.4.Adrian wants to do some follow-up on the comment.

3.4.6.5.Hold for now CID 14089 and 14082 in MAC comment group.

3.4.7.CID 14052

3.4.7.1.review comment

3.4.7.2.Proposed Resolution: Accept

3.4.7.3.Move CID to Comment Group MAC Motion A

3.4.8.CID 14026

3.4.8.1.review comment

3.4.8.2.Proposed Resolution: Accept

3.4.8.3.Move CID to Comment Group MAC Motion A

3.4.9.CID 14053 and 14180

3.4.9.1.Same as 14026

3.4.9.2.Proposed Resolution: REVISED (MAC: 2011-09-19 23:39:16Z) Globally replace "non-AP STA[s] [and|or] mesh STA[s]" with "non-AP STA[s]". See CID 14026

3.4.9.3.This is a global change, it will be necessary to look for variants (extra spaces or line breaks etc.)

3.4.9.4.Move CID to Comment Group MAC Motion A

3.4.10.CID 14126

3.4.10.1.Review comment

3.4.10.2.Proposed Resolution: Accept

3.4.10.3.Move CID to Comment Group MAC Motion A

3.4.11.CID 14184

3.4.11.1.Review Comment

3.4.11.2.Proposed Resolution: Accept

3.4.11.3.Move CID to Comment Group MAC Motion A

3.4.12.CID 14006

3.4.12.1.Review comment

3.4.12.2.look at the choices given

3.4.12.3.Proposed Resolution: REVISED (MAC: 2011-09-19 23:49:30Z) "The receiving STA should maintain two additional caches, one
containing entries of recently received <Address 2, sequence-number, fragment-number> tuples from received
management frames that are not time priority management frames and the other containing entries of recently received <Address 2, sequence-number, fragment-number> tuples from received time priority
management frames."

3.4.12.4.Move CID to Comment Group MAC Motion A

3.4.13.CID 14038 and 14041

3.4.13.1.Review Comment

3.4.13.2.This has been switched back and forth several times.

3.4.13.3.We need to check to determine what the right answer is.

3.4.13.4.When do we want SIFS time include or not included?

3.4.13.5.see 956.18 – seems correct on this line

3.4.13.6.Concern on why it seems to swap back and forth.

3.4.13.7.In 802.11-2007 it was in there. We deleted it for some reason.

3.4.13.8.Assign to Mark Hamilton to check to see why we changed it.

3.4.13.9.Mark, Mark and Adrian to review and propose new resolution.

3.4.14.CID 14027 and Editor CID14054

3.4.14.1.Review Comment

3.4.14.2.this was handled on the Telecon with the Editor CID 14054

3.4.14.3.Proposed Resolution: REVISED (MAC: 2011-09-20 00:04:22Z) - Change list at 978.14 to a 2-level dashed list.

3.4.14.4.Move CID to Comment Group MAC Motion A

3.4.15.CID 14187

3.4.15.1.Review comment

3.4.15.2.Proposed Resolution: REJECTED (MAC: 2011-09-20 00:10:20Z) - The term is not used to indicate a new requirement.

3.4.15.3.Move CID to Comment Group MAC Motion A

3.4.16.CID 14189

3.4.16.1.Review Comment

3.4.16.2.Proposed Resolution: REJECTED (MAC: 2011-09-20 00:14:30Z) The limitation expressed later in the sentence relates to which MCCAOP Advertisement elements are present.

3.4.16.3.Move CID to Comment Group MAC Motion A

3.4.17.CID 14055 and 14034

3.4.17.1.Review comment

3.4.17.2.Proposed Resolution: Accept (See CID 14034)

3.4.17.3.Move CID to Comment Group MAC Motion A

3.4.18.CID 14056 and 14055

3.4.18.1.Review comments

3.4.18.2.Proposed Resolution: Accept. (See CID 14034)

3.4.18.3.Move CID to Comment Group MAC Motion A

3.4.19.CID 14035

3.4.19.1.Review comment

3.4.19.2.Proposed Resolution: Accept

3.4.19.3.Move CID to Comment Group MAC Motion A

3.4.20.CID 14057

3.4.20.1.Review comment

3.4.20.2.Similar spot different proposed resolution.

3.4.20.3.What is really missing is just Clause 17 that should be added to the cited location.

3.4.20.4.Discussion on if there is a need to add a separate paragraph for ERP mesh STA or not.

3.4.20.5.There is an issue in the baseline text, but we are not fixing it now, but we will propagate the issue in the new paragraph. This can be addressed later.

3.4.20.6.Proposed Resolution: REVISED (MAC: 2011-09-20 00:22:50Z) Change the condition to "Clause 16, Clause 17, and Clause 19 frames"
(parentheses omitted for clarity). Ditto at line 36. (See CID 14035)

3.4.20.7.Move CID to Comment Group MAC Motion A

3.4.21.CID 14058

3.4.21.1.review comment

3.4.21.2.Proposed Resolution: Agree

3.4.21.3.Move CID to Comment Group MAC Motion A

3.4.22.CID 14197

3.4.22.1.review comment

3.4.22.2.Proposed Resolution: Accept

3.4.22.3.Move CID to Comment Group MAC Motion A

3.4.23.CID 14028

3.4.23.1.review comment

3.4.23.2.another “Editor Note”

3.4.23.3.need to correct this paragraph as it is very confusing

3.4.23.4.The text that was rolled in from 11s has added more confusion.

3.4.23.5.Discussion on possible alternatives to clear up this clause.

3.4.23.6.We have the lists that include Mesh STA and in some classes infers that they are included and in other locations it is explicit.

3.4.23.7.There was a typo on page 1064.18 “DS Parameter Set” that should be “DSSS Parameter Set”…this is covered in another CID.

3.4.23.8.Proposed Resolution: REVISED (MAC: 2011-09-20 00:39:58Z)
Delete the sentence in red at 1064.11.

3.4.23.9.Move CID to Comment Group MAC Motion A

3.4.24.CID 14199

3.4.24.1.same as 14028, and has the same conclusion.

3.4.24.2.Proposed Resolution: Agree

3.4.24.3.Move CID to Comment Group MAC Motion A

3.4.25.CID 14200

3.4.25.1.review comment

3.4.25.2.Proposed Resolution: REVISED (MAC: 2011-09-20 00:44:44Z)
Replace lines 15-20 with
"An associated mesh STA that receives a Probe Request frame shall not respond with a Probe Response frame when dot11RadioMeasurementActivated is true and the Probe Request frame contains a DS Parameter Set element with its Current Channel field value different from the value of dot11CurrentChannelNumber."