Capwap Mailing List: Re: PANA v.s. LWAPP: a false dichotomy (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)

[Marcus Brunner (brunner]

I agree that the 2 approaches might have some overlap, but this should 
really not be a problem to let both of them proceed.

Marcus

--On Samstag, 26. Juli 2003 21:23 +0200 James Kempf 
<kempf [at] docomolabs-usa.com> wrote:

> Pat,
>
> Let's try to avoid an argument on the list about the relative merits of
> one architecture v.s. another. There is plenty of room for both these
> approachs in the IETF. The intent of LWAPP is to do something quickly to
> satisfy vendor requests. The intent of PANA is more long term, as you
> point out. There is no reason why these two approaches can't co-exist.
> After all, the IETF currently has no less than 3 working groups doing
> work on instant messaging protocols, and the architectural territory
> covered by these protocols is much closer than that covered by PANA and
> LWAPP.
>
> Let's stick to discussing the charter, around the bullet points I sent
> out. We need to get some text around those.
>
>             jak
>
>
> ----- Original Message -----
> From: "Pat R. Calhoun" <pcalhoun [at] airespace.com>
> To: "Alper Yegin" <alper [at] docomolabs-usa.com>; <rkp [at] intotoinc.com>
> Cc: <lwapp [at] frascone.com>
> Sent: Wednesday, July 23, 2003 3:25 PM
> Subject: RE: [Lwapp] Certificates, Discovery Request/Reply, and
> validation.
>
>
> > > 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?
> >
> > Apparently. I think the key point that you are missing here is the 'LW'
> > in
> LWAPP. Specifically, the goal is to reduce the complexity of the AP, which
> is something that we are hearing both customers and AP manufacturers want.
> The proposal above requires so much code in the AP that one has to
> question what the advantages are.
> > I think we've already had the IEEE vs. IETF discussion, so unless you
> > have
> a clear explanation of why this is a MAC or PHY problem, please state it.
> > >> 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.
> >
> > I see, so the horse isn't dead....
> >
> > > I still feel like missing couple of necessary steps here if we already
> jump
> > > to solution evaluation stage.
> >
> > Correct. I think the part that's missing here is that unlike other topics
> in the IETF that are mostly around research topics (build it and they will
> come), this is the inverse. Products are shipping, and many vendors in
> this space wish to ensure some form of interoperability between their
> devices.
> > I understand that you're trying to find some market for the PANA
> architecture, and I'm sure there are customers, but I think that the
> vendors in this particular space have already made an architectural
> decision. If the IETF wishes to standardize on an architecture the
> players in the 802.11 space are not interested in, then I think it's
> missed its mark.
> > Further, I think that your proposal does not benefit the Internet
> Community, which is looking for lowering the cost of AP deployments and
> operation. What you proposal does is drive the standards process much
> longer with dubious advantages.
> > PatC
> > _______________________________________________
> > Lwapp mailing list
> > Lwapp [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/lwapp
>
> _______________________________________________
> Lwapp mailing list
> Lwapp [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner [at] ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus