Yoav Nir wrote: > > My conclusion is that we can't just ignore industry and keep polishing > away, but that we have to do things in a timely manner. One thing > we've learned from the TLS renegotiation thing was that it is possible > to get a document from concept to RFC in 3 months. Yes, you need > commitment from ADs and IETFers in general (IIRC you and I were among > those pushing to delay a little), but it can be done. Funny that you mention TLS renego. This document was actually a severe abuse of most IETF process rules. And a significant part of the document contents was written and published against WG consensus and without IETF consensus. We could have easily finished the work in two month with a simpler and more robust solution and higher quality spec if there had not been so much resistence from a group of conspiring vendors plus AD, WG co-chair and document editor. I realized it is *MUCH* easier to write a new I-D from scratch than getting the problems of the original proposal fixed by discussion in the WG because of the existing bias -- which is why I think that both, the document editing process and the "WG item, documented progress hobbled by consensus process" is the most significant roadblock in IETF document progression if there is strong bias in the system. If there is a need to ship draft versions of a spec, there should be a field in the protocol identifying which version of a draft a particular implementation is based on -- or the "early adopters" should voluntarily bear the burden to either limit control or field update distributed implementations of early drafts. Another worrysome event was with the TLS channel bindings document, when the definition of "TLS-unique" channel bindings had to be changed underneath the RFC Editors feet to match the installed base of some vendor (who failed to point out this issue earlier, although the original definition had been like that for a few years). Or the gssapi zero length message protection, which had been explicitly described for GSS-APIv2 (rfc-2743,Jan-2000) because it is a non-expendable protocol element required by the FTP security extensions (rfc2228,oct-1997) specified in rfc-2743, section 2.3 last paragraph of page 62: https://tools.ietf.org/html/rfc2743#page-62 but foobar'ed in Microsoft Windows Vista & Windows7 (fails decryption of gss_wrap(conf=TRUE) tokens with SEC_E_ALTERED_MESSAGE). This features is tested and the error is reported by the OpenSource gssapi test tool that I've been providing since 2000. But as I've previously commented: http://www.ietf.org/mail-archive/web/kitten/current/msg00640.html testing seems not very high up on some vendors priority lists. It is a real pity that either Microsoft didn't bring any Vista betas to this event: https://lists.anl.gov/pipermail/ietf-krb-wg/2006-March/005885.html or there was no interest in performing rfc-4121 interop tests with a GSS-API interop test tool that works quite well for interop testing an MIT Kerberos for windows with Microsoft Win2K&Win2K3 Kerberos SSP. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf