> For the record, I'd like to say that I believe estimates of how fast > we can do work expressed in the Huston proposal that started the whole > problem discussion are too optimistic. The numbers were debated among, and chosen by, a set of long-term IETF participants with extensive product delivery experience. That doesn't guarantee that the numbers are the right ones to choose, but it means that they had a pragmatic basis. The only way to make sure deliveries of product -- in this case, IETF documents -- are timely is to decide when they are needed by and set firm deadlines. The IETF currently does not do that. Instead, we leave everything open-ended. At base, there seems to be quite a bit of confusion about the different between delivering useful engineering specifications for use on the Internet, versus doing networking research. Some of the responses on this thread reflect that confusion, suggesting that taking an essentially infinite amount of time is just fine. I thought that that was what the IRTF was for. > Speaking as a vendor who ships IETF technology, I would never let IETF > time lines or milestones become critical dependencies for my products. If IETF output has no critical utility to product development, then it is not clear what we are doing. What is the utility, if not to become critical to the products used in the Internet? Sometimes, the output provides incremental benefit, so that developers can choose to fold it in, whenever convenient. The product is useful without the IETF output. At other times, the output is needed to create a basic capability. Exterior routing would be an example, as would a public email format... (On the other hand, private conventions for mail attachments were used for years before MIME was defined.) > That is true no matter how good the IETF gets at being efficient. It > is inappropriate to let an external organization create critical > dependencies without contractual relationships that hold that > organization accountable for failing to deliver on those dependencies. It is inappropriate for the IETF to take forever to turn out complex specifications that then have questionable utility. It costs money to participate in the IETF. If an organization cannot see near-term benefits, it will stop spending the money to send participants. Oh. That's what is already happening... > I'd certainly like to be faster and more efficient in producing > standards. THat phrasing suggests this is merely a "nice" improvement to have, rather than one that is critical to the long-term survival of the organization. > P.S. It took us 10 years to finish the first revision of Kerberos. > Yes, years could have been taken off that process. I don't think the > process could have been cut in half and still produced a reasonable > result though. I'm quite happy with that work and think it has been > useful to the vendor community. really? what the market penetration? how many people use kerberos? or rather, how many use the version that took 10 years to produce? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf