Review of agenda
- discussion on whether WiMAX is applicable to the CAPWAP protocol draft.
- WiMAX is a working group issue, not a protocol draft issue.

Review of milestones

Discussion on the CAPWAP Protocol Specification
- the LWAPP protocol has been used as a basis for CAPWAP-00, as recommended by the Evaluation Committee
- the working group encourages publication of the other candidate protocols as informational RFC's. That will give the working group a record of the protocols that were considered for standardization.
- there was a request for an interim meeting: an interim meeting would require a 30 day announcement 
- there would need to be an updated CAOWAP draft for the interim meeting as well as an official agenda
- the agenda would need to contain concrete work items. 
- CAPWAP needs to get more input for the MIB document. That could be done at the interim meeting.
- there is a feeling that CAPWAP protocol development is progressing slowly and an interim meeting could speed up the process.

IEEE 802.11 Liason presentation
- Is IEEE 802.11p going to be considered by the CAPWAP working group?
- IEEE 802.11p has not been considered. It deals mostly with adhoc communications

Editor's presentation
- Pat presents update on tracker:
	- 85 issues submitted, 41 closed, 19 targetted for rev -01 and ~25 remaining for rev -02
	- mentions a lot more issues to come since not many have read the draft yet
- Dorothy presents change summary
	- inclusion of DTLS was made since in November '05 meeting there was large support for this
	- other editorial changes made
- Pat discusses other major changes
- Dorothy presents other changes editors are looking to resolve.
	- DTLS related issues, author section updates, Waitjoin timer default values, cipher, keying and other open issues
	- polls whether the message elements should be scattered or unified in one section: two individuals spoke in favor 	for placing the elements in one section.  
- Mike presents his updates to consider
	- 802.11 configuration statistics and consistancy issues
	- 802.11i and RADIUS considerations
	- other minor edits
 Pat presents his updates to consider
	- Issue 37 needs more discussion
	- Will address issues 53, 59, 63 and 69
	- open issues that need more discussion in reflector: 43, 66, 75, 40, 72, 74
- Discussions show that a couple of individuals were looking at starting prototype by July

CAPWAP Protocols concerns by Richard Gwee
- the Join phase was removed when the DTLS was added. If you add the Join phase back, you address the state machine 	problems.
- the number of WTP's that the AC can support is a discrete value. However traffic loading and other metrics vary over time.
- The "periodic" firmware update means that the WTP would periodically check for a firmware update.


Presentation on CAPWAPHP on Behcet Sarikaya
- Inter-domain roaming handles roaming between the AC's. This could involve either a protocol definition between AC's, or a new protocol between WTP and the AC.
- IEEE 802.11F had been deprecated because there were no implementations of the protocol.
- CAPWAP already provides roaming solutions. This proposal introduces a new architecture that is not included in the taxonomy document. The architecture depicts the entire IEEE 802.11i implemented in the WTP as local MAC.
- This protocol adds additional feature to the split MAC implementation.
- As an alternative, you could simply forward the frame from the WTP to the AC.
- This document addresses problems with client roaming.
- Is it within the scope of CAPWAP to define roaming between WTP's across AC's.
- The interpretation of the CAPWAP charter is that it only deals with the protocol between WTP and the AC.
- If that is true, there is a single point of failure.
- Roaming between AC's is more the scope other IETF groups.
- multiple AC's could share the same AAA server.
- Roaming between AC's is clearly out of scope of this working group.
- If the controller fails, the WTP will connect to another controller. AC's could be part of a mobility group.
- If an AC fails, WTP's will connect to other available AC's and the STA's will re-authenticate.
- IEEE 802.11i introduces key caching so that a STA can establish a PMK and re-use it when it re-connects.
- IEEE 802.11r provides a mechanism to minimize latency between WTP's across the same controller.

Presentation on CAPWAP Security by Scott Kelly
- Recommend that a design team be created to address the issues with adding DTLS support to CAPWAP.

Presentation on Saag for CAPWAP by Scott Kelly
- This presentation will be need to be explained to Sam 
- CAPWAP represents the AC/WTP architecture as a AP works today.
- All Access Control is done at the AC. The WTP is more like a forwarding engine.
- There needs to be formal Liason with the security area.
- We don't really need a formail liason, but we need a security advisor.
- This can be simplified by renaming "formal liason" to "designated point of contact".
- If we choose to go with DTLS, there may be other issues that come up that could be addressed quickly with a security advisor.

- Presentation of the CAPWAP MIB documents.
	- We should be able to be able to create a single MIB document.
	- From a CAPWAP perspective, the STA state is completely independent of the CAPWAP state.
	- What does it mean to CAPWAP if a STA has gone away.
	- The STA stop is a trap that occurs when a STA disassociates.
	- IEEE 802.11v is working to define an AP MIB. This MIB looks to be re-creating an AP MIB.
	- One of the goals with this work is not to re-cast work already being done by other standards bodies.
	- The IEEE 802.11 MIB assumes a single entity.
	- This MIB work should be specific to CAPWAP.