It looks like we have rough consensus for a new EAP type. I Agree, that with a new EAP type it makes sense to start the version at 1. I was originally thinking of the SSL 3.0 to TLS 1.0 transition where the protocol version went from 3.0 to 3.1, but in that case TLS did not have an equivalent code point assigned. I'll add these to the list of changes for the next revision.
Cheers, Joe On May 30, 2011, at 11:25 PM, Glen Zorn wrote: > 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> >> >> >> > <gwz.vcf> _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
