Re: Issue 199: EAPoL-Key message generation at WTP or AC
From: Bob O'Hara (boohara) (booharacisco.com)
Date: Mon, 4 Sep 2006 10:51:17 -0700 (PDT)
Saranavan,

The current protocol, as it is specified in -02, does meet the stated
objectives.  It supports both local MAC and split MAC architectures, as
those architectures are described in the taxonomy document.  

There is no requirement in the objectives that the protocol support any
other arbitrary split of functionality between the AC and WTP.
Otherwise, we would have to negotiate EVERY possible frame that might be
exchanged between a mobile node and the 802.11 access point, to
determine if it is generated in the AC or the WTP.  For example, do the
objectives require that the protocol must support the Association
Request being processed in the AC and the Association Response being
generated in the WTP for a split MAC architecture?

 -Bob
 
-----Original Message-----
From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] 
Sent: Sunday, September 03, 2006 7:01 PM
To: Pat Calhoun (pacalhou); Capwap [at] frascone.com
Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or
AC

Pat,

This is not a new functionality, but one that is mandatory by the
Objectives. 

Also, I do not think this is an issue of where the EAPoL-Key is
generated, but rather "how" EAPoL messages are exchanged in local-MAC
and split-MAC architectures. 

I have made a number of proposals with both text and figures that direct
address the mandatory objective. 

I am not comfortable with a protocol that does not support explicitly
stated objectives. 

Saravanan




-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] 
Sent: Friday, September 01, 2006 7:32 AM
To: Capwap [at] frascone.com
Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC

This issue was opened to add a new mode of operation to the CAPWAP
protocol, allowing the WTP to generate the EAPOL messages. I do not
agree with this request, and would like to see this one rejected. We
really need to focus on getting a protocol completed, and I just don't
see a burning need to add this new functionality. 
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

Results generated by Tiger Technologies using MHonArc.