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@xxxxxxx> 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@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf