My $.02 -- the new list software being used was using a new version
of Mailman that was stripping DKIM signatures out (which will be
fixed in later versions of Mailman). I contacted the support folks with
a config patch to stop doing that and it was implemented a day later.
I'd say that's pretty damn impressive.
Mike
Dave Crocker wrote:
Bill Fenner wrote:
On 2/20/08, John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
How much more of this will it take before you conclude that we
have a problem?
John,
Forgive me for saying so, but this sounds like a very extreme
response to me. (Unless the expected answer is "A lot")
Since a) I'm a ready critic of anything IETF, and b) since John and I have
tended to agree about IETF operational problems, here's my own view on the
current status of the transition:
Seems to be going pretty well and maybe even excellent.
(My grammar engine tried to write 'excellently' but failed.)
We flogged the issue of the strategic approach to changing IETF operations,
back
when it was moved from CNRI. While I thought, and think, that the strategic
issues were handled badly by the IETF -- no matter what criticisms of CNRI
one
might subscribe to -- that ship has long sailed, so current -- hmmm. pun.
current. get it? -- concerns ought to focus on current operations.
I was taught a long time ago to use a different model for operations quality
assessment than for engineering quality assessment. The difference is due to
the
jobs having different types and degree of control over output, as well as
tending to have differences in rewards. Engineers are usually praised with
praise. Operations (and especially administration) is usually "praised" by a
low complaint rate. It is easy to appreciate good engineering. All too often,
folks fail to communicate appreciation of good operations, but I think the
IETF
community has been better than average in expressing appreciation of IETF
operations staff.
The cost of making a transition like this be nearly flawless would be very
high
and the sequence would be very slow, since it would include massive amounts
of
pre-testing and careful, iterative consultation with IETF management and/or
the
IETF community. The IETF doesn't run on that kind of budget or schedule, so
my
own criteria for a transition like this are: 1) is a problem due to
someone's
outright thoughtlessness or silliness, or 2) is the recovery from a
transition
problem handled badly -- for any reasonable definition of badly.
I would not expect inherited tools to have been documented well or written
for
optimal portability. So I'd expect the tools to present some challenges.
Equally, I'd expect new staff to demonstrate a learning curve, and that means
rough edges. Given that this is the IETF's second change in operations
administration in a very short time, I'd expect the current transition to be
particularly difficult.
The number, type and rate of transition problems hasn't struck me as all that
remarkable. Maybe low; maybe not. Certainly hasn't seemed high. To me, it
is
more important to ask how the problems that have occurred have been handled,
and
the handling has seemed quite good, both in the details and the tone. Fixed
quickly and with whatever adjustments as are needed to minimize damage -- as
opposed to inconvenience -- to those affected in the IETF community.
If there are specific, higher-level changes to the transition or to basic
operations that ought to occur, we probably ought to see them raised
individually.
d/
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf