Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Jul 2003 08:59:55 +0200

Harald,

>> On the contrary, I believe there were plenty of people in both
>> situations that had a very clear vision of what they wanted to achieve.
>> The real problem is that they were prevented from pursuing those
>> visions, due to requirements to satisfy additional constraints and/or to
>> coordinate with competing efforts.

HTA> I don't think those two descriptions contradict each other....
HTA> as I frequently say when asking for charters to be more clear:

I was referring to situations in which there is a constituency that is
clear about what it thinks needs to be done and says so clearly. I was
referring to situations where such a constituency is prevented from
making progress, either

1. because they are forced to "negotiate" or "compromise" with a
different group that has a different -- and usually equally clear sense
of needs and tasks -- at the level of paradigm differences, or

2. because they are saddled with a potentially large and potentially
varying set of additional requirements, by folks who are not doing the
work.

All of this is well-intentioned, but that is irrelevant. (I mention
this, in order to to exclude conspiracy explanations.)

And all of this has nothing at all to do with basic engineering flaws
that mean the result of their efforts will fundamentally not work. (Path
#2, above, is often claimed to be in the interest of ensuring that the
result will work, but folks are directed to Charlie Perkins' thread, of
9 June, on that score.)

By way of providing a concrete example, I'll note the problem with
imposing delays on XMPP while the highly problematic IMPP stuff gets
worked out. XMPP is derived from an extremely successful, working
system, with a significant installed base. The technical work has been
done diligently and in a timely fashion. There is even documentation
that the work satisfies the published IETF "requirements" for an IM&P
service.

Best of all, there is a clear constituency for using the working group's
output. Yet it appears that that work will not be issued in a timely
fashion, because there are problems elsewhere, outside of the working
group. Concerns about Internet-scale "coordination" of multiple IM
efforts are, at best, misguided, at this point.

HTA> When we have the case of "plenty of people .... that had a very clear
HTA> vision of what they wanted to achieve", and have "requirements to satisfy
HTA> additional constraints", the people imposing additional constraints are
HTA> people too, and part of the community. What's more, in the cases where
HTA> those "imposing" people are chosen as leaders of the community, they
HTA> believe that they represent other members of the community - and may even
HTA> be right.

This was an extremely helpful posting.  I think it honestly and
accurately highlights two points of disparity.

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
productivity and morale. A pattern of imposing, like this, needs to be
balanced by an accompanying pattern of being perceived to help achieve
timely and productive results.

The other point of disparity is that this is a community that supposedly
has its ultimate authority in the community, not in its "leaders".
Leaders in this community are supposed to be facilitators at pursuing
community rough consensus, rather than folks who "impose" requirements.

However the IETF construct of community rough consensus is explicitly
designed to ensure that no one person (or tiny minority) holds a veto.

And if it sounds like my last sentence is the same as your last
sentence, yes, that is interesting. The difference in views is who has
vetoes and who is accountable.

(And if anyone wants to suggest that nomcom is our way of achieving
accountability, please don't, and for quite a few different reasons.)

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 07 Jul 2003 07:11:40 +0200

--On søndag, juli 06, 2003 08:59:55 +0200 Dave Crocker <[email-masked]> 
wrote:

> HTA> vision of what they wanted to achieve", and have "requirements to
> satisfy HTA> additional constraints", the people imposing additional
> constraints are HTA> people too, and part of the community. What's more,
> in the cases where HTA> those "imposing" people are chosen as leaders of
> the community, they HTA> believe that they represent other members of the
> community - and may even HTA> be right.
>

[I'm not convinced that this point achieves anything but pointless debate 
about who is doing "real" work.... I won't pursue at this time]
> community rough consensus, rather than folks who "impose" requirements.

We agree.

When the leaders are wrong, and impose additional requirements that are 
*not* the community's, the leaders need reeducation wrt what the 
requirements that the community wants *really* are.

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 7 Jul 2003 17:03:43 +0200

Harald,

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

---

From: [email-masked]
Date: Mon, 7 Jul 2003 10:35:53 -0700

Dave, Harald,

In the interests of more light, less heat, for this particular list,
may I suggest that we continue discussion of the IMPP
situation either on the IETF main list or in person?  The particulars
of the situation may require public discussion, but I think the main problem
for this list has already been raised:

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

I'll send a follow-up message to the individuals on the XMPP
specifics; if they indicate there is broad interest or others indicate
broad interest, we'll explore an appropriate public forum to discuss it.

As a _very_ brief note on the subject, I last week asked the Chairs
of XMMP to hold the XMPP core documents in their queue or understand
that I will hold them in my queue prior to issuing an IETF last call.  This
is because the current XMPP charter imposes a dependency on IMPP
and there has a been a challenge by Dave and Marshall on the appropriateness
of the work project and output of IMPP.  Though the IMPP-related mechanisms
have been put into a separate document, I do not believe that the 
IETF last call
can adequately assess the set of documents if the scope is not known, that is,
we're not sure whether they are meant to be part of a mesh of cooperating
IM systems or meant to stand alone (the question of how to judge 
"completeness" in
2026 terms being critical).  Were we not about to have a face-to-face meeting,
the IESG would have considered the IMPP documents on this Thursday's
conference call, but I have held them off so we could gather community input
in Vienna.  They are on the IESG's tentative agenda for its Sunday meeting, and
I know of at least one person planning to speak to the subject at the 
IESG open mic.

Again, I believe follow-ups to this belong elsewhere; if you are interested in
following up _prior_ to Vienna, please let me know by email if you are not
on the cc list now.
			thanks,
				Ted Hardie
				(Area Advisor for XMPP & IMPP)

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Jul 2003 22:07:48 +0200

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:

and with respect to the current example of XMPP:

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/

---

From: [email-masked]
Date: Thu, 10 Jul 2003 11:09:39 -0700

>    fulfilled its charter and has a ready constituency awaiting

Charters do create dependencies, though, both on work that is completed
(as Lemonade on Conneg) and work that is ongoing (as XMPP on IMPP).
Charters are reviewed by the community, and it may well be that some
form of highlighting that there will be dependencies would be useful.  Working
groups also create dependencies (for example, one of the candidate solutions
for CRISP might require an extension for LDAP).  Those dependencies are
on technical output, not "process dependencies" in the sense of "you appeal
to the IAB after the appeal to the IESG has returned".

There may be a judgement call in whether a particular technical output is
or is not required to construct a particular solution and whether or not
it is required to evaluate that solution.  Making those explicit is very
important, so that there is not a "pocket veto" effect of  WG chair or
AD saying to themselves "I'd like to see how FOO comes out before
sending this into the next bucket, so I'll wait".  Explicit statements about
the dependencies mean that the other interested parties can discuss it
when necessary.  This working group is not the place to have those
discussions, though.

On the other, possibly larger question, on the creation of 
dependencies more generally,
I believe we disagree.  In draft-hardie-12-2-1-00.txt, I have this as 
one of the
heresies:

1.6 Dependencies.

      The work of one group must be able to depend on the work of another.

      An organization with expected output of the IETF must be able to
      have the work of one unit depend on the work of another.  Working
      groups commonly divide their work into multiple related documents,
      rather than trying to create a single, monolithic specification.
      The IETF as a larger community needs to be able to do the same
      thing, by allowing specific groups' work to depend on that being
      done at other layers or in other areas.  One advantage the IETF
      has in open review and input is that when one group's lack of
      conclusive output is gating other work, those waiting can add
      their energy to the working group they depend on.

In other words, I see handling of dependencies as something which
presents challenges, but it is not in and of itself a problem in my view.

My opinion,
				Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jul 2003 15:01:25 +0200

hardie,

hqc> Charters do create dependencies,

that warrants ensuring proper coordination between the dependent parts,
not the entire body of work.

hqc> On the other, possibly larger question, on the creation of
hqc> dependencies more generally,
hqc> I believe we disagree.

we do.

i'm contemplating a response to your I-D.

d/