----- Original Message ----- From: "John C Klensin" <john-ietf@xxxxxxx> To: "Dan York" <dyork@xxxxxxxxx>; "Michael Thomas" <mat@xxxxxxxxx> Cc: "Bill Fenner" <fenner@xxxxxxxxxx>; "IETF discussion list" <ietf@xxxxxxxx> Sent: Friday, February 22, 2008 11:05 PM Subject: Re: Transition status (was Re: ISO 3166 mandatory?) > > --On Friday, 22 February, 2008 15:17 -0500 Dan York > <dyork@xxxxxxxxx> 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. > 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 > john > > _______________________________________________ > IETF mailing list > IETF@xxxxxxxx > http://www.ietf.org/mailman/listinfo/ietf _______________________________________________ IETF mailing list IETF@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf