--On Wednesday, 15 September, 2004 12:04 -0700 Carl Malamud
<carl@xxxxxxxxx> wrote:
> John -
>
> Let me try again. I wasn't trying for debating points.
>
> It seems to me that you said that my report covered a lot
> of ground that doesn't need to be covered. And, that the
> overall focus of the administrative restructuring is
> misconceived, trying to solve a set of problems that don't
> necessarily exist and perhaps trying to solve those
> problems in a non-optimal way. In other words, the
> exercise is misguided. Not trying to put words in your
> mouth.
No, actually, I think much, or most, of what you covered needed
covering. To the extent to which I would debate the importance
of some of those points, it is only in retrospect, which made
your raising them useful. I remember that I participated in
writing 3716 and, at least at a 10K foot level, I agreed with
everything in it at the time. I also think the extrapolations
you have made from 3716 are extremely helpful, and would be
extremely helpful even if all they accomplished was to cause us
to take a fresh, and more skeptical, look at some of the
statements in 3716.
However, when it comes to recommendations of actions, I would
like to see a tight coupling of "critical path problem" and
"solution". I see the "let's leave the current 'clerk' portion
of the secretariat in place while dealing with issues that are
more tractable but lots less important" suggestion as both a
problem in itself and a symptom of, to rephrase your words
above, a badly suboptimal approach. Based on discussions
starting before the San Diego meeting and trying to understand
the Secretariat breakdown, I would also quibble with your
description and boundaries of that role, but don't consider that
critical-path.
I think the need for that coupling is where your report breaks
down, perhaps because it dived in too much detail and perhaps
only because of its somewhat intimidating length. The latter
induces some people to want to capture sound bites and respond
to them, or to respond to what they think is the substance of
comments on the list, without actually studying and responding
to the report. That frightens me and should frighten us all--
probably you especially.
I also believe that, while the creation of categories into which
to group possible strategies can be extremely helpful, it can
also be damaging. When those categories have fuzzy boundaries
or can be identified with phrases that cause emotional
reactions, they can be used to dismiss useful possibilities by
means of those labels or "guilt by association" with other
possible members of the category. I think the report, and
interpretations of it, have fallen seriously into that trap of
poor categorization and sound-bite labeling while merely
intending to provide a useful intellectual aid.
> I then jumpted on the one action that it seemed you might
> endorse (which is hire an administrative director).
> Again, the point you're making is, imho, an important one,
> and I'm trying to translate that into terms that I
> can understand, which is what specific actions might be
> taken.
I understand and appreciate that. But, as I've tried to say in
other notes, I think hiring an administrative director without
an appropriate framework (job description, reporting structure,
etc.) would be the worst sort of "getting the cart before the
horse". I also believe that making any major (e.g.,
substantially irreversible) action to "reorganize the IETF"
without clear community consensus behind those actions or a
_really_ clear delegation of authority would be an extremely
dangerous step, especially given what I perceive as the "you bet
the IETF" character of the stakes involved.
In addition, if there is any hint of using some of the language
in 3716 to justify a "we need to ask for input, but don't need
to pay attention to it because the community has empowered us to
decide" position, then I think the IETF has problems serious
enough to push even the secretariat problems behind them on the
critical path. Fear of that interpretation, although I'm sure
he didn't intend it in his note, is why I decided it was
important to pick Harald's statement about "what is obvious"
apart. We just can't go there and survive.
So, at this moment, the actions I would support/endorse would be:
* Some really serious discussion about critical-path
problems. Have you identified them correctly and
clearly in the report and, if not, can we fix that?
* Some really serious discussion about linkages between
potential solutions and those critical-path problems.
Can one differentiate among your scenarios (or any
better differentiated set of scenarios) on the basis of
their impact on the critical-path problems? If not,
what good do the scenarios do us and are there other
scenarios that would permit better differentiation?
* Some analysis of what problems really need solving
based on past experience or reasonable projections. Is
your report (or thinking elsewhere) too heavily
influenced by fantasies about unlikely
problems? And, if it is, or those fantasies are not as
paranoid as they might appear, can they really be used
to differentiate among the scenarios you have outlined
(or any better differentiated set of scenarios).
A few people in the community have seen some notes on what I
would actually propose if I were proposing something right now.
The details are irrelevant, since I've changed my mind several
times in the last half-year. But one or two of the responses
have been, essentially, "that is just a special case of scenario
X, and I've decided I don't like scenario X, so I don't need to
read or understand it any further". I see that as a very
dangerous trend and response, and I want to see if we can all
get our thinking out of those boxes and focused, once again, on
underlying critical path problems and what might solve them.
john
p.s. I'm about to go offline until at least late tomorrow night
and possibly longer, so the lack of further responses on this
thread should not be construed as lack of interest.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf