[Emu] Some questions about eap type code and the tunnel method

2011-05-16 Thread Sam Hartman
I'd like to confirm my understanding. The current text proposes the use of eap type code 43. I'd like to confirm that code is in use both by implementations of eap-fast v1 and v2. Does the current text mandate support for eap-fast v1 as well as v2? Is it expected that most implementations

Re: [Emu] Some questions about eap type code and the tunnel method

2011-05-16 Thread Alan DeKok
Sam Hartman wrote: I'd like to confirm that code is in use both by implementations of eap-fast v1 and v2. As a backup question: Are there *any* implementations of v2? The draft does not make it clear if this is the case. Can the authors step in and give their opinion? Does the current

Re: [Emu] Some questions about eap type code and the tunnel method

2011-05-16 Thread Hao Zhou
Alan: Please see responses inline below. On 5/16/11 9:02 AM, Alan DeKok al...@deployingradius.com wrote: Sam Hartman wrote: I'd like to confirm that code is in use both by implementations of eap-fast v1 and v2. [HZ] Yes. Type Code 43 is being used by EAP-FAST v1 and widely deployed.

Re: [Emu] Some questions about eap type code and the tunnel method

2011-05-16 Thread Alan DeKok
Hao Zhou wrote: As a backup question: Are there *any* implementations of v2? [HZ] Not right now. Once this draft is finalized, it will be. OK. That means there are no costs to choosing a new EAP type code. [HZ] The draft doesn't mandate support for v1 and v2, it's up to each

Re: [Emu] Results of consensus call on tunnel method document

2011-05-16 Thread Dorothy Stanley
I support allocating a new method type for the new standard method, sooner, rather than later. The new method is defined by an IETF group, based on submissions/modifications from multiple parties, and should carry/use an IETF rather than specific vendor identifier. Dorothy On Sat, May 14, 2011

Re: [Emu] Results of consensus call on tunnel method document

2011-05-16 Thread Dorothy Stanley
Joe, Understood. The EAP-FAST protocol and name and type value (from the IETF space) are tied in the market to specific vendor. A new name and a corresponding new IETF type help associate the new standard method with the IETF. Dorothy On Mon, May 16, 2011 at 11:37 AM, Joe Salowey

Re: [Emu] Results of consensus call on tunnel method document

2011-05-16 Thread Sam Hartman
Based on the answers to my questions, I strongly support allocation of a new EAP type code . I think using the existing type code will significantly disadvantage implementations that want to implement the IETF spec but not eap-fast v1. I believe that is highly undesirable.

Re: [Emu] Some questions about eap type code and the tunnel method

2011-05-16 Thread Nancy Cam-Winget
It seems too early to decide whether there is a need to change the EAP type at this point. I think there is merit to considering reducing customer education as to why yet another new EAP type is being definedas Hao mentioned, there is also merit to facilitating code reuse and reducing

Re: [Emu] Some questions about eap type code and the tunnel method

2011-05-16 Thread Glen Zorn
On 5/16/2011 7:39 PM, Sam Hartman wrote: I'd like to confirm my understanding. The current text proposes the use of eap type code 43. I'd like to confirm that code is in use both by implementations of eap-fast v1 and v2. I'm pretty sure that there are no implementations (except maybe

Re: [Emu] Some questions about eap type code and the tunnel method

2011-05-16 Thread Glen Zorn
On 5/16/2011 9:32 PM, Hao Zhou wrote: ... Sam Hartman wrote: I'd like to confirm that code is in use both by implementations of eap-fast v1 and v2. [HZ] Yes. Type Code 43 is being used by EAP-FAST v1 and widely deployed. As a backup question: Are there *any* implementations of v2?