Re: Uneccesary slowness.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Dave" == Dave Crocker <dhc2@xxxxxxxxxxxx> writes:

    Dave> Thomas,
    >> 1) produce a document.  2) get a small number of quality
    >> reviews.  3) revise in response to those reviews 4) ensure that
    >> reviewers in step 2 are satisfied by the revision.  5) Repeat
    >> steps 1-3 with a _different_ set of reviewers.  6) Repeat step
    >> 5 until it becomes clear that the reviewers are finding only
    >> minor editorial issues.
    >> 
    >> Observations:
    >> 
    >> 1) You can't hurry the above, e.g., by imposing artificial
    >> deadlines, or by saying "no objections during LC, therefor
    >> ready to go". You have to have the reviews, and you have to
    >> iterate.


    Dave> The IETF is supposed to produce a product that has market
    Dave> relevance.

    Dave> It has to be useful to a sufficient number of vendors and
    Dave> operators within a window of opportunity.  Windows of
    Dave> opportunity close.


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.  Also, much of our work does
have value even if it takes longer than sufficient value in the market
to justify us doing it even if it takes longer than that proposal
anticipated.


Speaking as a vendor who ships IETF technology, I would never let IETF
time lines or milestones become critical dependencies for my products.
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.


Instead, I ship a product based on my best ability to predict what
will happen in the IETF.  I budget time for fixing my product to
comply with the standards as they emerge.


I'd certainly like to be faster and more efficient in producing
standards.  I do understand that if the IETF takes too long that it
limits relevance for its work; it must leave a space or adopt small
changes on what was actually shipped.


--Sam

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.  On the other hand, it took too long
for some participants and we'll be facing interoperability problems
for years because of that.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]