Hi All, Here are the notes from the CAPWAP session on July 29th, 2007. I attempted to send these notes earlier, but I guess I had some technical difficulties, because they aren't on the proceedings site and weren't in my sent messages folder. Please let me know if you get this message and can post these minutes. Thanks, Margaret --- Notes from CAPWAP session: July 29th, 2007 1740-1840, Dublin Margaret Wasserman opened the meeting and reviewed the agenda: Agenda is to - - Review status of documents - - Present MIB status - - Discuss issues raised on list Margaret: I’m sending around the blue sheets – please sign them. Margaret: Is there a volunteer for scribe? Dorothy Stanley volunteers. Margaret: Status: We have 6 documents in progress, see the website: -CAPWAP base specification – currently in IETF last call, closing week after next -.11 binding document – also in IETF last call, closing week after next -Security threat analysis- – finished IETF last call, minor changes required -DHCP – finished IETF last call, minor changes required And 2 MIB documents that are not yet completed. We’ll wait to send the Security threat analysis and DHCP document to the IESG until the protocol and binding documents are completed, for context. Base document – we knew there would be comments and a new revision. Have received comments from Pasi, which will require text changes. Review period ends in over a week, may get more last call documents. However, we are most actively working on the MIB documents. After we finish the MIB document update, we can review comments that have come in from Pasi. Is anyone following jabber? No Any comments on the document status summary? None Presentation - Chris Elliot (Cisco) – CAPWAP WG MIB Drafts Report - He has been working with Shi Yang (Richard), who has done most of the work on this Current status – both documents published as working group documents Current version number of drafts is 00. David Harrington has offered MIB doctor services. Most issues involve description errors, smlint complaints and inconsistent name rules. Dan Romascanu comment: the protocol has changed, but is not yet synchronized with the MIB. Since the protocolis now stable, should be able to do this. Next version is planned to be published in August - Fix bugs found by Dan and other experts - Keep synchronization - Clean up language - Verify compliance with latest IETF MIB guidelines - Request more comments form CAPWAP working group members. Questions or comments? Margaret: you should update the author list – include currently active folks, and acknowledge others as contributors. Also, want to finish this work soon. Dan R – Took me two days to review the document. Also lots work to check consistency. Chris: Aiming for sometime in August. Dorothy Gellert: – Puneet is no longer able to work on the mIB, we are looking for additional volunteers, if anyone is interested. Margaret – Need to make sure that the MIB issues are in tracker, to document resolutions. Margaret – Issue of MD5 used for hash of checksum, does the application make a difference? Pasi Eronen– does make a difference. There are some environments where it is difficult to use MD5 for any purpose – e.g. government applications. Tim Polk may have more info, I haven’t had a chance to check with him on this. Are there shipping implementations? Margaret – Depends on what you mean by “shipping implementations”. Am aware of 2 interoperable implementations. Margaret – DTLS retries – view it as good that retries can go on forever. We saw this as a decision for the application. Pasi – Doesn’t really matter where the timer is, should be clear. Margaret – Does matter, if we specify that timer is in DTLS, application can’t go longer. In this type of application, right thing might be to not time out – it’s a brick if it can’t connect. Pasi – In most applications, doesn’t make sense to transmit forever. Margaret – Another issue – start-up might be overcomplicated, session resumption. Give us more advice on how this can work. Pasi – Sent e-mail on this to the list. Complexity comes from fact that full handshake not needed for the data channel. Don’t see a gain from requirement to “not implement”. TLS has renegotiation capability – need to figure out how this works with “must not”. Charles Clancy: What would happen if you resume when first session is still active? Pasi – Web browsing uses multiple connections Charles: Seems reasonable to simplify. Possible to open a data channel without having an established control channel. Dorothy G: Is that a new comment/issue? Charles: No, part of the “must not” question. Charles: If we change to a CRC – would that be better? Pasi – Yes Margaret – Need to check with Tim on the MD5 question first, before decision to change is made. Margaret – MTU issue. Current text put in based on transport AD input. You’re saying that we should say “we send a packet at a given size” All out packets are small until firmware download – find out then. Pasi – have complexity – send probe, get response, interacts with how capwap protocol does implementation. Do path MTU discovery in the discovery phase. If get too large packets at that time, need to look at how this is fragmented. Order is maintained by lockstep requirement. What if one was larger than the max? Need more text. Margaret – May be an issue if backoff due to no response. Pasi – Don’t need to probe all the time, need to figure out what to do if you get an ICMP back. Seems possible that the 2 ends could get out of synch, no offset to the end of the file. Margaret – If have a block, and it doesn’t get through. If packet was received, but not acknowledged, would we send the packet again? In a lossy network – send lots of packets. Pasi– Look at text in an RFC – 45?? – Recommendation is to retransmit a couple of times, then decrease packet size. Margaret – What about the interaction with DTLS? Pasi – DTLS never retransmits anything. It doesn’t remember what it transmits. Margaret – Are there any other comments to discuss? Pasi – Some of the comments were questions, need more explanation. How the WTP processes the information elements that it gets from the AC? Discuss on the list. Pasi – Need more explanation of how the information elements are processed. Dorothy Stanley: Processing of 802.11 information elements is specified in 802.11 document. Pasi – Yes, but seems like in most cases the WTP receives elements to forward, and just sends the elements out, for example in a Beacon or Probe Response. But it consumes some elements. Dorothy S: Agree that the CAPWAP spec should clarify the cited different cases. Margaret – Security analysis document Pasi – I have sent comments to the list. Charles: response to Pasi’s comments on threat analysis. One comment re: support of WEP. not precluding support of WEP, support this, and also RSN. Dorothy S: WEP is deprecated in the .11 standard, but implementations are not prevented from supporting it. Pasi – An editorial change is needed to make it clear in the threats document that WEP is supported in the CAPWAP spec, but Not advised to use, and not considered in the threat analysis document. Pasi: Zero config WTP? How to make sure you’re talking to the right AC. List of ACs? Margaret – Implemetations will attach to any AC in some cases. Pasi – Should include a discussion of this in the security considerations. Charles: Need to add this in the base spec security analysis. May rely on the Cert, cert has the right options set. Will propose text, with Scott, see if Pasi’s comments are addressed. Margaret – Thank you to Pasi for his thorough review Pasi – I started reviewing now, due to schedule conflicts, and decided to send the comments early – rather than entering in the discuss tool later. Dorothy G – Start talking about future work. Margaret – There is a wish list for CAPWAP, Also could support other items added in 802.11 since the spec - .11k and .11r. on the wish list – DTLS 1.2 (in final review), QOS. Do we want to go to draft 2.0 of CAPWAP? Do these items warrant future work? Or should we quit while we’re ahead. Puneet – We have done a lot, we should take a break, revive the group later if needed based on deployment experience. Margaret – I agree. Dorothy G – Spec updates, could be done in ops area, not require the WG to be restarted. Margaret: If people deploy, then we will get feedback. Dan R – Talking about new work, this is the time to discuss it. Individual submissions can be proposed. A 2.0 – is this a major revision? Margaret - Meant only the next revision, not necessarily a major revision. Bug fixes – Implementation, deployment BCPs – do in the OPS area, if take to draft standard. Margaret: Is there anyone who disagrees with closing the group after the current documents are published? No objection. Charles: IESG review – will we have issues re: hash agility re: DTLS 1.0? Pasi – No. The new DTLS draft is in -00, will take some time to complete. Don’t delay the capwap specs for this. Should be an easy extension. Minor upgrade with Draft 1.2. Abijit: Need to check that we change the text that currently requires use of block ciphers. Pasi – Current version does not require this, it was incorporated already. Margaret – Hope we have no reason to meet in Minneapolis.