Task Group R Teleconference Meeting Minutes

May 2004 doc.: IEEE 802.11-04/664r01

IEEE P802.11 Wireless LANs Task Group r Teleconference Meeting Minutes

Date: June 1, 15, 28, 2004

Author: Michael Montemurro Chantry Networks 1200 Minnesota Ct, Mississauga, ON, CANADA Phone: 905-567-6900 e-Mail: [email protected]

Tuesday June 1, 2004

Chair: Clint Chaplin Secretary: Mike Montemurro Attendance: Bob Love Bob O’Hara Rajiv Gupta John Ager Jon Edney Frank Ciotti Bob Beach Jim Wendt Dan Harkins Haixiang He Emek Sadot Paul Newton Bill Brazier Partha Narasimhan Naveen Fanny Mlinarsky Trisi So Fred Haisch

 Opening remarks:  We cannot vote during these teleconferences  Teleconference minutes will be approved in the July meeting  There will be a document submitted which will describe the Task Group r Document List (example: scope, requirements, test methodology, etc.)  We can now submit documents under Task Group r  All email conversations should take place on the IEEE mailing list  Requirements were submitted in Document 11-04/516r0  Additional requirements was submitted in Document 11-04/619r1

Submission page 1 Michael Montemurro, Chantry Networks May 2004 doc.: IEEE 802.11-04/664r01

 Discussion on how we should organized the document structure? None.  Discussion on the Requirements Document:  When are the requirements going to be closed? We are trying to finalize the requirements in July. If the document has to be re-opened later, then we will do it.  Request that ESS Mesh review the requirements document to ensure that Mesh roaming requirements are addressed.  Possibly there could be a joint Mesh session during the July meeting.  The formal requirements document would come out of the two earlier submissions.  Document 11-04/619r1 is an outline for the requirements document  We need to add metrics and their values to the document. We can get that information from the use cases.  The Use Case document needs to be expanded. We need a volunteer to flush the use cases out.  What is the purpose of the requirements document?  The purpose of the Requirements Document is to formalize the solution requirements so that proposals which do not meet them can be rejected. We will vote on the requirements document.  The requirements document should not specify hard and fast rules. We need to take the time to make sure everyone has bought into the requirements.  We need more detail on the requirements so that we have a stake in the ground.  We should not force the pace for requirements development. If we rush through this process, we’ll end up ignoring the requirements in the future.  The requirements draft should be a guideline for the people making proposals – as long as its development is not rushed. It should ideally be closed while proposals are being evaluated.  We could review the Requirements document in one of the next two teleconferences.  Is verification data in the Requirements document?  We have discussed producing another document on test methodology to compare different proposals  Document 11-04/086r1 and Document 11-04/378r0 discuss test methodologies.  Discussion on the Scope submission is Document 11-04/608r1  Call for input into the scope document as it exists.  Jim Wendt will update the scope document for the next teleconference.  The scope and requirements will not be locked down before proposals are accepted.  The discussion on the Scope and Requirements should take place at the meeting with a broader audience.  The document describes SSID/VLAN mapping is out of scope. Shouldn’t this be in scope under security?  The focus was on roaming in an ESS. Whether it maps to a common VLAN is out of scope.  The VLAN mapping is in scope because it is part of the authorization process.  If the VLAN changes through AAA, it is part of the security association. Therefore you cannot roam.

 We do not have a “slow” roaming solution to SSID/VLAN mapping, therefore it should not be part of the Task Group r solution.  Task Group i has already specifically stated that AAA-assigned VLAN mapping is part of the security association.  All authorization (security association) attributes should be in scope.  Is it part of our scope to define a roaming framework or a roaming model?  It would be useful to formalize the roaming process.  The model could be part of each proposal. We could make it part of the proposal requirements.  Who’s going to generate the model? It would introduce a lot more work in submitting the proposal.  It needs to be done in some way before the proposal.  We were going to define the roaming model as it current exists. Then the proposals can describe how they change the roaming model and process.  Do we need an additional document to describe a roaming model?  It’s very useful to describe where we are with roaming.  Are we creating a model to describe the solution as it exists? We might want to have a model as it currently exists.  Clint will put out a call on the reflector for volunteers for submissions on a roaming model.  We have run out of time – next Teleconference will be at 7am EST on June 15.  Teleconference is adjourned.

Tuesday June 15, 2004

Chair: Clint Chaplin Secretary: Mike Montemurro Attendance: Jon Edney Trisi So Bob Love Jim Wendt Bill Marshall John Agar Chris Durand Gunther Kleindl

 Call to order  Request for a joint meeting with Task Group s (TGs - MESH) during the July Plenary  A joint meeting with TGs could work on Tuesday afternoon during the Plenary session in July.  TGs will discuss the possibility of a joint meeting during their teleconference at the end of June.  The session would take place 1:30-3:30pm  Discussion on the Requirements document, which been posted as document 11-04/666r0:  We can review the document on the next teleconference.  What is the source of the roaming metric of 40 ms? A source should be included.  This document is by no means complete – we should discuss the purpose of this document on this call.  This document describes the requirements that we can agree on (by meeting a 75% approving vote) – there may be additional requirements that we can’t agree on.  Bob Love will post his comments on how the requirements document should used will be posted to the email reflector.  If there are comments on this document – please send it to Bob Love  This document will only be effective if it is brief and focused on only addresses key requirements.  Discussion on the Scope ideas:  The document is completed but couldn’t be posted to the server.  Perhaps we need two categories of the scope: elements we would change in the standard, and elements we would not break in the standard.  The standard that would be used is a basis for this work would be the current approved standard. Other standards in progress would need to be co-ordinated during the process of developing the standard.  For instance, preservation of VLAN tags would be something we would not want to break as part of our standards development.  VLAN tags were part of the security association. We need to make sure that we preserve security association as part of this solution.  Jim Wendt will not be available for the Monday session at the July Plenary, so that likely we could discuss it during the Tuesday session.

 Call for use cases – we still need a volunteer.  We still don’t have a selection procedure. We don’t really have to close on this until after the call for proposals.  The selection procedure will likely be modelled on what TGn is using  We’ve put to a call on test plans for roaming – but nobody has come forward.  Scan times are out of scope of this work. TGk is working to create a map of candidate access points for roaming.  The Scope document describes what’s not in scope.  The TGr list of documents has been updated in submission 11-04/661r2

Submission page 5 Michael Montemurro, Chantry Networks