On Feb 5, 2019, at 12:25 AM, Mohit Sethi M <mohit.m.se...@ericsson.com> wrote: > > Thanks for bringing this up. I agree that we should take this > opportunity to fix other EAP methods which rely on TLS for the outer > tunnel. I think that these updates merit a separate document. But I am > not certain why the two documents need to be published simultaneously?
To be clear: they don't need consecutive RFC numbers. But it will be absolutely a disaster if EAP-TLS is published, and then 18 months later "TLS 1.3 for other methods" is published. It makes zero sense to publish TLS 1.3 for EAP-TLS, and then to tell all of the other EAP methods "too bad, you're not getting updates". People will want to use TLS 1.3 for other methods, and they will ask the very good question as to why the IETF punted on the problem. If there is no standard for TLS 1.3 for other methods, the customers *will* demand one, and implementors *will* create one. At that point, the IETF will have ceded change control for those EAP methods over to those implementors. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
