| Re: Certificates, Discovery Request/Reply, and validation. | <– Date –> <– Thread –> |
|
From: Alper Yegin (alper |
|
| Date: 23 Jul 2003 01:58:52 -0000 | |
>> 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? I've discussed these before, but nevertheless: - Configuring APs: SNMP, COPS, etc. - Migration of AAA stuff from AP to AR: PANA - Auth/Authz between AP and AR: PANA (if physical security is not good enough) - Migration of per-packet ciphering from AP to AR: Either use IPsec with AR, or tunnel 802.11 frames on the wired segment. Whether the latter should be done at IEEE vs. IETF is debatable. Did I miss any other problems we are tackling here? > >> 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... Please see above. > >>> >>> 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. I still feel like missing couple of necessary steps here if we already jump to solution evaluation stage. Alper > > > PatC > >
- Re: Certificates, Discovery Request/Reply, and validation., (continued)
- Re: Certificates, Discovery Request/Reply, and validation. Yoshihiro Ohba, July 22 2003
-
RE: Certificates, Discovery Request/Reply, and validation. Pat R. Calhoun, July 22 2003
- Re: Certificates, Discovery Request/Reply, and validation. Alper Yegin, July 22 2003
-
RE: Certificates, Discovery Request/Reply, and validation. Pat R. Calhoun, July 22 2003
- Re: Certificates, Discovery Request/Reply, and validation. Alper Yegin, July 22 2003
- Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.) James Kempf, July 26 2003
-
RE: Certificates, Discovery Request/Reply, and validation. Pat R. Calhoun, July 22 2003
- Re: Certificates, Discovery Request/Reply, and validation. Alper Yegin, July 22 2003
- RE: Certificates, Discovery Request/Reply, and validation. Pat R. Calhoun, July 22 2003
Results generated by Tiger Technologies using MHonArc.