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 defined....as Hao mentioned, there is also merit to facilitating code reuse and reducing deployment complexity. Changing the type code has implications to the configuration and management interfaces especially on the client side. Nancy. On 5/16/11 7:45 AM, "Alan DeKok" <[email protected]> wrote: > 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 >
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
