IEEE P802.11 Wireless Lans s28

March 2011 doc.: IEEE 802.11-11/0381r0

IEEE P802.11
Wireless LANs

1.0  TGmb Monday, March 14, 2011 PM1 –

1.1  Called to order at 1:33pm by Dorothy

1.2  We did introductions – Adrian Stephens called in via Skype to present the Editor report for this session.

1.3  Patent Policy and Meeting rules

1.3.1  There was no notification given.

1.4  Approval of Agenda contained in 11/291r0

1.4.1  See slide 3

1.4.2  No objection to proposed Agenda.

1.4.3  Note that Reg and Annex D&E

1.5  Minutes from January and telcon approved:

1.5.1  11/074 and 11/0275

1.5.2  Approved by unanimous consent without objection.

1.6  Editor Report doc 11/42r2

1.6.1  Adrian presented the details

1.6.2  Review Ballot status on Slide 4

1.6.3  Slide 5 explains the numbering used for comments

1.6.4  Slide 6 shows recent comment status

1.6.4.1  Note that we have 178 comments fairly equally split originally, but some have been shifted from editor to MAC and Gen.

1.6.4.2  There is one comment that is a spreadsheet that has more comments that were added to the database.

1.6.5  Slide 7 has the revision summary, and shows where TGv and TGu were rolled into 7.01 and 7.03 respectfully.

1.6.6  MAC Adhoc needs an update to be sent to Michael.

1.6.7  Slide 8 1284 has all the comments, and in 10/1455 it has comments sorted by topic

1.6.8  Slide 9 reports on 802.11v roll-up

1.6.9  Slide 10 reports on 802.11u roll-up

1.6.10  Slide 11 reports on

1.6.11  Slide 12 reports on Planning for D8.0

1.6.11.1 Need 4 volunteers for review:

1.6.11.1.1  Dorothy Stanley

1.6.11.1.2  Michael Montemurro

1.6.11.1.3  Harry Worstell

1.6.11.1.4  David Hunter

1.6.11.2 Each will need to give about 2 hours. This is contingent on having the comment resolutions done this week. If we do get this goal, then the review is needed.

1.6.11.3 We have a call for the 25th if needed. Otherwise the ballot would start that day.

1.6.12  Slide 13 unadjusted project plan.

1.6.12.1 2 weeks for ballot prep can be reduced to 1 week and then we could give 7 days to the ballot or to resolution or not

1.6.13  Slide 14 review of comment status.

1.6.14  Slide 15 review of CID 11211

1.6.15  Slide 16 discussions on proposed resolution from David.

1.6.15.1 Possible choices are reject, or to prepare a mapping table.

1.6.15.2 We do not have a list of the rules that we follow on how the variables are named. Is there a definitive list of how the variable names are being created.

1.6.15.3 We tried to document some things, and that is captured in the 802.,11 style guide, but that has not been touched for a couple years. Maintainance of that document would be helpful to the editors.

1.6.16  Slide 17 proposed rejection resolution

1.6.16.1 How burden is the tech editor and the effort that this may cause.

1.6.16.2 Not certain the full weight of change.

1.6.16.3 It may be possible to automate the changes, but it may cost about a week of time.

1.6.16.4 If we are waiting for TGs, then time would be afforded to do it.

1.6.16.5 The risk may not be high if we open the document up.

1.6.16.6 The timing of the comment is very different coming now vs. coming later.

1.6.16.7 The window of opportunity is in a short window time.

1.6.16.8 Trying to understand the ripple effect.

1.6.16.9 The reason for the capitulation is to make things more precise and to show the overload of field names with the germane useage of the word.

1.6.16.10  The logistics does not allow for the comment to be held open and start the ballot, but would be better to reject and allow a later submission.

1.6.16.11  The formal process is to reject and then a pile-on comment with a submission that can be evaluated.

1.6.16.12  The timeframe that David is wanting may work ok after rejection.

1.6.16.13  The changes would be able to done, and then a thorough check would have to be done after the fact to ensure that the proper change was applied.

1.6.16.14  Mapping table: old name – new name – Rule. Giving the context.

1.6.16.15  i.e. change “priority” to “Priority” where followed by field or variable.

1.6.16.16  Location points are very hard and tedious, that would be much harder.

1.6.16.17  Pragmatically this would need to be done.

1.6.16.18  Proposed Resolution had no objection, and so this comment would be to disagree.

1.6.16.19  Any further discussion would be if the commentor provides further comments on future ballots.

1.6.16.20  Adrian is willing to work with David on a few junk ones to see if it will work the way we think, but after the ballot gets started.

1.6.17  Slide 18: E-Motion 1

1.6.17.1 Motion # 115: Approve comment resolutions in 11-10-1455-05-000m-revmb-sponsor-ballot-editor-comments on the “Editorials & Terminology” tabs. 24 Agree, 14 Principle, 4 Disagree, 2 Scope, 1 Unresolvable

1.6.17.1.1  Moved: Micheal Montemurro, 2nd Harry Worstell

1.6.17.1.2  Results: Passes 7-0-0

1.6.18  Slide 19 a new motion for later in the week if we get all the comments taken care of.

1.7  Review Doc 11-316r0 – CID 11001

1.7.1  Review Comment and discussion in the submission.

1.7.2  The effort done here has shown a clash at 46 and 47 where 11u has added a code that should have been different, but the implementors may not know of this clash at this point, and we may want to make the change to correct the clash .

1.7.3  Some values do not have names. In Table 8-35 Reason codes:

1.7.3.1  If the implementors agreed that these values (46 and 47) could be reassigned, then it would be ok to do it but in the lack of that feedback, we would just follow the proposed changes as documented.

1.7.4  In Table 8-36 Status codes

1.7.4.1  Need some feedback from 11u on value 62. if it is a local STA timout, then it is in the wrong place. Need to find out if this is an external entity then it would be ok and valid. “timeout” is a bad name, but rather “Guest Timeout” would be a better choice for the name, and for clairity.

1.7.4.1.1  Propose that we change “Timeout” to “GAS timeout” in clause 6 interface and here in this table.

1.7.4.2  Feedback needed on line 64 where the name and the description are not very good match. Would a better name or description be better in this instance.

1.7.4.2.1  There is a chance that this change to the description may have just missed being updated.

1.7.4.2.2  Michael to check with Stephen to see what the intent was for this row.

1.7.4.3  Codes used in a Primitive that do not have an entry .

1.7.4.3.1  We would need the ANA to add new entries for these 4 rows, and we need a description for the “QUERY_RESPONSE_OUTSTANDING”

1.7.4.3.2  Michael will check with Stephen as well.

1.7.4.3.3  The first 2 are old instances and were not in the tables, we could delete them, as they do not exist…it may be that we error on the side of caution and give them a number.

1.7.5  Clause 10.4.4 TS setup

1.7.5.1  Remove of table 10-2.

1.7.5.2  Add a reference to table 8-36

1.7.5.3  We are not making any technical change, because we are just moving where the names are enumerated.

1.7.5.4  The MLME definition should provide the detail list.

1.7.5.5  Review context in 6.3.26.5.

1.7.5.6  The MLME SAP would need to be updated:

1.7.5.6.1  Merge the result code from table 10-2 into the result code enumerations in 6.3.26.5.

1.7.5.6.2  With the 11v and 11u rolled in this may be a null set, but this is a action that is already done.

1.7.5.6.3  With the 7.03, this is a mute point, and the extra update is not needed.

1.7.6  Page 9: 10.4.9 TS deletion

1.7.6.1  Review the proposed change.

1.7.6.2  There is almost a match into d7.03, but the timeout code is missing.

1.7.6.3  This would have to be added as a change in r1 of the document.

1.7.6.4  Add an editing instruction to add the missing Result Code enumerations.

1.7.7  Page 9: 10.5.2.3

1.7.7.1  Review the proposed change.

1.7.7.2  Need to check the MLME has all the result codes.

1.7.7.3  We should remove the TIMEOUT value in the MLME

1.7.7.4  Editor line added that removes the TIMEOUT here where it is not valid.

1.7.8  Page 10: 10.5.3.2 Block ACK teardown

1.7.8.1  Review the proposed change.

1.7.8.2  In this case, the TIMEOUT should be added. As it was in the text, but not in the table.

1.7.9  Page 10: 10.7.2.3 Setup DLS Procedure

1.7.9.1  See page 196 of D7.03

1.7.9.2  Propose to remove the Timeout in the .confirm for consistency.

1.7.9.3  Table 10-7 did not include Timeout, so it should be removed in the result code enumeration.

1.7.10  10.7.4.2 DLS teardown.

1.7.10.1 Table 8-35 has the reason codes, but the applicable is left in the table 10-8.

1.7.10.2 We should also check the DLS Teardown request to ensure that the Result Codes are in fact all there and match them appropriately.

1.7.10.3 The lists should be merged.

1.7.10.4 Add an Editor instruction to merge the lists in the .request and .indicate primatives for DLS teardown. – 6.3.27.5.

1.7.10.5 TIMEOUT was there, but it is needed to be added in the .request…. it is on the .indicate already.

1.7.11  10.21.3.1.3 GAS request

1.7.11.1 .indication and .confirm are on 360 of D7.03

1.7.11.2 In the response we have 7 values in both places, so it should match, but it does not, so they need to be merged.

1.7.11.3 Page 362 the response… is missing a transmission failure.

1.7.11.4 SUCCESS is missing in status code field table 10-15, but it is in the MLME, so the updated reference takes care of that.

1.7.11.5 TRANSMISSION_FAILURE does not make sense in the GAS response. In general, Michael to check on if this is necessary in 10-15.

1.7.11.6 The reference in the table in the MLME will need to be updated.

1.7.12  Changes to Clause 6 interfaces

1.7.12.1 Doc 11-284 removes a bunch of .confirms which are listed on page 12.

1.7.12.2 In 6.3.7.5.2, list changes

1.7.12.3 In 6.3.29.5.2 remove the TIMEOUT

1.7.12.4 In 6.3.38.4.2 ignore the add “INVALID PARAMETERS”, and have only the addition of “REFUSED”

1.7.13  8.5.8.10 DSE Power Constraint frame format

1.7.13.1 Change table 8-206 to match the MLME interface

1.7.14  Menzo was asked to look at some of the last remaining issues that 6.3.64.3 and Micheal is checking 6.3.71.2.

1.7.15  The final editor note will have to be discussed later

1.8  Time was up at this point, Recess at 3:33pm

2.0  TGmb Tuesday March 15, 2011, PM1

2.1  Called to order by Dorothy at 1:31pm

2.2  Proposed agenda: TDLS Comments, then Annex D &E and Regulatory.

2.2.1  No objection to the ordering.

2.3  MAC Comments:

2.3.1  CID 11049 Security TDLS

2.3.1.1  Review comment

2.3.1.2  Proposed resolution: Agree

2.3.1.3  No objection - Moved to MAC motion B

2.3.2  CID 11227 TDLS Peer Key Handshake

2.3.2.1  Review comment

2.3.2.2  Proposed Resolution: Agree

2.3.2.3  No objection - Moved ot MAC motion B

2.3.3  CID 11032 TPK handshake message 1

2.3.3.1  Review comment

2.3.3.2  Proposed Resolution: Agree

2.3.3.3  No objection - Moved ot MAC motion B

2.3.4  CID 11017 TPK handshake Message 1

2.3.4.1  Review Comment

2.3.4.2  Proposed Resolution: Agree in Principle: “Replace “10.22.2 (TDLS payload)” with “1.22.4 TDLS direct-linke establishment)”. In addition, the same change in 11.5.11.4.3 (Page 920 line 63). – Change to 10.22.4 (TDSL direct-link establishment)

2.3.4.3  No objection - Moved ot MAC motion B

2.3.5  CID 11018 TPK handshake Message 2

2.3.5.1  Review Comment same thing

2.3.5.2  Proposed Resolution: Agree in Principle: “Replace “10.22.2 (TDLS payload)” with “1.22.4 TDLS direct-linke establishment)”. In addition, the same change in 11.5.11.4.3 (Page 920 line 63). – Change to 10.22.4 (TDSL direct-link establishment)

2.3.5.3  No objection - Moved ot MAC motion B

2.3.6  CID 11019 TPK handskae Message 3

2.3.6.1  Review comment

2.3.6.2  Proposed Resolution: Agree

2.3.6.3  No objection - Moved ot MAC motion B

2.3.7  CID 11235

2.3.7.1  Review Comment

2.3.7.2  Proposed Resolution: Agree in Principle – delete “appropriate”.

2.3.7.3  Discussion on what the word “appropriate” is… decision to delete “appropriate”.

2.3.7.4  No objection - Moved ot MAC motion B

2.3.8  CID 11104

2.3.8.1  Review comment

2.3.8.2  Proposed Resolution: Agree in Principle: the intent of 802.11z has been to disallow broadcast discovery requests in order to avoid too much traffic and potential wakeup at the STAs. The sentence on page 533 is likely a remnant of an earlier version of 802.11z where broadcast discovery was still allowed. Therefore, on page 533.28, delete “or to the Boardcast address”.

2.3.8.3  No objection - Moved ot MAC motion B

2.3.9  CID 11034 TDLS direct-link teardown

2.3.9.1  Review comment

2.3.9.2  Proposed Resolution: Agree

2.3.9.3  No objection - Moved ot MAC motion B

2.3.10  CID 11234 TDSL channel Switching

2.3.10.1 Review Comment

2.3.10.2 Proposed Resoluton: disagree On the base channel, the TDLS STAs have no option but to follow the bandwidth of the AP per the following rule in 10.22.1 on page 799.46: “The channel width of the TDLS direct Link on the base channel shall not exceed the channel width of the BSS to which the TDLS peer Stas are associated.”.

2.3.10.3 No objection - Moved ot MAC motion B

2.3.11  CID 11048: TDLS Channel Switching

2.3.11.1 Review Comment

2.3.11.2 Proposed Resolution: AGREE IN PRINCIPLE (MAC: 2011-03-15 05:58:32Z) - Replace "When two TDLS Channel Switch Request frames still cross, then both TDLS Channel Switch Response frames are executed sequentially depending on their reason code." with "If a TDLS Channel Switch Request frame is received from the TDLS peer STA to which a pending TDLS Channel Switch Request frame was previously sent before receiving TDLS Channel Switch Response, the TDLS initiator STA shall not reply to the TDLS Channel Switch Request frame and the TDLS responder STA shall reply to the TDLS Channel Switch Request frame."