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

[Alper Yegin (alper]

>> I've discussed these before, but nevertheless:
>> [a] - Configuring APs: SNMP, COPS, etc.
>> [b] - Migration of AAA stuff from AP to AR: PANA
>> [c] - Auth/Authz between AP and AR: PANA (if physical security is not good
>>   enough)
>> [d] - 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.

Let's put LWAPP and the above framework on scale. For the above framework,
[b] and [d] has 0 cost on AP. Are you saying LWAPP is light-weight because
it has a lw-SNMP (for [a]) and lw-802.1X/lw-PANA (for [c])? If you come up
with the lw versions of these, I'm sure they'd be useful as standalone as
well.

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

This is about tunneling 802.11 frames to AR. All you said was IETF could do
this, I agree. That does not mean that IETF should do it. I'm still waiting
for the explanation why IEEE shouldn't/couldn't do this. Any response to
that?

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

What are the products shipping LWAPP and alikes?

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

Well, this BoF comes with a problem and I'm trying to show how we can reuse
existing/ongoing work. I think this is a good IETF practice :)

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

Yes it does. Don't you see how it moves processing from AP to AR?

Alper