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 > implementation. How, ever, due to the small changes from V2 to v1, I suspect > most of them could support both easily. Doesn't running code mean something > in IETF? Speaking as an individual contributor and implementor, I think the v2 draft is a lot clearer than the v1 specification. It looks to be simpler, too. > [HZ] Agree. Considering all devices out there supporting EAP-FASTv1 and it > may take a while for them to support the new method, most server > implementations would probably support both. Again, speaking as an individual, some server software doesn't support EAP-FAST. There have been few complaints so far about that. > [HZ] Realistically, until the new tunnel method is published and adopted by > all servers and supplicants, implementation would have to support older > tunnel methods, including EAP-FASTv1. See above. > By retaining the EAP-FAST type, > customers wouldn't have to be educated with another new EAP type and > validate its security, and they would have a smoother migration path, from > v1 to v2. Implementers could reuse the same code. I agree that cost of deployment is a factor to consider. > I thought one of the > reasons EAP-FASTv2 is adopted is because of its existing code and > deployment, with small changes to meet EMU requirements. Changing the method > name and type would totally negativate that. I'm not sure how changing the type code adds deployment costs. The new version has to be deployed no matter what. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
