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
