ietf
[Top] [All Lists]

Re: Uneccesary slowness.

2005-05-21 07:12:44
 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>