Hi Alan, One could use the same argument. Those only interested in implementing EAP-TLS will be forced to wait while all other methods are being updated.
Anyhow, I don't expect the other document to take 18 months. I look forward to your submission (and reviewing it once it is available). --Mohit On 2/5/19 3:16 PM, Alan DeKok wrote: > 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
