ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets)

[graham.travers at bt.com]

Apologies if somebody's already addressed this, as I've been away and missed
some of the discussion.

It's been said of I-D's, and it's true of these wider issues too: give the
definitions before starting to discuss them.  

Do we have any working IETF definitions of *current* customers, mission, etc
?  If not, I think we should solve that problem before trying to understand
*customers' requirements*, *furthering the mission of the IETF*, etc.

	Regards,

	Graham Travers

	International Standards Manager
	BT Exact

	e-mail:   graham.travers at bt.com
	tel:      +44(0) 1359 235086
	mobile:   +44(0) 7808 502536
	fax:      +44(0) 1359 235087

	HWB279, PO Box 200,London, N18 1ZF, UK

	BTexact Technologies is a trademark of British Telecommunications
plc
	Registered office: 81 Newgate Street London EC1A 7AJ
	Registered in England no. 1800000

	This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or email (to the numbers or address above)
immediately.
	      




-----Original Message-----
From: Keith Moore [mailto:moore at cs.utk.edu]
Sent: 11 June 2003 15:59
To: Dave Crocker
Cc: harald at alvestrand.no; moore at cs.utk.edu;
problem-statement at alvestrand.no
Subject: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes shold
be focused on IETF purposes, not markets)


On reading this, I'm convinced that "excessive perfectionism" is not an
accurate statement of the forces that delay our standards.  It might seem
like
excessive perfectionism to the person who thinks it's "good enough" or who
doesn't recognize the reason that the change is being requested.  But I
think
the real problem is more subtle (and more insidious) than that - e.g.

- When a protocol affects a large span of interests, we have trouble getting
  a widespread understanding of the issues.   The folks who are "pushing"
the
  protocol often represent a narrow set of those interests, and they might
  even be reluctant to try to understand those issues that don't affect them
  directly; seeing them as distractions rather than genuine issues that need
  to affect the design.

- Often we have trouble even identifying some of those issues in a WG before
  the design is considered to be mature and frozen, but this is usually
  because the WG hasn't tried to do so.

- Even if we have the issues on the table, many groups have a difficult time
  making decisions in a timely fashion.  Those who want those pesky issues
to
  go away may hope that the ones pushing those issues can be considered 
  irrelevant to the rough consensus, so (perhaps out of fear of delay should
  the issue be found to be valid and require a change to the protocol) they
  will do anything to discredit the issue (or those raising the issue)
rather
  than look at it.  Those who want the issues to get fixed may try to delay
  the proceeedings merely in the hope that someone will eventually start
  taking it seriously (sometimes this even works, but rarely).

I also agree with Harald that neither "the timeframe that markets need" nor
"appropriate quality" are objectively identifiable with any accuracy.

So I suggest that this be reworded:

The frequent inability of the IETF to deliver specifications within
the timeframe expected by those "pushing" the specifications could be 
improved if appropriate Engineering Practices were in use and in particular,
if IETF working groups could recognize issues associated with their
specifications early in the development process, and once the issues
were identified, if they could make design decisions and have review on
those
decisions in a timely fashion.

Now I also agree with Dave that IETF has some tendency to ignore its
customers; but I believe that the customers of a WG are all of those
affected
by the WG output, not merely those who want that particular WG's output to
be
finalized.  Those customers are often very distant from the WG, they have
little idea about what the WG is actually doing because what little they
know
comes from the trade press, speculation on slashdot, or other rumor mills.
So
I don't think it's realistic to give customers what they want or expect;
instead, we need to try to give customers what they need.  In this sense we
are different from an organization that derives income (and existence) from
sales and which is content to give customers whatever they will pay for (as
long as it has sufficient margin).

> The existing text is intended to precisely highlight the IETF's tendency
> to ignore its customers.
> 
> Your suggested change eliminates that point entirely.
> 
> While one might develop a logic chain that puts it back, one can easily
> instead develop a logic chain that says that the timeframe can whatever
> any particular IETF participant believes it should be. Hence, the direct
> reference to the needs of the market is the key point in this problem
> statement.
> 
> 
> d/
> 
> HTA>    The frequent inability of the IETF to deliver specifications
within
> HTA>    the timeframe that the markets need and the excessive
perfectionism
> HTA>    that is exhibited in some cases could both be improved if
> HTA>    appropriate Engineering Practices were in use.
> 
> HTA> ISSUE: This sentence presupposes that the "timeframe the markets
need"
> HTA> and the "appropriate quality" are relatively quantifiable quantities.
I
> HTA> think they aren't.
> HTA> SUGGESTED RESOLUTION: Replace "the timeframe that the markets need"
> HTA> with"the timeframe in which IETF particpants think they are needed to
> HTA> further the mission of the IETF".
> 
> 
> 
> 
> d/
> --
>  Dave Crocker <mailto:dcrocker at brandenburg.com>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
>