Subject: Re: Uneccesary slowness.

From: Bob Braden <[email-masked]>
Date: Wed, 18 May 2005 13:55:13 -0700 (PDT)

Maybe it would be useful to talk about *necessary* slowness, also.

Bob Braden

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 19 May 2005 09:43:43 -0400

> Maybe it would be useful to talk about *necessary* slowness, also.

Indeed.

When I step back and ask  what leads to the best specifications (and
indeed, documents in general), it is all rather simple:

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.

2) Where the IETF is failing (at times) today is that it isn't
   actually reaching step 6) prior to sending a document to the
   IESG. Result: IESG finds issues that should have been found
   earlier.

3) You can "hurry" the process somewhat, but not too much. You can
   hurry it in the sense of having steps 1-3 take on the order of 3-5
   weeks. I.e., if you get fast (but good reviewers) and responsive
   editors, that is a huge win. The obvious corollary is that if steps
   3-5 take too long, you lose momentum big time. Indeed, one real
   problem we have today is too many WGs/documents are in a one
   revision per IETF meeting cycle. I would assert that any
   document/WG in this mode has veered off the road and into a ditch.

   You can also hurry the process by having good editors and good
   reviewers, as they help ensure that one doesn't get stuck in a rut
   at step 5).

4) In the above, there is nothing that requires the IESG do things
   differently. It really requires that _WGs_ do things
   differently. And, indeed there are some WGs that are doing the
   above, and doing it fairly well. They have
   chairs/editors/participants that move the discussions/the process
   along, they employ issue trackers to ensure that things don't get
   lost and so they can actually see whether the sorts of issues that
   are being raised are still serious, etc. And when those WGs do a
   good job, the IESG "delays" are generally short.

In summary, the most important improvement that the IETF needs to make
(IMO) is to get its WGs operating better and make them responsible for
demonstrating that the above steps have been followed (and
specifically, step 6 has been reached) before a document is allowed to
go to the IESG, and having those steps be done in a _timely_ manner.

Thomas

---

From: Dave Crocker <[email-masked]>
Date: Thu, 19 May 2005 08:20:46 -0700

Thomas,

>  have to have the reviews, and you have to iterate.

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

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

Can you cite any successful company that produces products in a dynamic 
market, according to the model you describe above?

I can't.

The model you describe fits my own sense of research efforts, not product 
development.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Scott W Brim <[email-masked]>
Date: Thu, 19 May 2005 11:41:53 -0400

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

The IETF does not have a "market" beyond its mission statement (qv.).
 The "markets" addressed by IETF activity depend on IETF participants.

> The model you describe fits my own sense of research efforts, not product 

To the extent that the problems the IETF participants choose to work
on are hard, the activities will in fact be research.  The point here
is to make the process efficient, not to hurry the work when it
shouldn't be.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 May 2005 22:02:27 -0400

>>>>> "Dave" == Dave Crocker <[email-masked]> 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.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 21 May 2005 10:12:08 -0400

>  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.

>  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.)

>  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...

>  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.

>  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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 May 2005 08:26:59 -0700

>deadlines.  The IETF currently does not do that.  Instead, we leave everything

This gives the unfortunate impression that setting firm deadlines is 
all it takes
to get product out.  This is contrary to my experience, and I suspect nearly
everyone else's.  I assume this is not what Dave meant, but that he is simply
pointing out the usefulness of having a deadline in planning, allocation of
resources, and setting up follow-on activity.

I'd like to suggest, though, that a better model for the problem is queuing.
At the moment, every "packet" (document) emitted by IETF working groups
and every document reviewed for the RFC Editor ultimately goes through the
same queue, which is not allowed to drop any item.  The traffic is bursty
and the resources used for processing the packets have priority interrupts
for other tasks (in the individuals: day jobs, family life; for the group:
appeals, other critical IETF business).

That the  queue depth gets longer should be no surprise.  That moving
things around in the queue starts to happen is no surprise, even though
moving them takes energy that could have been otherwise spent on throughput.
Making deadlines ever firmer creates priority interrupts or causes more
energy to be expended in queue management instead of throughput.

My personal belief is that we need to implement multiple queues instead.
If the IETF continues to believe that reviewing RFCs for end-runs is
valuable, okay; let's select individuals who can undertake that review,
and get it out of the "make standards" queue.  I've pushed that idea
before; I stopped because the simpler solution (ensure that there are
sufficiently different publication avenues for standards and RFC editor
documents) seemed to be gaining support and that pushed even
the development of the new queue to the RFC Editor.

The fundamental idea, though, remains:  important to the IETF does
not mean "needs to pass through the IESG".
				regards,
					Ted Hardie

PS.  I almost got through the whole email without saying
"functional differentiation".

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 May 2005 17:38:26 +0200

Dave Crocker wrote:
...
> deadlines.  The IETF currently does not do that.  Instead, we leave everything 

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

---

From: Steve Crocker <[email-masked]>
Date: Mon, 23 May 2005 11:56:14 -0400

Ted,

I like your queuing theory formulation.  A couple of easy things follow 
from looking at it that way.

1. Burstiness should result in temporary queuing, but it shouldn't 
result in continuously growing queues.  It's relatively easy to separate 
out the effects of insufficient capacity from burstiness.  I think these 
effects are usually given in terms of the first and second moments, i.e. 
average time to get through the queue and variance.

2. There's enough data available to allow someone -- not me -- to do a 
little parameter fitting to one of the standard queuing models.

3. It would be interesting to get some estimates from the relevant 
parties such as the RFC Editor, IESG ADs, et al as to how much time they 
think it should take to process an individual document through their 
part of the system, assuming no interference or queuing effects.  That 
would give the optimal time for processing a document and provide a 
baseline for understanding the queueing effects and/or other issues such 
as extra work for poor writing, waiting for normative references, down 
time for vacations, sick leave and day job, etc.  (My intuition is that 
it shouldn't take more than about 2 days to get through each part of the 
process if nothing else were in the way.  Except for burstiness and 
waiting for completion from authors, if the system were running 
smoothly, documents really should move that quickly.  All else is a 
symptom something is amiss.  And the numbers for the current system 
suggest (to me) that things are amiss big time.)

Steve

Ted Hardie wrote:
> This gives the unfortunate impression that setting firm deadlines is all 
> it takes

---

From: Thomas Narten <[email-masked]>
Date: Tue, 24 May 2005 10:49:34 -0400

> require open debate to converge to a rough consensus before those

One can't. That is what (at least some people) don't seem willing to
admit. If you want a quality document (and producing
readable/implementable documents is a key IETF deliverable), there is
no substitute for the review/iterate cycle I mentioned in an earlier
message.

Any attempt to eliminate or otherwise cut short that cycle will lead
to a loss in quality. While we can (and should) debate about the
proper balance between quality and timeliness, focusing only on
timeliness risks undermining a core IETF strength.

That doesn't mean there is no hope, however. What we should
collectively be working on is making the review/iterate cycle work
more efficiently and with fewer "dead time" delays, i.e., work hard on
eliminating "dead time" where the "token holders" of a document
(whether reviewers, editors or someone else) are not actually
delivering on their part in a reasonable amount of time. 

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 24 May 2005 10:50:22 -0400

Dave Crocker <[email-masked]> writes:

> 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.

We should do better at "setting deadlines", but simplistic deadlines
aren't enough.

Going back to my list of what is needed in a successful WG,

> 2) Building/having a "team", that serves as the critical mass and
>    "core competency" for the WG. This teams needs to have at least the
>    following set of skills (collectively):

>    a) project manager (i.e., puts together a pragamtic schedule --
>       something much more detailed than project milestones with
>       deadlines and nags folk to deliver, etc.)

Here is where the deadlines come in. And these deadlines need to be
updated on an on-going basis. And if it becomes clear that the window
of relevance is going to be missed, pulling the plug should be one of
the options on the table.

I.e., this is something that should be going on at the WG level.

Thomas

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 May 2005 11:28:47 -0400

> deadlines.  The IETF currently does not do that.  Instead, we leave everything 

Deadlines are useless unless they are well-informed.  If you haven't ever done
something before, you don't know how long it will take.  The timeframes we
put in our charters are guesses at best - maybe informed by intuition but 
little else.  At worst they are wishful thinking.

Another part of the reason our deadlines are unrealistic is that the milestones 
we set are usually meaningless.  Faced with the large task of developing
a protocol to do X, we fail to break that task down into meaningful subtasks.
A milestone like "produce draft 00 of document Y" is a measurable goal but
not a meaningful goal, because as stated it is irrelevant to the larger task.

> versus doing networking research. 

"Research" is a broad word.  Some forms of research are appropriate 
subtasks of an engineering effort and reasonable to do within IETF.
Others are not.  For instance, every WG needs to do some research 
to understand its problem space and likely impacts of its work.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 May 2005 18:10:00 +0200

>  require open debate to converge to a rough consensus before those

Contrary to Thomas' view, it is entirely to possible to achieve his, in spite 
of your and his certainly being correct that they create a trade-off tension. 
In fact it occurs regularly in the ietf, although perhaps less often than it 
used to.

Before discussing an example of how, let me cite some precepts:

1.  A charter is supposed to be a contract between the working group and the 
rest of the ietf community.  I believe we use the word "contract" very 
intentionally.

2.  Milestones are part of the contract and their inclusion is not merely pro 
forma.  Put differently: why include milestones, if they are not to be taken 
seriously, both by the working group and the iesg, both at chartering time and 
during working group operation?

3.  IETF output is supposed to get used and the likelihood of that happening 
depends upon the timeliness of the output event.  Not *only* on timeliness, 
but timeliness is almost always a critical factor.  

As for the exemplar:

1. The working group has to take the deadlines seriously.  In other words, 
there must be working group buy-in for the need to be timely.

2. The chairs must balance fair and open "discussion" with the need to make 
"forward progress".  Infinite open discussion, in the absence of forward 
progress, is not useful.

3. As the chairs press for forward progress, they repeatedly confirm with the 
working group that participants have rough consensus that forward progress is 
important.  (If they fail to achieve that particular rough consensus, the 
working group probably should consider disbanding.)

4. The chairs work actively to resolve open issues, rather than waiting 
patiently for it to happen on its own.

As I said, I claim that the above is done frequently by ietf working groups 
and that the process is entirely fair and open and the results are (more 
often) useful to the community.

One of the real problems with discussion of this sort of topic is the tendency 
to jump on a particular posting and trivialize its comments.  

For example, if someone says that timeliness is important, they have not said 
that other issues are unimportant.  Yet some folks seem pretty eager to assert 
that that has indeed been said.  It would greatly aid discussion for folks to 
refrain from presuming that a participant has said something naively 
simplistic

  d/
  ---
  Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 May 2005 10:18:44 +0200

Dave,

You described the charter as a contract between the WG and the rest of 
the IETF.  I'll argue an alternative below, but let's stick with 
contracts for the moment.  My basic understanding of contract law tells 
me that there are certain real world and legal limitations on contracts 
that must be considered:

1.  A contract requires due consideration from all parties, meaning that 
nobody performs without an expectation of receiving some sort of 
benefit.  What are the benefits to the WG and what are the benefits to 
the rest of the community?

2.  Most contracts don't require the dissolution of a party should it 
default.  Rather there are remedies, often times monetary.  Sometimes 
there are bonuses.  My point: dissolving a working group because they're 
late would often be imprudent and short of replacing the chair there are 
very few other viable remedies.

3.  A contract in which one of the parties cannot reasonably be expected 
to carry out his or her obligations is not a contract at all.  Again, if 
the WG is a party and the community is a party, what is the expectation 
of the community and is it reasonable?  But even with the WG is it 
reasonable to ever expect innovation as part of the solution under such 
a circumstance?

4.  Contracts generally have limitations when it comes to unforeseen
circumstances, force majeure, etc.  One such unforeseen circumstance is 
where a working group comes up with a solution and the IESG finds 
sufficient fault with it to require a review.  In this case, the terms 
of the contract need to allow for a resetting of the charter.

As I wrote above, I don't think the contract analogy is perfect.  I 
think we want a cross between a research proposal a'la NSF etc. and a 
contract, where we allow for changes in direction based on developments 
within the working group.  I'm not saying we should ignore 
non-performing or under-performing groups, but we should certainly allow 
some flexibility.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Sat, 28 May 2005 08:55:16 +0200

Eliot,

interesting note.  it is always provocative to challenge long-standing precepts, 
in this case as per section 2.2 of RFC 2418, Working Group Guidelines, first 
published as RFC 1603, in 1994.  That does not guarantee that your challenge is 
mis-placed but rather that it is fundamental to the long-established view (or 
that it isn't so much as a challenge but rather a call to make sure we know what 
we have been meaning.)

>  the rest of the community?

I suspect each of us might answer this differently.  My own answer is that the 
working group gets the IETF imprimatur on its work and the IETF gets work to put 
its imprimatur on.  (There is a more elaborate and less glib way of saying it, 
but if you think about the implications of each side of the statement, I trust 
it will be obvious that each is, in fact, a significant benefit.)

>  very few other viable remedies.

Contracts typically DO have an out.  So, dissolution of the relationship is not 
at all uncommon.  In this case, the dissolution is of the entity within the 
IETF, not of the collection of people within the working group.

At any rate, (eventual) termination for non-performance is more than just 
'typical' in contracts, it is very nearly mandatory for a competent contract in 
which one party authorizes work to be done by the other.

Yes, having steps for first attempting to cure the problem is, equally, typical, 
but cures often do not work.

>  reasonable to ever expect innovation as part of the solution under such

Sorry, but I don't understand any of this one.  The best I can think to respond 
is to the question of mutual expectations, which certainly is needed for a 
legitimate, formal relationship.  

The community expects working groups to produce material that is timely, 
relevant -- to the targeted consumer base -- and useful.  (For anyone who hasn't 
been tracking the ietf list recently, these 3 items are my own mantra, though I 
think they are entirely or largely compatible with the views of many others.)

The working group expects that it will have the support of the IETF community 
(such as by receiving the IETF imprimatur) for wg output that conforms to the 
requirements I cited.  

Timely performance is a typical expectation for a contract.  Therefore one might 
reasonably view a lack of timeliness on either side as a contractual violation.  
The same hold for imposition of whimsical requirements at the end of the effort, 
or other impositions that are unproductive to the generation of timely, relevant 
and useful documents.

>  of the contract need to allow for a resetting of the charter.

As much as the IESG does, indeed, seem to be a force of nature, your example 
nicely underscores the problem of last-minute requirements-creation by the iesg. 
 They have a choice in the matter.  It does not come from some external, 
uncontrollable source.

Let's keep the contractual model and pursue the exercise from a purely pedantic 
standpoint for this matter:

The IESG is supposed to perform oversight of the on-going working group, on 
behalf of the larger IETF community.  At the end of the wg's effort, if the IESG 
suddenly decides that some new requirement is to be imposed, then the IESG is 
demonstrating that it did not do the on-going oversight that is normal for any 
contract.  If the wg submits something that suddenly contains something that is 
new and problematic, then it has not been coordinating properly with the agent 
providing it with oversight.

(I am trying to explore these sort of things as having mutual obligations.  It 
is a point you stressed and I think it applies quite helpfully to the 
relationship between the IETF/IESG and the wg.

>  non-performing or under-performing groups, but we should certainly allow

In an earlier and simpler time, it was entirely safe to permit this, since the 
*real* oversight of a working group's effort came from within the working group. 

In the larger and more diverse IETF, I must entirely disagree with any 
suggestion that IETF working groups can operate in a research mode of any sort.  
That's what the IRTF is for.  The IETF side of things is for developing a 
community consensus about the engineering of a technology or practise for the 
global Internet.

(and on that, my *own* provocative note...)

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 May 2005 12:14:33 -0400

> suggestion that IETF working groups can operate in a research mode  

I think you're simply wrong about that, for the reason that research  
and engineering are not mutually exclusive and it's difficult to draw  
a definite line between the two.  In particular, almost no IETF  
working group really understands the nature of the problem it is  
trying to solve at the time it is chartered, and to gain the  
appropriate level of understanding will often require some  
research.   I am also inclined to believe that protocol engineering  
almost inherently involves _more_ research than many other forms of  
engineering.  Designing protocols is not like designing bridges or  
automobiles in that most of the design constraints are understood  
when the effort is undertaken.  Every new protocol that is designed  
requires a new learning experience.  This is true even if there is a  
legacy protocol in the same space - because often that legacy  
protocol was not well-designed and does not adequately serve the  
needs of the broader Internet community.  Indeed, one of the "value  
adds" that IETF provides is the vetting of a design across a broad  
set of interests.  Denying the ability of IETF WGs to conduct  
"research" would remove much of that added value and impair IETF's  
ability to do a good job.

The existence of IRTF doesn't change any of this.  Nor would it be  
beneficial to anyone - IETF, IRTF, or the community of users - to  
require that every IETF WG be preceded by an IRTF RG so that the  
"research" phase of the engineering effort could be done in the  
"right place".  IRTF seems like a good place to do research in areas  
where we don't have a good grasp of the problem we want to solve and/ 
or we don't have a good idea what the eventual engineering solution  
should look like.  But this doesn't mean that all research should be  
done in IRTF.

Keith

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 30 May 2005 04:30:09 +0200

Dear Keith,

At 18:14 29/05/2005, Keith Moore wrote:
>research.

Unless the WG is lead by a group which want to force an external 
proposition through.

>  I am also inclined to believe that protocol engineering

One of the form of this pre-research should be community experimentation. 
ICANN called upon such an experimentation in one of its reference document 
(ICP-3 Part 5/conclusion). It calls for it to be controlled by 
organisations such the IETF. Prior to launching such an experimentation in 
2001/2003, and from time to time, I recalled the ICANN's call on this list. 
The response was always that this is not the role of the IETF as a standard 
organisation to carry an operational test. However ICANN makes a very good 
point that Internet always developed that way...

The experimentation we carried shown that ccTLDs and national internet 
communities have the need for a permanent test-bed and for guidelines that 
only such an experimentation can really document and check. This is in 
domains I feel not covered by an IETF area (national security, naming and 
addressing sovereignty, multilingual ethics, service innovation, cultural 
empowerment and support, ICT convergence, user-centric network 
architecture, CRCs, externets, naming PADs, impaired users-support, network 
interoperating system, etc.) with possibly deep architectural and technical 
consequences in many areas.

I have undertaken the writing of a Draft on this. I can document what ICANN 
and our experimentation identified. I am embarrassed in documenting the way 
IETF should share in this experimentation and in its support. And how to 
include the work on resulting best practices in the IETF Internet standard 
process.

Some of the main problems I see are:
- which organising entity: ICANN calls (so it will not take the lead) for a 
community effort, IETF can advise but not organise? A specialised TF?
- which IETF area is/are concerned (IMHO every of them and more)?
- changes in the Internet usage architecture.
- probable involvement of other SDOs (ISO, MPEG, WSIS, WIPO, WTO, ICANN, etc.)?

>where we don't have a good grasp of the problem we want to solve and/ or 
>we don't have a good idea what the eventual engineering solution

Another problem is the "time to the market" issue. There are areas like 
multilingual internet where the urgency of the need or commercial interests 
lead to the risk of propositions that no existing R&D can advise.

jfc

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 May 2005 20:15:14 +0200

Hi Dave,

> that it isn't so much as a challenge but rather a call to make sure we know what 

Yes, I understand.  My point is that the analogy is strained.  Please 
see below.

> at all uncommon. 

> but cures often do not work.

First I agree that terms of dissolution are important, and I probably 
wasn't as clear as I could have been.  I meant that one shouldn't start 
with the nuclear option, if you'll pardon the use of the term.

> think they are entirely or largely compatible with the views of many others.)

Yes.  You and I differ on what "timely" means.  We also differ about the 
nature of work done in WGs.

>  They have a choice in the matter.  It does not come from some external, 

We have a working group that did something unexpected.  It wasn't 
against its charter, but it doesn't sit well with various IESG members. 
  What should happen?  Should the IESG suffer the choice?  If so, why do 
they exist?  Keep in mind, by the way, that IESG members change.  What 
happens then?  Should the new member let such a concern go just because 
the old guy didn't catch it earlier?  All of this just happened in ISMS.

> community consensus about the engineering of a technology or practise for the 

I guess my concern is that we're not building cookie cut houses.  We're 
not a fab factory.  Companies who have hierarchical control can't 
predict the exact release of a product when new techniques are used. 
They can't do this precisely because the techniques are new.  Who knew, 
for instance, that going into ietf-smtp we would end up with MIME?  Not 
I.  Who knew going into the IPng effort we'd end up with a 16 byte 
address.  Definitely not I.  Why?  Because some of this stuff is Hard.

While recognizing that good is the enemy of great, I would hate if a WG 
felt so under the gun to complete in order to get shlock out the door. 
I can demonstrate several examples of that.

Regards,

Eliot