Subject: Re: Uneccesary slowness.

From: Sean Dorman <[email-masked]>
Date: Fri, 20 May 2005 08:54:00 -0700 (PDT)

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 <[email-masked]> 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.

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sean Dorman <[email-masked]>
Date: Fri, 20 May 2005 10:17:58 -0700 (PDT)

So the outline of "What is the IETF" http://www.ietf.org/tao.html#what 
is not agreed upon?
It doesn't mention market relevance...did I miss something?
 
In the close to 10 years I've been a member, my understanding was our 
goal was to be outside market influence and be part of something 
"influential"...
 
Our "late coming IETF specifications" are making us irrelevant.
 
While I agree that "implementers' consensus" working groups are 
typically market
driven, I think the greatest issue that needs to be addressed IS 
expeditious consensus within IETF ( IE identifying areas there need to be 
more effecient / more timely... )
 
IETF should be guiding and driving the market, not responding to it 
with hindsight.
 
Some element should be added to the specifications process, some 
limiting time frame administered internally, which eliminates our being late 
( IE paralleled idea development )

Christian Huitema <[email-masked]> wrote:Friday, May 20, at 2005 8:54 AM Sean Dorman wrote:

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

There is no agreement that this is in fact the purpose of the IETF.
Historically, the IETF has engaged in two types of activities, creating
technology that was perceived as much needed for the Internet, and
driving consensus between implementers on specific functions. 

The "implementers' consensus" working groups are typically market
driven. A bunch of companies or non-profit groups realize that they are
working on quasi similar products, and that using an interoperable
standard would be more efficient than letting the market sort out
between proprietary designs. Such working groups typically have strong
timing requirements. If the IETF takes too long to reach consensus, then
proprietary solutions will gain market share, and the late coming IETF
specification will be essentially irrelevant. Having delays because the
working group cannot agree is bas enough, but it can usually be avoided
by just letting several proposals progress in parallel -- a choice
between two standard ways being sometimes perceived as more efficient
than complete fragmentation. On the other hand, there is no excuse for
delays created by bureaucratic processes and arbitrary pocket vetoes.

-- Christian Huitema

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 20 May 2005 10:50:45 -0700

> It doesn't mention market relevance...did I miss something?

It also does not mention "guiding the market", but rather prominent
usage of words like "pressing" or "near-term" that emphasize the need
for timely completion of specifications. 

A phrase like "Specifying the development or usage of protocols and the
near-term architecture to solve such technical problems for the
Internet" specifically does not mention that the IETF proposes solutions
to all problems, or that the IETF solution is expected to be adopted
regardless of process issues. The philosophy is simple: the IETF
proposes, and if the IETF solution has merit it will be adopted. There
are plenty of examples of IETF standards that did not get significant
adoption, and non-IETF protocols that got wide deployment. 

-- Christian Huitema

---

From: Sean Dorman <[email-masked]>
Date: Mon, 23 May 2005 08:53:55 -0700 (PDT)

First, our group would have to come to some agreement on what would be considered "timely".Do we want to limit submission / introduction of new IETF documents to one month time frames? 6 months? 1 year? 2 years?
 
Some framework has to be agreed upon by the entire group to satisfy the criteria of being timely. Would most people feel that if IETF documents were introduced within, say, a year, would be considered timely, as long as said document(s) addressed issue relevant for the next 3+ years?
 
Once we have defined what would be considered timely, we could then focus more on some method of ammendment / addendum policy that could allow for IETF document adaptation over extended periods to allow for unaccounted-for situations and/or technologies.

Brian E Carpenter <[email-masked]> wrote:
Dave Crocker wrote:
...
> 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. 

I'm very curious how one can set rigid deadlines and simultaneously
require open debate to converge to a rough consensus before those
deadlines.

Brian