On 5/24/2011 12:53 AM, Joe Salowey wrote: > One benefit I see in keeping the same EAP method type code is it allows > secure version negotiation from v1 to v2 with version rollback protection. > > However, moving to a new EAP type code would seem to make EAP method > negotiation somewhat better since all implementation may not implement v1. > > I'm OK with assigning a new EAP method type code, but I'd like to try to > maintain some backward compatibility with the v1 versioning in the case that > v1 > > implementations find it advantageous to negotiate the v2 feature set under > the v1 type code.
None of this seems to me to be relevant to the IETF, the emu WG or the discussion at hand. Just to be clear, EAP-FAST is not a product of any IETF WG and does not specify a standard of any kind. Furthermore, regardless of the IANA type registration status, EAP-FAST is, in fact, a proprietary protocol; it's publication in RFC 4851 reflects the RFC Series as a vanity press, not the IETF as a SDO. The method that this WG is developing will be a standard, however, and must not be tethered in any way to a proprietary protocol; i.e., backward compatibility with EAP-FAST. Whatever the name of the tunneled method ends up to be, the version number must be one (1). If a vendor wants to track the IETF protocol development for whatever reason so that, for example, v2 of its protocol is equivalent to v1 of the standard then that is their choice, but enabling (let alone encouraging) that behavior is not any of our concern. ...
<<attachment: gwz.vcf>>
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
