On 5/31/2011 11:08 AM, Joe Salowey wrote: > > 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.
Hmm. I thought we were talking about EAP-FAST version negotiation. > >> 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. A new EAP type would be better. If a new EAP type is assigned, how does it make sense to start the version numbering for that type @ 2? > How the protocol evolves is up to the working group. Absolutely, but unless the rules have changed rather drastically recently, I'm pretty sure that I'm a WG member... > >> 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> > > >
<<attachment: gwz.vcf>>
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
