Pasi,
If folks are opposed to publishing descriptions of deployed EAP method
when they're less than perfect (or even ugly hacks with bad
architecture),
and may not offer perfect security in all circumstances (but accurately
document their limitations), they should have said so much earlier.
Indeed.
(In hindsight, publishing these via the RFC Editor independent submission
route, and including the vendor's name in the document title, might
have been better idea. Since the intent was to describe what existing
implementations do, the IETF does not realistically have much change
control...)
Maybe we should focus on what to do next as opposed to figuring out what
we should have done years ago. However, I think this would not have
changed the substance of the matter, and per RFC 3932 the IESG would
probably have noted that a non-IETF submission should not have an effect
in an EAP type code defined by an IETF RFC (RFC 3748). So I think the
document took the right path (and I still think it should be published),
but we can of course wish that some of this discussion had happened in
Last Call. That is, after all, what Last Calls are for :-)
Jari
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
