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

[Alper Yegin (alper]

Hi James,

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

This is an incorrect characterization of this discussion. Nobody is
proposing to use PANA instead of LWAPP. As I said several times by now, this
is not possible as LWAPP attempts solving several problems at the same time.
Whether this is a good idea or not is a separate discussion. All I'm
pointing is that some of the problems raised in this forum can already be
solved by PANA. 

It is not true that intent of PANA is long-term. And I'm still looking for
some technical clues on what architectural difference people are referring
to. (I heard that they are different enough many times, but no one has
explained how they are different.....)

Alper


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