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