John, and others,
First, let me plead with all of you who would prefer to ignore
this --and I certainly understand the feeling-- do technical
work, and let others decide to _not_ do that. If implementation
of these changes begins, and then fails, it is, IMO, unlikely
that we will have a sufficiently functional IETF from which we
can rebuild. The stakes are that high. And, for that reason, I
get really frightened when I see what look like high-risk social
experiments being proposed moving forward.
Let me see if I can try a 20,000 foot summary of the underlying
issues to see if those who are really on the "inside" of this
can disagree with me or further explain the issue. I think
those of us who think we understand the issues and that they are
important have an obligation to try to explain them to those who
care but consider themselves uneducated or the issues
impenetrable at a reasonable investment level. While I applaud
the good intentions behind trying to conduct a poll, I don't
think they do the job (on the other hand, I haven't seen the
poll).
In some respects, this is a different perspective on some of
Tony Hain's recent remarks, although I don't know whether he and
I agree on all issues. These are personal impressions and
opinions although, having been involved in some of the build-up
to these issues while I was still on the IAB, having been on the
AdminRest committee, etc., I'm probably a much closer
approximation to an "insider" than the typical IETF participant.
But I am not, really. There have been hundreds of hours of
discussions between various combinations and subsets of the IAB
and IESG with Carl, with various ISOC-related people, and so on,
to which I'm not privy. Most of those conversations are, I
assume, completely reasonable, but, in San Diego, we were
promised complete openness about what is going on and what
processes are being followed. I don't think that promise is
being kept.
(1) What is the critical issue and what caused it?
Historically, there are two and they are tightly enough
intertwined that reasonable people keep losing sight of the
differences. The first is that, for a number of reasons, the
ability or willingness of the Secretariat to respond to the
needs of the IESG, and the IETF more generally, has seriously
deteriorated over the last several years. Much of the "IETF
leadership" views the Secretariat as having become completely
unresponsive to their requests, reports of problems, or demands.
Whether we have identified them as such of not, most of us have
seen some of the more superficial symptoms of the problems,
e.g., the secretariat cannot manage to keep IETF-Announce a
restricted posting list and the old policy of removing addresses
from the IETF list when they result in posting vacation
messages, etc., back to the list seems long gone. Other
problems are occasionally visible to WG Chairs or document
authors, but are in the IESG's face all the time: fouled-up
notices, lost agenda items, mishandled and delayed documents,
and worse.
The other critical issue is that there are ambiguities about the
IETF - Secretariat relationship, ambiguities as basic as who is
running/ steering whom. Attempts to get those ambiguities
resolved have been completely unsuccessful. For example, there
have been fairly regular efforts to work out a formal MOU
between the IETF and the Secretariat, one that spells out the
relationship, lines of authority, ownership of intellectual
property, and so on. Those efforts started more than six years
ago by some counts and more than eight years ago by mine. I
think it is fair to say that there has been almost zero
progress.
The reasons seem to very fundamental differences in assumptions.
For example, there is a long-standing question of who determines
what is in the best interests of the IETF and the Internet
Community? From the perspective of much of the IETF Leadership,
they have been selected for those positions by the community,
they are, and ought to be, in charge and to be making those
decisions. I hope I'm not misrepresenting this too badly, but
my impression is that, from the CNRI perspective, they were
around before the IETF, they were largely responsible for
putting the IETF together, they don't rotate every few years,
they have more of a long-term view than those who are actively
involved in the standards process, they have far more experience
with fiscal and administrative management than most of the IETF
volunteer leadership, and so it is entirely appropriate that
they should be in charge of many of these support issues.
There is, IMO, a certain amount of truth in each of those
beliefs. But, at the same time, if their decisions or
capabilities, based on those models, are insufficient to support
the IETF properly, and that is pretty clearly the case, then we
have a really serious problem.
Whether it is critical path or not depends on one's perspective,
but these differences in role-perception also lead to another
problem: As far as I can tell, CNRI and Foretec view supplying
in-depth financial information to the IETF leadership as a
professional courtesy rather than an obligation (some
information, including the elements of exactly what goes into
the overhead rate, have, as far as I know, never been disclosed,
despite several requests). And, symmetrically, they have viewed
input from the IETF leadership about budgets and priorities as
advisory, not in any way binding requirements.
(2) Ok, so why is all of this big process, one that involves
everything in sight, necessary?
The IETF Leadership has, quite reasonably, looked at the above
situation and tried to extrapolate it both to other support
arrangements the IETF has and requires and to issues with other
models going forward. The AdminRest report was, to a
considerable extent, an attempt to organize and report on that
extrapolation process. Some of the answers seem pretty obvious:
(i) We shouldn't have money coming in through meeting fees
dedicated exclusively to meeting costs and secretariat support,
with no mechanism for either putting more money into that pool
from other sources or for using some of it for other expenses.
Similar comments could be made about the ISOC-related pool, but
we have more flexibility there. (ii) We should have an
administrative structure that is required to pay attention to
inputs/requests/ problem reports from the volunteer leadership
and to be response to those things.
(3) So, what is the big difference between "O" and "C"?
Various others have tried to summarize their cut on this, let me
try mine.
Many of the stronger advocates of "C" feel that they (and the
community) have been badly burned by the deterioration in the
CNRI/ Foretec relationship, that ISOC might, somehow, similarly
turn bad, and that they therefore want an organization that is
completely under IETF control. There are also various
philosophical and ideological arguments associated with Scenario
C, some of which I've been inclined to dismiss as "social
experiments". To paraphrase Dave Crocker, the number of people
in the IETF who are really trained and experienced in
organizational structures, analysis, and design perhaps exceeds
the number of qualified tax lawyers, but not by much, and the
future/ survival of the IETF is probably not a good place for
them, or the rest of us, to experiment.
The "O" folks feel that ISOC can do the job, the relationships
are already in place, and it is therefore the safer, easier,
faster, and cheaper strategy.
I tend to agree, but mostly because aspects of "C" horrify me.
What almost all of us have learned from either elementary
engineering principles or bad experiences is that, if something
is important and one needs to make changes, it is wise to make
as few changes at one time as possible. By doing so, one
maximizes both the chance of going forward and that of going
back somewhat if things go seriously wrong. Scenario O has most
of the right properties in that regard (the even more
conservative approach is probably not plausible). Scenario C
looks to me like a leap into the dark, based on lots of
assurances and probabilities about what won't go wrong and with
no obvious fallback scenario. Worse, the "what if ISOC goes
bad" hypothesis seems to me like a very strange one, for at
least two reasons:
(i) There are dozens of things that could go wrong with
either of these scenarios. Ending up with a body in
control of the administrative stuff that turns
non-responsive is only one of them. There is almost as
much of a possibility that an IETF-created organization
with hand-picked people, would go bad as might be the
case with an ISOC-housed one. I trust the community
doesn't need reminding that one of the claims during the
"Problem Statement" process was that the IESG itself had
turned unresponsive, despite its very close ties to the
community, selection by a Nomcom process that certainly
should know how to evaluation IESG behavior, and so on.
So we are proposing to build a fairly complex and
probably more expensive structure in order to avoid a
risk that (a) seems low probability given history with
ISOC, (b) is not clearly better with regard to that
particular risk, and (c) doesn't address any of the
other problems that could occur with one or the other of
these scenarios and is actually more risky for some of
them (e.g., others have pointed out the risk of an ISD
who is really part of a one person structure resigning)
(ii) The important issues in front of us on the critical
path are to get the secretariat (and not even
necessarily the meeting planning part of the
secretariat) problem solved and to bring the finances
under some sort of centralized regime. "Restructure the
IETF's administration by creating a brand new shiny
organization that we can all point to and admire" would
not be on the critical path, even if it were a good
idea. So, IMO, even if we were somehow guaranteed that
there would be serious problems with ISOC in a
half-dozen years, the principle of making incremental
changes would strongly suggest that we would be better
off doing so with the high-level secretariat and
financial problems already under control (even if in an
ISOC context) than trying to change the the umbrella
organizational structure, the financial model, and major
aspects of the standards support and meeting
administrative model, all at the same time.
(4) What are the real risks?
Putting on the garb of one of those pessimists who is rarely
disappointed, the survival of the IETF is at stake in this.
Even with the problems with the present secretariat situation,
we are limping along -- successfully even if badly and at high
stress-costs to the IESG and various WGs. But suppose we set up
a new structure with a new IAD, and move all of these
arrangements into it. And then suppose it doesn't function,
either because the IAD can't work with the IESG after all, or
because assumptions about outsourcing Secretariat
standards-support functions as generic activities don't come
together to yield a quick and effective result, or because an
"external incorporated organization" plan turns out to be wildly
more expensive than anticipated, ISOC cannot or will not make up
the difference, and sufficient additional funds cannot be
quickly located. Different people, with different perspectives,
will assign different likelihoods to each of those risks, and
others, but the risks aren't zero. Suppose that, as a result,
we end up with no meetings for six months or a year, no
organized support for the IESG, and lots of us scrambling around
to try to maintain mailing lists and archives on a volunteer
basis. Would the IETF pull through? Maybe. But I'd assume
that many of us would find other ways to get things done, at
least some companies who have been supporting the time and work
of IESG and IAB members, and even Nomcom members, would decline
to make/ continue the investment under these circumstances. It
would not be a happy time.
And that is why we should minimize the risks in every way we can
--consistent only with making significant progress on the
critical path problems -- even if the results are ideologically
or aesthetically unattractive to some participants.
(5) Has there been as much transparency and efforts to inform
and educate the community about this process as it requires, as
the traditions of the IETF dictate, and as the community has
been promised?
While there is a need for confidentiality about some things, I
believe the community is entitled to know what topics have been
singled out for discussion in confidence. More generally, I
think the answers to the above questions are "no", "no", and
"no", partially because I don't believe the community ever
authorized the IAB and IESG to go off on this adventure (that
position differs very significantly from one of Harald's
"obvious" positions which, if read carefully, implies the right
and responsibility of the IETF and IAB Chairs to make a decision
on these issues and implement it with little consultation of the
IAB and IESG and very little consultation with the community.
YMMD, of course.
(6) Whichever scenario is chosen, the administrative entity will
need some sort of steering / management/ or overview body to
manage it. How should that body be chosen?
On this one, I'm pretty clearly in a minority position, at least
on the basis of responses to various of my comments on the
subject. First, it is absolutely clear to me that any such body
better have good mechanisms for getting regular input and
feedback from the standards side of the IETF --and especially
its leadership-- about what is working well and what isn't, what
can be made better, what specific changes appear helpful, etc.
If it becomes non-responsive in that regard, we are in big
trouble. But responsiveness is historically more a matter of
personalities and commitment than it is of structures.
Certainly, it is possible to design a structure that is
guaranteed to be non-responsive. But designing one that is
guaranteed to be responsive is much harder. In particular, the
notion that "we can fire you, therefore you will be responsive"
is much less effective than it first appears, as anyone who has
tried to bring an employee who isn't working out well knows.
But, while responsiveness is very important, I believe it is
also of significant benefit to maintain a very clear separation
of people who handle money and deal with funding sources is to a
standards body that is subject, as all standards bodies are, to
accusations of capture (or purchase) by specific industry
interests. I'd like to see as great a separation as we can
design because this is a _known_ problem and risk, not
speculation about, e.g., how ISOC could stop caring about the
IETF. In addition to the importance of clear separation, I
think our first goal for that Board or steering activity must be
that it be effective and, in particular, that it contain very
strong representation from people who actually have the
expertise to manage a large budget and administrative operation.
While the advantages of keeping a small organization which
contracts most tasks out are clear, it is also often the case
that a "many contractor" environment actually takes more
management skill and attention than having things in-house. And
here is where Avri and I disagree about the appropriate role of
the Nomcom...
(7) Should the Nomcom select the members of the Board/ Steering
group, or whatever?
I respect Avri's experience and perspective. At the same time,
I think this is different from the situation she describes. To
paraphrase a recent note, most people can figure out how to
recognize the skills they need in a boss and how to select one.
But selecting the CFO is another matter. Sure the Nomcoms
considers management and administrative skills, especially at
the level needed to oversee and coordinate WGs and do some
general cat-herding. If they didn't, I assume we would be in
really bad trouble. But that level of management skills is very
different from the skills needed to supervise an administrative
organization that handles a very large budget, oversees multiple
contracts with potentially interlocking functions, generates
RFPs and evaluates proposals, and so on. We are better off in
that regard if we give ISOC a leading role in the decision
process, because they clearly have to deal with the same issues
and have the staff and expertise to do so. But I'd like to see
us end up with a Board --especially if we get anywhere near
Scenario C-- that contains a significant number, probably a
majority, of people who really do have enterprise line
management experience with both contracts and budgets.
In addition, it appears to me, from Danny McPherson's recent
notes and other things, that we may be in trouble with the
Nomcom. It is a lot of work over a short period. The number of
volunteers isn't nearly large enough to ensure that the Nomcom
constitutes a representative sample of the eligible community.
Unless it can be demonstrated that adding another body for which
candidates must be chosen, with yet a different set of
qualifications, won't increase the workload enough to have a
negative impact on the number of volunteers, I think that
sticking this on the Nomcom is bad strategy, even if I were
convinced they could do the job.
And I _think_ those are the big issues.
john
--On Friday, 24 September, 2004 07:03 +0300 John Loughney
<john.loughney@xxxxxxxxxxx> wrote:
> I've skimmed the recent documents and have come away feeling
> rather uninterested in the topic. As with most others, I
> asume, I'm more interested in technical work not
> aministrative or reorg work.
>
> What I assumed would happen is that we would hire a consultant
> to review the possible structures for the IETF (we did). Next
> would be for that consultant to make a recommendation, get
> buy-in from the major stakeholders, then institute the change.
>...
> At the end of the day, any structure we create will have its
> unintended consequences that we will need to engineer around.
> However, the current process is akin to slowly peeling a band
> aid off rather than just pulling it off. Reorgs that I have
> been involved in that have been long and drawn out have tended
> to impact morale negatively.
>...
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf