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

[James Kempf (kempf]

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
>
>