ISSUE: Determinants for timeliness missing in section 2.1

Dave Crocker dhc at dcrocker.net
Mon Jul 7 18:03:43 CEST 2003


Harald,


>> One is that the folks imposing those additional requirements are not the
>> folks doing the work to satisfy them. Consult one of Randy's learned
>> texts on management about the effect of a pattern of such impositions on
...
HTA> [I'm not convinced that this point achieves anything but pointless debate
HTA> about who is doing "real" work.... I won't pursue at this time]

Harald, if you had really chosen not to pursue it, then you would not
have written something that rejected it as "pointless debate",
particularly when I offered it as a fundamental point, which I
encourage you to consider further:

   I was referring to situations in which we have people doing real work
   of real quality for a real market, and the work is delayed for
   external factors, by people who are not perceived as helping to
   resolve the problems.

   The de-motivating effect of such forces is not "pointless", although
   it often makes participation seem that way.

The IETF has, historically, given priority to the people who do the
work. Others are not irrelevant, but there is a clear -- and, I believe,
entirely appropriate -- difference in their role.

It does not take much of a review of IETF history to see that most
generalized requirements for "coordination" -- and most especially those
that are imposed post-hoc -- are not successful, except at causing
delay.

Feel free to cite examples to the contrary. I do not know of any myself.

It is particularly problematic to impose delays *after* work has been
done that followed its charter, proceeded in a timely fashion, and shows
all the signs of having an eager community to implement it.



HTA> I still have not been so educated in the IMPP case, it seems, but that is a
HTA> debate for another forum.

Problems with IMPP are one thing, and convincing the IETF Chair who
happened to previously be chair of IMPP, is another.

Neither is the issue, here.

The issue I was citing was forcing XMPP to be delayed, when there are no
known problems with it. Citing the need to resolve IMPP matters, prior
to processing XMPP working group output, is a very good example of a
post-hoc requirement that is -- at very best -- only going to cause
delay.

So far, no one has stated that there are any technical problems with
XMPP.

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>



More information about the Problem-statement mailing list