Capwap Mailing List: RE: Certificates, Discovery Request/Reply, and validation.

[Pat R. Calhoun (pcalhoun]

>> 
>> You see, the PANA architecture really only touches the tip of the iceberg.
>> Moving towards a LWAPP architecture solves these issues, and significantly
>> reduces the amount of protocol work required between the AP and the AR
>> (because 802.11 terminates in the AR, so 802.11 *is* the protocol).
>
> I'm not comparing PANA with LWAPP. This does not make sense. LWAPP is more
> like an architecture that tackles several problems. I'm trying to understand
> what each one of these problems are and see if there are alternative
> solutions that should be considered.
ok, which one, specifically?

> PANA comes into the picture when we talk about the AAA between hosts and AR,
> and AA_ between the AP and AR. I don't see PANA's relevance to all the other
> bells and whistles LWAPP provides.

correct, but somehow you keep asking the question. If we agree that we've 
beaten this horse to it's full extent, then I'll gladly oblige...

>> 
>> We seem to be focused on EAP only, but again, I think the problem is much
>> greater in scope - hence CAPWAP.
>> 
>
> Is there a documented list of problems, like a problem statement? It is
> really hard to reverse engineer the LWAPP to undertsand the problems we are
> solving here.

Other than what's in the current document (which I assume you've read), no. 
However, the problems are well understood enough that many vendors are actively 
building, or shipping, products, all with the same architecture and a protocol 
that looks like LWAPP.

If the IESG believes that we need to go down the problem statement path, and 
tack on another 12 months of effort to CAPWAP, then we can consider it. But 
personally, having gone through some of this at the IETF, and the fact that 
this is a current problem that is known, I think that the players involve all 
know what we need.


PatC