Subject: [Capwap] a necessary and sufficient capwap base protocol

From: Scott G Kelly <[email-masked]>
Date: Sat, 25 Mar 2006 09:38:22 -0800

At the capwap wg meeting last week, the chairs and editors detailed a 
very aggressive schedule for completing the capwap protocol document. 
Basically, we want to wrap this up sometime in July. I think this is 
highly optimistic (some might say unrealistic) given all the 
functionality folks are saying we must support.

I'd like to make a suggestion, following precedents set in other working 
groups faced with similar problems: we should define a base protocol 
consisting of the minimal necessary and sufficient elements for capwap 
interoperability. In addition, I think we should discuss Darren's 
question about a roadmap document (and/or effort). Here, we could detail 
extensions we intend to address once the base protocol is complete.

Some things I think we might want to consider deferring from the base 
protocol discussion include these:

- NAT traversal (IPsec working group did this as an add-on, and since 
not all vendors care about this, it makes sense to consider that 
approach here)

- AC/WTP load balancing; different vendors have different approaches, 
and it's not clear that we should be forcing one vendor's view on 
everyone else.

- split tunneling, where data channel terminates on a different endpoint 
than the control channel; this has definite security implications, and 
probably requires a secure inter-AC protocol, in addition to its own 
state machine loop(s). It's a corner case that many won't care about.

I'm sure there are others. I'm not in my office right now, so I don't 
have the annotated document handy, but I'll make a point of looking at 
it Monday and following up with any additional items.

I want to emphasize that this does not preclude support of any 
particular feature - rather, it is a pragmatic approach aimed at getting 
us to a standard protocol quickly. I'd like to hear what others think 
about this.

--Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Philip Rakity <[email-masked]>
Date: Sat, 25 Mar 2006 14:05:45 -0800

Scott,

We strongly believe that this specification (in it's draft 3  
incarnation) could not be implemented in a manner that allowed 3  
independent  implementation to inter-operate.   Draft-00 is better  
but still will have holes.   (Just looking at NAT and DTLS).  Before  
progressing to a real RFC, we believe a number of back-off's are  
required.

regards,

Philip

On Mar 25, 2006, at 9:38 AM, Scott G Kelly wrote:

> At the capwap wg meeting last week, the chairs and editors detailed  
> a very aggressive schedule for completing the capwap protocol  
> document. Basically, we want to wrap this up sometime in July. I  
> think this is highly optimistic (some might say unrealistic) given  
> all the functionality folks are saying we must support.
>
> I'd like to make a suggestion, following precedents set in other  
> working groups faced with similar problems: we should define a base  
> protocol consisting of the minimal necessary and sufficient  
> elements for capwap interoperability. In addition, I think we  
> should discuss Darren's question about a roadmap document (and/or  
> effort). Here, we could detail extensions we intend to address once  
> the base protocol is complete.
>
> Some things I think we might want to consider deferring from the  
> base protocol discussion include these:
>
> - NAT traversal (IPsec working group did this as an add-on, and  
> since not all vendors care about this, it makes sense to consider  
> that approach here)
>
> - AC/WTP load balancing; different vendors have different  
> approaches, and it's not clear that we should be forcing one  
> vendor's view on everyone else.
>
> - split tunneling, where data channel terminates on a different  
> endpoint than the control channel; this has definite security  
> implications, and probably requires a secure inter-AC protocol, in  
> addition to its own state machine loop(s). It's a corner case that  
> many won't care about.
>
> I'm sure there are others. I'm not in my office right now, so I  
> don't have the annotated document handy, but I'll make a point of  
> looking at it Monday and following up with any additional items.
>
> particular feature - rather, it is a pragmatic approach aimed at  
> getting us to a standard protocol quickly. I'd like to hear what  
> others think about this.
>
> --Scott
>

Philip Rakity
[email-masked]

This message is hereby marked U4EA CONFIDENTIAL, is intended only for  
the use of the individual or individuals to which it is addressed and  
shall notbe disclose or made available to any other party except with  
the prior written consent of the sender. If the reader of this  
message is not the intended recipient, you are hereby notified that  
any dissemination, distribution or copying of this message is  
strictly prohibited. If you have received this communication in  
error, please notify us immediately by replying to the sender of this  
E-Mail.