> 2. The following text could be added either in the introduction or IANA > considerations (or anywhere the IESG prefers): > "EAP-FAST has been implemented by many vendors and it is used in the > Internet. Publication of this is intended to promote interoperability. > The reuse of EAP-MSCHAPv2/EAP-GTC EAP method IDs with different meaning > and behavior inside the tunnel method might cause problems in some > environments. If EAP-FAST were to be designed today, these > difficulties > could be avoided by the assignment of new EAP Type codes, which was > more > difficult before RFC 3748 defined expanded EAP Types.
Uh-huh. The extremely onerous & time-consuming FC,FS allocation policy... > The reuse may > cause problems in implementations where the use of unaltered methods is > required. It also can make implementations that use methods both > within > and outside of the tunnel method more difficult, since this support > requires special case execution of these methods within a tunnel. > Given > these issues, assigned method types must not be re-used with different > meaning inside tunneled methods in the future." This is getting tiresome. Given your obvious & continuing disdain for both the recipients of your messages (do you think that nobody on this list ever requested an EAP Type code pre-3748?) & the IETF in general, combined with the poor quality of the documents themselves, I will have to agree with Dan's assertion & ask that these documents not be published & that the existing IANA registries be removed. I'm sure that Cisco's marketing department can continue its fine job of publicizing EAP-FAST & you can just run your very own registry of EAP-FAST numbers. > > Thanks, > Nancy. > > > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Jari Arkko > Sent: Thursday, February 05, 2009 1:01 AM > To: Bernard Aboba > Cc: emu@ietf.org > Subject: Re: [Emu] Potential Notes in EAP-FAST Documents > > Bernard, > > > c. EAP negotiation issues. Neither the IESG note nor the text > > explicitly states what is wrong with using an EAP Type Code for > > incompatible versions of an EAP method that does not support version > > negotiation. > > They should state this. > > > Indeed, it would appear that some > > members of the IESG think that method overloading is required by EAP > > tunneling methods desiring to incorporate support for cryptographic > > binding. > Not sure who you are referring to, but for the record I at least do not > believe that. Cryptographic binding can clearly be achieved without > overloading or re-definition of behaviour of existing components. > > > Saying that this "might be difficult > > in some software environments" isn't a good characterization. > > Would the IESG use the same words to describe the reuse of IP > protocol > > > numbers within an IP tunnel? I doubt it. > > I guess this referred to the difficulty of implementing the remedy > where > EAP within a tunnel is different from EAP outside the tunnel. In some > cases this would be possible, in some other cases not... depending on > what the software architecture, APIs, etc are. But in all cases it is > painful, which is why this is a bad approach and should not be done by > future methods. > > Jari > > _______________________________________________ > 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
