ISSUE: Determinants for timeliness missing in section 2.1

Dave Crocker dhc at dcrocker.net
Wed Jul 9 23:07:48 CEST 2003


Ted,

Light is great.  Excellent idea...

hqc> of the situation may require public discussion, but I think the main problem
hqc> for this list has already been raised:

hqc>   It is difficult to manage dependencies between groups and
hqc>   the result of creating those dependencies may be that
hqc>   the output of a group is slower than it would be without that
hqc>   dependency or set of dependencies.

My original note focused on a particular kind of delay.  XMPP was merely
cited as an example.  The focus was on XMPP, not IMPP.  Deferring debate
about IMPP is certainly fine with me, since it was not something I was
raising.

However, with all due respect, I must observe that your summary does not
cover the point I was/am making..

My point was about a certain *kind* of delay, and a certain *aspect* of
purported coordination. The difference between that point and your
summary is significant.

The text I wrote said:

   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.

and with respect to the current example of XMPP:

   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.

In other words, the point I was raising is exactly NOT about the
difficulty of coordinating dependent effort.

It was/is about:

   a) the artificial creation of process dependencies, in the absence of
   any clear technical dependency, and

   b) post-hoc creation of dependencies, even though a working group has
   fulfilled its charter and has a ready constituency awaiting
   publication of its work.


hqc> Though the IMPP-related mechanisms have been put into a separate
hqc> document, I do not believe that the IETF last call can adequately
hqc> assess the set of documents if the scope is not known, that is,
hqc> we're not sure whether they are meant to be part of a mesh of
hqc> cooperating IM systems or meant to stand alone (the question of how
hqc> to judge "completeness" in 2026 terms being critical).

I believe the general form of your statement, here, is that the IETF
should not issue any components of a set of specifications, until we are
completely clear on all the ways it will be used.

No doubt, that is not what you intended to imply, but I would request
you to consider carefully the interpretation I am offering. I believe it
represents a natural derivation of what you *did* write and it is a
very, very slippery slope to take a step on.

In effect it means that we can arbitrarily delay issuing specifications
which appear to be well written and usable, but for which we have some
ill-defined discomfort about its use.

And, of course, this is not a forum for trying to resolve IMPP or XMPP
questions.  However it *is* a forum for considering problems with
timeliness.

And I think you have demonstrated a very basic issue with the role the
IETF is attempting to take in standards management.

At base, the question is just what level and type of gate-keeping is
appropriate for the IESG should perform, for work that has a clear
community constituency, produces competent specifications, and which
fulfills its charter in a timely fashion.

The concept that there is some higher-level "coordination" (or, rather,
orchestration) that the IESG should be doing sounds quite reasonable,
but has not been anything that we have done successfully.  And it's
always dangerous to take on such a task when the existing track record
suggests we will doing it badly.

In other words, abstractly purporting to perform coordination on efforts
that have little or no known technical dependency, but is instead based
more on ill-specified "discomfort" is only effective at introducing
uncertainty and delay.

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