On Fri, May 13, 2011 at 6:29 PM, Alan DeKok <[email protected]> wrote: > The reason for the name change is that there have been questions > raised about whether this document should be left as EAP-FASTv2, or > whether it should request allocation of a new EAP type. > > Since the document name (individual draft) currently reflects the EAP > type name, abstracting that would be useful. That way the document name > will not change no matter what the WG decides to do. > > Anyone with opinions either way is requested to discuss the pros and > cons of the issue.
I would prefer to allocate a new EAP type for this method and do that as soon as possible to make it easier to run early interoperability testing without having to use vendors specific type or experimental type (of which there are only one) and to agree between various implementations what to use.. Allocating a new EAP type enables cleaner design options for implementations that only support the standard method and do not have support for the proprietary EAP-FAST method. In addition, it allows proprietary EAP-FAST extensions to be kept separate in case both methods are implemented. EAP-FAST requires various hacks in the EAP implementation, including modifying a phase 2 method (EAP-GTC) based on the phase 1 method. I do not really want to extend those hacks any further and just want to keep them conditional on the already allocated EAP-FAST type instead of having to figure out which EAP-FAST method version is being run in a method that is not really supposed to be in any way dependent on the tunnel method. As far as EAP method/version negotiation is concerned, I find it more likely that the EAP-NAK mechanism for selecting the EAP method has received much more testing than EAP-FAST version negotiation and as such, is more likely to interoperate with legacy implementations. - Jouni _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
