Re: Uneccesary slowness.

[Sean Dorman <sean_dorman@xxxxxxxxx>]

The purpose of IETF is to provide documented standards and guidelines that help guide the market, NOT the other way around.

 

Market relevance is NOT what drives IETF. Market relevance is moot, whereas the "Rinse-Repeat" means of idea refinement is not; we do the best we can with what we have.

 

I design software. When I finish a programming assignment, MORE THAN LIKELY additional ideas and changes will have to be addressed AFTER the software is released.

 

Thus we have "Versioning" and "Legacy systems"...

 

Does that make the initial program development stage any less relevant?

 

What IETF produces is more like a piece of sculpture worked on by multiple artisans. A document is complete when ALL involved parties agree a document is complete.

 

What market relevance that does exist is fleeting at best, due to the introduction of new ideas and new technologies at sporadic points; before, during & after the development of a standard or guideline has begun. This will not change.

 

Thus the reason our industry has newer RFC's to replace older, no longer applicable, versions due to "unforeseeable" changes.

 

The only way to expedite standards development is to focus on developing standards utilizing the knowledge we have, on hand, at the initial time a standard is proposed BARRING outside or ancillary motivating factors.

 

As for Kerberos, that's a perfect example of ancillary issues and market relevance having a noticeable impact on it's development. Not to mention the introduction of new people / new ideas "along the way" during the years of development it took...

Sam Hartman <hartmans-ietf@xxxxxxx> wrote:

>>>>> "Dave" == Dave Crocker 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.


Inste! ad, 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 mailing list
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

---

Do you Yahoo!?
 
Yahoo! Small Business - Try our new resources site!
_______________________________________________

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