ISSUE: Determinants for timeliness missing in section 2.1

[Dave Crocker]

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:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>