On May 23, 2011, at 5:50 PM, Glen Zorn wrote: > 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.
[Joe] I would hope that negotiation of methods is relevant to the EMU WG. > 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). [Joe] A new method name would be good. How the protocol evolves is up to the working group. > 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. > > ... > <gwz.vcf> _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
