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.
Cheers, Joe On May 13, 2011, at 8:29 AM, Alan DeKok wrote: > > Since we have reached WG consensus on the method, can the authors of > > draft-zhou-emu-eap-fastv2-00.txt > > please re-submit the document as: > > draft-ietf-emu-eap-tunnel-method-00.txt > > 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. > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
