doc.: ieee 802.11-03/319r0grouper.ieee.org/groups/802/11/minutes/cons_minutes_july-2003.pdf ·...

July 2003 doc.: IEEE 802.11-03/511r2

IEEE P802.11 Wireless LANs

Approved Minutes of the IEEE P802.11 Full Working Group

July 20-25, 2003

Hyatt Regency San Francisco, San Francisco, CA, USA

Joint 802.11 / 802.15 Opening Plenary: Monday, July 21, 2003 1.1. Introduction

1.1.1. 1.1.2.

1.1.3. 1.1.4.

1.2.1. 1.2.1.1. 1.2.1.2.

1.2.1.3. 1.2.1.4. 1.2.1.5.

1.2.1.6. 1.2.1.7.

Meeting called to order by Stuart J. Kerry at 1:00PM. The agenda of the 80th session of 802.11 is in doc: IEEE 11-03-445r4, This session is including 802.11, 802.15, 802.18 RREG TAG, 802.19 Coexistence TAG, and 802.20. Secretary – Tim Godfrey Straw Poll of new attendees at this meeting: 93

1.2. Policies and procedures Al Petrick reviews document 00/278r7

Review of WG officers and duties. Operating policies and procedures are reviewed. The source

documents are listed in document 278r7 Rules for registration and media recording are presented. Review of the electronic attendance logging rules. The rules for gaining and maintaining voting rights are presented.

Document 462r13 “New Members Orientation” has further details. Review of individual membership and anti-trust rules. Al Petrick reviews the rules on Patents, according to the standard

bylaws. All members must be aware of this policy. Al Petrick reads the following text to the group:

6. Patents

IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard. This assurance shall be provided without coercion and prior to approval of the standard (or reaffirmation when a patent becomes known after initial approval of the standard). This assurance shall be a letter that is in the form of either

a) A general disclaimer to the effect that the patentee will not enforce any of its present or future patent(s) whose use would be required to implement the proposed IEEE standard against any person or entity using the patent(s) to comply with the standard or

b) A statement that a license will be made available without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination

This assurance shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal and is irrevocable during that period.

IEEE-SA Standards Board Bylaws on Patents in Standards

Slide #1 Approved by IEEE-SA Standards Board – December 2002

Minutes page 1 Tim Godfrey, Intersil

July 2003 doc.: IEEE 802.11-03/511r1

Inappropriate Topics for IEEE WG Meetings

Don’t discuss licensing terms or conditions

Don’t discuss product pricing, territorial restrictions or market share

Don’t discuss ongoing litigation or threatened litigation

Don’t be silent if inappropriate topics are discussed… do formally object.

If you have questions,contact the IEEE Patent Committee Administratorat [email protected]

Slide #2 Approved by IEEE-SA Standards Board – December 2002


July 2003 doc.: IEEE 802.11-03/511r1

1.2.1.8.

1.3.1. 1.3.2.

1.4.1. 1.4.2. 1.4.3.

1.4.4. 1.4.4.1.

1.4.4.2.

1.5.1. 1.5.2.

1.6.1. 1.6.2.

1.7.1. 1.7.1.1.

1.7.1.2.

1.7.1.3. 1.7.2.

1.7.2.1. 1.7.3.

1.7.3.1.

1.7.3.2.

1.8.1.

1.8.2. 1.8.3. 1.8.4.

The copyright status and rules are reviewed.

1.3. IP Statements 802.11 has not received any new IP statements There are no new statements for 802.15, 18, 19, or 20.

1.4. Server and electronic Attendance Al Petrick, Mike Hewitt, and Tim Godfrey Review of document 03/044r3 The network status, file sharing procedures, and attendance recording web site are reviewed. Q&A

Will the Document template change to match the new document control number format? We are trying to minimize the changes – the templates will stay the same.

Members can only upload documents through the web site.

1.5. Approve Agenda The agenda is reviewed by the chair. The agenda is approved as stated, without objection.

1.6. Approval of Minutes Any matters arising from the minutes. The minutes from May 2003 are approved without objection.

1.7. Interim Meetings September 2003 – Singapore

The May 03 meeting surplus will be transferred to the Singapore meeting to reduce the registration fee by about $140US.

Attendance is unknown – expecting about 250 for planning purposes.

Registration must be done through the Tourhosts link only. January 2004 – Vancouver

Hosted by IEEE 802 Looking for sponsors for May 2004

Straw Poll at DFW indicated a preference for Europe, but we don’t have a host.

Stuart Kerry notes that we are following the correct process for selecting interim venues, and following the input of the working group. Stuart asks for any issues any member has with venue locations to be brought to his attention.

1.8. Review of financials Bob Heile reviews the Wireless working groups’ financial status and previous expenditures, and reserves. The finances are being audited. There is a current cash reserve of about $35K. There was a second server purchased. The 802 ExCom will determine whether 802 or the Wireless WG’s will pay for this.

1.9. Report on Executive Committee


July 2003 doc.: IEEE 802.11-03/511r1

1.9.1. 1.9.2. 1.9.3.

1.10.1. 1.10.1.1. 1.10.1.2.

1.11.1.

1.12.1.1.

1.13.1. 1.13.2. 1.13.3.

1.13.4.

1.13.5.

1.13.6. 1.13.7.

1.13.8.

1.13.9.

1.14.1.

1.14.2.

1.14.3. 1.14.4.

The 802 treasury has a $62K surplus 802.10 is likely to disband. There are issues in the financial operations of 802.11, 15, 17, and 3 regarding maintaining a treasury for interim meetings. We are moving interim meetings to follow the same rules as the 802 plenary. There will be an executive committee for the wireless groups, and a treasurer will be appointed. The Executive Committee will have a special session to debate the issues on maintaining these accounts last year.

1.10. Voter Status for 802.11 Al Petrick reviews Document 01/402R13.

397 voters, 139 nearly voters, Potential voters of 536. Voting Tokens will be distributed today by Al Petrick

1.11. 802.11 Agenda The agenda modification for 802.11 is accepted unanimously

by 802.11 members. 1.12. Approval of the 802.11 WG Minutes

The minutes of 802.11 for May 2003 were approved without objection.

1.13. 802.11 WG policies and Procedures Al Petrick presents document 03/434r1 Changes to the policies and procedures are in red. The new document will be 00/331r6. There is a table of

revisions. This document is on the server. There is a global change from “operating rules” to “policies

and procedures”. There are changes to document numbers to match the new

document system. There is the addition of a treasurer and financial operations. Added informative text for TG and WG secretaries for

minutes. The revision will be voted on at the next Plenary meeting in

November. If there are any issues, please contact Al Petrick.

1.14. WG Editor update Terry Cole presents document 03/197r3 on the working

group. Coordinating the technical editor role with the activities in

TGm (Maintenance PAR). 802.11g has been published. The reaffirmation of 802.11-1999 has been approved, but

not published yet. It will be on the next CD and can be ordered.


July 2003 doc.: IEEE 802.11-03/511r1

1.14.5.

1.14.6.

1.15.1.

1.15.2.

1.16.1.

1.16.2.

1.17.1. 1.17.2.

1.17.3. 1.17.4.

1.17.5.

1.18.1.

1.19.1.

1.19.2.

1.19.3.

1.19.4.

1.20.1.

1.20.2.

Documents on the server describe pending changes from standards in the sponsor ballot.

Sponsor Pools have been formed for 802.11e and 802.11i. 1.15. TGe - John Fakatselis

Resolving comments. Down to about 20 remaining comments. There have been ad-hoc activities between the May meeting that addressed many comments.

Objective is to resolve all remaining comments before the end of tomorrow. We will have a new draft going to recirculation at the end of the week.

1.16. TGf – Dave Bagby 802.11f is done. It was approved by RevCom in June. It is in

the hands of IEEE waiting for publishing. Stuart Kerry thanks Dave and the TGf group for their work.

1.17. TGg – Matthew Shoemake The final report is in document 03/521 The IEEE standards board approved 802.11g on June 12th.

It is now available from IEEE. There are no further sessions of TGg. Stuart Kerry thanks Matthew and the TGg group for their

work. Stuart Kerry announces a celebration on Wednesday at

11:30. 1.18. TGh – Mika Kasslin

In the second recirculation. Will process two comments this week. Hope to submit draft to RevCom this week.

1.19. TGi – Dave Halasz Passed LB52 with 76%, LB57 moved to 77% and about

1400 comments. An ad-hoc meeting resolved many comments. The comments are maintained in 03/452.

A proposed update to the draft has been submitted as document 03/485.

Hoping to resolve remaining comments this week, and go to a recirculation ballot.

There will be a discussion of VoIP in the evening WNG session.

1.20. TGj – Sheung Li There are 5 unresolved comments from the first letter ballot.

There will be technical presentations to resolve them. Planning to have a new draft ready for a recirculation ballot

at the end of the week. 1.21. TGk – Richard Paine


July 2003 doc.: IEEE 802.11-03/511r1

1.21.1.

1.21.2.

1.22.1.

1.22.2.

1.23.1. 1.23.2.

1.24.1.

1.24.2.

1.25.1.

1.25.2.

1.25.3.

1.26.1. 1.26.2.

1.26.3.

1.26.4.

1.26.5. 1.26.6.

1.26.6.1.

1.26.7. 1.26.7.1.

1.26.8.

Preparing for Letter Ballot. Hope to have a draft submitted by the end of the week.

Looking at scenarios and considering quality of signal measurement issues. Working on framework for fast roaming and MIBs for measurements.

1.22. TGm – Bob O’Hara TGm will meet 3 times on Wednesday. There is one new

interpretation request.

1.23. WNG Standing Committee – TK Tan There are three sessions. In addition to industry updates, there are presentations on

Ad Hoc networking, VoIP, DSRC proposal. 3GPP3. Wednesday presentations on compression and test methodology. Dave Johnson will review 802 handoff activities.

1.24. HTSG – Jon Rosdahl Hoping to become a task group. Comments on PAR will be

due tomorrow at 5:00PM. Will be approved by WG on Wednesday AM. Expecting ExCom approval on Friday.

In September we will meet as 802.11n. 1.25. Call for Interest

Clint Chaplin. There is a call for interest in fast roaming. More applications require continuous connection during roaming. But more and more state is being added to 802.11.

Desiring to set up a Task Group. Will be put on Agenda in TGi and WNG. There is no overlap between TGi and WNG.

This is a call for interest in a Study Group. 1.26. 802.15 WG – Bob Heile

118 voters, with 207 potentially at this meeting. There will be a brief 802.15 plenary session at 3:30 today.

There will be discussions of rules and PARs on the table LB24 was to suspend the rules to operate with a treasury.

There were 87 yes, 1 no, 8 abstain. The corresponding results of the 802.11 WG were posted to

the reflector and web site. 802.15.2 was approved by the standards board. 802.15.3 – John Barr

TG3 has completed its work and has been approved by the standards board. 802.15.4

802.15.4 was approved in May. 802.15.3a – Bob Heile


July 2003 doc.: IEEE 802.11-03/511r1

1.26.8.1.

1.26.9. 1.26.9.1.

1.27.1.

1.28.1. 1.28.1.1. 1.28.1.2. 1.28.1.3.

1.28.1.4. 1.28.1.5. 1.28.1.6.

1.28.1.7. 1.28.2.

1.29.1.

1.30.1. 1.30.2. 1.30.3. 1.30.4. 1.30.5.

1.30.6. 1.30.7. 1.30.8.

1.31.1.

1.31.2.

1.31.3.

1.32.1.

This meeting will conduct a down-selection vote. From an initial 31 proposals we are down to 6. Study group for 802.15.1 update – Tom Seip

There will be a meeting tonight to consider updating 802.15.1 to match Bluetooth 1.2

1.27. Publicity Committee – Brian Matthews. Will meet Tuesday at 8:00. Objective is to receive industry

group reports, and review draft text of press releases. 1.28. Other Working Group PARs

There are PARs from other Working Groups 802.1AE - MAC SECURITY 802.1Q (REVISION) - VIRTUAL BRIDGED LANS 802.1X (REVISION) - PORT-BASED NETWORK ACCESS

CONTROL 802.11N - HIGH THROUGHPUT 802.15.1A - BLUETOOTH 1.1 => 1.2 802.16 (REVISION) - CONSOLIDATION PLUS 2-11 GHZ

PROFILES 802.16.2 (REVISION) - 2-11 GHZ ENHANCEMENT

We can submit comments on these before Tuesday at 5:00PM.

1.29. 802.18 – Radio Regulatory TAG – Carl Stephenson Reviewing regulatory letters and results from WARC

1.30. 802.18 – Coexistence TAG – Jim Lansford Will meet this week Coexistence Guideline document is on the web server. Considering usage models for 802.15.3a. There have been conference calls every 2 weeks. There are also conference call results for HTSG usage

models. Joint sessions with 802.15.3a and HTSG are planned. Will select a vice chair for the TAG. Documents are on the web site at 802.org/19. There also the

local server \\802-18-19 1.31. 802.20 – MBWA – Jerry Upton and Mark Klerer

Chair Position is open. There are 184 members. There was not a quorum at the interim.

This week will have nominations and elections for the chair. Election will be Thursday afternoon.

There are three correspondence groups on email reflectors. 1.32. IEEE and 802 Brand Identification

The representative is not present. It will be brought up on Wednesday.


July 2003 doc.: IEEE 802.11-03/511r1

1.33. Bob Heile reminds members that there will be an 802.15 plenary session at 3:30

1.34. The meeting is recessed at 2:30 PM

2. Mid-Week Plenary Session 2.1. Opening

2.1.1. 2.1.2.

2.1.3.

2.2.1. 2.2.2.

2.2.3. 2.2.4.

2.3.1. 2.3.1.1.

2.4.1.

2.4.2. 2.4.3.

2.5.1. 2.5.2.

2.5.2.1. 2.5.2.2.

2.6.1. 2.6.1.1.

2.6.2. 2.6.2.1.

2.6.3. 2.6.3.1.

2.6.4.

The meeting is called to order by Stuart J. Kerry at 10:30AM Operating from 03/445r5 agenda. There have been two new motions 4.1 and 4.2 added to the agenda, as mentioned on Monday. IEEE staff will hopefully be here to discuss IEEE branding. There is a new item 5.1 in new business for IEEE web area, and a motion from WNG, and then the special event as announced. The special event will start about 11:30, and we will go into recess. This special event has been sponsored by five companies.

2.2. Announcements Voting tokens will be available at noon at the registration desk. The sponsor ballot pool will be circulated among the members. If any member is not on the list, they should add contact information. CAC meeting reminder for 7:00AM Thursday. Ideal will have a discussion on the network today at 5:00PM.

2.3. IP Statements Are there any new IP statements or letters?

None

2.4. Attendance Recording The attendance application still records all members as “new members”. We should have voting status in by Friday. Ideal Software company representatives are available. Straw Poll – who thinks the attendance program is better – Unanimous

2.5. Agenda Are there any other changes to the agenda Approval of agenda

Moved Colin / Jon Approved with unanimous consent

2.6. Liaison Reports 802.11 to 802.1

None 802.11 to 802.15

No Report 802.11 to 802.15.3a

Conducting a down selection process. Now down to 4 proposals. 802.11 to 802.16


July 2003 doc.: IEEE 802.11-03/511r1

2.6.4.1. 2.6.5.

2.6.5.1. 2.6.6.

2.6.6.1.

2.6.6.2.

2.6.7. 2.6.7.1. 2.6.7.2.

2.6.7.3. 2.6.7.4.

2.6.7.5. 2.6.7.6. 2.6.7.7.

2.6.8. 2.6.8.1. 2.6.8.2.

2.6.8.3. 2.6.8.4. 2.6.8.5.

2.6.9. 2.6.9.1.

2.6.10. 2.6.10.1.

2.6.11. 2.6.11.1. 2.6.11.2.

2.6.11.3.

2.6.11.4. 2.6.11.5. 2.6.11.6. 2.6.11.7. 2.6.11.8.

2.6.11.8.1.

2.6.12. 2.6.12.1. 2.6.12.2.

None 802.11 to 802.18

None 802.11 to WiFi alliance

Bill Carney ask if he can defer to Friday? The chair prefers to do it today. Cannot do it today.

Any objection to moving to Friday? Yes. There are two objections. Terry Cole and Jon Rosdahl.

JEDEC JC61 liaison – Tim Wakeley Document 03/583 43 member companies. Met last week Members are asked to review

and vote on the BB/RF draft standard. Continuing to review compatibility requirements U/L MAC has adopted the electrical interface of the BB/RF interface.

Expecting baseline draft in September. Discussion of combined Ethernet / WLAN interfaces. New ballots starting August 6. Next meeting Sept 3-4 in Santa Rosa, CA

802.11 to CableLabs – Lior Ophir Document 03/613 Coordinating the use of 802.11 in Docsis cable modems.

CableHome 1.1 is the current version. 5 residential gateways have been certified. The chair moves to Al Petrick CableLabs has provided input to the HTSG usage models.

802.11 to IEEE 1394 – Peter Johansson Not Present - 3rd call – removed as liaison

802.11 to 3GPP-SA2 - Barry Not Present – 3rd call – removed as liaison

802.11 to IETF – Dorothy Stanley Document 03/546 3GPP and IETF met with IETF operations directors, asking for

standards groups to request input on Radius usage. Considering forming a Radius working group. 3GPP2 and WiFi alliance are considering Radius for public WLAN use.

BOF session was held to consider a working group on controlling provisioning of Access Points. A secure protocol for lightweight access points and routers. A mailing list has been set up.

The CAPWAP charter has been defined. The Seamoby group is shutting down. The chair moves to Stuart J. Kerry. The next IETF meeting is in November Discussion

Is there any way to coordinate to prevent IEEE and IETF meeting the same week? They are trying but sometimes there is a conflict.

802.11 to MMAC – T. Inoue Document 03/609 T71 is working on specifications for CSMA based WLAN including

802.11a. T71 ad hoc WG has been created to revise T71. First draft has


July 2003 doc.: IEEE 802.11-03/511r1

been approved. STD-T71 Version 2 is now available. Harmonized with 802.11J draft 1.0. Will have English version soon.

2.6.12.3.

2.7.1.

2.7.1.1.

2.7.1.2.

2.7.1.2.1. 2.7.1.2.2.

2.7.1.3. 2.7.1.3.1.

2.7.1.4. 2.7.2.

2.7.2.1.

2.7.2.2.

2.7.2.3.

2.7.2.4. 2.7.2.5.

2.7.2.6. 2.7.2.7.

2.7.2.8.

2.7.2.9.

2.7.3. 2.7.3.1. 2.7.3.2.

2.7.3.3.

Next will deal with new allocations at 5.4GHz and 5.25 for Fixed Wireless Access.

2.7. Old Business 802 PARs and motions for ExCom meeting approval -802.11 HTSG comments from 802.15

We received a document from 802.15. They had seven comments on 11/03/588.

Motion: Believing the response contained in 11-03/0588-00 to be accurate and to meet IEEE-SA guidelines for responses to comments on the PAR & 5 Criteria contained in 11-02/798r7 & 11-02/799r6, approve WG 802.11 providing the aforementioned response to WG 802.15 (author of comments on WG 802.11 PAR & 5 Criteria contained in 03288r0P802-15_WG-Comments-on-11n-PAR-&-5C.pdf) and all ExCom Members no later than 5pm Wednesday, July 23, 2003.

Moved Jon Rosdahl on behalf of HTSG (passed 97:0:1 in HTSG)

Discussion None

Vote: Passes 145 : 0 : 3 IEEE Brand Identification

Karen McCabe – Sr. Marketing Manager from Standards Association.

Discussion of how IEEE can support brand identification of products. IEEE works to protect the value of the IEEE brand name. Use the IEEE logo. The Master Brand is available on the IEEE web site.

Specific practices for brand identification – associate the standard number with the IEEE. Use trademarks for standards designations.

PR programs are available for publicity purposes. Requesting input from the WG and industry on marketing and

branding needs and requirements. Q&A What is the relationship with the WiFi alliance and their branding?

The WiFi alliance has put effort into insuring interoperability. What is the value of the IEEE brand above what WiFi offers?

WiFi does reference IEEE. This is about protecting the IEEE brand. IEEE is the technical expertise of developing the standards. IEEE does work closely with WiFi Alliance.

What about stating conformance to draft standards? Many companies want to claim conformance to a draft standard – from the IEEE perspective, as long as it is clear that it is a draft standard, the IEEE is OK with the practice.

802.11 Web Private Area Ken Clements Concerned about access to private areas of the web site. There is a

need for public access, but also the needs of the IEEE SA must be considered. There have been problems with the password of the private area during some recent ballots. To decrease our problems with administration suggest that we stop changing the password for the private area unless it has become public. Then there won’t be an issue during letter ballots.

Motion: Whereas: the 802.11 Working Group maintains a private web area for the purpose of standards development , and is required to


July 2003 doc.: IEEE 802.11-03/511r1

protect unpublished drafts, but must provide access for voting and comments without undue procedural difficulty. Resolved: the Chair of the 802.11 shall refrain from changing, or authorizing others to change, the private web area user code or password unless he or she has made a determination that the access information has become public, or known well beyond the community of standards developers concerned.

2.7.3.4. 2.7.3.5. 2.7.3.6.

2.7.3.6.1.

2.7.3.6.2.

2.7.3.6.3.

2.7.3.6.4.

2.7.3.6.5.

2.7.3.6.6.

2.7.3.7. 2.7.3.7.1.

2.7.3.8. 2.7.4.

2.7.4.1.

2.8.1.

2.8.2.

3.1.1. 3.1.2.

3.2.1.

Moved Ken Clements Second Srini Kandalas Discussion

In favor: Decreases procedural overhead. When we have a LB – anybody may make comments.

These drafts are kept private because they are drafts. As they become closer to completion, they are sold by the IEEE. Otherwise anyone can come to the meeting and pay the fee for the meeting. The IEEE gains revenue from meeting fees and drafts.

Oppose this because we provide the password information by email to all voting members. It is the responsibility of members to inform the officers of updates in contact information and email address.

Opposed – members do lose their voting rights all the time. Those who lose their rights should not have access to the private area.

For the motion – this doesn’t say make the drafts public. Members don’t have the responsibility to receive the password. Emails may get lost.

Against – this is not the right way to fix the problem. Perhaps the announcement could contain the password.

Call the question / Matthew Sherman / John Kowalski The motion is called without objection

Vote: Motion Fails 3 : 112 : 28 WNG Motion –

Defer until Friday

2.8. Special Agenda Item The WG Chair would like to recess for a privately funded event to celebrate the passage of the 802.11F and 802.11G standards. The WG Chair thanks the sponsoring companies: Broadcom, Intersil, Texas Instruments, Atheros, and the Wi-Fi Alliance. The WG chair asks the body if there are any objections to taking photographs of this event? None.

2.9. The meeting is recessed at 11:40AM.

3. Closing Plenary Session, Friday, July 25, 2003 3.1. Opening

The meeting is called to order at 8:05AM by Stuart J. Kerry. The agenda is in 03/445r6.

3.2. Agenda The agenda is adopted as stated without objections.

3.3. Announcements


July 2003 doc.: IEEE 802.11-03/511r1

3.3.1.

3.3.2.

3.3.3.

3.3.4.

3.3.5.

3.4.1.

3.4.2. 3.4.3.

3.4.4.

3.5.1. 3.5.1.1. 3.5.1.2.

3.5.1.3.

3.5.1.4.

3.5.1.5. 3.5.1.5.1. 3.5.1.5.2.

3.5.2. 3.5.2.1. 3.5.2.2.

3.5.2.3.

3.5.2.4.

The Wi-Fi liaison report will be posted as 03/0652r0 after this meeting. The Singapore meeting registration will be up today. It will be $700 Australian or $450US. Book the hotel through the registration link. Info for visa requirements and invitation letters are present on the link. We are looking for volunteers for loaning us LCD projectors. We still need interim hosts for May 2004 and September 2004. We have an offer from Samsung for May 2004. CAC members are reminded of upcoming teleconferences and due dates for minutes and web site updates. No new IP statements have been received. The chair requests any new statements, and there are none.

3.4. Documentation Update Straw Poll – how many members think the software has improved the documentation numbering and submission process? 109 for, 0 against, 4 abstain. Send comments on software to Al Petrick. We are moving towards a record year of documents. There are almost 200 documents at this meeting. The chair thanks Broadcom, Intersil. TI, Atheros, and the WiFi alliance for providing funds for the private celebration we had on Wednesday.

3.5. Reports TGe – John Fakatselis

Report in document 03-646 Approved resolutions for LB51. Have approved a new draft. Will

request recirculation ballot on the new draft Announcing an Interim meeting the week of August 24 in New

Jersey. Will conduct a 21 day recirculation ballot, timed to enable the interim

meeting to resolve comments. The objective of the Interim would be to conduct another recirculation.

Discussion There will be a motion to conduct an interim? Yes When will the first teleconference be conducted? There

is 30 day notices. The motion must have the time and date set. We have an ongoing approval for continuing teleconferences until letter ballots are issued.

TGh – Mika Kasslin Report in 03/598 Completed comment resolutions on Sponsor 2nd recirculation Ballot.

Held final motions. Ballot history – sponsor ballot was 92% affirmative. First recirc got to

96%. Final recirculation was 98% affirmative with 2 comments. Only remaining “No” vote has been changed to “Yes”. There were no new technical comments, and all comments were rejected by unanimous vote.

The WG chair reminds all chairs that all comments, whether technical or editorial, need to be addressed.


July 2003 doc.: IEEE 802.11-03/511r1

3.5.2.5. 3.5.2.6. 3.5.2.7.

3.5.2.7.1.

3.5.3. 3.5.3.1. 3.5.3.2. 3.5.3.3.

3.5.3.4.

3.5.3.5.

3.5.3.6.

3.5.3.7. 3.5.3.8.

3.5.3.8.1.

3.5.3.9. 3.5.4.

3.5.4.1. 3.5.4.2. 3.5.4.3. 3.5.4.4.

3.5.4.5. 3.5.5.

3.5.5.1. 3.5.5.2. 3.5.5.3. 3.5.5.4.

3.5.5.5. 3.5.5.6.

3.5.6. 3.5.6.1. 3.5.6.2.

3.5.6.3. 3.5.6.4.

3.5.6.5.

3.5.6.6. 3.5.6.7. 3.5.6.8.

3.5.6.8.1.

The TGh draft will be moving to ExCom and RevCom. The WG wishes Mika good luck and thanks him for all his work. Discussion

There is no need for further recirculation because the comments were attached to a “Yes” vote.

TGi – Dave Halasz Report in document 03/648 Will have a motion for a 15 day recirculation Interim meetings August 26-28 in Portland OR, and October 14-16,

in Herndon VA. Comments on LB57 in 03/452r6. There were 1467 comments, 1214

accepted, and all were addressed. Will have motions for delayed recirculation, authorize and empower

September and October meeting. Considering how security in future task groups is addressed. The

scope of TGi has to have limits so it can be completed. Discussions will continue in WNG

Next meeting to address comments from recirculation ballot. Discussion

Given that there are 7 weeks, why is a 15 day recirculation necessary? We wanted to get the draft out, and then meet at the interim in Portland to address comments.

TGj – Sheung Li

Report in document 03/636 Reviewed remaining comments on letter ballot. Passed motions on 10MHz channelization. Affirmed 10Mhz channelization, but no motion to adopt specific

mechanism was able to pass. Plan to issue a new draft in September.

TGk – Richard Paine Report in document 03/651 Were not able to complete draft for letter ballot. Still have a number of working issues to solve. Objectives for Sept 2003 : conduct Letter Ballot, have additional

presentations. Will continue weekly teleconferences on Wednesdays Planning to have draft ready at start of September meeting.

TGm – Bob O’Hara Report in document 03/574 Processed interpretation requests and forward to WG for approval.

Begin to develop updates to the standard. Used submissions 03/199r1 and 03/382r7 Any members questions on the standard is through the interpretation

request procedure on the IEEE web site. Review of interpretation request and response in beacon timing

issue. The resolution will be presented to the WG for approval. Response in 03/576r1 Discussion

The WG chair reminds the membership that interpretation request are also on the 802.11 web site.


July 2003 doc.: IEEE 802.11-03/511r1

3.5.7. 3.5.7.1. 3.5.7.2.

3.5.7.3.

3.5.7.4.

3.5.7.5.

3.5.7.6. 3.5.7.6.1.

3.5.8. 3.5.8.1. 3.5.8.2.

3.5.8.3. 3.5.8.4.

3.5.8.5. 3.5.8.6.

3.5.9. 3.5.9.1. 3.5.9.2.

3.5.9.3.

3.5.9.4.

3.5.9.5. 3.5.9.6.

3.5.9.7. 3.5.10.

3.5.10.1. 3.5.10.2. 3.5.10.3. 3.5.10.4. 3.5.10.5. 3.5.10.6.

3.5.11. 3.5.11.1.

3.5.12.

WNG – TK Tan Report in document 03/630 Had presentations on VoIP, SDR forum, ad-hoc, data compression,

test methodology, DSRC, 3GPP, child safety, and fast handoff. Conducted a short WIG meeting, more time will be available in

Singapore Upcoming motions on DSRC study group, and 802.11 fast handoff –

planning study groups on these topics. September objectives: Continue receiving contributions on topics of

presentations. Discussion

In May we had planned to have a public presentation from the 802.11 chairs to update the wireless community of Singapore. We are going to re-schedule that, and the Singapore government will bring in several high level speakers. That will be Friday afternoon.

Publicity – Brian Matthews Report in document 03/519 Received reports from industry trade groups, and reviewed press

releases. WiMedia Alliance presented on their activities. Press release for formation of TGn on the server as document

03/556. Will go out in September. Reviewed text for press release of 802.15.2, 802.15.3 and 802.15.4. The WG chair notes that this 802 plenary are 1400 people, and 2/3

of the people are attending wireless groups. HTSG – Jon Rosdahl

Report in 03/520 Special committees on usage model and channel models met this

week, and will provide input to TGn meetings in Singapore. PAR and 5 criteria were posted to ExCom. Comments were received

and responded to. All comments were processed and responded in a timely manner.

802.11n will be created by September. Straw Polls were conducted to start defining selection procedure. Conference call on selections will be held Aug 27th and Sept 3rd.

PAR and 5 criteria have been posted as required by 802 ExCom. The SG chair thanks the members for their help in completing the

work. The WG chair thanks Jon for his exemplary work in the HTSG.

WG Technical Editor – Terry Cole Report in Document 197r3 Met with all TG editors this week, and with the IEEE. Only Draft 3.0 of TGi is available for sale. There will be motions to forward documents to ISO. Electronic attachments are available for SDL and MIB.. IEEE will provide an electronic PICS template.

ANA Status Update There have been several requests in document 03/635. We have

received element numbers. Everything needed for TGe has been received. 802 Handoff Study Group – DJ Johnson


July 2003 doc.: IEEE 802.11-03/511r1

3.5.12.1. 3.5.12.2. 3.5.12.3. 3.5.12.4.

3.5.12.5.

3.5.12.6.

3.5.12.7. 3.5.12.7.1.

3.6.1. 3.6.1.1.

3.6.1.1.1. 3.6.1.1.2. 3.6.1.1.3.

3.6.1.2.

3.6.1.2.1. 3.6.1.2.2.

3.6.1.2.2.1.

3.6.1.2.2.2.

3.6.1.2.2.3.

3.6.1.2.2.4.

3.6.1.2.2.5.

3.6.1.2.2.6.

Report in document (handoff SG) 030. Working on PAR, titles, and problem statement. Approved draft text for these. Will request formation of new WG. The 802.11 WG chair supports

this motion. Planning to have PAR and all other document by the end of

September meeting. There are some questions regarding the relationship between this

SG and 802.11 fast roaming. Discussion

Could the output documents be forwarded to the 802.11 reflector? Yes.

3.6. Standing Orders – Motions in Old Business TGe

Motion: Authorize the TGe editor to issue draft 5.0 by incorporating the TGe comment resolutions from LB #51 and to submit the draft for a 21- day WG recirculation ballot no later than August 1, 2003.

Moved John Fakatselis on behalf of TGe The question is called without objection. Vote on the motion: 113 : 0 : 0

Motion: Conditionally authorize the September 2003 Interim meeting to resolve comments from the TGe recirculation ballot, to create a new draft and to issue a WG recirculation ballot or request initiating a sponsor ballot and conduct any activities required for sponsor ballot assuming that comment resolutions have been completed from the most recent at the time TGe recirculation ballot.

Moved John Fakatselis on behalf of TGe Discussion

To issue a draft to Sponsor Ballot, ExCom approval is required. That would require a conditional approval out of this meeting. That means the final results have to be presented to ExCom today. This is regarding Procedure 10. The intention is to not impede any process toward sponsor ballot. This is not actually approving sponsor ballot.

Without procedure 10 approval a sponsor ballot cannot be started. Would accept an amendment?

Suggests dividing the question – authorization for WG recirculation, and another regarding sponsor ballot.

This has been discussed with ExCom members. It is possible through the use of ExCom email ballots. This motion does not state how it would be done specifically. This motion requests the WG chair initiate an ExCom email ballot.

The WG chair asks the TG chair if the documentation will be in order by that time to initiate an ExCom email ballot. The preference is that these approvals are done in a face to face meeting rather than email. The WG chair cautions that there is a danger in this process.

Recent experiences with email ballots at ExCom have been negative. Urges that we don’t do it again.


July 2003 doc.: IEEE 802.11-03/511r1

3.6.1.2.2.7.

3.6.1.2.2.8.

3.6.1.2.3. 3.6.1.2.4.

3.6.1.3.

3.6.1.3.1. 3.6.1.3.2.

3.6.1.3.2.1.

3.6.1.3.2.2.

3.6.1.3.2.3. 3.6.1.3.2.3.1.

3.6.1.3.2.4.

3.6.1.3.2.5.

3.6.1.3.3.

3.6.1.3.4. 3.6.1.3.4.1. 3.6.1.3.4.2. 3.6.1.3.4.3. 3.6.1.3.4.4. 3.6.1.3.4.5.

3.6.2. 3.6.2.1.

3.6.2.1.1. 3.6.2.1.2.

3.6.2.2.

3.6.2.2.1. 3.6.2.2.2.

3.6.2.3.

3.6.2.3.1. 3.6.2.3.2.

3.6.2.3.2.1.

The WG chair notes that SEC members have dissention, and don’t like it. Warns that there is a risk of a repeat problem.

If all Procedure 10 materials are in place, and there are no objections, then the ExCom wouldn’t mind. This motion could prevent wasting time if everything is in order for Sponsor Ballot at the end of the September meeting. The question is called without objection Vote on the motion: passes 94 : 4 : 14

Motion: Conditionally authorize the Task Group 802.11e meeting, to be held the week of August 24, 2003, to resolve comments from the TGe recirculation ballot, to create a new draft and to submit for a 15 – day WG recirculation ballot assuming that comment resolutions have been completed from the most recent TGe recirculation ballot.

Moved John Fakatselis on behalf of TGe Discussion

What is the proposed status of the meeting? Ad-Hoc vs. Interim? We want limited empowerment to resolve comments and send out a recirculation.

Question to the WG chair – Will the output of the meeting have to be ratified? Yes the chair says the output has to come back to the WG if it is an ad-hoc.

The WG chair rules this is an ad-hoc meeting. The WG chair asks if there is any

request to appeal the ruling? None. the TGi chair grants one more minute to this

motion. The TG chair asks to empower those who meet

to send out a recirculation This should be a formal TGe task group session. In favor

of the motion. Motion to amend: add the word “Interim”.

Moved Matthew Shoemake Second John Fakatselis Call for the orders of the day Moved Jon Rosdahl Defer this motion until new business

TGi Motions – Dave Halasz Motion: At the September IEEE 802.11 interim meeting: empower

TGi to make motions, address comments received from letter ballot, adopt a new draft and forward to WG re-circulation.

Moved Dave Halasz – on behalf of TGi Vote: Passes 105 : 0 : 3

Motion: Authorize a 15-day LB recirculation of 802.11i draft 5.0 by TGi to conclude no later than 8/19/2003.

Moved Dave Halasz – on behalf of TGi Vote: passes 100 : 3 : 2

Motion: Approve a meeting to be held by TGi on October 14, 2003 through 16 empowered to make motions to address comments received from letter ballot, adopt a new draft and forward to WG re-circulation.

Moved Dave Halasz – on behalf of TGi Discussion

This motion enables the comments to be brought back to the full working group before conducting a sponsor ballot.


July 2003 doc.: IEEE 802.11-03/511r1

3.6.2.3.3. 3.6.3.

3.6.3.1.

3.6.3.1.1. 3.6.3.1.2.

3.6.3.2.

3.6.3.2.1. 3.6.3.2.2.

3.6.3.3.

3.6.3.3.1. 3.6.3.3.2.

3.6.4. 3.6.4.1.

3.6.4.1.1. 3.6.4.1.2.

3.6.5. 3.6.5.1.

3.6.5.1.1. 3.6.5.1.2.

3.6.6. 3.6.6.1.

3.6.6.1.1. 3.6.6.1.2.

3.6.6.1.3. 3.6.6.1.3.1.

3.6.6.1.3.2.

3.6.6.1.3.3.

3.6.6.1.3.4.

3.6.6.1.4. 3.6.6.2.

Vote: passes 101 : 3 : 5 TGj Motions – Sheung Li

Motion: Approve teleconferences to be held by TGj no more than every two weeks, prior to 9/14/2003, and at a starting time and date announced at least 30 days in advance using the WG 802.11 reflector.

Moved Sheung Li on behalf of TGj Vote: Passes 90 : 0 : 1

Motion: Approve an ad hoc meeting to be held by TGj prior to 9/14/2003.


Motion: Conditionally authorize a 15-day LB recirculation to conclude no later than 11/10/2003, conditional on the existence of a comment response database and document by TGj meeting rules for letter ballot.


TGk Motions – Richard Paine Motion: Conditionally authorize a 40-day LB to conclude no later than

one week prior to the November plenary asking the question “Should the attached draft by TGk be forwarded to SB,” conditional on the existence of a document by 802.11 WG meeting rules for letter ballot.

Moved Richard Paine on behalf of TGk Vote: Passes 89 : 1 : 5

TGm Motions – Bob O’Hara Motion: To accept and forward the interpretation response contained

in document 03-576 to Linda Gargiulo at the IEEE office as the official response of the 802.11 working group.

Moved Bob O’Hara on behalf of TGm Vote: Passes 87 : 0 : 2

WNG Motions – TK Tan Motion: Request that an 802.11 Study Group be formed to develop

an amendment to extend and modify the 802.11 5GHz PHY to support DSRC technology in the 5.9GHz DSRC (Dedicated Short Range Communication) band, and incorporate necessary MAC changes.

Moved TK Tan on behalf of WNG The chair notes that this motion requires ExCom

Approval. Discussion

Request for a brief synopsis of papers that are presented. Is there sufficient interest to form a study group? Yes there was a large number in WNG in support of this work

There is potential for a turf war. This does not describe WLAN technology. Asking the WG chair for an opinion if this is a PAN.

DSRC is some what of an misnomer. The power can be up to 44dBM up to 1000 meters. The terminology is a hold-over from techniques used for toll reading.

The WG chair affirms that this is an 802.11 activity Vote on the motion: Passes 83 : 9 : 19

Motion: Request to the WG to bring to ExCom that an 802.11 Study Group be formed to develop an amendment to extend and modify the 802.11 MAC to support fast roaming/fast handoff.


July 2003 doc.: IEEE 802.11-03/511r1

3.6.6.2.1. 3.6.6.2.2.

3.6.6.2.2.1.

3.6.6.2.2.1.1. 3.6.6.2.2.1.2.

3.6.6.2.2.2.

3.6.6.3.

3.6.6.3.1. 3.6.6.3.1.1.

3.6.6.3.1.2.

3.6.6.3.1.3.

3.6.6.3.1.4.

3.6.6.3.1.5.

3.6.6.3.1.6.

3.6.6.3.2. 3.6.7. 3.6.8.

3.6.8.1.

3.6.8.1.1. 3.6.8.1.2.

3.6.8.1.3. 3.6.9.

3.6.9.1.

3.6.9.1.1. 3.6.9.1.2.

3.6.10. 3.6.10.1.

3.6.10.1.1. 3.6.10.1.1.1.

3.6.10.1.1.1.1.

Moved TK Tan on behalf of WNG Discussion

Motion to amend: Add the text “with no meetings starting before November” at the end of the motion.

Moved Dave Halasz Second Clint Chaplin

Vote on the amendment: Passes with unanimous consent

Motion as amended: Request to the WG to bring to ExCom that an 802.11 Study Group be formed to develop an amendment to extend and modify the 802.11 MAC to support fast roaming/fast handoff with meetings no sooner than November 2003.

Discussion There was a motion to form a Working Group on

Fast Handoff. How does the WG chair plan to represent this at the ExCom.

The WG chair decides to withdraw his second for the 802. Working Group on fast handoff, and will support this motion for a Study Group in 802.11

How do we differentiate this fast handoff from the 802 WG on Handoff? What is the distinct identity.

The WNG group has clarified the differences with DJ and the 802 group.

This has been endorsed by the chair of the 802 handoff group as distinct. The 802 handoff is between 802 working groups, but this proposed Study group is within 802.11.

The WG chair notes that the 802 handoff SG chair has affirmed this position with him. Vote on the motion: Passes 96 : 2 : 13

Recess for break at 10:03AM, until 10:23AM Publicity Motions

Motion: Believing that the formation of 802.11n is newsworthy and that information in 11-03-556 is accurate and appropriate for a press release, approve transmission of aforementioned document to IEEE-SA marketing staff.

Moved Al Petrick on behalf of Publicity Committee The chair notes that this is dependant on ExCom

Approval Vote: Passes 68 : 0 : 2

TGh Motions – Mika Kasslin Move to forward IEEE 802.11h Draft 3.11 to the IEEE 802 SEC and

the RevCom for final approval. Moved Mika Kasslin on behalf of TGh Vote: Passes 78 : 0 : 1

TGe Motion – continued Motion on the floor: Conditionally authorize the Task Group 802.11e

meeting, to be held the week of August 24, 2003, to resolve comments from the TGe recirculation ballot, to create a new draft and to submit for a 15 – day WG recirculation ballot assuming that comment resolutions have been completed from the most recent TGe recirculation ballot.

Motion to amend – on the floor: Add the word “Interim” Discussion

The WG chair quotes from the 802.11 policies and procedures section 3.6.2. “A TG will


July 2003 doc.: IEEE 802.11-03/511r1

normally meet during 802 plenaries… Interim meetings can be held…. “ The WG chair states that interim meetings are in order. Task Groups may have interim meetings, subject to overruling by higher authorities.

3.6.10.1.1.1.2.

3.6.10.1.1.1.3.

3.6.10.1.1.1.4. 3.6.10.1.1.2.

3.6.10.2.

3.6.10.2.1. 3.6.10.3.

3.6.10.3.1. 3.6.10.3.2. 3.6.10.3.3.

3.6.10.4.

3.6.10.4.1. 3.6.10.4.2. 3.6.10.4.3.

3.6.10.4.3.1.

3.6.10.4.4.

3.6.10.4.4.1. 3.6.10.4.4.2. 3.6.10.4.4.3.

3.6.10.5.

3.6.10.5.1.

3.7.1. 3.7.1.1. 3.7.1.2. 3.7.1.3. 3.7.1.4. 3.7.1.5.

The WG chair requests that the previous ruling on Ad Hoc be struck from the record.

There is a 30 day notice requirement – the notice must be on the web site today. Harry will make sure it is on the web site today.

The meeting actually starts August 25th. Vote on the amendment on the motion: Passes

75 : 0 : 1 Motion on the floor: Conditionally authorize an Interim Task Group

802.11e meeting, to be held the week of August 24, 2003, to resolve comments from the TGe recirculation ballot, to create a new draft and to submit for a 15 – day WG recirculation ballot assuming that comment resolutions have been completed from the most recent TGe recirculation ballot.

Vote on the main motion: Passes 76 : 2 : 3 Motion: Conditionally authorize a Task Group 802.11e Interim

meeting, to be held the month of October, 2003, to resolve comments from the TGe recirculation ballot, to create a new draft and to submit for WG recirculation ballot and or request a sponsor ballot assuming that comment resolutions have been completed from the most recent TGe recirculation ballot.

Moved John Fakatselis Second Dave Halasz Vote: Passes 80 : 2 : 2

Motion to authorize Task Group 802.11e to conduct teleconferences for the purposes of resolving ballot comments for any ballots held prior to the next 802 Plenary.

Moved Matthew Sherman Second Srini Kandala Discussion

This motion lacks the required notice for holding a public motion for 802.11. Motion to amend to include the words “properly

announced 30 days prior to the teleconferences” Moved Bob O’Hara Second Srini K Vote on the amendment: Accepted by

unanimous consent Motion on the floor: Motion to authorize Task Group 802.11e to

conduct teleconferences properly announced 30 days prior to the teleconferences, for the purposes of resolving ballot comments for any ballots held prior to the next 802 Plenary.

Vote: Approved with unanimous consent

3.7. Reports 802.18 – Carl Stephenson

Report in document 18-03-0044. Prepared comments on FCC NPRM on 5GHz allocation. Approved regulatory document, replying to comments of detractors. Updated policies and procedures, Adopted resolution to work with WFA regulatory committee to work

on 802.11d issues regarding passive scanning.


July 2003 doc.: IEEE 802.11-03/511r1

3.7.1.6. 3.7.1.7.

3.7.1.7.1. 3.7.1.7.2. 3.7.1.7.3. 3.7.1.7.4.

3.7.1.8.

3.7.1.8.1. 3.7.1.8.2. 3.7.1.8.3. 3.7.1.8.4.

3.7.2. 3.7.2.1. 3.7.2.2. 3.7.2.3.

3.7.2.4. 3.7.2.5. 3.7.2.6.

3.8.1.

3.8.2. 3.8.3.

3.8.4.

3.9.1. 3.9.1.1.

3.9.2. 3.9.2.1.

3.9.2.1.1. 3.9.2.1.2. 3.9.2.1.3.

3.9.2.1.3.1.

To approve document 18-03-0041-00-0000_802_Cmts_ET-03-

122_r0.doc,authorizing the Chair of 802.18 to do necessary editorial and formatting changes, seek SEC approval as an 802 document, and file the document in a timely fashion with the FCC.

Moved Carl Stephenson an behalf of 802.18 Also approved in 802.15 and 802.16 Second Harry Worstell Vote: approved with unanimous consent.

To approve document 18-03-0042-00-0000_Rep_Cmts_IB_01_185_IB-02-364_Addtl_2.4GHz_Spectrum_r0.doc,authorizing the Chair of 802.18 to do necessary editorial and formatting changes, seek SEC approval as an 802 document, and file the document in a timely fashion with the FCC.

Moved Carl Stephenson an behalf of 802.18 Also approved in 802.15 and 802.16 Second: Amjad Soomro Vote: passes 73 : 0 : 4

802.19 Coexistence TAG – Jim Lansford Report in document 802-19/03-025 Held joint session with 802.15.3a on coexistence usage models. Held a session in 802.11 HTSG and had Q&A for how the process

would be conducted in 802.11n. 802.19 will develop usage model document appropriate for 802.11n

Reviewed coexistence guideline, will split into 3 parts. Conducted vice chair and editor elections Will continue working on usage models in September.

3.8. General Discussion The WG chair had some discussion on the relationship between WNG fast roaming and the 802 handoff. The chairs of the respective groups agree that there is no overlap. Asking the WG chair to reconsider the support of the PAR for the 802 handoff WG The WG chair will revert his position to support the formation of 802 link handoff in SEC. He wishes to strike his previous statement from the record.

3.9. New business HTSG – Jon Rosdahl

The chair of HTSG thanks his chair and editors for their help in the Study Group

WG Technical Editor – Terry Cole Move to submit 802.11-1999 (2003 edition) including 802.11d

amendment, to ISO/IEC for Fast Track Approval through he UK national body. Robin Tasker has volunteered to make the submission, and Terry Cole will be the project editor

Moved Terry Cole Second Garth Hillman Discussion

Isn’t 802.11d in the 2003 edition? Why is it called out specially? Because it is the new material that hasn’t already gone through ISO,


July 2003 doc.: IEEE 802.11-03/511r1


3.9.2.1.3.2. 3.9.2.1.4.

3.10.1. 3.10.2.

3.11.1.

Including 802.11b Cor1? Yes Vote: Passes with unanimous approval.

3.10. Next Meeting The next meeting will be Sept 14-19 in Singapore. The registration link will be on the web site.

3.11. The meeting is adjourned at 11:16 AM Unanimous consent

802.11 eBook Report: Dallas DFW Hyatt - March 10th - 14th 2003 - 03/14/2003 12:00:02 GMT-6 First Last Tomoko Adachi Thomas Alexander Areg Alimian Richard Allen Keith Amann Merwyn Andrade Carl F. Andren David C. Andrus Hidenori Aoki Mitch Aramaki Takashi Aramaki William A. Arbaugh Malik Audeh Geert A. Awater David Bagby Jay Bain Dennis J. Baker Bala Balachander Boyd Bangerter Simon Barber Farooq Bari John Barr Burak Baysal Tomer Bentzion Jan Biermann A. Mark Bilstad Bjorn A Bjerke Simon Black Jan Boer Herve Bonneville William M. Brasier Jennifer A Bray Jim Brennan Phillip Lynn Brownlee Alex Bugeja Alistair G. Buttar IN OH CHUNG Peter John Cain Richard Cam Nancy Cam-Winget Bill Carney Broady Bernard Cash Jayant Chande Clint Chaplin Ye Chen Yi-Ming Chen Greg Chesson Alan Chickinsky

Aik Chindapol Sunghyun Choi Woo-Yong Choi Simon Chun-Yu Chung Frank Ciotti Ken Clements John T. Coffey Terry Cole Anthony Collins Craig Conkling Steven Crowley Nora Dabbous Rolf De Vegt Bretton Lee Douglas Simon John Duggins Baris B Dundar Roger Durand Donald E. Eastlake III Dennis Eaton Peter Ecclesine Jon Edney Natrajan Ekambaram Darwin Engwer Vinko Erceg Javier Espinoza Christoph Euscher Lars Falk Steve Fantaske Weishi Feng Matthew James Fischer Ruben Rabara Formoso Sheila E. Frankel Martin Freedman Satoru Fukumoto John Nels Fuller Marcus Gahler Rodrigo Garcés Atul Garg Al Garrett Vafa Ghazi Monisha Ghosh James Gilb Jeffrey Gilbert Tim Godfrey Wataru Gohda Jim Goodman Yuval Goren Alex Gorokhov Rik Graulus Larry Green Patrick Green

Daqing Gu Srikanth Gummadi Qiang Guo Herman Fred Haisch David Halasz Steve D. Halford Robert J Hall, P.E. Neil Hamady Rabah Hamdi Christopher J. Hansen Yasuo Harada Daniel N. Harkins Thomas Haslestad Amer A. Hassan Vann Hasty James P Hauser Yutaka Hayakawa Morihiko Hayashi Xiaoning He Garth Hillman Christopher Hinsz Jun Hirano Michael Hoghooghi Allen Hollister Keith Holt Satoru Hori Srinath Hosur Russell Housley Frank P Howley, Jr David Hudak John Hughes David Hunter Gyung Ho Hwang Syang-Myau Hwang David Hytha Muhammad Zubair Ikram Daichi Imamura Yasuhiko Inoue Salvador Iranzo Eric Jacobsen Marc Jalfon Kyung Hun Jang Taehyun Jeon Walter Johnson Cesar Augusto Johnston David Johnston Jari Jokela Christopher Richard Jones Tyan-Shu Jou SRINIVASA RAO KOCHERLA Seiji Kachi

Daryl Kaiser Srinivas Kandala Kevin Karcz Mika Kasslin Toshiro Kawahara Patrick Kelly Stuart J. Kerry Vytas Kezys Andrew K. Khieu Ryoji Kido Byoung-Jo Kim Dooseok Kim Edward Kim Joonsuk Kim Yongbum Kim Young-soo Kim Wayne King Günter Kleindl David Kline Toshiya Kobashi Lalit Kotecha John M. Kowalski Bruce P. Kraemer Thomas Kuehnel Denis Kuwahara Joe Kwak KAB JOO LEE Jon LaRosa Paul A. Lambert John B. Langley Colin Lanzl David J. Leach, Jr. Dongjun Lee Jae Hwa Lee Jay Hwa Lee Tae-Jin Lee Richard van Leeuwen Martin Lefkowitz Pen C Li Sheung Li Jie Liang Isaac Lim Wei Lih Yong Je Lim Huashih A. Lin Sheng Lin Victor Chiwu Lin Stanley Ling I-Ru Jim Liu Titus Lo Peter Loc Patrick Lopez

Hui-Ling Lou Luke Ludeman Hui Luo Majid Michael Malek Rahul Malik Jouni Kalevi Malinen Krishna Mohan Malladi Alexander A Maltsev Mahalingam Mani Thomas Maufer Conrad Maxwell Stephen McCann Kelly McClellan Bill McFarland Timothy McGovern Bill McIntosh Jorge Medina Robert C. Meier Klaus Meyer Robert Miller Julian E. Minard David James Mitton Peter R. Molnar Leo Monteban Michael Montemurro Jae Moon Tim Moore Tony Morelli Mike Moreton Robert Moskowitz Oliver Muelhens Joe Mueller Peter Murphy Boyd Murray Peter Murray Andrew Myles Ravi Narasimhan Panos E Nastou Slobodan Nedic Kevin Negus Robert J. Neilsen David B. Nelson Chiu Ngo Terry Ngo Qiang Ni Erwin R. Noble Hiroshi Nomura Karen O'Donoghue Bob O'Hara Kei Obara Hideaki Odadgiri

Yoshihiro Ohtani Chandra S. Olson Tim Olson Lior Ophir Richard H. Paine Mike Paljug Stephen R Palm Jong Ae Park Taegon Park Alan Robert Parrish Glenn Parsons Jeff Paul Lizy Paul Tan Pek-Yew Al Petrick James Everett Pigg Konstantinos P Platis Leo Pluswick Dennis Yu Kiu Pong Stephen Pope James D Portaro Henry Ptasinski Anuj Puri Aleksandar Purkovic Jim Raab Ali Raissinia Noman Rangwala Kamlesh Rath Ivan Reede Stanley A. Reible Joseph Repice Valentine Joseph Rhodes Mark Rich Terry Richards Maximilian Riegel Carlos A. Rios Juan Riveiro Stefan Rommer Jon Rosdahl Ali Sadri Hemanth Sampath Sumeet Sandhu Nicholas J Sargologos Hideaki Sato John Sauer Sid Schrum Michael Seals Joe Sensendorf Krishna Seshadri Peijun Shan N. K Shankaranarayanan

Yangmin Shen Matthew Sherman Ming Sheu Matthew B. Shoemake William Shvodian Floyd Simpson Donald I. Sloan Michael Douglas Smith Yoram Solomon Amjad Soomro Massimo Sorbara Gary Spiess Dorothy V. Stanley William K. Steck Adrian Stephens Carl Stevenson Fred Stivers Warren E. Strand Paul F Struhsaker Hiroki Sugimoto Joan Sundstrom YASUO TOBITA Masahiro Takagi Mineo Takai Katsumi Takaoka Nir Tal Henry Christopher Taylor John Terry Jerry A. Thrasher James D. Tomcik Walt Trzaskus Jean Tsao Chih C. Tsien Kwei Tu Sandra Lynn Turner Takashi Ueda Hidemi Usuba Gary Vacon Patrick Vandenameele Narasimhan Venkatesh Madan Venugopal Nanci Vogtli Gang WU Tim Wakeley Jesse R. Walker Brad Wallace Thierry Walrant Vivek G Wandile Jonathan L Wang Stanley Wang Fujio Watanabe

Mark Webster Stephen Whitesell Peter K. Williams Richard G.C. Williams Jin Kue Wong Timothy G. Wong Patrick A. Worfolk Harry Worstell Charles R. Wright James Chih-Shi Yee Jung Yee Kit Yong Patrick Yu Hon Mo Yung Erol K Yurtkuran Zhun Zhong Glen Zorn per erik christoffersson Javier del Prado bindu gill Ajay gummalla hyosun hwang dong-hoon kwak shmuel levy richard george odea tamara sophia sheton Hans van der Ven Members count: 380

July 2003 doc.: IEEE 802.11-03/670r0 IEEE P802.11 Wireless LANs

Minutes of 802.11 Task Group E MAC Enhancements - QoS

San Francisco, California, U.S.A.

Date: July 21 - 24, 2003

Author: David Hunter Vetronix Phone: 805 966 2000 x3145 e-Mail: [email protected]

1. Monday Afternoon, July 21, 2003

1.1. Opening

1.1.1. 1.1.1.1.

1.1.2. 1.1.2.1.

1.1.2.2. 1.1.2.3. 1.1.2.4. 1.1.2.5. 1.1.2.6.

1.1.3. 1.1.3.1. 1.1.3.2. 1.1.3.3. 1.1.3.4. 1.1.3.5.

1.1.3.6.

1.1.3.7.

Call to order John Fakatselis (JohnF) called the meeting to order at 1:40pm (delayed due to

meeting room setup).

Review of the agenda (JohnF) Tentative meeting agenda: 11-03-445r0-W-802.11-WG-Tentative-Agenda-July-

2003.xls JohnF reviewed the proposed agenda. Fixed time agenda items will be handled at: 7:30pm Thursday, 24 July 2003. Review minutes from previous meeting. Call for papers. Fixed Agenda Items are listed on the agenda.

Approval of the agenda JohnF: Are there any comments on this agenda? Matthew Sherman (MatthewS): Any discussion of ad-hocs? JohnF: Yes, that is scheduled. MatthewS: Probably also need to set aside time for motions. JohnF: That is covered by the agenda as the Old Business and New Business

on the last day (Thursday) of our scheduled sessions. JohnF: I ask the voting members, are there any objections to approving this

agenda? JohnF: I see no objections, so we have an agenda for this meeting.

Minutes of 802.11 Task Group E, July 2003 page 1 David Hunter, Vetronix

July 2003 doc.: IEEE 802.11-03/670r0 1.2. Review of 802.11 policies and rules

1.2.1. 1.2.1.1. 1.2.1.2. 1.2.1.3.

1.2.2. 1.2.2.1. 1.2.2.2.

1.2.3. 1.2.3.1.

1.2.3.2.

1.2.4. 1.2.4.1.

1.3.1. 1.3.1.1.

1.3.1.1.1. 1.3.1.1.2. 1.3.1.1.3.

1.3.1.2.

1.3.2. 1.3.2.1.

1.3.2.2. 1.3.2.3.

Review Objectives for this Session JohnF reviewed the general objectives of comment resolution. JohnF: Are there any other objectives that anyone here has? JohnF: I hear none, so we are agreed on the comments.

New participants JohnF: How many new participants here today? {Secretary: about 15 people raised their hands.}

Reviews of voting rules and process (JohnF) JohnF reviewed the general task group voting procedures and willingness for

open participation, but that motions must be made and voted by voting members.

JohnF: Last meeting was the first meeting we didn’t have a point of order, and hopefully we can do that again.

Letter ballot comment status JohnF: The goal is to resolve all remaining comments by the end of day

tomorrow at the latest, so that we can work Wednesday and Thursday on a draft to go into recirculation.

1.3. Comment resolutions

Document 03/512r0, Status of LB51 Comments, Srini Kandala Srini Kandala (SriniK): We have had 7 teleconferences and one ad-hoc meeting

since the May meeting. The total is 1819 comments, 1173 technical comments; now only have outstanding 19 technical comments and 46 editorial comments. There are three kinds of comments that need to be revisited:

Some changed due to other resolutions. Some did not include enough info to incorporate the draft Some seemed to the editor to break the protocol.

SriniK: With these additions, we have 57 unresolved comments. The summary is in document 03/517.

Technical vs. Editorial Comments JohnF: Apparently TGg had some problems with switching technical and

editorial comments. If you detect any such comments, please bring that to our attention.

SriniK: There are some open resolutions titled “leave it to the editor”. JohnF: We need to review those, also, in detail. We also have to be very clear

why we are rejecting any particular comment. If we don’t give full explanation to someone who can’t be here, we will be discouraging them from participating in the group. We need to be very professional in this feedback.


July 2003 doc.: IEEE 802.11-03/670r0 1.3.3.

1.4.1. 1.4.1.1.

1.4.1.2.

1.5.1. 1.5.1.1. 1.5.1.2. 1.5.1.3. 1.5.1.4. 1.5.1.5. 1.5.1.6.

1.5.1.7.

1.5.1.8.

1.5.1.9.

1.5.1.10. 1.5.1.11.

1.5.1.12. 1.5.1.13.

1.5.2. 1.5.2.1.

1.5.2.2.

1.5.2.3. 1.5.2.4.

1.4. Approval of minutes of May Meeting

Request for approval JohnF: Are there any questions or issues with the minutes of the May 2003

meeting in Dallas? JohnF: I hear none. The minutes of May 2003 are approved with unanimous

consent.

1.5. Papers and Comment Resolutions

Call for papers JohnF: What papers are available to be presented? SriniK: I have one paper on the resolved comments of the ad-hoc groups, 463r8. JohnF: Are any of these from the ad-hoc meeting? SriniK: 463r8 directly includes the results of the ad-hoc meeting. Amjad Soomro (AmjadS): One possible paper. Thomas Kuehnel (ThomasK): Two papers that address comments, one on

EDCF: 412r1. Sid Schrum (SidS): One paper on multicast frame handling that resolves letter

ballot comments. Simon Chung (SimonC): I have a general paper; it does not resolve any

comments. JohnF: We will try to fit your paper in, but comment resolutions will have to come

first. SriniK: Two papers on MoreData and TSOPs. Mathilde Benveniste (MathildeB): May have one paper on addressing

resolutions. MatthewS: I have problems downloading document 502. ThomasK: There are problems with the new numbering scheme, so I also

uploaded that paper as 412r1.

Comment Resolution Process JohnF: I hear no more requests for papers. We have 8 papers, all except one

with motions for comment resolutions. We need these papers on the servers as soon as possible, because we need to get all these resolutions done by tomorrow afternoon (the 3:30pm session).

JohnF: For speed, please everyone review the papers first and we will try to pass the proposed resolutions as a block. The ad-hoc meeting was very productive, and we should be able to agree on those proposed resolutions, as they include many different opinions. Does anyone disagree with this process? Is there any further discussion on the process and timing guidelines (to be done by closing of business tomorrow). I see none, so we will try to follow that process.

MatthewS: We’re still having problems downloading the documents. SriniK: Log onto http://802wirelessworld.com/groupselect.htm. Click on

documents. Click on web browser access to documents. Then choose “11”, then choose “INCOMING-Pre-03-500-Documents-Only” and our documents are there. Also the earlier version, 463r7, is available on the website.

1.5.2.4.1.

1.5.2.4.2.

JohnF: Who is ready to present a paper now? Matthew, would you take the chair temporarily?

Minutes of 802.11 Task Group E, July 2003 page 3 David Hunter, Vetronix MatthewS: Sure.

http://802wirelessworld.com/groupselect.htm

July 2003 doc.: IEEE 802.11-03/670r0 1.5.3.

1.5.3.1.

1.5.3.2. 1.5.3.3.

1.5.3.4. 1.5.3.5. 1.5.3.6.

1.5.3.7. 1.5.3.8. 1.5.3.9. 1.5.3.10. 1.5.3.11. 1.5.3.12.

1.5.3.13. 1.5.3.14.

1.5.3.15. 1.5.3.16. 1.5.3.17.

1.5.3.18.

1.5.3.19.

1.5.3.20. 1.5.3.21.

1.5.3.22. 1.5.3.23. 1.5.3.24.

1.5.3.25.

1.5.3.26. 1.5.3.27. 1.5.3.28. 1.5.3.29.

Document 03/503r0, WME Overview, Thomas Kuehnel ThomasK: This presentation addresses letter ballot comments 267, 184, 1101,

1686, and an alternative for 164. This proposal has been tested with real-world 802.11a equipment from multiple vendors. A test was run with one AP and six STAs running 6 Mbps RTP traffic, with equal priorities. We found that, without admission control, it could handle only up to 3 three streams with sufficient quality – but, with the 4th stream, the QoS could not be assured at all. With EDCA, the higher priority streams are less affected, while the best effort streams are still affected dramatically. Normative text is in document 03/412r1 – also called 502/r1.

MatthewS: Did you also examine lost packets and delay? ThomasK: The delay of the best effort classes was much higher for best effort

than for other classes. MatthewS: At the MAC layer? ThomasK: No, at the IP layer, using RTP. SriniK: Editorial question: there is one reserved bit, but there is another bit for

polled access. Maybe we can combine these bits, and use value 3 for EDCA. MathildeB: Both uplink and downlink? SriniK: Doesn’t make sense for downlink. May be just one way. MathildeB: Don’t think this group has chosen just one way. SriniK: You many be able to do it, but that is very hard to do. AmjadS: Is admission control in the second draft? ThomasK: There is no admission control shown here; can’t really see anything,

because admission control just prevents it. AmjadS: So what’s the difference between draft 1 and draft 2? ThomasK: Helps to differentiated higher priority traffic. There is no draft here

showing just admission control against no admission control. MatthewS: Do the changes you’re proposing include a downlink? Greg Chesson (GregC): Yes. Keith Amann (KeithA): Since the bandwidth for that voice call is so small, did you

look into that in detail? ThomasK: The delay went up for those voice samples, but less so if it had higher

priority. Would have to look up the details. MatthewS: In my testing, I’ve seen that TCP can cause major problems. If you

have high QoS sessions, TCP might time out. ThomasK: It depends a lot on application behavior; also TCP parameter tuning. GregC: Some people claim that they have versions of TCP that distinguish

packets lost from congestion to packets lost otherwise. But that needs to be researched more.

AmjadS: Could you explain the bug changes? ThomasK: Mostly editorial, but otherwise minor changes. MathildeB: The differences between slides 7 and 8; how did you implement

admission control? ThomasK: That is just showing the differences if you did have admission control.

This is just a paper calculation. We simulated on paper “can I admit this stream or not?”.

MatthewS: What is the normative text? ThomasK: Will do that separately. ??: Did you actually define an admission control algorithm? ThomasK: No. That is up to the implementer. But it is a long exercise.


July 2003 doc.: IEEE 802.11-03/670r0 1.5.4.

1.5.4.1. 1.5.4.2. 1.5.4.3.

1.5.4.4. 1.5.4.5.

1.5.4.6.

1.5.4.7.

1.5.4.8.

1.5.4.9. 1.5.4.10. 1.5.4.11.

1.5.4.12. 1.5.4.13.

1.5.4.14.

1.5.4.15. 1.5.4.16.

1.5.4.17. 1.5.4.18.

1.5.4.19. 1.5.4.20.

1.5.4.21.

1.5.4.22. 1.5.4.23.

1.5.4.24. 1.5.4.25.

1.6.1. 1.6.1.1.

Document 03/502r1 / 02/412r1, Proposed Normative Text for EDCA, Mark Bilstad and Thomas Kuehnel

Mark Bilstad (MarkB): The normative text changes are shown in red in this text. JohnF: Please hold your questions for the end. MarkB: The ACs are now named rather than numbered, so can issue something

lower than best effort without worrying about the number values. The largest change is to replace the entire section 7.3.2.14. It now includes admission control mandatory flags. The only thing that is sent in every beacon is the parameter set count. You advertise these only when they change, not all the time.

MatthewS: A STA creates a stream; how does it do that? ThomasK: Similar to HCF, the AP has all the information. The STA requests

that from the AP. KeithA: The paper states that the AC of the contingent window values is a return

value; if a device has been in power save mode, how does it get that information?

MarkB: The parameter set count does occur in every beacon, so you can see that there is a change in the count.

GregC: The STA that sees a new count then can do a Probe Request to find them.

SriniK: But the saving is only 16 bytes, is that the problem? GregC: Well, it is to some folks? MarkB: I also thought the savings were worthwhile, because the parameter

change will be very slow. GregC: The AP should be able to set in STAs a number of other parameters. ThomasK: For most cheap implementations we have done a lot of simulations of

the lowest numbers of parameters. JohnF: We’ll have the vote tomorrow morning, so everyone will have some time

to review these papers. AmjadS: Could you talk more about ACI and ACM? ThomasK: Those were described in the May session. These mainly were just a

name change from last time, for more consistent naming. Remember there is not a 1-1 mapping of priority categories and ACs.

AmjadS: There could be a combination of AP and STAs that can’t work together. MarkB: That is true if the AP advertises it requires Admission Control for a

particular AC. MatthewS: What if AP advertises (??). GregC: If it’s backwards, it’s a bug. WME and HCF need to do it the same way.

You need not to send at the higher priority. AmjadS: If want to downgrade to a lower category, is there a mechanism to

request that? Will AP get this traffic with flags set to the lower categories? ThomasK: Default traffic will not be modified. MarkB: We’re trying to put limits on how much traffic can be set at the higher

access categories. Can always send something best effort. MatthewS: Please review 6.1.1.2; believe that it currently does not set that. JohnF: To repeat, we will entertain motions tomorrow morning, hopefully before

10am, on this topic.

1.6. Closing

Recess JohnF recessed the meeting, until the evening meeting, at 5:25pm.


July 2003 doc.: IEEE 802.11-03/670r0

2. Monday Evening, July 21, 2003

2.1. Opening

2.1.1. 2.1.1.1.

2.2.1. 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. 2.2.1.5.

2.2.1.6. 2.2.1.7.

2.2.1.8. 2.2.1.9.

2.2.1.10. 2.2.1.11. 2.2.1.12. 2.2.1.13.

2.2.1.14.

2.2.1.15. 2.2.1.16.

2.2.1.17.

2.2.1.18. 2.2.1.19.

2.2.1.20.

2.2.1.21. 2.2.1.22. 2.2.1.23.

Call to order JohnF called the meeting to order at 7:30pm.

2.2. Motions

Comment Resolution Motions JohnF: What is the basis of the general motion for the comment resolutions? SriniK: Document 03/463r8. JohnF: Of these resolutions, what ones does anyone have objections to? MatthewS: Comment 784. JohnF: There also were a few comments with small errors that we decided to

remove from this list, so that they can be taken up separately. SriniK: Those are comments 36 170, 173, 784, 1006, 1074, and 1115. SriniK: I move to accept the resolutions, marked green in color, of 03/463r8 as

the responses to the comments in the Letter Ballot 51, with the exception of comments 36, 170, 173, 784, 1006, 1074 and 1115.

Charles Wright (CharlesW): Second. JohnF: Is there any objection to passing this motion? I see none, so this motion

is passed unanimously. JohnF: How many comments did this motion resolve? SriniK: 322. JohnF: Now let’s take up the exceptions from this list. SriniK: Comment 36 should be changed, because this subclause has been

deleted due to the resolutions of the other comments. Comment 173 is on the same subject, and so we should use the same response for it.

SriniK: I move to accept the resolution of the comments as documented in document 03/463r9.

CharlesW: Second. JohnF: Is there any discussion on his motion? Hearing none, are there any

objections to passing this motion as stated? Hearing none, this motion is passed unanimously.

SriniK: The next exception comment is 173, which we previously accepted. But then the time based APSD was not well defined. So the new proposed resolution is “Alternate resolution. Make TSInfo the only element in the DELTS action (not frame) body.”

John Fuller: Second. JohnF: Are there any comments on his motion? Hearing none, are there any

objections to passing this motion as stated? Hearing none, this motion is passed unanimously.

SriniK: I’ll skip comment 784 in favor of Matthew’s comments later. The next comment is 1006. Here 0-10 or 0-15 would be better than 0-256, since it is very unlikely you’ll ever have an AIFS value greater than 15.

SidS: It has never been spelled out clearly. SriniK: I’m proposing not to decline this comment, but to have alternate values. SidS: I believe that when you solve it that way, you miss the STA / AP

difference: should be 1-15 for STA, 0-15 for AP.


July 2003 doc.: IEEE 802.11-03/670r0 2.2.1.24.

2.2.1.25. 2.2.1.26. 2.2.1.27.

2.2.1.28. 2.2.1.29.

2.2.1.30.

2.2.1.31. 2.2.1.32.

2.2.1.33.

2.2.1.34. 2.2.1.35. 2.2.1.36. 2.2.1.37. 2.2.1.38. 2.2.1.39.

2.2.2. 2.2.2.1. 2.2.2.2. 2.2.2.3. 2.2.2.4. 2.2.2.5. 2.2.2.6. 2.2.2.7. 2.2.2.8. 2.2.2.9. 2.2.2.10.

2.2.2.11.

2.2.2.12. 2.2.2.13.

SriniK: I believe that that is what I was trying to say. Tomorrow there will be related proposal on that other issue.

CharlesW: Why not just address max value? SriniK: That was the topic of this comment. SriniK: So now I move to accept the resolution: “Alternate resolution: it is

unlikely that a STA would ever use a value of 255. Instruct the editor to specify the range of 0..15 for dot11HCAIFS and 1..15 or doc11EDCFTableAIFS.” I move to adopt the resolution of this comment in document 463r9.

MathildeB: Second. JohnF: Is there any more discussion on his motion? Hearing none, are there

any objections to passing this motion as stated? Hearing none, this motion is passed unanimously.

SriniK: Comment 174 is close to this topic. Commenter wanted range 1..10. The ad-hoc group had mentioned 0..255. Similarly, comment 1115 is about the same topic. I move to adopt the resolutions of these comments in document 463r9.

MathildeB: Second. JohnF: Is there any more discussion on his motion? Hearing none, are there


MatthewS: Srini, why don’t you also show 784? This new text will go into document 463r9: “Alternate resolution: Instruct the editor to add a response code of “Rejected”. Do not make further requests for X TU, where X is a value provided in a new element provided by the AP, is 4 octets, and, if set to zero, indicates that no further requests should be made.” I move to adopt the resolutions of this comment in document 463r9.

CharlesW: This will be a new information element? Matthew Fischer (MatthewF): Always going to be included? MatthewS: I believe this word is “may”. SriniK: “May” is always there, because this is one of 5 options. John Fuller: Second. JohnF: Is there any more discussion on his motion? Hearing none, are there


Remaining Comments JohnF: How many comments have not yet been addressed? SriniK: Exactly 19. John Fuller: How long will it be to discuss those 19? SriniK: A couple of them could take days. SidS: Some will be addressed by WME. SriniK: Seven will be addressed by that. JohnF: We have already agreed to take up that motion by tomorrow morning. SidS: How many multicast? SriniK: Only one. SriniK: Of the 19 I believe 7 or 8 need to be brought directly to the group. The

other 12 will be covered in other presentations. Some of the 7 or 8 will be difficult.

JohnF: Even if individual, someone needs to type some kind of resolution for us to discuss. Are any of the other papers available now?

SidS: Not yet. JohnF: How about recessing for 30 minutes so SriniK can create some text?

Hearing no objections, we will reconvene in about one half hour.


July 2003 doc.: IEEE 802.11-03/670r0 2.2.3.

2.2.3.1.

2.2.4. 2.2.4.1. 2.2.4.2. 2.2.4.3.

2.3.1. 2.3.1.1.

2.3.1.2.

3.1.1. 3.1.1.1.

3.2.1. 3.2.1.1.

3.2.1.2. 3.2.1.3.

3.2.1.4.

3.2.1.5.

3.2.2. 3.2.2.1.

3.2.2.2. 3.2.2.3. 3.2.2.4.

3.2.2.5. 3.2.2.6.

30 Minute Recess for Ad-Hoc Work Meeting recessed for 30 minutes at 8:10pm.

Reconvening JohnF reconvened the meeting at 8:39pm. JohnF: Srini, is there a proposed resolution from the ad-hoc work? SriniK: Two volunteers have stated that they will write up a proposed resolution

for review tomorrow. Also one of the related comments, number 1788, will be withdrawn. So I suggest that we continue with our ad hoc work until the morning.

2.3. Closing

Recess until morning session JohnF: Are there any objections to doing that? I hear none, so we will continue

the ad-hoc meeting now and reconvene in the next session at 8am tomorrow. JohnF recessed the meeting at 8:40pm.

3. Tuesday Morning, July 22, 2003

3.1. Opening

Call to order JohnF called the meeting to order at 8:08 am.

3.2. Papers

Request for Presentations JohnF: Yesterday I had several requests for presentations. What presentations

are available now? SidS: Am downloading a paper now. JohnF: Are there any other papers available? After the presentations we will go

through the 12 motions we know about and Thomas’s paper. Hopefully we’ll be able to go to recirculation this week.

SriniK: Can Thomas go first, because some of the other resolutions depend on the outcome of his proposal?

JohnF: Ok, then Thomas right after Sid.

Document 03/312r1 and r1a, Broadcast/Multicast , Sid Schrum, et al SidS: This document is under the old document area on the server. Draft 4.0 is

incomplete on broadcast and multicast, especially with respect to priorities, power save, legacy relationships, etc. Need multicast for some QoS traffic.

CharlesW: How about a clarification of basic rates for priority 0? SriniK: If this is the decision, can add that as editorial. SidS: Based on your knowledge now, is there anyone who would object to

including this text? JohnF: I see none. JohnF: To give people the time to review this proposal, we’ll have the vote on

this before lunch but after 10am today.


July 2003 doc.: IEEE 802.11-03/670r0 3.2.3.

3.2.3.1.

3.2.3.2. 3.2.3.3. 3.2.3.4. 3.2.3.5.

3.2.3.6. 3.2.3.7. 3.2.3.8. 3.2.3.9.

3.2.3.10.

3.2.4.

3.2.4.1.

3.2.4.2. 3.2.4.3.

3.2.4.4.

3.2.4.5. 3.2.4.6.

3.2.4.7. 3.2.4.8.

3.2.4.9.

3.2.5. 3.2.5.1.

3.2.5.2. 3.2.5.3.

Document 03/502r0, WME Motion, Thomas Kuehnel ThomasK: This paper addresses comments 1101, 184, 75, 267, 869, 883, 994,

1045 and 1062. I move to instruct the editor to include the proposed normative text from document 11-03-0502-01-003-Proposed-normative_text_for _EDCA.doc.

SidS: Second. AmjadS: Is section 9.10.1 informative or normative? MarkB: That all is informative. SriniK: We already have resolutions for some of those comments that does not

depend on that. Please remove the line on the coverage of the comments. ThomasK: That’s fine with me. SidS: I agree. SriniK: Should exclude the comments 184, 242, 994, 1045. JohnF: Is there any more discussion on his motion? Hearing none, are there


JohnF: After this and Sid’s motion we will have completed all of the comments that were addressed by the teleconferences and ad-hoc groups. After that I would like to give some time to an ad-hoc

Document 03/463r10, Outstanding Letter Ballot 51 Comments, Srini Kandala

SriniK: Described comments 26, 1788 is withdrawn, 184, 82, 242, 994, 1045 and 765, 197, 1065 and their proposed resolutions in draft 11-03-463r9. I move to accept the resolutions of these comments in Document 03/463r9.

MatthewS: What does it mean to say a service period is optional? SriniK: I means not aggregating the streams. It’s not really optional; those

technically are service periods. You’re just not allowed to aggregate them. AmjadS: Could we see comment 416? I would not say “comment accepted”, but

“Alternate resolution.” SriniK: Then this will make the draft 463r10. SriniK: I move to accept the resolutions of comments 26, 1788, 184, 82, 242,

994, 1045, 197 and 1065, 187 in draft 11-03-463r10 as the response to the corresponding LB51 comments. Further instruct the editor to incorporate the recommended actions in the resolutions into the next draft.

John Kowalski (JohnK): Second. JohnF: Is there any more discussion on his motion? Hearing none, are there

any objections to passing this motion as stated? Hearing none, this motion is passed unanimously, as well.

SriniK: Mark offered to resolve comments 105, 1016, 1036.

Comments 105, 1016 and 1036, Mark Bilstad MarkB: These comments are cleared up just by removing the reference to LLC,

and getting rid of those entanglements. So these resolutions become “Comment Accepted. Delete the word ‘LLC’ from the sentence.” So I move to accept the resolutions of comments 105, 1016 and 1036 in draft 11-03-463r10 as the response to the corresponding LB51 comments. Further instruct the editor to incorporate the recommended actions in the resolutions into the next draft.

SriniK: Second. JohnF: Is there any more discussion on his motion? Hearing none, are there



July 2003 doc.: IEEE 802.11-03/670r0 3.2.6.

3.2.6.1.

3.2.6.2. 3.2.6.3.

3.2.7.

3.2.7.1.

3.2.7.2.

3.2.7.3.

3.2.7.4. 3.2.7.5.

3.2.7.6.

3.2.7.7.

3.2.7.8. 3.2.7.9. 3.2.7.10. 3.2.7.11.

3.2.7.12.

3.2.7.13. 3.2.7.14. 3.2.7.15. 3.2.7.16.

3.2.7.17.

Comment 765, Srini Kandala SriniK: I need to fix one typo: I need to remove 1065 from the previous list and

include comment 765. I move to accept the resolution of comment 765 in draft 11-03-463r10 as the response to the corresponding LB51 comments. Further instruct the editor to incorporate the recommended actions in the resolutions into the next draft.

JohnK: Second. JohnF: Is there any more discussion on his motion? Hearing none, are there


Document 03/500r0, End of Service Period Bit Explanation, Amjad Soomro

AmjadS: I believe that there is a general agreement in the group on why the End of Service Bit is needed and used. This just clarifies this usage. We will have a motion later this afternoon. The More bit is to indicate the traffic that has been buffered in the AP due to the power save mode of a device. The EOSP bit, on the other hand, applies to traffic in the old mode that has been indicated to be scheduled at certain periods. Then the End of Service bit indicates the end of the scheduled service period. The changes in the draft add to the confusion. I believe that those changes should be taken out. The More data bit is not to be linked with a TXOP. We also need similar changes in 9.10.2.4.

MarkB: I agree with the plan to clarify these. But I am concerned about the text that is to be deleted. This describes using the More Data bit for an uplink purpose. I don’t see that as needing to be eliminated. This describes how the station signals to the AP.

AmjadS: I’m not strong on that, but believe that More Data bit is to be used for power save purposes only. The first sentence seems to apply to both uplink and downlink.

MarkB: That’s fair. I need to look at the text more just to make sure GregC: Are we overloading the More Data bit here, or are you proposing another

bit? AmjadS: The mechanism of delivery of a traffic stream applies to a data rate

agreement. That mechanism is being handled. GregC: If it means different things in different contexts, then it is correct to say

that the More Data bit is overloaded. I’d prefer to have another bit. AmjadS: I agree. I tried to define an End of Service bit. GregC: I agree with that intent. Need to review the details. AmjadS: This is just an attempt to include language in the draft to make it clear. ??: We need to make it clear that there are more multicast bits that have

nothing to do with power save mode. SriniK: Why not just delete these words, and then make sure More Data bit

works just as in legacy? AmjadS: Agree, but new users won’t understand that. ??: The intent is just the original statement. SriniK: You don’t need those extra words. GregC: Is it clear that the EOSP is not intended to be snooped by other stations.

That is just meant to be an AP to STA control channel, and we’re not trying to piggyback on other functions. We don’t intend this to be used as something to snoop in order to determine whether you can grab the channel. That’s a slippery slope.

SriniK: I agree that that intention is there. It would be nice to have a state diagram that actually shows that, but we don’t have that now.


July 2003 doc.: IEEE 802.11-03/670r0 3.2.7.18.

3.2.7.19.

3.2.7.20. 3.2.7.21. 3.2.7.22.

3.2.8. 3.2.8.1.

3.2.8.2.

3.2.8.3. 3.2.8.4. 3.2.8.5.

3.2.8.6. 3.2.8.7. 3.2.8.8.

3.2.8.9.

3.2.8.10.

3.2.8.11.

3.2.8.12.

3.2.8.13. 3.2.8.14. 3.2.8.15.

3.2.8.16.

3.2.8.17. 3.2.8.18. 3.2.8.19. 3.2.8.20.

MarkB: Jumping back to my previous point: I think that paragraph is only on uplink, and does not get in the way of what you’re trying to accomplish.

AmjadS: It’s fine, but would still like to make changes in the second sentence, which now is an unqualified reference to TXOP.

SriniK: Please identify the comments in the motion. AmjadS: I will do that in the motion. JohnF: We will try to make that motion in the next scheduled session after the

break.

Comments 904, 1047, 112, 867, Srini Kandala JohnF: Anyone else ready to present a paper or make any motions? I hear

none. So we now are complete with the comments except for three outstanding motions.

SriniK: There also is a motion by Matthew Fischer, plus four more comments that can be taken up: 904, 1047, 112, 867. These will need more discussion before we create proposed resolutions. Comment 867 is on broadcast/multicast and priorities.

GregC: Thomas’s proposal covers that. SriniK: Comment 112 is about support for polled delivery. MatthewS: For this you can just cross reference the resolution of comment 784

from yesterday. That is an alternative resolution. SriniK: I move to accept this proposed resolution of Comment 112. SidS: Second. JohnF: Is there any more discussion on his motion? Hearing none, are there


SriniK: Comment 1047 is about signaling the TID. First, the related sentence has been deleted. But there are architectural issues when TID goes across a bridge: it no longer makes sense on the other side, so it might be changed into a priority.

MatthewS: I would tend to say it should be priority on the outgoing interface. This is really more of an AP versus STA side.

ThomasK: There is a potential inconsistency if TCLAS, Tpriority and TID are used at the same time.

SriniK: Within the TSPEC there is both TID and Tpriority, so that mapping would be maintained.

CharlesW: So you have to go to 802.1D params in the second AP. SriniK: That is mapped by the other AP. GregC: We need to agree on the facts first. The QoS control field as well as

802.1D lead to problems when mappings are needed between namespaces. You really do have different namespaces. The TID is local to the link. There are really are only two possibilities – the link allocation could be further up, above the bridging AP, or stick with what we have now, in which TSPECs are limited to a link. These are forced conclusions that are imposed on the separate namespaces.

SriniK: For a wireless bridge it might be able to make it work, but what if the bridge is to a wired LAN? You cannot translate this TID over a wired LAN.

GregC: I agree. CharlesW: Any translation mechanism is at best incomplete. ThomasK: We might still have a VLAN and priorities. SidS: I agree with Greg – we don’t need to handle the wireless bridge with this

comment. In the wireless bridge case you could convey the priority using the TID. There are still issues about the access method. But that would take more work. The AP already has all the TSPECs, so it could map from a TID


July 2003 doc.: IEEE 802.11-03/670r0 into a priority. This is important, because otherwise the next AP would have no information on the priority of this transaction.

3.2.8.21.

3.2.8.22. 3.2.8.23. 3.2.8.24.

3.2.8.25. 3.2.8.26. 3.2.8.27.

3.2.8.28. 3.2.8.29.

3.2.8.30.

3.2.8.31. 3.2.8.32. 3.2.8.33.

3.2.8.34. 3.2.8.35.

3.2.9. 3.2.9.1.

3.2.10. 3.2.10.1.

3.3.1. 3.3.1.1.

3.3.1.2. 3.3.1.3. 3.3.1.4. 3.3.1.5.

3.3.1.6.

3.3.1.7.

SriniK: The only service it’s providing is to make sure the MSDU is received at the station. But should we worry about how that is done on another AP?

ThomasK: Using the priority as a means of classifying. SriniK: That can be done otherwise. ThomasK: But we can use TSPEC exchange for identifying a flow. If we don’t

do that, then we have no means to regenerate the information. SidS: The AP has all the TSPECs, so he can do that. SriniK: The priority information is still in the TSPEC. ThomasK: Even the same TCP port numbers can have different priorities. Need

one sentence that the priority class can be used for identifying the TSID. SriniK: We could do that. GregC: I believe there still can be problems with including the 802.1D tags.

Remember that subnets can be used for security purposes – this can cause AP to move it to another subnet that it has no right to access. We might need to strictly limit it to the priority side. Should zero out the TID bits, because that’s a security hole. The simplest thing is just as Thomas said: make sure you can specify the mapping.

SriniK: As far as this comment, is it necessary to read in the priority number on the receiver side?

ThomasK: I will propose some informative text after 10am. SriniK: Ok, we’ll come back to this later. JohnF: We do have 10 minutes. Are any other papers available? Hearing none,

Srini, how do we cover the other comments that have conflicts? Can they be moved as a block?

SriniK: Yes. JohnF: Then I’ll give some time for an ad-hoc group to work on that. Then we’ll

try to bring that up in the session after lunch. After 10:30 we’ll cover Mathilde’s and Amjad’s presentations, then recess until after lunch for Sid’s and ad-hoc work on the other comments.

Recess JohnF recessed the meeting for the break at 9:52am.

Reconvening JohnF reconvened the meeting at 10:35am.

3.3. More Paper Presentations

Document 03/0565r0, NAV Protection, Mathilde Benveniste MathildeB: This is a simpler proposal than a previous proposal about NAV

resetting. GregC: Can’t a poll be received with data? In that case it should be ACKed. MathildeB: Agree. MatthewS: I believe this proposal goes beyond the related comment. MathildeB: That text is just a recommendation. This can be improved without

major implementation work. GregC: The case for N=1 is good. But if that directly answers the comment, why

do we propose the vector. Why isn’t N=1 good enough? MathildeB: If you keep just one NAV, then you only update it if the incoming is

greater. Need NAV > 1 if receive two back-to-back. Still need to respect (the setting?).


July 2003 doc.: IEEE 802.11-03/670r0 3.3.1.8.

3.3.1.9.

3.3.1.10. 3.3.1.11.

3.3.1.12. 3.3.1.13. 3.3.1.14.

3.3.1.15.

3.3.1.16. 3.3.1.17.

3.3.1.18. 3.3.1.19. 3.3.1.20.

3.3.1.21. 3.3.1.22. 3.3.1.23.

3.3.1.24. 3.3.1.25.

3.3.1.26.

3.3.1.27. 3.3.1.28.

3.3.1.29.

3.4.1. 3.4.1.1.

??: If we retain the array of NAVs, how is it different from just setting a new one?

GregC: Look at a set of NAVs as a stack. Now assume going up more than once, caused by multiple station. If only last one is set, then not properly operating as a stack. But I still find an advantage to N=1.

MathildeB: It is fine to implement that way. MatthewS: I believe that we could just have 1-2 lines of text that permit it without

spelling out all this text about how it can be done. CharlesW: What if don’t reset the NAV? MathildeB: You’re wasting channel time. CharlesW: The proposal only seems to be an optimization that improves

throughput only in particular cases involving BSS overlaps. MathildeB: There already is a lot of mechanism built in on the basis that you will

be resetting NAVs. I’d like to get some feedback on how many people would oppose this.

{Secretary counted only three hands.} MatthewS: I’d like to propose an alternative. “At the end of section 9.10.2.2.1

add ‘A non-AP QSTA which implements a mechanism which separately tracks multiple station addresses and the durations they cause the NAV to be set for, may choose to reset the NAV to a smaller value if they receive a CF_END or QoS CF-Poll with duration/ID set to zero from an address outside their QBSS if the NAV is currently set by that address/BSSID, and the smaller value is selected to be the largest value for which the NAV has been set by any other station. Non-AP QSTA should not reset their NAV otherwise.’ “ Note that this text fits into other text in this paragraph.

MathildeB: How is this different from my proposal? MatthewS: This one works only for a true reset. GregC: In general these proposals are equivalent – Matthew’s proposal is just

saying the same thing, without describing a mechanism. MathildeB: There is a slight difference in functionality. GregC: We really need a specification only of what is axiomatically true. SriniK: The NAV setting in your BSS is always settable by your HC. So this

should only apply to those outside the BSS. MathildeB: I track the longest NAV. MatthewS: But in my proposal, if you had to throw that out, you’d have a record

of what to reset the NAV to. CharlesW: I agree with Matthew’s version in that you only have one NAV left,

then you don’t reset. SidS: You might say that you need at least three to follow these rules. MatthewS: We’ve fought the “how many” battle for years; my proposal is

independent of how many are implemented. How about having a strawpoll between the two texts after 15 minutes to get the two texts set up?

JohnF: Then we will take this to a vote after lunch. Also we’ll be able to take up the comments that Srini is covering. At 1:00 we’ll start with Sid’s and Amjad’s motions, then Srini’s motions, then Mathilde’s and Matthews’s motions.

3.4. Closing

Recess At 11:40am JohnF recessed the meeting until the afternoon session.


July 2003 doc.: IEEE 802.11-03/670r0

4. Tuesday Afternoon, July 22, 2003

4.1. Opening

4.1.1. 4.1.1.1.

4.2.1. 4.2.1.1. 4.2.1.2. 4.2.1.3. 4.2.1.4.

4.2.2. 4.2.2.1.

4.2.2.2. 4.2.2.3.

4.2.2.4.

4.2.2.5.

4.2.2.6. 4.2.2.7. 4.2.2.8. 4.2.2.9. 4.2.2.10.

4.2.2.11. 4.2.2.12.

4.2.2.13. 4.2.2.14.

4.2.2.15.

4.2.2.16. 4.2.2.17. 4.2.2.18.

Call to order JohnF called the meeting to order at 1:14 pm


Request for Presentations JohnF: Who is ready for papers now? SidS: Can present now SriniK: Document 03/517 lists the remaining comments that have problems. JohnF: Everyone please review that document today and make sure you’re

ready to discuss these.

Remaining Multicast / Broadcast Comments, Sid Schrum SidS: This only about a few of the unresolved comments related to broadcast

and multicast. So I move to instruct the editor to incorporate the changes in document 03/312r2 into the next 802.11e draft.

JohnF: Any friendly suggestions or clarifications? ??: The local multicast service AP has a different status; the AP seems to be

more restricted than other stations. Is that intentional? SidS: Currently, if the AP receives a multicast from the DS, it will automatically

send that out with a multicast address. The service class is to enable behavior that is not currently allowed. What restrictions are you talking about?

??: On page 7, section 9.6, it looks like the AP is allowed to use only things from the basic service set, while STAs are allowed to use more.

SriniK: This is the base standard’s restriction on the AP. ??: I agree. SriniK: So this is just adding more capability to the base standard. ??: I want the AP to be able to do the other things that STAs can. SidS: I agree that is not the case. But right now the goal is just to enable more

things. But we have a four hour rule. SriniK: I believe that the change can be made on the floor. JohnF: That seems alright unless there is any objection. Please repeat what

you’re trying to do. SidS: We’re trying to eliminate the restriction to the basic rate. JohnF: We want to emphasize that this change does not meet the four hour rule.

Is that all right with everyone? Hearing none, then that is what we’ll do. SidS: So I’ll change the text to r3 and change the motion to: I move to instruct

the editor to incorporate the changes in document 03/312r3 into the next 802.11e draft. And the r3 draft now eliminates this restriction to the basic rate.

JohnF: Before I ask for a second, are there any other friendly amendments? SriniK: Second. JohnF: Is there any more discussion on his motion? Hearing none, are there



July 2003 doc.: IEEE 802.11-03/670r0 4.2.3.

4.2.3.1.

4.2.3.2.

4.2.3.3.

4.2.3.4. 4.2.3.5.

4.2.4. 4.2.4.1.

4.2.4.2. 4.2.4.3.

4.2.4.4.

4.2.4.5.

4.2.4.6.

4.2.4.7. 4.2.4.8. 4.2.4.9.

4.2.4.10. 4.2.4.11. 4.2.4.12. 4.2.4.13. 4.2.4.14.

4.2.4.15. 4.2.4.16. 4.2.4.17. 4.2.4.18.

4.2.4.19. 4.2.4.20. 4.2.4.21. 4.2.4.22. 4.2.4.23.

Discussion of Comments with Conflicts, Srini Kandala SriniK described the proposed resolutions in 463r10, starting with comment

1804. There only are four remaining unresolved comments: 904, 752, 974, and 1047. There has been a lot of debate on 1047 (about signaling TIDs to other APs). Srini described the proposed resolution of comment 1047, in detail.

MarkB: It doesn’t seem that passing the TID is way to go – really only need to get the 802.1D priority to the other side.

SriniK: But this is the only way to directly address this comment. Hearing no other comments, I move to accept this resolution to comment 1047.

SidS: Second. JohnF: Is there any more discussion on his motion? Hearing none, are there


Motion on 03/500r0, Amjad Soomro AmjadS: I move to instruct the editor to incorporate the changes indicated in

IEEE document: 11-03-0500-000e-proposed-draft-text-end-of-service-period-bit-explanation.

SriniK: What is the reason for the two new lines in section 7.1.3.1.8? AmjadS: This is just to clarify when a particular class of traffic gets delivered.

This applies also to legacy mode. SriniK: This text may be an editorial change in clause 11 rather than here. This

is just descriptive. AmjadS: This should be kept with the other text in that section. So if the whole

thing is moved, that’s fine. MarkB: I believe that we just need to keep that mechanism for the uplink, unless

the group sees a reason to purposely get rid of that capability. SriniK: I would rather delete it. KeithA: I feel uncomfortable about just deleting it now. AmjadS: This paragraph leads to a lot more work in the AP, without more

information being provided. Strawpoll: (a) Delete the whole first paragraph in 7.1.3.1.8; (b) to include the changes as suggested ; and (c) restrict the usage of the More Data bit to power save mode only.

JohnF: I count: 4:4:0. {Secretary: Out of about 70 people present.} SriniK: I still speak against this; there are too many cases. KeithA: But the other case has the same problem. GregC: Not quite, because the QState is new, and the More Data bit has legacy.

The AP would have to check whether the More Data bit comes from a legacy station or not. Basically this doesn’t make a real difference, so why include it?

AmjadS: I agree; it tends to increase the complexity at the AP. AmjadS: Another straw poll: who now favors deleting the first paragraph? JohnF: I count 5:3. SriniK: I move to amend the motion to instruct the editor to delete the first

paragraph in 7.1.3.1.8 of document of 03/500r0. JohnF: There is no second yet, so this is just a friendly amendment. SriniK: So I second the main motion now. JohnF: Any more discussion on this motion? MarkB: There also is some other text that needs to be reviewed. GregC: I speak against. I believe the other text in 7.1.3.1.8 should not be

included.


July 2003 doc.: IEEE 802.11-03/670r0 4.2.4.24.

4.2.4.25. 4.2.4.26.

4.2.4.27.

4.2.5. 4.2.5.1.

4.2.5.2. 4.2.5.3. 4.2.5.4. 4.2.5.5.

4.2.6. 4.2.6.1.

4.2.7. 4.2.7.1.

4.2.8.

4.2.8.1.

4.2.8.2.

4.2.8.3.

4.2.8.4. 4.2.8.5.

4.2.8.6. 4.2.8.7.

SriniK: I move to amend the main motion to add the words “as well as remove the insertions from the subclause 7.1.3.1.8” in the last sentence of the motion.

GregC: Second. JohnF: Is there any more discussion on this motion to amend? Hearing none,

are there any objections to passing this motion as stated? Hearing none, this motion to amend is passed unanimously.

JohnF: Is there any more discussion on the new main motion? Hearing none, are there any objections to passing this motion as stated? Hearing none, this (main) motion is passed unanimously.

Document 03/0565r1, NAV durations , Mathilde Benveniste MathildeB: This proposed text says the STA has a responsibility to track multiple

NAV durations. This includes the point that Charles raised about being reset to 0.

MatthewS: One possible issue is the duration, which is not an absolute time. CharlesW: We need a better name for the multiple NAVs that could exist. MatthewS: I use the word “values” in my version. MathildeB: So substitute “values” for “durations” in this document, and I will

resubmit this as 565r2. Note that underscore blue is deleted text. We’re still working on the text, so can we come back after the break?

Recess JohnF: Ok, we’ll take the 30 minute break now.

Reconvene JohnF reconvened the meeting at 3:33pm.

Document 03/0569r2, Proposed Normative Text for EDCA, Matthew Fischer, Menzo Wentink

MatthewF: This document is written in response to a comment I had in the letter ballot; without changing any of the actual operation, we came up with the draft text to make it more readable. The new minimum AIFSN[AC] needs to be 1. The changes are in 9.10.1.3 and 9.10.1.5. The decision points for decrementing backoff should be at the same decision points of when to transmit. So now you either transmit or back off in the same decision point. The new text in 9.10.1.5 states directly when you are allowed to make these determinations and explicitly defines the slot boundaries at which the operations can be performed. The (d) condition is new; this case was not covered in the previous set of rules. Likewise, the (a) condition for transmission also is new. I also changed some “may”s to “might”s because they do not describe what you’re allowed to do, but what might happen. One key point is that there no longer is a “backoff slot” in the decision process. The figure also still needs another editorial change.

SidS: Above you talked about the slot boundaries, but in the description that accompanies the diagram the text seems to differ from what we had before.

MatthewF: The monitoring is now embedded with the slot boundaries. You’ve already been monitoring for AIFS.

SidS: Are these boundaries on the long vertical lines on the diagram? MatthewF: That is true, but this diagram only shows the (a) case and the (e)

case. SidS: Then what is the time for the “+D2” in the description? MatthewF: I believe that the rest of the unchanged text is not exactly correct, but

I was trying not to change that text also. These are not errors that were introduced by the changes. One key is that the reference point is at the end of the M1 block on the figure.


July 2003 doc.: IEEE 802.11-03/670r0 4.2.8.8.

4.2.8.9.

4.2.8.10. 4.2.8.11.

4.2.8.12.

4.2.8.13.

4.2.8.14.

4.2.8.15.

4.2.8.16. 4.2.8.17. 4.2.8.18.

4.2.9.

4.2.9.1.

4.2.9.2.

4.2.9.3. 4.2.9.4. 4.2.9.5. 4.2.9.6.

4.2.9.7.

4.2.9.8. 4.2.9.9.

4.2.10.

4.2.10.1.

4.2.10.2.

4.2.10.3. 4.2.10.4.

SriniK: Given the modified condition, do we need to make minimum AIFS 2 rather than 1?

MatthewF: I think you’re right; we should change that also. Then to meet the 4 hour rule I will have to make a motion first, then amend it.

SriniK: Then also need to add AIFS in bullet item (c). MatthewF: And need to change the bubble’s pointer to the end of the first

aSlotTime. Menzo Wentink (MenzoW): Then also the “and” in the last bubble should change

to “or”. MatthewF: In general, I believe there is no functional change here, just much

clearer wording. JohnF: We have less than an hour in this session. If Matthew wants to make

changes to this text, please make them now, and I won’t hold you to the four hour rule.

MatthewF: I have now included all of the changes we’ve talked about here. So, I move to instruct the editor to incorporate the changes referenced in document 03/569r3 into the next 802.11e draft.

GregC: Second. MathildeB: Can we have some more time to study these changes? JohnF: Procedurally we have to vote now or postpone. Strawpoll: who would

like to postpone? I have 3 people. Who would like to move forward now? I have 8 people. Do I hear any motion to postpone? Hearing none, is there any more discussion on the motion? Hearing none, are there any objections to passing this motion as stated? Hearing none, this motion is passed unanimously.

Document 03/0565r1 and 03/594r0, NAV Value Proposal, Mathilde Benveniste

MathildeB: We added a clause to take care of the concern that Matthew Sherman expressed.

??: A question about the last two sentences in red: removed when it expires versus none of the non-discarded values being expired?

MathildeB: You have to track whether or not you have discarded any values. ??: What does it mean to say “removed when it expires”? MathildeB: That just means discarded. CharlesW: What does it mean to discard a NAV value? How about adding “; the

shorter are discarded” at the end of the end of the fourth sentence? MathildeB: Done. Any other questions? Is anyone opposed to this? . So I

move to instruct the editor to incorporate the changes referenced in document 03/594r1 into the next 802.11e draft.

MatthewS: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there


Document 03/570r0, Remaining Comments that Have Conflicts, Srini Kandala

SriniK: The document 03/517r0 is now on the server; I have one open question about additional text we need.

JohnF: Why not just reject that comment, because the proposal by the commenter is insufficient?

SriniK: I’ll bring that up to the group. SriniK: The resolution of comment 752 is now included in 568r10 as the result of

the motion earlier on document 03/569r3.


July 2003 doc.: IEEE 802.11-03/670r0 4.2.10.5.

4.2.10.6. 4.2.10.7.

4.2.10.8.

4.2.10.9. 4.2.10.10.

4.2.10.11. 4.2.10.12.

4.2.10.13.

4.2.10.14. 4.2.10.15.

4.2.10.16.

4.2.10.17. 4.2.10.18. 4.2.10.19. 4.2.10.20. 4.2.10.21.

4.3.1. 4.3.1.1.

5.1.1. 5.1.1.1.

5.2.1. 5.2.1.1.

SriniK: The next comment is comment 4, which asks for state diagrams for the queue. There was a volunteer to produce a state diagram, but we have not received the state diagram.

GregC: But which queue is this about? SriniK: I’m making the proposed resolution: Comment declined; it is not which

queue the comment is about. SriniK: Comment 69: I sent an email to TGh; but TGh probably won’t recirculate

again. So the proposed resolution is to replace one phrase in the text. SriniK: Comments 361, 805: I would like to incorporate the text of 03/335r1. SriniK: Comment 129: the alternate resolution is to remove all related

references. SriniK: Similar for comment 139. SriniK: Comment 164: delete all references to APSD. The document 03/517

now becomes r2. SriniK: Comment 156 on retry counters was accepted, but could find no

statement about retry counter for EDCF. This needs to be added. SidS: I can help with that. SriniK: Comment 163 on receive buffer. I am not sure if this really is editorial. In

the meantime most of the receiver operation has been deleted, and it is up to the implementation how it is layered.

SriniK: Comment 84 on side stream traffic. This should be reconsidered as about traffic streams. We either should agree to the commenter or should provide a rationale.

MatthewS: Why encode it? SriniK: Policing. MatthewS: But only should police data frames. So it should be declined. SriniK: Writing the response. JohnF: We’re out of time; instead of rushing it, let’s wrap this up tomorrow

morning.

4.3. Closing

Recess JohnF recessed the meeting at 5:36pm.

5. Wednesday Morning, July 23, 2003

5.1. Opening

Call to order JohnF called the meeting to order at 8:10am.

5.2. Summary

Chair’s summary JohnF: We are almost done with the 1800 or so comments. The last group is

being described by the editor and I’d like to take those comments as a block. Everyone needs to make sure that they have read 03/517r2. Other than that, there is one remaining technical presentation, but there are no motions associated with it. After that we will recess so that the editor can work as fast


July 2003 doc.: IEEE 802.11-03/670r0 and as hard as he can. He will releasing incremental versions of the draft throughout Wednesday and Thursday, so we need everyone to review those drafts and provide timely feedback to Srini, so he can make those adjustments. In addition to the editor’s work, we need volunteers to review all of the technical comments and look (1) for conflicts; (2) changes to the language to be more respectful to the commenter. We think we’ve done a good job, but we need new eyes to review whether the resolution really is accurate, whether there are any conflicts, and whether the responses are respectful to the commenters. It doesn’t help if commenters question the interpretations by the group or question whether they want to participate in the next round. At the end of the comment resolution process this morning, I will be asking for these volunteers to identify themselves.

5.2.1.2. 5.2.1.3.

5.3.1. 5.3.1.1.

5.3.1.2.

5.3.1.3. 5.3.1.4. 5.3.1.5. 5.3.1.6. 5.3.1.7. 5.3.1.8.

5.3.1.9. 5.3.1.10. 5.3.1.11. 5.3.1.12.

5.3.1.13.

5.3.1.14. 5.3.1.15. 5.3.1.16. 5.3.1.17. 5.3.1.18. 5.3.1.19.

AmjadS: How will the volunteer group work, comment by comment? JohnF: I have no bias on this. It depends on the volunteers and how many

volunteers there are. That should be up to the volunteers.

5.3. Comment Resolutions

Remaining comments SriniK: Announcement: the current state of the draft is on the server as draft 4.5

in the TGe work area. I know of 200 comments that still need to be put into the draft. So we need feedback on this from the members.

SriniK: Document 03/517r3 includes the updates to what we did yesterday, plus one more comment, 1126, which asks for a change in 9.10. We have deleted the related paragraph, but we have moved the text to clause 7. I would now like approval of all of this and all of the other comment resolutions in 03/517r3, except for comments 1485 and 872. So, I move that we accept the comment resolutions in document 03/502r3, with the exception of comments 1485 and 872. Further instruct the editor to incorporate the suggested actions into the next draft.

JohnF: Before I ask for a second, are there any friendly amendments? MarkB: Why were those two set aside? SriniK: Basically because we don’t have resolutions yet. JohnF: Any more discussion? MatthewF: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there


JohnF: How many comments are left? SriniK: Two, plus one that Amjad has a comment on. AmjadS: I’d like to have several hours to create a presentation. JohnF: Let’s review that one before you put in those hours of work, but start with

the two excluded comments first. SriniK: Comment 872 applies to 9.10.2.4.3. Originally this was reclassified as

editorial. I believe, instead, we should be a little more explicit. We have many variations of “simple scheduler”; I believe we should choose one that is appropriate.

MarkB: I believe we should remove the work “simple”. SriniK: Maybe “exemplary”? MarkB: Yes. CharlesW: Would rather just say “example scheduler”. SriniK: I move to accept this resolution to comment 872. AmjadS: Second.


July 2003 doc.: IEEE 802.11-03/670r0 5.3.1.20.

5.3.1.21.

5.3.1.22.

5.3.1.23.

5.3.1.24. 5.3.1.25.

5.3.1.26. 5.3.1.27. 5.3.1.28. 5.3.1.29. 5.3.1.30. 5.3.1.31. 5.3.1.32.

5.3.1.33.

5.3.1.34.

5.3.1.35.

5.3.1.36.

5.3.1.37.

5.3.1.38.

5.3.1.39.

5.3.1.40.

JohnF: Is there any additional discussion on this motion? Hearing none, are there any objections to passing this motion as stated? Hearing none, this motion passes unanimously.

SriniK: The next is comment is 1485, which is on short retry limits. I believe that the main thing is that we say there are two counters that increment at different times. The WME proposal covers part of this. Any solution? Should it just be left to the editor? It would be better if we had a specific proposal from someone who is more knowledgeable about EDCF. Otherwise I’ll have to leave the response as is and leave it up to the user. Are there any comments?

SriniK: Hearing none, then the resolution to comment remains as before. This comment was previously approved, so we don’t need a new motion now.

SriniK: Finally, comment 904 on the mean and minimum data rates. Amjad is working to show why the data rates are different. Personally I don’t see much difference between minimum and mean.

MatthewS: I believe there is a difference between minimum and mean. CharlesW: The problem is that the definitions in the text make them sound the

same. MatthewS: Then I’ll take an action to come up with a resolution. MarkB: Does the scheduler treat them differently? MatthewS: No. MarkB: Then why distinguish? MatthewS: That is only a sample scheduler. SriniK: That is a scheduler you would never want to use. AmjadS: Earlier we agreed there would only be 3 or 4 parameters you would use

in a TSPEC. If someone thinks this is not needed, then this is an optional parameter.

SriniK: Then I propose that we resolve this in the next meeting at 1pm, with Matthew’s new text.

JohnF: Is Mr. Chung here to make his presentation? Apparently not. So this brings to conclusion all of the comments except for that one. We will now recess for ad hoc work – to work with the Editor to input the comments, to review the draft, and to review all of the comments to make sure that we’re crisp, clear and respectful to the commenters. I would like to ask for volunteers who are willing to do this comment review.

MatthewS: I believe that we also should have some additional meetings for discussing where we go from here.

JohnF: Any discussion on that topic? We are going to 15 day recirculation, and we undoubtedly will get more comments back. We will suggest another ad-hoc meeting as soon as we get the comments back, so we can knock out the comments before the Singapore meeting. I am investigating whether we can have a second recirculation ballot with those results. So the Singapore session can approve another recirculation ballot or forward to Sponsor Ballot.

MatthewS: I believe we should work on a detailed schedule. We should try to schedule things almost on a daily basis so that we can get some realistic feel when we will be done.

JohnF: I have given a document (which should be published somewhere) to Al Petrick that describes a second recirculation, so we would be finished in about 6 months, with final approval 10 to 12 months from now. It probably will take two recircs before the task group is done. If you count 2 months for each step, that brings us to 8 months.

MatthewS: I believe that other groups have been able to run multiple recirculation ballots in a single meeting cycle, with ad-hoc meetings.

JohnF: I am investigating the possibility of doing that. I want to avoid the possibility of getting another 1800 comments due to oversight. That would take more than another session to cover again. I also make a plea to


July 2003 doc.: IEEE 802.11-03/670r0 commenters not to repeat the same comments over several commenters; if you are from the same company, please consolidate your comments so that you’re not submitting similar or the same comments. Please exercise good judgment. I will give you an answer later.

5.3.1.41. 5.3.1.42.

5.3.1.43.

5.3.1.44. 5.3.1.45.

5.3.1.46.

5.3.1.47.

5.3.1.48.

5.3.1.49.

5.3.1.50.

5.3.1.51.

5.3.1.52.

5.4.1. 5.4.1.1.

5.4.1.2.

6.1.1. 6.1.1.1. 6.1.1.2.

MatthewF: Will the first recirculation ballot be out Monday of next week? SriniK: I will try to get everything incorporated by tomorrow, but I believe that I

need to take another week to go over the whole draft to make sure all the references are right, etc.

JohnF: I would like to start by Friday, because we need 30 days before the ad-hoc.

MatthewS: That would make the best time for an ad-hoc on August 18th. JohnF: Who wants to volunteer to review all of the comments? I see Matthew

Sherman and Amjad. We will recess and start that right away. I see Wim. Wim Diepstraten (WimD): On the recirculation ballot, given only 2 weeks, and

the vacation period, many people won’t be able to participate. JohnF: I will do whatever the group says, but the danger is that we will not be

able to do an ad-hoc session, so things will be delayed. Also, this draft is not all new.

MatthewS: If we slip the schedule a week, that will cost us two months in overall schedule, since we can’t do some things at the Plenary meetings.

JohnF: Any other opinions on the schedule? I also see Wim, CharlesW and Menzo who also are volunteering for the ad-hoc comment review group. How about some of the new people? We’d like to see someone new to participate. I don’t see any volunteers.

CharlesW: Are we just going to go through all the comments in order, and then just stop when we run out of time?

JohnF: We could divide it, since we have 5 volunteers. Srini, do you have any suggestions how to go about the review?

SriniK: The difficulty is that several hundred comments affect more than one clause each. But I’d suggest that it be broken up into clause 2 to 6, 7 to 7.3, 7.4 – 7.5 and annexes, 9, 10 – 11. The merged comment resolution document will 03/020r10 and will be on the server in 10 minutes.

5.4. Closing

Recess JohnF: So let’s recess for the ad-hoc work. Even if everyone else just reviews

all their comments, that will be a help. JohnF recessed the meeting at 9:15am.

6. Wednesday Afternoon, July 23, 2003

6.1. Opening

Call to order JohnF called the meeting to order at 1:07pm JohnF: There is only one comment left to be discussed. Amjad has a

presentation on it.


July 2003 doc.: IEEE 802.11-03/670r0 6.2. Papers and Comment Resolutions

6.2.1. 6.2.1.1.

6.2.1.2.

6.2.1.3. 6.2.1.4.

6.2.1.5. 6.2.1.6. 6.2.1.7.

6.2.1.8.

6.2.1.9. 6.2.1.10. 6.2.1.11.

6.2.1.12. 6.2.1.13.

6.2.1.14. 6.2.1.15. 6.2.1.16. 6.2.1.17. 6.2.1.18.

6.2.2. 6.2.2.1.

6.2.2.2.

6.2.2.3.

6.2.2.4.

6.2.2.5.

6.2.2.6.

Comment 1103, Amjad Soomro and Sai Shankar AmjadS: The twin token bucket is referenced in several IETF RFCs: 3290, 2215

and 2212 . This new document is an attempt to describe twin token buckets. The proposal is to include this text as an informative section.

SriniK: Maybe we should just use the RFC number as a reference; and that might be sufficient.

CharlesW: Are you suggesting that we just refer to this RFC? JohnK: I would be happier if we just referred to that, rather than give the

impression that we’re adding normative text. AmjadS: I agree. CharlesW: That would avoid creating another diagram. AmjadS: The commenter asked for a figure, but even in the original RFC there is

no figure included. SriniK: I believe that Amjad just made a new submission with an official

document number, so that we can just refer to that contribution. AmjadS: I’ll do that. Any other questions? ??: This seems to indicate you need a token per frame. AmjadS: To an extent you’re right, since some kind of framing is there. I can

clarify the text a bit more: I’ll change the text to refer to one or more tokens. JohnF: Any more questions? How do we move on this? AmjadS: I will do a submission, then refer to that document and the related

RFCs in the response. The document number is 03/618r0, Proposed Resolution for Comment 1103. Therefore I move to instruct the editor to include reference to IEEE document 03/618r0 as the resolution for comment 1103.

JohnF: Are there any clarification questions? CharlesW: I’d like to make a friendly amendment to do some edits in the text. AmjadS: Thank you. David Hunter: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there


Comment 904, Min vs. Mean Data Rate, Matthew Sherman MatthewS: I felt we needed just a little more text to accept the comment. So I

suggest that after “This field is to be used to compute the bandwidth” to put in “for any service interval”. This is an optional field, which does not have to be used by the scheduler.

GregC: The service interval can change; we usually work in bits or bytes per second, not per service interval. Since I want to measure usage in both AP and client the same way, I believe that we should be specifying this in bits/bytes per second.

MatthewS: I believe it is still in bits per second, just what service interval you measure it over.

SriniK: Do we really need this; it is not really useful because the codec has determined that it will use one particular rate, so the minimum should be the mean.

MatthewS: I believe that it will be used for video streams and for things that need to be transmitted every second; these will not be the minimum.

GregC: Do you wish to legislate that the AP support some minimum data rate (TXOPs per service period)?


July 2003 doc.: IEEE 802.11-03/670r0 6.2.2.7.

6.2.2.8. 6.2.2.9. 6.2.2.10.

6.2.2.11. 6.2.2.12.

6.2.2.13. 6.2.2.14.

6.2.2.15. 6.2.2.16. 6.2.2.17.

6.2.2.18.

6.2.2.19.

6.2.2.20.

6.2.2.21.

6.2.2.22.

6.2.2.23.

6.2.2.24.

6.2.2.25.

6.2.2.26.

6.2.2.27. 6.2.2.28.

6.2.2.29. 6.2.2.30.

6.2.2.31. 6.2.2.32.

6.2.2.33.

MatthewS: I don’t believe it is specifying TXOPs; it is saying that it needs some minimum data rate. I need to know the period it is being measured over.

GregC: Is one second the minimum? MatthewS: If I don’t give you service for one second, what happens? GregC: The customer won’t be happy. But then some big individual could have

walked in front of the antenna. MatthewS: For many applications I believe one second is too long. CharlesW: This is just one parameter in a whole bunch that is in the TSPEC. So

why is this important? MatthewS: Minimum data rate is there everywhere else. SriniK: But you have “mean” in other places in RFCs. If you look in the RFCs

you don’t see “minimum”. MatthewS: I believe that we need this for DOCSIS. CharlesW: We only need to clarify the difference between minimum and mean. MatthewS: That is my fallback situation; actually the text is clear enough on this.

Though I also don’t know how to measure minimum data rate. CharlesW: Of course, if you’re not transmitting, your minimum is zero. So now I

see why you are concerned with service interval. AmjadS: There is a different way. Mean could be anywhere between min and

max. We can base minimum on mean, and not use mean at all. So I agree with the commenter.

GregC: Is it legal for an HC to respond to a TSPEC, that the client sends with three distinct values, with minimum and mean being the same?

AmjadS: The HC should be allowed to do that. But now there is a statement in the spec that says QAP is not allowed to change the TSPEC.

Ed Reuss (EdR): A lot of this is for efficiency of stat muxes. That info could be useful, and you still could make more efficient usage of the bandwidth. But it is a fundamental aspect of stat muxing that you will go below that minimum at times. If instead you are just doing admission control, all this is irrelevant anyway.

MenzoW: The flowspec RFC has no minimum. Then the AP just accepts or rejects a TSPEC.

MatthewS: I believe that today the AP can reply with an alternative TSPEC when it denies one.

SriniK: I doubt anyone will be able to use the minimum value information. I propose that we accept the comment and delete minimum data rate.

MatthewS: I believe we should accept the comment and clarify the text. There is a use for minimum data rate. Partially I’m trying to get out of defining all schedulers.

SriniK: I’m worried about interoperability problems. MatthewS: If we make this per service interval, the meaning is very clear.

Strawpoll: (1) delete the minimum data rate field; (2) leave text as is and provide an answer to the commenter why they are different, but change nothing in the draft; (3) add a per service interval in the definition. Everyone may vote, but vote only for one.

JohnF: I count 12:5:6. JohnK: I move we remove the minimum data rate and all references from the

draft. GregC: Second. MatthewS: I am against. The minimum data rate is useful for some applications;

I feel strongly that we should it leave as is. AmjadS: I am opposed to do this, first, because the commenter only wanted

clarification; second, I have not had time to review this.


July 2003 doc.: IEEE 802.11-03/670r0 6.2.2.34.

6.2.2.35. 6.2.2.36.

6.2.2.37.

6.2.2.38.

6.2.2.39. 6.2.2.40. 6.2.2.41.

6.2.2.42. 6.2.2.43. 6.2.2.44. 6.2.2.45.

6.2.2.46. 6.2.2.47.

6.2.2.48.

6.2.2.49. 6.2.2.50. 6.2.2.51. 6.2.2.52.

6.2.2.53.

6.2.3. 6.2.3.1.

6.2.4. 6.2.4.1.

6.2.4.2. 6.2.4.3.

JohnK: Of course 802.15 does not have either a minimum or mean data rate. We are doing video, but we don’t know how to use minimum. What we do is in the recommendations we submitted in March. So I call the question.

SriniK: Second. JohnF: Is there any objection to call the question? I see one. Now we must vote

on calling the question. In favor, against, abstain? The outcome is 10:5:6. Therefore the motion fails and we continue the discussion.

GregC: We could take out the mean data rate rather than the mean. It is pretty clear the AP should use one or the other, but not clear which. I think we should vote this motion down, because we honestly don’t know whether we need three rates or two rates. I think we’re moving a little two fast; it is better to do nothing than to do the wrong thing. I think it’s kind of broken, but I don’t know which way it’s broken.

MathildeB: I agree with Greg that we should give it more time; I disagree that we should remove anything. We compute channel time this way.

EdR: I would like some more time to review this. JohnF: A motion to postpone would be in order, if you want to do it. GregC: If this motion is voted down, you could still move to remove mean

instead of minimum. JohnF: Yes, though we would like to have that. MatthewS: I would like to call the question, but will yield to Srini. SriniK: Maybe we can talk outside, and bring it up again tomorrow. MatthewS: I would rather have this happen during the recirculation ballot, so I call

the question. JohnK: Second. JohnF: Is there any objection to calling the question? I see none, so this time

the question is called. This is a technical motion and it requires 75 percent, and this is for voting members only. In favor, against, abstain? I count: 13:11:5 , so the motion fails. Therefore the response is to do nothing.

MatthewS: I can work out a response to the commenter, which we still need. Will take a minute to craft that.

JohnF: Please do that during the next presentation. MathildeB: I have discovered some errors in a previous resolution. SriniK: The differences may be editorial. JohnF: Then please review those changes together and bring them up tomorrow

if you find technical changes. JohnF: There is one more paper, by Qiang Ni. This paper is technical, but

involves no motions.

Document 03/577r0, A Fair Scheduling Scheme for TGe, Qiang Ni Qiang Ni (QiangN): This is a simulation of the QoS scheduler, using 802.11a

with 36Mbps data rate, with audio, plus variable and constant bit rate video applications. The primary parameter tracked is delay. In the proposed solution for minimum delay the TXOP is recalculated for each TS. The conclusion is that a simple scheduler is good for periodic constant bit traffic. But we propose a fair scheduler which uses queue length estimations.

Comment 904, Matthew Sherman MatthewS: I move to adopt the suggested resolution: “Declined. The min and

mean data rates have different meanings. For example, bursty applications such as video have different minimum and mean data rates. It is believed the current draft is sufficiently clear on this issue.”

JohnF: Is there any discussion. Hearing none, is there a second? GregC: Second.


July 2003 doc.: IEEE 802.11-03/670r0 6.2.4.4.

6.2.4.5.

6.3.1. 6.3.1.1.

7.1.1. 7.1.1.1.

7.2.1.1.

7.2.1.2. 7.2.1.3.

7.2.1.4.

7.2.1.5.

7.2.1.6. 7.2.1.7. 7.2.1.8.

7.2.1.9.

7.2.1.10. 7.2.1.11. 7.2.1.12.

JohnF: Is there any more discussion on this motion? Hearing none, are there any objections to passing this motion as stated? Hearing none, this motion is passed unanimously.

JohnF: Are there any more issues, comments? I hear none.

6.3. Closing

Recess JohnF recessed the meeting at 2:40pm until tomorrow’s 8am meeting.

7. Thursday Morning, July 24, 20038

7.1. Opening

Call to Order JohnF called the meeting to order at 8:07am.

7.2. Discussion of Procedures JohnF: Srini is creating a document that shows a number of changes that are

consequences of later votes, but which may not be simple editorial changes. This document will be passed to everyone to review; if anyone thinks there is a technical change in this group, we will raise that issue at 1pm today. Has anyone else who has been reviewing the comments identified any conflicts?

AmjadS: I have found about three related to 7.4 and 7.5. SriniK: There also is some input from Charles and Menzo. Could someone take

the comment distribution sheet and combine the comments into a single document?

AmjadS: I can do that. One of the comments I found probably needs to be brought up as an issue.

MatthewS: I have tried to look at Section 9, but haven’t had sufficient time. I would appreciate someone else helping me on Section 9.

Sudheer Motta (SudheerM): I can help with that. JohnF: Good, please coordinate with Matthew. JohnF: I have some news from this morning’s CAC meeting. The answer to our

questions about two recirculation ballots and the ad-hoc meeting is that yes we can do two recirculation ballots, and technically the meeting we will have is not an ad-hoc meeting but an interim meeting. I don’t know how feasible it is, but this is in an option that we need to keep in mind. Matthew and I looked over the schedule, and the earliest we can do that interim meeting is the week of 24 August. We will discuss this tonight, but I wanted to give everyone a heads up now. If that interim meeting decides to go for a second recirculation ballot, there will be time for that before the next 802.11 meeting.

Harry Worstell (HarryW): I was asked to bring it into this group that the PAR expires in March 2004. You have to ask for an extension; it is recommended that you have to get a PAR extension, and the latest you can do that is November 2003.

SriniK: Can we do that earlier? HarryW: As early as you like. JohnF: We can cover this with a motion tonight.


July 2003 doc.: IEEE 802.11-03/670r0 7.2.1.13.

7.2.1.14.

7.2.1.15.

7.2.1.16.

7.2.1.17.

7.2.1.18.

7.2.1.19. 7.2.1.20.

7.2.1.21.

7.2.1.22. 7.2.1.23.

7.2.1.24. 7.2.1.25. 7.2.1.26. 7.2.1.27.

7.2.1.28.

7.3.1. 7.3.1.1. 7.3.1.2.

MatthewS: It is scary to think this group has gone on for 5 years. Is there special paperwork needed? Also, Matthew Fischer mentioned to me that this is not a whole Working Group issue.

MatthewF: I believe that it should only be a Task Group issue, not a whole Working Group issue. So it does not need to be brought up for vote in the Working Group. Further, you can create motions that say “we can do this if that happens”. We did this earlier in TGg. I’m sure Matthew Shoemake has the documents that need to be submitted.

JohnF: I agree with everything you said. Matthew’s right, we are going to follow the model that TGg followed. I will consult with the TGg principals to coordinate that. If everything works out, great; if not, then we just go on as we have been.

MatthewS: I believe that some in the Working Group meeting may object to this: the first issue may be that people will complain that 15 days is too short for such a long draft. Maybe Srini can announce that the draft will be available as early as possible. The second issue is that people will complain because TGi tried to do something similar because they were told it is not legal. So this might be a controversial vote. Consequently, we will need as much support in the general Working Group meeting tomorrow as we can have.

JohnF: I am going to coordinate with David Halasz, the Chair of TGi, on this issue. Again, the formal vote on this and the interim meeting will be voted at 7pm this evening. Also, the document that Amjad is compiling is needed at 1pm today, so please everyone get your inputs in to him as soon as possible.

SriniK: I have put Draft 4.7 on the server in the TGe working group area (I don’t have permissions to put it under the Drafts area); it contains all of the resolutions that have been made this session, and I am trying to make all of the related changes for consistency.

JohnF: Any other issues before we move to ad-hoc work? MatthewS: There is a fair amount of documentation for Sponsor Ballot, including

collecting all of the comments that are related NO votes, and just those comments, in a single document. They insist on seeing all outstanding NO votes in a single file. So we have to be aware that there still is a lot of work even after we think all of the comments have been resolved.

SriniK: Right now we are using Word, and the document is 7.4 MB; last night it crashed at least 15 times. If we pass this ballot, I will need to convert this file to Frame Maker, anyway. I would like to convert this document to Frame earlier, because it is so troublesome in Word. I believe that TGi is already moving in that direction.

AmjadS: How will anyone other than the editor be affected? SriniK: You will not be able to copy and paste from the draft into your proposed

resolutions. ??: How will you distribute the document? SriniK: It still will be distributed in Frame. CharlesW: Will you do this in the next round? SriniK: No. I probably won’t be able to make this change until September; I just

wanted to let everyone know about it now. JohnF: Any other issues before we adjourn for ad-hoc work? Hearing none, we

will recess until our next session at 1pm.

7.3. Closing

Recess JohnF recessed the meeting at 8:39am until the afternoon session. {JohnF (10 minutes later, announcement to the ad-hoc groups working in the

room): I just received an email from Harry that the earlier discussion was


July 2003 doc.: IEEE 802.11-03/670r0 mistaken – that we really do have until March 2005. So please ignore that discussion.}

8. Thursday Afternoon, July 24, 2003

8.1. Opening

8.1.1. 8.1.1.1.

8.2.1. 8.2.1.1. 8.2.1.2.

8.2.1.3. 8.2.1.4. 8.2.1.5.

8.2.2. 8.2.2.1. 8.2.2.2. 8.2.2.3. 8.2.2.4. 8.2.2.5. 8.2.2.6.

8.2.2.7. 8.2.2.8.

8.2.2.9. 8.2.2.10.

8.2.2.11. 8.2.2.12.

8.2.3. 8.2.3.1.

8.2.3.2.

8.2.3.3. 8.2.3.4. 8.2.3.5.


8.2. Comment Resolutions

Remaining Items JohnF: Lets see if the ad-hoc groups have found any new resolutions. AmjadS: I have just received two new comments to review. It will take me about

15-20 minutes more before I can bring it up to the floor. JohnF: Can you tell us half an hour before you need discussion? AmjadS: We can discuss some of them now. JohnF: Good; let’s do that.

Comment Resolution to be Fixed, Amjad Soomro AmjadS: Comment 163. SriniK: That is a proposed resolution; it needs to be approved. AmjadS: Comment 509. There is a note that the contributor has released this. SriniK: But I have included this anyway, so just exclude this from this list. AmjadS: Comment 1485. SriniK: Sid will have a motion on this later; so it should also be excluded from

this list. AmjadS: Comment 794. SriniK: We should change the line 19 “shall” to “may”, and then we can approve

the result. AmjadS: Then am making this an “accepted” response. AmjadS: That is the [end of the] list; I’ll get a document number and make a

motion on this. JohnF: Then let’s have that motion at 2:00pm. JohnF: We will have Srini’s, then Matthew’s, then Sid’s motions. Please type

your motions so everyone can see them on the screen.

Document 635r0, TGe Request for ANA Assignments, Srini Kandala SriniK: We are not using APSD and random data elements any more, so we can

de-assign the APSD and Random Data ANA numbers. We need new numbers for QoS Capabilities, QBSS Load, EDCA Parameter Set, Traffic Specification, Traffic Classification, Schedule and Management Action.

SriniK: I move to request ANA to make the assignments and de-assignments as shown in Slide 2 of document 03/635r0.

JohnF: Any friendly amendments? I see none. JohnK: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there



July 2003 doc.: IEEE 802.11-03/670r0 8.2.4.

8.2.4.1.

8.2.4.2. 8.2.4.3.

8.2.4.4.

8.2.4.5.

8.2.4.6.

8.2.4.7. 8.2.4.8.

8.2.4.9. 8.2.4.10.

8.2.4.11. 8.2.4.12. 8.2.4.13. 8.2.4.14.

8.2.5. 8.2.5.1.

Minor Issue with Backoff Already Zero, Matthew Fischer. MatthewF: Draft 4.7, 9.9.1.3, has a description of slot boundaries at which a

decision is made. The last condition is meant to cover slot boundaries. If you have a slot time of medium idle, then will fall to condition (e), which causes a decrement or transmit for every slot. But can be at zero already, so have no slot boundaries at which to make decisions, but you may have to make decisions already. So I move to change the text in draft 4.7 appearing in clause 9.9.1.3 and reading as “e) following aSlotTime of medium idle indication which occurs immediately after a decrement of the backoff counter for that channel access function” to read as: “e) following aSlotTime of medium idle indication which occurs immediately after any of these conditions, a) through e) is met for that channel access function”.

JohnF: Any questions before I ask for a second? CharlesW: Is your intent to express the same normative behavior as the 1999

standard? MatthewF: Yesterday we agreed to have slightly different normative behavior

than the 1999 standard. This says that as soon as it hits the queue, you have to wait for a slot boundary to occur.

MenzoW: I think that this is a good change, but I would also like to note that when a period is gone, it doesn’t make much difference.

MatthewF: There is a case with the current version that doesn’t allow you to transmit; I’m trying to fix that.

Menzo: I agree, but believe that we have to be careful here. CharlesW: If channel has been idle for a while, what is the chance packets will

hit the queues for several STAs at once. Personally I don’t think it amounts to much.

MatthewF: That is a little side effect that I don’t think is a problem. Menzo: This text says that it is a good thing for you to stay on slot boundaries for

a while. I believe that this is the proper way to word it. JohnF: Any changes then? MatthewF: No. SriniK: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there


Retry Counters, Sid Schrum SidS: Clause 9.1.6 may need a little more work, but we can move closer to

where we want to be now. This might be an editorial change, but I’d like to make it a clear change. The question is whether retry counters are per station or per MSDU. So I move to instruct the editor to include the following text in the next draft of 802.11e: “9.1.6 Retry Counters QSTAs shall maintain a short retry counter and a long retry counter for each acknowledged MSDU or MMPDU awaiting transmission using the EDCA or HCCA access methods. The initial value for the short and long retry counters shall be zero. The short and long retry counters shall be modified after an attempt to transmit a MPDU or MMPDU according to the rules in Clause 9.2.5.3. For internal collisions occurring with the EDCA access method the appropriate retry counter is incremented. For Block transmissions, the rules in clause 9.11 also apply. QSTAs shall retry failed transmissions until the transmission is successful or until the relevant retry limit is reached.”


July 2003 doc.: IEEE 802.11-03/670r0

8.2.5.2.

8.2.5.3.

8.2.5.4. 8.2.5.5.

8.2.5.6. 8.2.5.7.

8.2.5.8. 8.2.5.9.

8.2.5.10.

8.2.5.11. 8.2.5.12. 8.2.5.13. 8.2.5.14. 8.2.5.15. 8.2.5.16.

8.2.5.17.

8.2.5.18. 8.2.5.19.

CharlesW: How about moving “according to the rules…” until after the attempt to transmission.

SidS: Is everyone OK with this change? Ok, so now we have the text: “9.1.6 Retry Counters QSTAs shall maintain a short retry counter and a long retry counter for each acknowledged MSDU or MMPDU awaiting transmission using the EDCA or HCCA access methods. The initial value for the short and long retry counters shall be zero. The short and long retry counters shall be modified according to the rules in Clause 9.2.5.3 after an attempt to transmit a MPDU or MMPDU. For internal collisions occurring with the EDCA access method the appropriate retry counter is incremented. For Block transmissions, the rules in clause 9.11 also apply. QSTAs shall retry failed transmissions until the transmission is successful or until the relevant retry limit is reached.”

SriniK: How do you account for failed transmissions? SidS: This is attempting to say that, when you are sending polled frames, you

should be following the DCF rules. I admit that there are problems with who failed transmissions count against.

MatthewF: If you delete the last sentence, then that doesn’t come in at all. SidS: It is really the incrementing that is more of a problem; this is still deficient

with respect to that problem. SriniK: I believe this clause should still cover legacy. SidS: I thought this was under HCF access; that’s a problem. The intent was

that this would apply to HCF access, but am not sure that this achieves that. SriniK: I believe you should delete the reference to HCCA and just put it in the

EDCF case. SidS: You mean to leave the HCF case open? SriniK: It is better to do that than make a change that we are uncertain of. SudheerM: I agree with Srini; it would be safer. SriniK: It should then go into clause 9.9.1.7. SidS: I generally agree, but note that we are leaving HCF uncovered. SriniK: I also see a reference to “block transmissions”; this is not defined.

Maybe it would be better to define it. CharlesW: I’m trying to define the paragraph number, but couldn’t we just say

“transmitted under the rules of clause xx”. MatthewF: Need to say “requiring acknowledgement and awaiting transmission” SidS: So now it becomes:

“9.9.1.7 Retry Counters QSTAs shall maintain a short retry counter and a long retry counter for each MSDU or MMPDU requiring acknowledgement and awaiting transmission using the EDCA access methods. The initial value for the short and long retry counters shall be zero. The short and long retry counters shall be modified according to the rules in Clause 9.2.5.3 after an attempt to transmit a MPDU or MMPDU. For internal collisions occurring with the EDCA access method the appropriate retry counter is incremented. For transmissions that use Block acknowledgment, the rules in clause 9.11 also apply. QSTAs shall retry failed transmissions until the transmission is successful or until the relevant retry limit is reached.”


July 2003 doc.: IEEE 802.11-03/670r0

8.2.5.20. 8.2.5.21. 8.2.5.22. 8.2.5.23.

8.2.5.24. 8.2.5.25.

8.2.5.26.

8.2.5.27. 8.2.5.28.

8.2.5.29.

8.2.5.30. 8.2.5.31.

8.2.6. 8.2.6.1.

8.2.7. 8.2.7.1.

8.3.1. 8.3.1.1. 8.3.1.2.

8.3.1.3.

SidS: Are any other comments, things the editor could take up later? JohnF: Does this address any comments? SriniK: At least comment 1497. SidS: I move to instruct the editor to include the following text in the next draft of

802.11e: “9.9.1.7 Retry Counters QSTAs shall maintain a short retry counter and a long retry counter for each MSDU or MMPDU requiring acknowledgement and awaiting transmission using the EDCA access methods. The initial value for the short and long retry counters shall be zero. The short and long retry counters shall be modified according to the rules in Clause 9.2.5.3 after an attempt to transmit a MPDU or MMPDU. For internal collisions occurring with the EDCA access method the appropriate retry counter is incremented. For transmissions that use Block acknowledgment, the rules in clause 9.11 also apply. QSTAs shall retry failed transmissions until the transmission is successful or until the relevant retry limit is reached.”

MatthewF: Second. EdR: The first paragraph is explanatory text. I appreciate that. But would like

more explanation about why “long” and “short”. That would help bring the context together into one file.

SidS: To me this is one of the finer points of a list of finer points that needs more discussion. I don’t disagree. But my sense is that we want to move to the recirculation ballot and come back to this again. The motion has now been seconded, so that would require an amendment.

EdR: Ok; I can make that an editorial comment during the recirculation ballot. JohnF: Is there any more discussion on this motion? Hearing none, are there


JohnF: Are there any more motions? Hearing none, we only have Amjad’s document to go. This is absolutely the last item before we are done with the list. Is there any objection to recess until 2:45?

MathildeB: I have one other item to bring up then. JohnF: OK, then we’ll reconvene at 2:40pm.

Recess JohnF recessed the meeting for 35 minutes at 2:05pm.

Reconvening JohnF called the meeting to order again at 2:40pm.


Document 03/639r1, Amjad Soomro AmjadS: This document is now on the server. JohnF: Please review this document thoroughly, because I am going to ask for a

block motion on all of the comments covered by this document. AmjadS: This covers 63 comments.


July 2003 doc.: IEEE 802.11-03/670r0 8.3.1.4.

8.3.1.5.

8.3.1.6. 8.3.1.7.

8.3.2. 8.3.2.1.

8.3.2.2.

8.3.2.3. 8.3.2.4. 8.3.2.5.

8.3.2.6.

8.3.2.7. 8.3.2.8.

8.3.2.9.

8.3.2.10. 8.3.2.11. 8.3.2.12. 8.3.2.13.

8.3.3. 8.3.3.1.

8.3.3.2.

8.3.3.3. 8.3.3.4.

8.3.3.5. 8.3.3.6. 8.3.3.7.

8.3.3.8.

SriniK: I move to approve the corrections made to the comment resolutions in Document 03/639r1 as the formal response of TGe to the corresponding commenters, with the exception of comment 1485.

JohnF: Are there any other questions, comments or other exceptions? Hearing none, is there a second?



Comment 1485, Sid Schrum SidS: The previous resolution has to be changed, partly because of the adoption

of WME. I move to include the resolution of comment 1485. JohnF: We need to reconsider the previous motion, just to be right [in the formal

approval process]. AmjadS: I move to reconsider the motion we just passed. SriniK: Second. JohnF: Is there any discussion on this motion to reconsider? Hearing none, are

there any objections to passing this motion to reconsider? Hearing none, this motion to reconsider is passed unanimously.

AmjadS: I move to amend to remove the works “, with the exception of comment 1485” from the motion.

SriniK: Second. JohnF: Is there any discussion on this motion to amend? Hearing none, are

there any objections to passing this motion to amend? Hearing none, this motion to amend is passed unanimously.

JohnF: So now we have the new main motion: “I move to approve the corrections made to the comment resolutions in Document 03/639r1 as the formal response of TGe to the corresponding commenters, with the exception of comment 1485.” Srini, do you still make this motion?

SriniK: Yes. JohnF: Matthew, do you still second this motion? MatthewS: Yes. JohnF: Is there any more discussion on this motion? Hearing none, are there

any objections to passing this motion, as stated? Hearing none, this motion is passed unanimously

Backoff Procedure, Mathilde Benveniste MathildeB: This is about the Backoff Procedure in clause 9.10.1.5. I believe we

should add the line “If the CWmax[AC] value is less than CWmin[AC], CW[AC] will be halved upon collision and retrial, as long as the CWmax[AC] value is not surpassed.* Footnote: Implementers are cautioned not to set CWmin[AC] and CWmax[AC] at a level too low for the contention level.”

MenzoW: I would support this change, because I think it could result in good behavior, unless a too small value is selected. But this has been contentious in the past, so I believe this is not a good time to bring up this motion.

MathildeB: If we wait for the next ballot, we will delay the implementers. JohnF: We can only make a motion on this if we insert this into the resolution for

the particular comment. We are out of time, but if no one calls for the orders of the day, we will have the discretion of not meeting again at 3:30pm.

MathildeB: Strawpoll: will anyone oppose a motion on this topic? I see two. MenzoW: How about a strawpoll on how many people support this? MatthewS: I do not oppose it on technical grounds, but I feel it is a risky

mechanism to add. EdR: Some companies are doing this already.


July 2003 doc.: IEEE 802.11-03/670r0 8.3.3.9. 8.3.3.10.

8.4.1. 8.4.1.1.

9.1.1. 9.1.1.1.

9.2.1. 9.2.1.1.

9.2.1.2.

9.2.1.3. 9.2.1.4. 9.2.1.5. 9.2.1.6.

9.2.1.7.

9.2.1.8.

9.2.1.9.

9.2.1.10. 9.2.1.11.

9.2.1.12.

JohnF: Straw poll: who is in favor, against, abstaining? I count 4:3:6. JohnF: I would like to ask the group to recess until the evening meeting, so that

Srini can update the draft. This will end the technical discussion; we have covered all of the comments. At 7:00pm I will ask for New Business; Old Business; then, at 7:30pm sharp, Srini will ask for approval of the new draft; if it is approved, I will ask for any motions for recirculation. The 7:30pm time is a fixed time agenda item. Anything else before the recess? I hear none, so we are recessed until 7:00pm.

8.4. Closing

Recess JohnF recessed the meeting at 3:17pm.

9. Thursday Evening, July 24, 2003

9.1. Opening


9.2. Fixed Agenda Items

Old Business, New Business JohnF: I don’t have anything from previous sessions. Does anyone have any

topics for old business? Hearing none, we move to new business. JohnF: I have prepared some motions for new topics. The earliest interim task

group meeting is the week of August 24th, with all of the comments back for the week before that. The following motions assume the plan of recirculation ballot, interim meeting, then possibly another recirculation ballot before the September Interim WG meeting. There also have been some requests for a 40-day recirculation ballot, which would only be completed the week before Singapore. I would like to hear some debate on which way to go.

SidS: It would be useful if you could educate us on recirculation. JohnF: It is a minimum of 15, but also possibly up to 60 days. SidS: Why is there that latitude? JohnF: It has to be approved by the WG, but anything they approve is OK, as

long as it is 15 days or longer. SidS: I believe there is benefit to completing as soon as possible, but I am

concerned that people would be concerned about this being a major revision of the draft. So I think we have to be cautious about a 15 day recirculation ballot.

MarkB: Assuming we had an ad-hoc on August 24th, what are the considerations?

JohnF: The earliest we can start is August 1st, so August 16th is the earliest it could be completed.

MarkB: Can we make it any longer? JohnF: We could make it up to ending on August 22nd, which would make it

about 20 days. MarkB: I was suggesting we bump it up about a week. If we could get some

more days, I think that would be a good thing.


July 2003 doc.: IEEE 802.11-03/670r0 9.2.1.13.

9.2.1.14.

9.2.1.15.

9.2.1.16.

9.2.1.17. 9.2.1.18. 9.2.1.19.

9.2.2. 9.2.2.1.

9.2.2.2. 9.2.2.3.

9.2.3. 9.2.3.1.

9.2.3.2. 9.2.3.3.

9.2.4. 9.2.4.1.

9.2.4.2. 9.2.4.3.

9.2.5. 9.2.5.1.

9.2.5.2. 9.2.5.3.

9.2.5.4.

9.2.5.5.

9.2.5.6.

JohnF: Any further discussion? We could make it a 21 day recirculation ballot. The flip side is that we are going to be losing a week.

SriniK: I believe we might have several hundred comments, so we might [need the extra time].

Steve Whitesel: It seems that the magnitude of changes in this ballot warrant a 30 day ballot; I could be persuaded to a 21 day ballot. I would encourage you to do it right, rather than do it expeditiously.

MarkB: It seems that most people want both an interim meeting and a 21 day ballot.

JohnF: Is there any objection with that plan before I make the formal motion? SidS: Do we have a volunteer [to sponsor the interim meeting]? JohnF: Let’s get this agreed on first.

Request 21-Day Recirculation Ballot, John Kowalski JohnK: I move to request the 802.11 Working Group to hold a 21-day

recirculation ballot for the newest TGe draft. SriniK: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there

any objections to passing this motion, as stated? Hearing none, this motion is passed unanimously

Request WG Recirculation Ballot, John Kowalski JohnK: I move to conditionally authorize the September 2003 Interim meeting to

issue a WG recirculation ballot or initiate a sponsor ballot assuming that comment resolutions have been completed from the most recent TGe recirculation ballot.

SriniK: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there

any objections to passing this motion, as stated? Hearing none, this motion is passed unanimously.

ANA Information element ID, Srini Kandala SriniK: I move to request the 802.11 Working Group to obtain ANA Information

Element ID changes [that we voted on earlier; see Slide 2 of document 03/635r0].

SidS: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there


Draft Review, Srini Kandala JohnF: It now is 7:30pm, and we have the standing orders to entertain the

motion on the present status of the draft. SriniK: The draft 4.11 is in the Incoming area of the server. SriniK walked through the changes in the draft. The red-marked text is against

Draft 4.0. Srini then walked through the Letter Ballot 51 Comments document and the changes that were made to the ballot resolutions.

JohnF: Please publish both of these documents, so that people can get another week of review before the letter ballot starts.

SriniK: All changes are now in; I would like just to do some more cleanup of the text in the next week.

JohnF: Any more questions for Srini? I hear none, so I need two more motions.


July 2003 doc.: IEEE 802.11-03/670r0 9.2.6.

9.2.6.1.

9.2.6.2. 9.2.6.3.

9.2.7. 9.2.7.1.

9.2.7.2. 9.2.7.3.

9.2.8.

9.2.8.1.

9.2.8.2. 9.2.8.3.

9.2.8.4.

9.2.8.5. 9.2.8.6.

9.2.8.7.

9.2.8.8.

9.2.8.9. 9.2.8.10.

9.2.8.11.

9.2.8.12. 9.2.8.13.

9.2.8.14.

9.2.8.15.

Issue Draft 5.0, John Kowalski JohnK: I move to authorize the editor to issue Draft 5.0 by incorporating the

comment resolutions from LB #51 of TGe as documented in document 03/020r12 and to submit the draft for a 21-day recirculation ballot no later than August 1, 2003.



Complete Responses, Sid Schrum SidS: I move to authorize the editor to complete the responses on editorial

comments not presently addressed in 03/020r12 and incorporate those resolutions in Draft 5.0, which is the draft for the next recirculation ballot to be initiated no later than August 1, 2003.



Authorizations to Resolve Comments and Create Draft, Matthew Sherman

MatthewS: I think we need to authorize us to update the draft during that interim week. I move to authorize the September 2003 Interim meeting to resolve comments and to create a new draft.

JohnK: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there


MatthewS: I move to authorize the TGe meeting to be held during the week of August 24th to resolve comments and to create a new draft.

JohnK: Second. JohnF: Is there any more discussion on this motion? Hearing none, are there


JohnF: Is there any objection to my combining these two motions into one, to reduce the confusion in the Plenary meeting? Hearing none, that’s what I will do.

MatthewS: I believe we cannot initiate a sponsor ballot, we can just reconsider that motion. I move to reconsider that motion.



MatthewS: I move to amend the motion to: replace the text “or initiate a sponsor ballot” to “or request initiating a sponsor ballot and conduct any activities for sponsor ballot”.

SriniK: Second. JohnF: Is there any more discussion on this motion to amend? Hearing none,

are there any objections to passing this motion to amend? Hearing none, this motion to amend is passed unanimously.

JohnF: So now we have a new motion. Is there any more discussion on this motion? Hearing none, are there any objections to passing this motion, as stated? Hearing none, this motion is passed unanimously.

MatthewS: Do we need to make any more motions to empower you?


July 2003 doc.: IEEE 802.11-03/670r0


9.2.8.16.

9.2.9. 9.2.9.1. 9.2.9.2. 9.2.9.3. 9.2.9.4.

9.2.9.5. 9.2.9.6. 9.2.9.7. 9.2.9.8. 9.2.9.9.

9.3.1. 9.3.1.1.

9.3.1.2.

JohnF: We’ve all been there before; they will override whatever you empower me to do, anyway.

Location and Time of Interim TG Meeting SidS: Where can the Interim TG meeting be held? JohnF: I can offer my office location for the Interim TG meeting. MatthewS: I can also offer AT&T. JohnF: Is there any one who objects to hold it in New Jersey? Hearing none,

that is what we will do. I will also announce that tomorrow. JohnF: What dates? SriniK: Starting Monday is fine with me. SidS: How far is the location from the airport? MatthewS: About 45 minutes, apart from rush hour. JohnF: Proposal: TGe will hold a meeting the week of August 24th in New

Jersey hosted by AT&T. Further details will be announced on the reflector. The meeting will begin on Monday August 25th at 9:00am and end on Thursday the 28th at 4:00pm. Sessions will run until 7:00pm the rest of the days.

9.3. Closing

Session close JohnF: The time is up, so this session is over. Hearing no objection, this

session is closed. The session closed at 9:33pm.

May 2003 doc.: IEEE 802.11-03/591r0


Meeting Minutes for 802.11h July

Date: July 22, 2003

Author: Peter Ecclesine Cisco Systems 170 West Tasman, MS 10/5, San Jose, CA 95134-1706 Phone: +1-408-527-0815 Fax: +1-408-526-7864 e-Mail: [email protected]

Tuesday, July 22, 3:30PM session Peter Ecclesine appointed Secretary for the July first session Mika Kasslin presented IEEE 802.11-03/527r0 TGh Agenda, Reviewed the 03/564 TGh Opening Report about Patent Policy status and the agenda. Andrew Myles moves to release Wednesday and Thursday TGh timeslots Chris Hanson seconds motion Approved unanimously Simon Black moves to approve 03/527r1 as the agenda for the week Chris Hansen seconds motion Vote 16 approve, 0 against, 0 abstain Approve the 03/366r1 minutes from the May meeting Moved Andrew Myles, Second Chris Hansen Approved unanimously Andrew Myles moved to accept Sponsor Ballot comment fesolution file 03/529r1 Seconded by Chris Hansen Approved unanimously Moved to forward IEEE 802.11h Draft 3.11 to the IEEE 802 SEC and the RevCom for final approval Moved by Andrew Myles, Seconded by Chris Hansen Approve 13, against 0, abstain 0 `Move a vote of thanks to Mika Kasslin as chair ‘Move a vote of thanks to Andrew Myles as editor Adjourned at 4:05PM

Submission page 1 Peter Ecclesine, Cisco Systems

July 2003 doc.: IEEE 802.11-03/0616r0


TGi San Francisco Plenary Meeting Minutes July 2003

Date: July 21-25, 2003

Author: Frank Ciotti Apacheta Corporation 25231 Grogan’s Mill Rd. Suite 330 The Woodlands, TX 77380 Phone: 281-465-4949 Fax: 281-465-4216 e-Mail: [email protected]

Abstract

Minutes of the 802.11 Task Group I meetings held during the 802.11 WLAN Working Group Plenary Session in San Francisco, California from July 21th – 25th, 2003.

Minutes page 1 Frank Ciotti, Apacheta

July 2003 doc.: IEEE 802.11-03/0616r0

Tuesday, July 22, 2003 10:39am Call to Order & Agreement on Agenda Meeting called to order on Tuesday, July 22, 2003 10:39am by Chair Dave Halasz. Chair: Agenda discussion Proposed Agenda:

o Approve Agenda o Approve meeting minutes from Dallas (03/406) & NH (03/468) o Review IP Policy & Letters Received o Chair’s Status

o TGi Letter Ballots 52 and 57 o Lincoln, NH Ad-Hoc

o Discuss IEEE 802.11i Sponsor ballot pool being renewed o Discuss roaming call for interest o Comment resolution of Letter Ballot 57 (draft 4.0 of TGi)

o 03/485 Submission and motion (work from ad hoc) o Request Submission presentations to address specific comments o Comment resolution o General Submissions o Go to re-circulation!

o Prepare for next meeting. Chair: Any comments on the agenda? None Chair: Any Objection? None Approve meeting minutes Any objection to approving the meeting minutes from Dallas and NH ad hoc? None Minutes approved Review IP Policy

Chair read and showed the two slides requested by WG chair “IEEE-SA Standards Board Bylaws on Patents in Standards” and “Inappropriate Topics for IEEE WG Meetings”. Any objections regarding IP Policy are to be made to either the WG or TG chairs.

Chair: Does anybody have a patent they wish to disclose?


July 2003 doc.: IEEE 802.11-03/0616r0

None

Chair’s Status Ch: LB52 passed with 76% & 2074 comments LB57(re-circ) passed with 78% & 1467 comments (03/452 comments from LB 57) Lincoln, NH ad hoc recap: We divided into sub-groups to process LB57 comments. C: for re-circ, are you unable to comment on sections of the draft that are not new? Ch: Yes, we had to verify that when processing comments. C: we have changed nearly all sections. C: can I submit one comment on a section that changed, and then add additional comments on old text Ch: yes, we are not real strict on this at this time. 802.11i Sponsor Ballot Ch: The 802.11i Sponsor Ballot is being renewed. You have to sign up for this. The previous pool was formed about a year ago. Stuart asked if SB pool for TGe and TGi should be renewed. You need to be an IEEE SA member. You may want to join IEEE at that time as well. C: If you are not currently an SA member, the additional fee is increasing from $10 to $35. Roaming Call for Interest Ch: Clint has proposed a Call for Interest. I would like to take straw polls on this topic to see the direction that the group would like to take. Ch: there were proposals on how to address fast roaming in TGi. That merged into a single proposal. The we looked at improving the current implementation to see if that would address the issue. A motion on the merged proposal failed. Ch: Where should work proceed? TGf, 802 handoff SG, IETF, new TG in 802.11. Clint: doc 03/533 was presented at the WNG meeting last night. A call for interest must be made at the opening plenary of a plenary. I have time scheduled with WNG. C: is it premature to have a handoff group? Can we handle a context transfer in 40ms. Should the fast handoff be part of a maintenance group? Clint: We need more state to be setup in the AP before communications can begin (security, QoS). C: Isn’t this was DJ’s group is doing? Clint: No, he is addressing for all of 802. This is 802.11 specific. The two are complementary. C: The focus in TGi should be to facilitate fast roaming. This includes PMK cacheing. C: A SG can recommend that the work be done somewhere else, instead forming a new TG. Ch: Resources from this TG moving to another SG/TG may impact the work on completing this TG. I people are part of both, then they have to balance their decisions between the two. We have that now with TGe. Ch: The vote we had indicated that this wasn’t even needed. C: How this is resolved will depend on how TGe and TGi end up. If we can’t resolve it in TGi, others may not want to try to resolve it in a new TG. A SG at some time is critical. Clint: There must be a demand for fast roaming otherwise we wouldn’t have the proposals.


July 2003 doc.: IEEE 802.11-03/0616r0

C: if we facilitate fast roaming, we are not ignoring it. It is not only a TGi issue. C: we do have the option to put this into the maintenance PAR. This may be the most efficient way of handling this instead of creating a new PAR. C: whatever we do will be an incomplete solution because of the limitations of our PAR. Ch: I would like to ask for a straw poll. Straw Poll by Dave Halasz

The discussions for Call for Interest and Study Group for Fast Roaming should be delayed until the November 802.11 WG meeting.

Result: 32-11-16 Straw Poll by Dave Nelson

The formation of a Fast Roaming Study Group or Task Group would alleviate the Letter Ballot ‘No’ votes in TGi related to Fast Roaming.

Result: 11-16-32 Ch :any other discussion or straw polls on this topic? C: protecting management frames is something that TGi did not address at all. Perhaps that should be the focus of a new SG. C: we are straying from the issue for a Call for Interest. Straw Poll by Pratik Mehta

The largest issue for TGi is the issue of support for Fast Roaming. Result: 0-30-19 Straw Poll by Dave Nelson

TGi should recommend to the full 802.11 WG that the Fast Roaming Study Group proceed. Result: 42-6-19 Recessed at 12:03pm Resume 1:02pm Motion by Al Potter

TGi should recommend to the full 802.11 WG that the Fast Roaming Study Group proceed.


July 2003 doc.: IEEE 802.11-03/0616r0

Second: Bob Moskowitz Discussion: Al: I wanted to make the Straw Poll conclusion official. C: for: we should start now to make sure the work is started because it will take them into next year. C: against: resources taken from TGi. C: A SG is not guaranteed to become a TG. Motion to amend by Jon Edney

TGi should recommend to the full 802.11 WG that the Fast Roaming Study Group proceed but not before November of this year.

Second: Andrew Khieu Discussion: C: against: These are two different results. We should split the motion. Vote: 29-3-6 Passes New main motion:

TGi should recommend to the full 802.11 WG that the Fast Roaming Study Group proceed but not before November of this year.

Discussion: Ch: I do not have time on the Wednesday mid-session plenary agenda to discuss this. Vote: 31-2-5 Passes Ch: move on to the next agenda item Comment Resolution of LB57 (Draft 4 of TGi) Discussion: C: The proposed new draft needs to be merged with draft 4.1. Annex C seems to be missing. C: The changes are in the document, but did not print properly. C: have the MIB changes been validated against a MIB compiler? C: no


July 2003 doc.: IEEE 802.11-03/0616r0

C: can we see a list of all of the comments that are addressed with this submission? Motion by Tim Moore:

Instruct the editor to create the TGi draft from submission 03/485r0 Second: Merwyn Andrade Discussion: C: if this fails, can we create new motions for the individual Clauses? Ch: yes C: does this provide the editor with enough latitude to incorporate missing sections? C: The editor will need to come back to the TG for some of these. Vote: 41-0-3 Passes Ch: Tim will provide the number of comments addressed by this motion tomorrow. Ch: the spreadsheet indicates there are about 10% remaining. Ch: we don’t make motions to reject a comment. However, we do supply a reason why the comment was reject. Submissions for comment resolution

03/563 Nick Petroni – Fast roaming performance 03/483 Tim Moore – Group Key optimization 03/484 & 03/419 Tim Moore – PMK ID’s 03/495r1 Tim Moore – IBSS/802.1aa Port Valid 03/547 Tim Moore – MIB name variable fixes 03/561 Tim Moore – IE in the 4-way handshake 03/560 Tim Moore – Clause 10 & Annex D misc 03/474 Tim Moore – MIB compliance 03/477 Tim Moore – Dis-association procedures 03/471 Jesse Walker – Clause 8.4 additional changes Jesse Walker – Annex C 03/493 Robert Moskowitz – Pre-authentication 03/545 Dororthy Stanley – Clause 5

Submissions for comment resolution Submission: Nick Petroni – doc 03/563r0 – An Empirical Analysis of the 4-way Handshake


July 2003 doc.: IEEE 802.11-03/0616r0

Discussion: N: PSK used to ensure timings were only for 4-way and not key management. C: Where does Airopeek obtain its times from? Host time? C: It takes the OS time, plus hw time added to this to provide more accuracy. C: was this all WPA equipment? N: Not sure – most was beta. C: The two APs we supplied were. One of the clients was not certified yet. C: was this all the same OS N: yes C: all TKIP? N: yes C: OS scheduling problems result in long delays. There is an issue with timing of when Media Sense and msg 1 of 4-way are received. C: what rate were all these tested? N: left at default. C: Were all of these 802.11b? N: one was a b/a/g card. C: the faster cards tend to be Card-bus Vs. PIO. C: how do we define the differences as bugs or interop differences. C: most of the issues I have seen are due to bugs. C: Shouldn’t the EAPOL-Start reset the 4-way handshake. C: yes, but this is PSK so the EAPOL-Start is being ignored. Submission: Tim Moore – doc 03/547 802.11i MIB variable name fixes T: Inconsistencies between MIB names in MIB and MIB names in text. Motion by Tim Moore:

Instruct the editor to incorporate the following changes into the TGi draft:

In clause 5.9.5 and 8.4.6.2 change: dot11RSNPMKLifetime

To: dot11RSNAPMKLifetime


July 2003 doc.: IEEE 802.11-03/0616r0

In clause 7.2.3.1, 7.2.3.4, 7.2.3.6 and 7.2.3.9 change

dot11RSNEnabled To:

dot11RSNAEnabled

In clause 7.3.2.9 change: dot11RSNNumberOfReplayCounters

To: dot11RSNANumberOfReplayCounters

Second: Clint Chaplin Discussion: None Any objection? None Motion Passes Any objection to recessing until 3:30pm? None Recessed at 2:50pm Resume at 3:30pm Motion by Tim Moore:

Instruct the editor to incorporate the following changes into the TGi draft: Change:

Add to dot11StationConfigEntry dot11RSNANumberOfReplayCounters INTEGER

To:

Add to dot11RSNAConfigEntry dot11RSNANumberOfReplayCounters INTEGER

Change:

Add definition of dot11RSNANumberOfReplayCounters dot11RSNANumberOfReplayCounters

SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION

"Specifies the number of replay counters: 0 –> 1 replay counter, 1 –> 2 replay counters, 2 –> 4 replay counters, 3 –> 16 replay counters"

::= { dot11StationConfigEntry 2 }


July 2003 doc.: IEEE 802.11-03/0616r0

To: Add definition of dot11RSNANumberOfReplayCounters

dot11RSNANumberOfReplayCounters SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION

"Specifies the number of replay counters: 0 –> 1 replay counter, 1 –> 2 replay counters, 2 –> 4 replay counters, 3 –> 16 replay counters"

::= { dot11RSNAConfigEntry 20 }

Second: Merwyn Andrade Discussion: None Any objection? None Motion Passes Submission: Tim Moore – doc 03/474 C: I would suggest that the MIB be run through a MIB compiler Motion by Tim Moore:

Instruct the editor to incorporate document 11-03-474r0 into the TGi draft: Second: Dorothy Stanley Discussion: None Any objection None Motion Passes Submission: Tim Moore – doc 03/483 Discussion: C: this eliminates the synchronization issues. C: I would prefer that this be mandatory. C: We are stuck with the way it is because of WPA. C: WPA is a different OUI. C: this reduces a re-key from 6 to 4 messages.


July 2003 doc.: IEEE 802.11-03/0616r0

C: are there any cases where you would only want to send the pairwise key, and not the group key? Straw Poll by Tim Moore:

If we include the Group Key optimization in doc 03/483, we should make it mandatory in an RSN. C: do people understand the consequences of making this optional or mandatory? Ch: If the issue is with WPA, there is a different OUI. C: The optimization would solve issues I had when performing WPA testing. C: the WPA spec is closed. C: has this been prototyped? T: no C: the sta could choose to plumb the group key before the pairwise key with this method. If we don’t want that to happen, then we should specify the order of the plumbing. C: the pseudo code is written to plumb the pairwise key first. Result: 43-0-16 Submission: Dan Harkins – doc 03/419 Naming Cached PMK’s Discussion: C: is this based on 484r0? D: 484r1. The STA MAC address is included. C: The approach that the IETF EAP group is looking at does not expose any PMK information. D: the same HMAC-SHA has been used by many other security algorithms that have received much cryptographic analysis. C: the EAP group is using other (human readable) names for PMK’s C: you need to include the SSID in the construct. The AP may have multiple SSID’s. D: why? What breaks. C: It has to do with the table lookup. D: it doesn’t seem to be necessary. C: another option is to do a SHA1 and truncate to 128. D: HMAC is FIPS compliant. Is SHA1 alone? C: yes D: then I agree, it will speed things up to do SHA1 instead of HMAC-SHA1. C: a concern is if PSKs are used, a dictionary attack is possible. C: an attacker can do the same thing by sniffing any 4-way handshake message. C: but this gives the attacker multiple points to validate that he has the correct key. Jesse plans to draft an alternate scheme for compact PMK’s using human readable form. C: Unless a human has to actually read them, why make them so? C: my experience is that it is helpful for debugging.


July 2003 doc.: IEEE 802.11-03/0616r0

C: having unique names is more difficult if human readable format is used. C: where does the STA get the value for the PMK cache lifetime? D: It is a MIB variable. C: how does it get set? D: don’t know – magical fairies? C: we need more analysis on the key format before we incorporate this into the draft. T: there is a need for n>1 for when the AP contains more than one cached PMK for a given STA Motion by Tim Moore:

Instruct the editor to incorporate document 11-03-484r1 into the TGi draft, excluding Clause 8.5.1.2: Second: Dan Harkins Discussion: Motion to amend by Dave Nelson

Instruct the editor to incorporate document 11-03-484r1 into the TGi draft, excluding Clause 8.5.1.2, and change dot11RSNPMKLifetime to dot11RSNAPMKLifetime:

Second: Robert Moskowitz Discussion: None Any objection? None Motion Passes New main motion:

Instruct the editor to incorporate document 11-03-484r1 into the TGi draft, excluding Clause 8.5.1.2, and change dot11RSNPMKLifetime to dot11RSNAPMKLifetime:

Discussion: None Vote: 37-6-9 Passes Submission: Tim Moore – doc 03/560 – Clause 10 and Annex D


July 2003 doc.: IEEE 802.11-03/0616r0

The proposed resolution for Comment 378 does not address the Comment Motion by Tim Moore

Instruct the editor to include the resolutions specified in document 03/560 for LB57 Comment 226 with ‘may’ changed to ‘might’, and reject LB57 Comment 378.

Second: Dave Nelson Discussion: None Any objection? None Motion Passes Motion by Tim Moore

Instruct the editor to delete the ‘Tx’ parameter from section 10.3.11.1.2 MLME-SETKEYS. (Not used in the draft)

Second: Jesse Walker Discussion: None Any objection? None Motion Passes Discussion on Comment 436 Consensus is to reject this Comment. Could Discussion on Comments 501, 504, 1144, 1196, 587 Motion by Paul Lambert

Instruct the editor to remove Group Key only support from the TGi draft. Second: Kevin Hayes Discussion: C: for - there is a contradiction as TGi devices must support CCMP anyway.


July 2003 doc.: IEEE 802.11-03/0616r0

C: against – this is for legacy support. C: for – this mode does not address our public relations issue with the market wrt WEP. C: against – not wise to diverge too much from WPA. C: for – we need to allow ourselves to diverge from WPA if warranted. C: against – all along we have agreed to support the install base. C: Legacy equipment will never be TGi compliant as it cannot support CCMP. C: the WPA draft points to the TGi draft. If we remove this support, WPA will have a dangling reference. Call the question Any objection? None Vote: 18-16-12 Fails (comments will be rejected) Recessed at 5:31pm until 7:00pm Resumed at 7:15pm Submission: Tim Moore – doc 03/495r1 – IBSS/802.1aa Port Valid Discussion: C: What about using a modified 4-way instead of a double ended 4-way to avoid this problem. T: If you do that, there will be completely different Authenticator pseudo-code for ESS Vs. IBSS. C: If you do this, there will be a separate supplicant for 802.3 and 802.11 since 802.3 sets PortValid differently. C: A comment that I made in LB52 for the StaProcessEAPOL-Key state machine was not addressed T: we addressed it, but we did not utilize your resolution. Motion by Tim Moore

Instruct the editor to incorporate the changes specified in document 03/495r1 into the TGi draft.

Second: Dorothy Stanley Discussion: None Any objection? None Motion Passes Motion by Jesse Walker


July 2003 doc.: IEEE 802.11-03/0616r0

Replace the following editing instruction from Annex C of TGi draft 4.2: “Delete the text of this annex.

With the following editing instruction: “Insert the following text at the end of the text portions introducing Annex C.3 and C.4:

This annex describes only clauses 8.2.2 and 8.2.3” Second: Clint Chaplin Discussion: J: it would be a 10-15 man year project to update Annex C. C: should we add text annotating why we are doing this? Ch: you are just asking for trouble if you do. Jesse: TGh is going to RevCom without any changed to Annex C. If they are approved, then precedence will be set. C: did TGh have any SB comments about this? Jesse: they had none. Vote: 31-0-1 Passes Submission: Robert Moskowitz – doc 03/493 – Pre-authentication motion Discussion: Robert: The PMK Caching that we now have is a much better approach. C: a unicast EAPOL frame will be forwarded, a multicast will not. Motion by Robert Moskowitz

Instruct the editor to remove Pre-authentication from the TGi draft Second: D.J. Discussion: Does this provide the editor enough instruction to perform this task? Editor: in 24 hours, no. in 48 hours, maybe. C: would it be better to insert a clause at the beginning of draft that it has been removed, and ask for comments of where to remove from the draft. Ch: no C: Pre-authentication is a way to speed up the initial authentication to an AP. I still don’t see another way to do that, even with PMK caching. R: removing this would remove a default method of pre-authentication. C: I like Pre-authentication. However, we are referencing a non-std, and RevCom will kick our draft back to Letter Ballot. C: We could encapsulate EAPOL frames in our own Ethertype to get around the 802.1X issue.


July 2003 doc.: IEEE 802.11-03/0616r0

C: 802.1 will not address this until they are finished with 802.1aa. R: one option is to leave pre-authentication in the draft is to indicate over what types of DS pre-authentication is valid. Vote: 16-14-7 Fails C: why was .1aa opposed to making the changes? Workload? C: they did not understand what they needed to do. R: There is also the security issue of an EAPOL-Start frame on 802.1X Vs. non 802.1X interfaces. C: 802.1aa comment 110 on pre-authentication and VLAN tagging is to be discussed. R: I will see that this get discussed tomorrow morning in the 802.1aa mtg. Submission: Dorothy Stanley – doc 03/545 – Clause 5 comments Motion by Dorothy Stanley

Instruct the editor to incorporate the changes specified in document 03/545 to address LB57 Comment 473. Second: Al Potter Discussion: C: Does the ‘Privacy’ field change? D: No, that is a different usage of the word. Ch: Any objection? None Motion passes This concludes the submissions we had for today. Are there additional submissions or motions? Yes. Ch: We could start ad-hoc work on Comments now. Or, we could begin general submissions now and work in an ad-hoc tomorrow morning. General Submissions

Paul Lambert doc 03/573 – enabling encryption in hotspots Jon Edney doc 03/552 – protection of action frames Robert Moskowitz doc 03/492 authentication layering model Clint Chaplin – 802.11 security maintenance


July 2003 doc.: IEEE 802.11-03/0616r0

Submission: Paul Lambert – doc 03/573 Enabling Encryption in Hotspots C: This motion failed at the last meeting. P: That was a different meeting, and a different motion. That text had a NULL RSN element. C: what happens to broadcast frames in a mixed-mode? Unencrypted only? Broadcast twice – encrypted and un-encrypted? C: Use VLAN tags. Have two separate broadcast domains. C: if the Privacy bit is on, will the AP then expect WEP? P: yes. C: for hotspots, you could simply have two AP’s non-secure and secure, and have the STA switch after it receives its keys. C: you could also have the AP create two virtual BSS by having the AP send two beacons with different SSIDs. C: would this change require changes to WPA clients. C: no, it is a different IE. C: there are solutions for this with RSN and WPA capable devices. P: Yes, but I’m trying to solve the problem for legacy devices that do not support 802.1X. C: the fact that people have found ways to do this with multiple APs or APs with dual personality Motion by Paul Lambert:

Instruct the editor to replace the first paragraph in section “7.3.1.4 Capability Information field” with: “STAs (including APs) that include the RSN IE in beacons and probe responses may set the Privacy Subfield to 0 or 1 independent of the RSN IE. STAs that are only IEEE 802.11-1999 compatible will not recognize the RSN IE and will continue to use the Privacy Subfield to determine if the WEP algorithm must be used.”

Second: Merwyn Andrade Discussion: C: Is the IEEE 802.11-1999 accurate? Motion to amend by Dave Nelson

Instruct the editor to replace the first paragraph in section “7.3.1.4 Capability Information field” with: “STAs (including APs) that include the RSN IE in beacons and probe responses may set the Privacy Subfield to 0 or 1 independent of the RSN IE. STAs that are pre-RSNA devices will not recognize the RSN IE and will continue to use the Privacy Subfield to determine if the WEP algorithm must be used.”

Second: Paul Lambert Discussion: Noen


July 2003 doc.: IEEE 802.11-03/0616r0

Any objection? None Motion to amend passes Motion to amend by Jesse Walker

Instruct the editor to replace the first paragraph in section “7.3.1.4 Capability Information field” with: “STAs (including APs) that include the RSN IE in beacons and probe responses may set the Privacy Subfield to 0 or 1 independent of the RSN IE. STAs that are pre-RSNA devices do not recognize the RSN IE and continue to use the Privacy Subfield to determine if the WEP algorithm must be used.”

Second: Dorothy Stanley Discussion: None Any objection?n None Motion to amend passes New main motion:

Instruct the editor to replace the first paragraph in section “7.3.1.4 Capability Information field” with: “STAs (including APs) that include the RSN IE in beacons and probe responses may set the Privacy Subfield to 0 or 1 independent of the RSN IE. STAs that are pre-RSNA devices do not recognize the RSN IE and continue to use the Privacy Subfield to determine if the WEP algorithm must be used.”

Discussion: C: can the author re-cap the intent of this motion? P: this facilitates both encrypted and un-encrypted traffic to supported by an AP (e.g. VLAN). C: the text does not state how broadcasts are processed. C: I would like to see text stating that an AP will not re-broadcast encrypted RSN broadcast traffic sent to it as unencrypted. Call the question Any objection? Yes Vote on calling the question: 18-5-7 Passes Vote on main motion: 7-11-11 Fails Recessed until tomorrow at 1:00pm


July 2003 doc.: IEEE 802.11-03/0616r0

Wednesday, July 23, 2003 Resume 1:15pm Any objection to modifying the agenda to add the following items:

• Discuss 802.1 mtg • Status of comment resolution • Request for further submissions and comment resolution

No objection. 802.1 mtg discussion: ch: The pre-authenticat motion we had yesterday failed. There was an 802.1 meeting this morning to determine where work in this area should be done. The suggestion to have 802.1 assume the pre-authenticat task was not accepted well. 802.1 did define a list of questions that Dave has asked for help in answering. We should check with them again at the next plenary in November. Comment resolution status Percentage accepted or rejected: 91. 5% pending. 49 untouched. Further submissions for Comment Resolution 03/466 Frank Ciotti – Endianess 03/561(03/606) Tim Moore – Information element 03/483 Tim Moore – Group Key (later Wednesday afternoon) 03/xxx Paul Lambert – Clause 8.3 CCMP Submission: Frank Ciotti –doc 03/466 – Endian Motions 5 comments regarding endian. Shouldn’t refer to web page, for instance. Comments are 156, 157, 160, 161, 881. C: Revcom doesn’t like external references. F: OK, but still need need to answer if bytes or bits C: Should be just for bytes. F: Will need to look and see if any reference to bit ordering. Submission: Tim Moore – doc 03/606 - C: If the STA recvs IE’s that it doesn’t understand, it is supposed to discard them. Now it must keep them. T: yes C: another concern is that some proprietary IEs are large. This will increase the size of the messages. This may push the frame size beyond max size. C: Are we trying to prevent a DoS attack.


July 2003 doc.: IEEE 802.11-03/0616r0

T: A down-service attack. Plus there are interesting consequences if the Association ID is changed. C: I would like to keep the 4-way as close to WPA as possible. Ch: by stating all IE’s, we future proof the std. C: what if there is a proprietary IE’s that the vendor expects to be muted. Should we have an escape clause to allow this? T: I can’t think of why we would need this. C: there are dynamic IE’s that may change during the 4-way. T: In that case, a copy of the IE’s will need to be retained until the 4-way completes. Motion by Tim Moore

Instruct the editor to incorporate the changes specified in document 03/561 into the TGi draft. Second: Tom Maufer Discussion: C: against – does not solve enough problems for the added complexity, esp w/WPA deployed. Ch: if all we wanted was WPA, then we’re done. C: against – there may be a need for mutable IE’s that we don’t understand yet. C: if an IE mismatch occurs, policy could indicate the course of action. Vote: 5-26-14 Fails (related LB Comment rejected) ch: There are no further comment resolution submissions at this time. We can move on to General Submissions. Submission: Jon Edney – doc 03/552r0 – Protection of Action Frames Discussion: C: Are the action frames in or outside the context of the association? J: not sure. C: The key management will be the most difficult part. J: the group key could be used. C: are there uses other then topology? J: yes. C: in TGh, the Action Frames are sent after the Association. But they can be sent in an ibss as well. C: other groups could send them before the Assoc. C: perhaps this is something we should address in a maintenance PAR. Protection before the Association will require Public Key cryptography. C: another option is allow both secure and non-secure action frames. J: that is what the proposed bit would be used for.


July 2003 doc.: IEEE 802.11-03/0616r0

Straw Poll by Jon Edney TGi should propose a protection mechanism for action frames

Result: 34-8-15 Motion by Tim Moore

Instruct the editor to make the following changes to the TGi draft: In Clause 8.7.2.1 change:

IBSSS To:

IBSS

In Clause 8.1.4 change: a ESS

To: an ESS

In Clause 8.1.4 bullet 2 change:

global pre-shared key To:

pre-shared key

In Clause 8.2.3.1 at the start of the second sentence change: authentication

To: IEEE 802.11 authentication

Second: Clint Chaplin Discussion: Any objection? None Motion Passes Motion by Dave Nelson

Instruct the editor to make the following change to the TGi draft: In clause 8.1.4, bullet 1, third sentence, correct the spelling of the word “achieve”.

Second: Jesse Walker


July 2003 doc.: IEEE 802.11-03/0616r0

Discussion: None Any objection? None Motion passes Ch: Any further submissions or motions? None Ch: I would like to recess so that people can work on submissions and motions. Any objection to recess until 4:30pm None Recessed at 2:44pm Resume at 4:30pm Motion by Frank Ciotti

Comments 156, 157, 160, 161, 881

In Clause 3, replace the definition for “Big-Endian” with the following:

Big-Endian: For a given multi-octet numeric representation, the most significant octet has the lowest address.

In Clause 3, replace the definition for “Little-Endian” with the following

Little-Endian: For a given multi-octet numeric representation, the least significant octet has the lowest address.

Second: Jesse Walker Discussion: None Any objection? None Motion Passes Motion by Frank Ciotti

In 7.3.2.9, add the following: The Group Key Cipher Suite contains the cipher suite selector used by the BSS to protect broadcast/multicast traffic transmitted by the AP.

Second: Clint Chaplin


July 2003 doc.: IEEE 802.11-03/0616r0

Discussion: None Any objection? Yes Motion to amend by Kevin Hayes

In 7.3.2.9, add the following: The Group Key Cipher Suite contains the cipher suite selector used by the BSS to protect broadcast/multicast traffic transmitted by the peer STA.

Second: Frank Ciotti Discussion: None Any objection: None Motion to amend passes New main motion

In 7.3.2.9, add the following: The Group Key Cipher Suite contains the cipher suite selector used by the BSS to protect broadcast/multicast traffic transmitted by the peer STA.

Discussion: None Any objection? None Motion passes Discussion on encapsulate/decapsulate LB comments: Suggestion is to indicate that for the purpose of this document, the terms mean to encapsulate and protect. Discussion on Comment 1341 Motion by Dorothy Stanley

Instruct the editor to change the following text in Clause 8.4.4 from: Informative Note: The RSN Information Elements in message 2 and 3 are not the same as in the Beacon and Probe Responses. The multicast cipher and AKMP are the same but the pairwise ciphers are different because the pairwise cipher suite selector is not included in Beacons and Probe Responses.


July 2003 doc.: IEEE 802.11-03/0616r0

To: Informative Note: The RSN Information Elements in message 2 and 3 are not the same as in the Beacon and Probe Responses. The multicast cipher and AKMP are the same but the pairwise ciphers are different because the pairwise cipher suite selector is not included in Beacons and Probe Responses. Thus STAs in an IBSS use the same authentication suite and multicast-cipher, while different pairwise ciphers can be used between station pairs.

Second: Jesse Walker Discussion: None Any objection? None Motion Passes Ch: any further motions? None Ch: We can recess now to work on additional submissions. Any objection to recessing until tomorrow at 8:00am? None Recessed at 5:00pm Thursday, July 24, 2003 Resume at 8:10am Ch :resume with submissions from yesterday Submission: Time Moore – doc 03/483r1 – Group Key Optimizations Discussion: T: updated diagrams to remove the group key handshake, and added text to indicate the Motion by Tim Moore

Instruct the editor to incorporate the changes specified in doc 03/483r1 into the TGi draft. Second: Kevin Hayes Discussion:


July 2003 doc.: IEEE 802.11-03/0616r0

C: against – the complications outweigh the benefits. There are still synchronization issues. There are WPA concerns as well. C: for – there will always be some difference between the TGi code and WPA code (OUI). It does remove 1 of the 2 synchronization issues. C: against – we haven’t proven this solves the race condition. T: one of the two conditions of where the race condition can occur does not exist anymore. C: for – reduces the number of msgs from 6 to 4. C: against – changes state machines for small optimization. C: against – this does not go far enough. We are planning to have a fast-roaming SG to look at this. C: for – as long as there is a necessity for a 6-way handshake, a 4-way is better. C: for – the benefits are worth the change. We should be able to make improvements that don’t significantly change to document. We have seen the race condition in testing. C: we have empirical data indicating the race condition, and this solves it. T: based on Bill Arbaugh’s data we saw this week, there is 20% chance of hitting this race condition. C: This may open up further problems that we don’t know about yet. C: the faster roaming aspect is a side benefit. C: does this reduce the security of distributing the group key? T: no. C: For fast roaming, we need an order of magnitude improvement. Vote: 26-5-7 Passes Submission: Tim Moore – doc 03/477r0 – Disassociation Procedures Discussion: C: do you plan to remove the other sections that discuss Disassociation and point them to this new clause? T: no, I think it is better to leave them as-is. Motion by Tim Moore:

Instruct editor to include document 11-03-477r0 with "section" changed to "clause" and "clause" added in front of references without clause and "RSN capable" replaced by "RSNA capable"

Second: Dave Nelson Discussion: C: note to editor - there are multiple occurrences of some of these changes Ch: any objection? None Motion Passes Submission: Paul Lambert – doc 03/620r0 – Proposed Changes to Section 8.3 to Resolve Ballot Comments C: in Clause 8.3.3.5, there were conflicting comments on how to resolve the references to QoS from TGe. We have three choices; remove it, include TGe text or


July 2003 doc.: IEEE 802.11-03/0616r0

Motion by Jesse Walker

Instruct the editor to remove Clause 8.3.3.5 from the TGi draft Second: Fred Stivers Discussion: J: Intent is to galvanize the group to the process issue with referring to non-standard docs. C: c: my preference is to fix the IEEE process rules. Taking the text out will generate comments as well. P: I feel we need to leave it in because there are other references in the draft to QC. If we do remove this section, we will need to fix the other references to QC. Ch: Have people looked at the effort to include the text from TGe into our draft? Vote: 1-29-11 Fails C: I suggest that we make the text normative, but remove the disclaimer. That will only serve as a magnet for comments. Motion by Paul Lambert

Instruct the editor to incorporate the changes specified in document 03/620r0 to the TGi draft, with the disclaimer in header of Clause 8.3.3.5 deleted.

Second: Tim Moore Discussion: None Ch: any objection? None Motion Passes Submission: Paul Lambert – doc 03/628 – Annex F Motion by Paul Lambert

Instruct the editor to make the Test Vectors in Annex F normative text. Second: Thomas Maufer Discussion: C: What has priority, the test vectors or the text? P: if it all normative and contradicts itself, then it must be fixed. C: text vectors require more work to validate. Leaving them as informative allows the text to have priority.


July 2003 doc.: IEEE 802.11-03/0616r0

C: conformance tests are no longer required in 802, which is why we have WiFi. I don’t want to see conformance tests made mandatory. Vote: 7-8-23 Fails P: there were comments on the copyright for the CCM “as-is” reference code that the authors names should be removed Ch: we should treat this as any other submission and remove the name. C: I suggest we leave this to the lawyers. C: we had a similar issue with x, and an email to the author for permission to remove the copyright resolved the problem. P: we should be sure to remove all names and copyrights from Annex F. Motion by Paul Lambert

Instruct the editor remove all authors’ names and licensing statements from Annex F. Second: Jesse Walker Discussion: C: we should first ask the author before removing copyright or licensed material. Ch: this is a draft and in a private area. C: if published, violates law. Ch: by making a submission to IEEE, leaving this text in is incorrect. No IP statement has been made in these cases. P: These are not in the restricted public domain. Ch: It is the authors intent to have this treated as a submission. Vote: 29-1-11 Passes Ch: Paul will send an email to Doug Whiting. Discussion on C: has the internet draft been assigned an RFC number yet? P: no C: then we cannot reference it. C: There is another reference to CCM at the NIST web site. C: is the NIST reference in a std? C: it is in a submission Motion by Dave Nelson

Request that the TGi chair request of the IETF RFC editor RFC numbers for any CCM related internet drafts currently in the RFC editor’s queue for use within the TGi draft.

Second: Kevin Hayes


July 2003 doc.: IEEE 802.11-03/0616r0

Discussion: C: should we ask Stuart or the IETF liaison if this is the correct procedure. Ch: myself, Stuart and the IETF liaison will be involved. Vote: 37-0-3 Passes Motion by Paul Lambert

Instruct the editor to delete Clause F.4.2 CCM test vectors from the TGi draft Second: Jesse Walker Discussion: C: We will still have CCMP test vectors? P: yes Ch: any objection? None Motion Passes Discussion on Pass Phrase : Motion by Tim Moore

Instruct the editor to incorporate the Pass Phrase changes specified in document 03/310 into the TGi draft. Second: Jesse Walker Discussion: None Ch: any objection? None Motion Passes Submission: Jesse Walker – doc 03/471 Discussion: J: There are two definitions for Key Identifiers. Bob Moskowitz, Dan Harkins, Tim Moore and myself will meet to resolve the conflict. Motion by Jesse Walker


July 2003 doc.: IEEE 802.11-03/0616r0

Instruct the editor to incorporate the changes specified in document 03/471 into the TGi draft, with the exception of the Key Identifier definitions.

Second: Clint Chaplin Discussion: None Ch: any objection? None Motion Passes Discussion on capitalization of 4-way Handshake and Group Key. Motion by Robert Moskowitz

Instruct the editor to capitalize the terms “4-Way Handshake” and “Group Key” in the TGi draft. Second: Jesse Walker Discussion: None Any objection? No Motion Passes Motion by Robert Moskowitz

Instruct the editor to add the definitions for the terms “4-Way Handshake” and “Group Key Handshake” to the TGi draft.

Second: Clint Chaplin Discussion: C: this is technical text. Can we do this without the actual text for the definitions? Ch: yes. Any objection? None Motion Passes Recessed at 10:00am Resume 10:35am


July 2003 doc.: IEEE 802.11-03/0616r0

Ch: Are there any further submissions for Comment resolution?

Frank Ciotti – Encapsulation definitions Tim Moore - Paul Lambert -

Motion by Frank Ciotti:

(Comments 358, 393)

In Clause 3, replace the following: Decapsulate: A verb meaning to recover an unprotected packet from a protected one.

With: Decapsulate: In the context of this standard, this term refers to the recovering of an unprotected packet from a protected one.

In Clause 3, replace the following:

Decapsulation: A noun referring to the plaintext data produced by decapsulating an encapsulation.

With:

Decapsulation: In the context of this standard, this term refers to the plaintext data produced by decapsulating an encapsulation.


Encapsulate: A verb meaning to construct a protected packet from an unprotected packet.

With:

Encapsulate: In the context of this standard, this term refers to the construction of a protected packet from an unprotected packet.


Encapsulation: A noun meaning the cryptographic payload constructed from plaintext data. This is comprised by the ciphertext, as well as any associated cryptographic state required by the receiver of the data, such as initialization vectors, sequence numbers, message integrity codes, key identifiers, etc.

With:

Encapsulation: In the context of this standard, this term refers to the cryptographic payload constructed from plaintext data. This is comprised by the ciphertext, as well as any associated cryptographic state required by the receiver of the data, such as initialization vectors, sequence numbers, message integrity codes, key identifiers, etc.

Second: Tim Moore

C: so we are claiming that this is our private definition?

Ch: yes

Any objection?


July 2003 doc.: IEEE 802.11-03/0616r0

None

Motion Passes

Motion by Tim Moore

Instruct the editor to change text in section 8.3.2.1.1 from: "Reuse of any TSC value compromises already sent traffic."

To: "Reuse of any TSC value compromises already sent traffic. Note that retransmitted packets reuse the TSC without any compromise of security."

Second: Onno Letanche

Discussion:

None

Any objection?

None

Motion passes

Motion by Tim Moore

Instruct the editor to change text in section 8.4.1 from: "A STA already associated with the ESS can instead request its IEEE 802.1X Management Entity to authenticate with a new AP before associating to that new AP. In this case the Management Entity can request its IEEE 802.1X Supplicant to send an AuthenticationRequest to an AP with which it is not associated."

To:

"A STA already associated with the ESS can request its IEEE 802.1X Supplicant to authenticate with a new AP before associating to that new AP."

Second: Merwyn Andrade Discussion: None Any objection? None Motion passes Motion by Tim Moore

Instruct the editor to delete the following text from section 8.4.6.1: "An Authenticator should only accept an IEEE 802.1X EAPOL-Start frame if the source MAC address is not currently ASSOCIATED and IEEE 802.1X Authenticated to the AP"


July 2003 doc.: IEEE 802.11-03/0616r0

Second: Frank Ciotti Discussion: t: the comment indicated that if we state this here, we have a layer violation with 802.1X any objection? None Motion passes Motion by Tim Moore

Instruct the editor to change text in section 8.4.6 from: When IEEE 802.1X authentication is an authentication option, an RSNA-capable STA may use IEEE 802.11 Open System Authentication prior to Association or Reassociation

To: When IEEE 802.1X authentication is an authentication option, an RSNA-capable STA shall use IEEE 802.11 Open System Authentication prior to Association or Reassociation

Second: Kevin Hayes Discussion: None Any objection? None Motion passes Discussion on fast roaming comments Tim: there are ~23 comments on fast roaming. How do we want to address these comments? C: We voted to move the topic of fast roaming to a study group. Reject the comments C: not reject the comments, but accept and list the resolution we voted on. Ch: we’re not changing the draft, so it seems we should reject. C: WNG had a similar vote to defer fast-roaming to the new SG. Ch: are there any objections to me including the recommendation for fast roaming topics moved to the new SG in my closing report on Friday? None C: can any member make a motion to for the Fast Roaming SG? Ch: there is an agenda that needs to be followed. C: if the vote passes in the WG, it then has to be passed by the SCC.


July 2003 doc.: IEEE 802.11-03/0616r0

Straw Poll by Dave Halasz Comments regarding Fast Roaming in Letter Ballot 57 should be marked rejected with the stated reason that a request has been made for a Study Group to be formed to study this task, and TGi considers this beyond the scope of its PAR.

Discussion: C: we should reject the comments because the motions for it continue to fail. C: could we accept some of the comments but reject the recommendation? Ch: yes C: one comment is to reduce the number of round trips, and we have done that. C: The TGi vote indicates that we want a new SG to solve this. The market may decide that TGi provides sufficient solution for its needs. Or that is doesn’t, and use what the SG provides. Result: 29-7-20 Straw Poll by Dan Harkins

Comments regarding Fast Roaming in Letter Ballot 57 should be marked accepted by the inclusion of Named PMK Caching, and we suggest that a Study Group be formed to determine if any additional work is required.

Discussion: None Result: 34-8-15 C: we could reject the comments because the motion failed. C: the Straw Poll by Dave Halasz

The LB57 comments on Fast Roaming should be marked as Accepted Result: 25-7-21 Straw Poll by Andrew Khieu

Comments regarding Fast Roaming in Letter Ballot 57 should be marked accepted by the inclusion of Named PMK Caching, and we suggest that a Study Group be formed to determine if any additional work is required.

Discussion: Ch: if this gets majority, we will choose this wording over the previous straw poll Result: 40-4-9


July 2003 doc.: IEEE 802.11-03/0616r0

Motion by Tim Moore

Instruct the editor to delete the following text from section 8.4.6: Informative Note: Pre-authentication completes when the AP’s IEEE 802.1X Authenticator sends the first message of the 4-way handshake to the STA’s IEEE 802.1X Supplicant.

Second: Clint Chaplin Discussion: None Any objection? None Motion passes Submission: Paul Lambert – doc 03/632

C: do we want to allow WEP as a multicast cipher?

C: we should indicate here that the intent is to preclude the use of group key only for pairwise for CCMP

C: if vendors want to do this, they will.

C: the AP should not advertise the group key only as a pairwise cipher.

Motion by Paul Lambert

Instruct the editor to append the following sentence to the description of “Use Group Key” in clause 7.3.2.9: “The Selector 00:00:00:0 shall only be used as a pairwise cipher when the Group Key Cipher Suite is TKIP (selector 00:00:00:2). If an AP specifies “Use Group Key Cipher Suite” as the pairwise cipher selection, this shall be the only pairwise cipher selection the AP advertises.”

Second: Nancy Cam-Winget Discussion: None Any objection? None Motion passes Status on LB57 Comments: 6 comments that are neither accepted or rejected. Ch: we still have the issue of PMK ID’s. Are there further motions? None Ch: I would like to recess until 2:00pm to allow work on the remaining comments. If you would like to help work on these, meet here at 1:00pm.


July 2003 doc.: IEEE 802.11-03/0616r0

Any objection to recessing until 2:00pm? None Recessed at 12:05pm until 2:00pm Resume 2:01pm C: We need to include the SSID Len from the IE. C: why are ANonce and SNonce included, they are part of the hash for the PTK anyway? C: I will need to check with people why it was suggested that this be included. C: then remove it and comment on the LB C: applicable to IBSS as well? C: yes, this is agnostic. Motion by Tim Moore

Instruct the editor to make the following changes to the TGi draft:

• Insert the following text in section 8.5.1.2: A PMK identifier is defined as

PMKID = HMAC-SHA1-128(PMK, "PMK Name" || BSSID || STA-MAC-Addr) A PTK identifier is defined as

PTKID = HMAC-SHA1-128(PTK, "PTK Name" || SSID) A GTK identifier is defined as

GTKID = HMAC-SHA1-128(GTK, "GTK Name" || SSID || BSSID) where the SSID is of the length from the SSID IE

• Move SSID from PMK SA to PTK SA and GTK SA

• Remove GNonce from GTK SA Second: Clint Chaplin Discussion: C: Since we have no reference to PKTID and GTKID, they should not be in the draft. Vote: 33-0-8 Passes Motion by Tim Moore

Instruct the editor to change text in section 8.4.4 from: "A STA shall not advertise any authentication or cipher suite that is not enabled and that it will not agree to use"

to: "A STA shall not advertise any authentication or cipher suite that is not enabled"


July 2003 doc.: IEEE 802.11-03/0616r0

Second: Dave Nelson Discussion: C: Does this mean that while the AP is in countermeasure, the beacons should not advertise TKIP? T: That is implementation specific. TKIP is still enabled so it seems it should still be advertised. Any objection? None Motion passes Motion by Tim Moore

Instruct the editor to change text in section 8.4.4.1 from: "When an RSNA STA in a TSN IBSS cannot identify a newly identified peer as RSNA, it may treat the new STA as non-RSNA and attempt to communicate with it using WEP and a default WEP key."

To: "After a failed attempt to identify a new peer as RSNA capable, an RSNA STA in a TSN IBSS may treat the new STA as non-RSNA and attempt to communicate with it using WEP and a default WEP key."

Second: Dorothy Stanley Discussion: None Any objection: None Motion passes Motion by Tim Moore

Instruct the editor to change text in section 8.4.4 from: "The IEEE 802.1X entities of two directly communicating STAs negotiate pairwise key cipher suites using the 4-way handshake."

to: "The IEEE 802.1X entities of two directly communicating STAs negotiate pairwise key cipher suites using one of the two 4-Way Handshakes."

Second: Merwyn Andrade Discussion: None Any objection: None Motion passes


July 2003 doc.: IEEE 802.11-03/0616r0

Motion by Tim Moore

Instruct the editor to change text in section 8.4.1 from: "When explicit authentication is not used"

to: "When IEEE 802.1X authentication is not used"

Second: Nancy Cam-Winget Discussion: None Any objection? None Motion passes Motion by Tim Moore

Instruct the editor to make the following changes to the TGi draft: • Change text in section 8.4.4 from:

Beacons and Probe Responses within an IBSS shall specify an empty list of pairwise key cipher suites.

To: Beacons within an IBSS shall specify an empty list of pairwise key cipher suites.

• Change text in section 8.4.4 from:

Informative Note: The RSN Information Elements in message 2 and 3 are not the same as in the Beacon and Probe Responses. The multicast cipher and AKMP are the same but the pairwise ciphers are different because the pairwise cipher suite selector is not included in Beacons and Probe Responses.

To: Informative Note: The RSN Information Elements in message 2 and 3 are not the same as in the Beacon and Probe Responses. The multicast cipher and AKMP are the same but the pairwise ciphers are different because the pairwise cipher selector is not included in Beacons.

Second: Onno Letanche Discussion: Motion to amend by Dave Nelson




July 2003 doc.: IEEE 802.11-03/0616r0




To: Informative Note: The RSN Information Elements in message 2 and 3 are not the same as in the Beacon. The multicast cipher and AKMP are the same but the pairwise ciphers are different because the pairwise cipher selector is not included in Beacons.

Second: Kevin Hayes Discussion: None Any objection? None Motion to amend passes Main Motion:






To: Informative Note: The RSN Information Elements in message 2 and 3 are not the same as in the Beacon. The multicast cipher and AKMP are the same but the pairwise ciphers are different because the pairwise cipher selector is not included in Beacons.

Discussion: None Any objection? None Motion passes


July 2003 doc.: IEEE 802.11-03/0616r0

Discussion on Comment 586 Ch: Any objection to rejecting this comment? None Ch: We have processed all LB comments. Ch: How much time will be necessary to prepare the draft for LB? Jesse: not today, but less than a week. Ch: Since the next session is an Interim mtg, we will want to pre-authorize actions for that meeting. C: Can we have an ad-hoc session to fix editorial issues with the draft before submitting to re-circulation? Ch: at the last ad-hoc, we completed 90% of the comments. We may be able to process all comments if we make the ad-hoc a little longer. C: I don’t think we can turn around 2 re-circulation ballots before the Singapore meeting. There is not enough time. C: all other TGs read their drafts through as a group. At some point we really need to do this. Ch: It seems that there would be too many opinions to get through a full TG review quickly. C: Then we should break the spec into sections and have small groups review the sections. C: I don’t have time to review the whole document in great detail. Focusing on a smaller section would be better. C: 802.16 performs a TG review before going to LB. C: two re-circs before Singapore will hard for us, but hard for the readers as well. Ch: TGg did this in Sponsor Ballot. C: The TG could review the draft a few days before posting to LB. C: TGg was down to a small number of issues, we are not. They were also in SB, we are not. Recessed at 3:20 until 3:30pm Resume: 3:35pm Ch: these motions would be pre-authorizations. They are non-binding. We are not forced to going to 2 re-circulations. C: if we felt the 2nd rec-circulation was going to be our last, then it would make sense. But I don’t see that happening. Also, I thought we could only go to SB at a Plenary, and Singapore is an Interim. Ch: we would need to pre-authorize the draft going to SB at the Interim. C: I suggest that we authorize now to go to SB after Singapore. Straw Poll by Dave Halasz

TGi should pre-authorize two re-circulations ballots before the September Singapore meeting. Result: 23-15-5 Ch: based on these results, I do not plan on requesting for the pre-authorization for two re-circulations. C: If we want to go to SB in Singapore, Stuart will need to request it from RevCom.


July 2003 doc.: IEEE 802.11-03/0616r0

C: if we want to go to two re-circulations between Singapore and November mtg, do we need to pre-authorize that at this meeting. Ch: the pre-authorization we get now should suffice. Straw Poll by Dave Halasz

TGi should schedule an ad-hoc meeting after the September meeting such that it is possible to have two re-circulations between September and November.

Discussion: C: Two re-circs will be more tolerable later in the process because the document will be more “cooked”. C: I think that anything you do between now and the next Plenary, has to be pre-authorized. C: I believe it is possible to provide the power of a plenary mtg to the interim or ad-hoc. Result: 31-1-7 The week of August 25th would make the most sense to hold the ad-hoc on August. Straw Poll by Dave Halasz

TGi should hold an ad-hoc meeting the week of • October 13th - 19 • October 20th - 6

Ch: I would like to recess to craft motions for empowering the Task Group. Any objection to recessing until 5:00pm? None Recessed at 4:30 Motion by Frank Ciotti

Instruct the editor to create draft 5.0 of IEEE 802.11i from TGi draft 4.2. Second: Nancy Cam-Winget Discussion: None Any objection? None Motion Passes Motion for September Pre-authorization Meeting

At the September IEEE 802.11 interim meeting: empower TGi to make motions, address comments received from letter ballot, adopt a new draft and forward to WG re-circulation.


July 2003 doc.: IEEE 802.11-03/0616r0

Movers: Frank Ciotti/Jesse Walker Discussion: None Vote: 34-0-2 Passes Motion for Delayed Recirculation:

• Believing that comment responses in 11-03/452r6 and motions duly adopted in TGi will enable the editor to produce the document mentioned below that satisfies WG 802.11 rules for letter ballot recirculation,

• Authorize a 15-day LB recirculation of 802.11i draft 5.0 by TGi to conclude no later than 8/19/2003. Movers: Nancy Cam-Winget/Clint Chaplin Discussion: C: Will comments be due by 8/19? Ch: yes Vote: 29-0-4 Passes Motion for meeting

Approve a meeting to be held by TGi on October 13 through 17, 2003 empowered to make motions to address comments received from letter ballot, adopt a new draft and forward to WG re-circulation.

Movers: Jesse Walker/Nancy Cam-Winget Discussion: C: Are we bound to meet on all five of those dates? Ch: no Vote: 25-1-6 Passes Ch: there is one remaining general submission. We also need to decide where we are going to have the ad-hocs. Ch: any objection to recessing until 7:30pm? None Recessed at 5:32pm until 7:30pm Resume 7:56pm Ch: we need to determine the location of the August and October ad-hocs. The August ad-hoc will be from the 26th to the 28th.


July 2003 doc.: IEEE 802.11-03/0616r0

The October ad-hoc will be from the 14th to the 16th. Straw Poll by Dave Halasz

TGi should hold its August 26th – 28th ad-hoc meeting at the following location: • Herndon: 9 • Portland: 11

The August meeting will be in Portland, OR. Jesse Walker (Intel) will host the meeting Straw Poll by Dave Halasz

TGi should hold its October 14th – 16th ad-hoc meeting at the following location: • Herndon: 9 • Seattle: 8 • Paris: 7

The October meeting will be in Herndon, VA. Al Potter (ICS Labs) will host the meeting. Ch: Robert Moskowitz had to leave so he will not be able to present his submission. Motion by Frank Ciotti

Update the dates specified in the empowerment motion for the October ad-hoc meeting to be October 14th through 16th instead of October 13th through 17th.

Second: Fred Stivers Discussion: None Any objection? None Motion passes Submission: Clint Chaplin – doc 03/629 – Security Maintenance Discussion: Clint: There is nothing to prevent future changes to the 802.11 standard from breaking the security work we have done. C: Other bodies have solved this by having a security considerations requirement as in IETF, but that does not seem to work. The IESG type solution may work. The first option of waiting for letter ballot and then comment may work. C: The security people need to get out of the security working groups and get involved in the other groups, because as we have seen with TKIP, it is not easy to add security after the fact. Clint: None of the current PARs have security included. Ch: in my closing report, I will mention that this needs to be looked at. C: The IETF tutorial includes security to educate the new members. Perhaps we should add this to the IEEE new members’ session.


July 2003 doc.: IEEE 802.11-03/0616r0


C: Perhaps having a new category for flagging ‘No’ votes on Letter Ballots for security reasons so that they can not be rejected. Clint: has anyone reviewed other drafts for security? C: TGf can be cracked in the same way that WEP can be. It uses RADIUS keys incorrectly. C: perhaps we could put security on the 802 Plenary. C: why can’t there be a maintenance TG for TGi like there is for 802.1D C: Because 802.11i is not a standalone standard, as is 802.1D. Upper Vs. lower case suffix. Submission: Bernard Aboba – doc 03/647 – 802.11 AP Architecture Bernard: there is nothing in the 802.1aa spec that prohibits pre-authentication. Bernard: the exercise was to diagram the architecture of a pre-authentication frame going from one AP to another. B: A different Ethertype should be used. B: 802.1X allows forwarding unicast EAPOL frames, but opens a security hole. Suggestion to not forward new Ethertype across relay entity. B: non of this text belongs in 802.1aa since it talks about APs. 802.1X does not prohibit pre-authentication. Ch: I thought 802.1aa was confused on what pre-authentication is. B: no, they were confused on what 802.11 is. C: we need to ensure that 802.1aa is not going to be an impediment to us. B: because it is a different Ethertype, they should not be objecting. B: there has been a big misunderstanding as to how this affects 802.1aa, but if you use a different Ethertype there is no issue. C: If we create a new Ethertype, can we use the 802.1aa state machines? B: the new Ethertype is needed to allow other L2 switches to forward the EAPOL frames, and also to indicate to the AP when received from the DS that the frame is for the WM port. C: for wired DS, 802.1aa states that EAPOL frames must be multicast. Therefore you can always differentiate EAPOL traffic for the DS Vs. WM, as frames for the WM received on the DS will be unicast. B: the AP will forward non-forwardable multicast traffic to the DS. Motion by Jesse Walker to adjourn Second: Clint Chaplin Ch: any objection? None Adjourned at 9:35pm

July 2003 doc.: IEEE 802.11-03/570r0


Meeting Minutes 802.11j July 2003

Date: July 24, 2003

Author: Christopher J. Hansen Broadcom 190 Mathilda Place, Sunnyvale, CA 94086 Phone: +1 408 5433378 Fax: +1 408 543 3399 e-Mail: [email protected]

8:08am 7/22/03 Review of Agenda IEEE Policies and Procedures Technical Presentation 454, 542, “no number” Review of Japanese Standards Activities – Y. Inoue, NTT

• No new information from MMAC • New band 5.47-5.725 GHz , 5.25 – 5.35 GHz may become available in Japan – harmonization with WRC-

03 Letter ballot comment resolution Technical Contributions:

• 03/542 – Chris Hansen, Broadcom • 03/454 – Mark Webster, Intersil

Editor (P. Ecclesine) presents draft text D1.1.1 in the working group area. Break for coffee.

10:30 am 7/22/04 Technical Contributions:

• 03/522r2 – Y. Inoue, NTT Motion to Adjourn until Thursday. P. Ecclesine, C. Hansen Adjourned until Thursday, 7/24 1:05 pm 7/24/03

• 03/562 – (to be on server Wednesday), S. Pope, TI Editor, P. Ecclesine, presents three possible drafts from the task group draft area. 1_4 includes changes from the letter ballot review. 1_4_10_PICs is 1_4, but with 10 MHz channels added, assuming the PHY clock divided by 2 from 802.11a. 1_4_10_CH_PICS contains the PHY clock divided by 2, plus PHY changes from 802.11-03/542. Discussion and explanation follows from editor and chair.

802.11j Minutes for July 2003 page 1 C. Hansen, Broadcom

July 2003 doc.: IEEE 802.11-03/570r0

802.11j Minutes for July 2003 page 2 C. Hansen, Broadcom

Presentation from B. Douglas on 10 MHz channels. No document number yet. Comments and discussion from members of the group. Break for Coffee. 3:35pm 7/24/03 Editor continues review of letter ballot comments. Motion: This group, in principle, would like the draft to contain text specifying 10 MHz channels. A Myles/B. Kramer - Y = 25/ N = 0/ A = 4 Motion passes. Motion: The ½ rate 10 MHz solution, including 52 sub-carriers with 4 fixed pilots, as shown in document 1_1_4_10_PICS, is the 10 MHz channel solution we will adopt. This is our resolution of comments group A. A. Myles/E. Perahia 28/13/3 Motion: The ½ rate 10 MHz solution, including 50 sub-carriers, as shown in document 1_1_4_10_CH_PICS, is the 10 MHz channel solution we will adopt. This is our resolution of comments group A. A. Myles/B. Douglas 5/38/2 Motion: The 10 MHz solution, including 26 sub-carriers, as shown in document, 802.11-03/562, is the 10 MHz channel solution we will adopt. This is our resolution of comments group A. Myles/B. Douglas 4/30/8 Motion: The ½ rate 10 MHz solution including 52 sub-carriers with 4 fixed pilots, as shown in document 1_1_4_10_PICS, shall include a +/- 10 ppm clock frequency tolerance. This is our resolution of comments group A. B. McFarland/A. Myles 11/21/9 Further discussion on the inclusion of 10 MHz channels in a new draft. Back to comment resolution on other topics. Straw Polls: Do we need to provide for greater multi-path mitigation than 802.11a for all channelizations? (See document 03-522 for measurement data.) Y = 10; N = 5; A = 14 Do we need to investigate (i.e. study to determine necessity) the need for greater multi-path mitigation than 802.11a for all channelizations? Y = 17; N = 2; A = 8 Motion: To empower TGj to hold teleconferences, interim, and ad-hoc meetings, if necessary, to discuss and resolve letter ballot comments and, if necessary and confirmed by the working group at the September 2003 meeting, issue subsequent letter, re-circulation, or sponsor ballots. A. Myles/ D. Richkas Y = 27; N = 0; A =0. Move to Adjourn. A. Myles/S. Halford 7/24/03 4:40pm

July 2003 doc.: IEEE 802.11-03/539r0


Tentative Minutes for the TGk July 2003 Session

Date: July 21-25, 2003

Author: Harry Worstell AT&T 180 Park Avenue Phone: 973-236-6915 e-Mail: [email protected]

Monday, July 21, 2003 3:30 PM – 5:30 PM

Chair: Richard Pain Secretary: Harry Worstell 1) Call to order 2) Attendance

3) Agenda

Approve Agenda Review IEEE802 & 802.11 Policies and Rules

IP Patent Policy Voting Roberts Rules

Approve May 2003 DFW Meeting minutes Approve the teleconference minutes Set/ Review Objectives Update On Teleconferences Matrix Review Technical Presentations Break Technical Presentations Recess until Tuesday, July 22

Move to Approved the agenda Approved by unanimous consent

Reviewed the IP Patent Policy with the group. Reviewed Inappropriate topics for IEEE meetings Reviewed document rules

must be on the server before presentation Reviewed voting policy for status Must follow Robert’s Rules of Order 4) Chairs comments

Submission page 1 Harry Worstell, AT&T

July 2003 doc.: IEEE 802.11-03/539r0

Reviewed scheduled for the week 5) Approval of the May 2003 minutes Motion: Move to approve the minutes of the May 2003 DFW session. Approved Unanimously Motion: Moved to defer the approval of the minutes of the May-June-July 2003 teleconferences until Thursday at the 1:00PM session. Moved Marty Lefkowitz Second J Kim Approved 18 Disapproved 0 Abstain 1 6) Set Objectives for the week

Meet the technical requirements for Scenarios Work Matrix EVM vs. PSNI Quality measurement Site Reporting Adding measurements Framework for fast roaming and MIBs

Later in week Pat Calhoun will present Will attempt to get Bob O’Hara to speak Make sure the measurements are in place for fast roaming

Make sure that the draft is technically complete before going to letter ballot 7) Teleconference update were covered

a. Scenarios b. Start up issues c. updated the matrix

8) Covered the matrix document 427r7 with revisions _ Document not available on server a. Pre-association Services

i. Need more bits Doc 338 by Simon Black b. Channel Map

i. new proposal by Simon Black c. Initialisation

i. How do you determine the county code for mobile application ii. Get information out with out loading the beacon (Simon and Joe will

present) d. RCPI

i. Already in draft e. S/N - Data quality

i. Dave to present (Doesn’t believe we can produce a measurement) ii. Joe Kwak to present opposite view

f. Neighbourhood Map i. most is already in site report (Arunesh Mishra will present for Bill

Arbough) g. Site Report


July 2003 doc.: IEEE 802.11-03/539r0

i. In draft 1. Might need Byte counters

h. Unsolicited reports i. Needs to be incorporated in the draft text ( From the Microsoft

presentation) i. MAC MIBs

i. Changes may be presented this week – J Kim ii. Actions-request and reports need a place to be stored so that they can be

qued up to an AP j. STA statistics table

i. Debatable as to need k. SMT MIB for configuration Parameters

i. Open Issue l. Neighbourhood maps are necessary in every category m. Security management frame

i. out of scope n. Distribution service of RRM info to STA and AP

i. Still needed – Simon Black will address o. AP and STA statistics gathering service

i. Joe Kwak to offer text p. Commanded STA action service

i. Only 2 is the beacon report and action report need to be reworded q. Threshold trigger

i. Hassa Sinivaara to present r. Add the Hidden Node Report to 13.7

i. Patrick to do 9) Technical Presentations - Call for Papers

a. Site reporting - Simon Black -Tuesday AM b. Sta Stats - Simon Black -Tuesday AM c. Adaptive beacon - Simon Black -Tuesday AM d. Site Reporting - Arunesh Mishra - Monday evening ~7:00 e. Review of current status – J Kim – Monday Evening f. Periodic measurement normative text - Joe Kwak – Tuesday g. concept of PHY measurements from 11H - Joe Kwak – Tuesday h. Concept broadcast of neighbour list/maps - Joe Kwak – Tuesday i. MIB - Joe Kwak – Tuesday evening j. MIB - Joe Kwak – Tuesday evening k. MIB - Joe Kwak – Tuesday evening l. MIB - Joe Kwak – Tuesday evening m. MIB - Joe Kwak – Tuesday evening n. EVM simulations - Joe Kwak – Tuesday evening o. Normative text New MAC measurements - Joe Kwak – Thursday evening p. Normative text New MAC measurements - Joe Kwak – Thursday evening q. MIB – J Kim – Wednesday – PM r. 531 – EVM vs Packet error rate results - Dave Skellern – Monday evening s. Patrick Worfolk – Wednesday PM

10) Moved to recess by Harry unanimous


July 2003 doc.: IEEE 802.11-03/539r0

Monday, July 21, 2003 7:00 PM – 9:30 PM

1) Call to order 2) Attendance 31

2) Dave Skellern presented 531
