Subject: Transition status (was Re: ISO 3166 mandatory?)

From: "Bill Fenner" <[email-masked]>
Date: Thu, 21 Feb 2008 23:49:42 -0800

On 2/20/08, John C Klensin <[email-masked]> 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")

  During a transition like this, there are hundreds of things to
manage.  Several of the I-D submission problems were due to the code
supplied by NSS being less portable than most applications; one
problem that I'm aware of was due to a bug in idnits, which would have
been triggered by either the old installation or the new one.

  When writing a tool to accept meeting registrations, let's say you
are a random web app developer and you want to give the user an
opportunity to pick their country from a drop-down list.  What set of
choices are you going to give them?

  Over the last several years, I've been fairly closely involved in
the IETF's IT infrastructure; I've been quite impressed with how well
the transition is going.  Problems are being acknowledged and fixed
quickly.  The AMS staff is very knowledgeable, but the system they
were given was basically undocumented and requires a fair amount of
TLC to keep running day-to-day.  One input to setting expectations for
how this transition turns out should be the quality of the input.

  At this point, instead of worrying about the fact that there have
been hiccoughs during the transition, I'd congratulate AMS for a job
well done.  The web site, in my experience, is significantly more
responsive when browsing the mailing list archives.  While there have
been hiccoughs in the tools, they worked (and continue to work) to
resolve them.

  Bill
_______________________________________________
IETF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Feb 2008 10:05:25 +0000

> response to me.  (Unless the expected answer is "A lot")

Bill's right here IMO. Seems like the sky hasn't fallen, at least
when viewed from here in any case:-)

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Feb 2008 09:09:17 -0800

> 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/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Michael Thomas <[email-masked]>
Date: Fri, 22 Feb 2008 09:15:01 -0800

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

---

From: Dan York <[email-masked]>
Date: Fri, 22 Feb 2008 15:17:55 -0500

I'll agree, too.  We had some challenges getting the RUCUS mailing  
list up and running and then getting the web archives of the list up  
and running but the support folks were great to work with and got  
things sorted out rapidly.

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: John C Klensin <[email-masked]>
Date: Fri, 22 Feb 2008 17:05:52 -0500

--On Friday, 22 February, 2008 15:17 -0500 Dan York
<[email-masked]> wrote:

> I'll agree, too.  We had some challenges getting the RUCUS
> mailing list up and running and then getting the web archives
> of the list up and running but the support folks were great to
> work with and got things sorted out rapidly.

Folks, what I said was "How much more of this will it take
before you conclude that we have a problem?".  That is a
question, not an assertion that things are hopelessly snafued
(or anything equivalent to that).   I even accept Bill's
proposed answer of "A lot".  Like several others, I've been very
favorably impressed with how quickly AMS has gotten on top of
problems and gotten them resolved once they are identified.  

I am concerned that insufficient resources were allocated to
manage and test for what Bill describes as "hundreds of things to
manage".  Some of that is due to an accident of bad timing that
was presumably under no one's control: a cutover of the
secretariat and web sites after, as Russ pointed out,
registrations for IETF71 had already started.  But I do believe
that, if we ever recompete secretariat services again, the IAOC
at the time should be sure they understand the risks and be sure
that adequate investments are made to, at least, avoid repeating
the types of problems that have been uncovered this time.  That
doesn't necessarily imply that we (or AMS) should be doing
anything different now --again, I've been very impressed by the
diligence with with problems have been addressed and the speed
of recovery from them.  It does imply that we should not be
saying "well, these things happen".  In particular, it implies
that the IAOC needs to be sure that there is institutional
memory about things we are learning from this transition (and
even from the CRNI->Neustar one) so that we are better prepared
for "next time".

That is all, really.

    john

---

From: "Tom.Petch" <[email-masked]>
Date: Mon, 25 Feb 2008 14:33:05 +0100

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Dan York" <[email-masked]>; "Michael Thomas" <[email-masked]>
Cc: "Bill Fenner" <[email-masked]>; "IETF discussion list" <[email-masked]>
Sent: Friday, February 22, 2008 11:05 PM
Subject: Re: Transition status (was Re: ISO 3166 mandatory?)

> even from the CRNI->Neustar one) so that we are better prepared

I think that there have been rather more problems in areas that are less in the
public view, supporting the more private parts of the operation.

But, I see the IAOC as culpable, at least in part, in that there seems to be no,
or at least no adequate, specification of just what the system is.  John's point
about institutional memory is a good one, but to be effective, it has to be
coupled with change control, so that all the changes that have taken place since
the previous transition - and they seem to me to be numerous - are known and can
be passed on to the incoming operators as and when there is a next transition.

My sense is of AMS doing a grand job, but finding out after the event that there
are a number - perhaps lots - of functions that they were not told about, that
run by virtue of scripts tucked away in some dark corner that depend on a
non-standard, locally-modified platform.

Tom Petch

---

From: Dave Crocker <[email-masked]>
Date: Mon, 25 Feb 2008 10:32:23 -0800

> public view, supporting the more private parts of the operation.

This community has been moving relentlessly towards a complete loss of any sense 
of propriety.

So I guess it was inevitable that we would have to suffer through references to 
the IETF's private parts.

I cringe at the possible application of that discussion framework to the details 
of IETF anatomy and performance. The latter, in particular, engenders much anxiety.

d/

-- 

   Dave Crocker