Tony, Thanks for the followup. > You are correct we need a detailed documentation of the > interface before we deal with any corporate entity. As I see > it the differences between your opinion and others has more > to do with your focus on the interface than the > organizational structure others are commenting on. My focus is on knowing what the details of the jobs are that we want done. Referring to the interface(s) is a convenient technique for trying to surface those details. Currently we do not have the details. What we are doing is like buying a building or a vehicle before we really understand what uses they are going to be put to. This leads to thinking that those details are trivial. They aren't. Privately I have been accused of carrying some sort of grudge against ISOC. That reaction is unfortunately typical for these discussions. One cannot ask basic, entirely pro forma questions about needs and competence without being discounted as carrying a grudge. In a very basic way, I think the question of ISOC is irrelevant. It cannot become relevant until a) we have a substantial specification of the work to be done and b) a precise statement of how a candidate (ISOC) will do it. So far, anytime someone asks about either, they get no answer or they get a handwave. If they press further, the answer changes. Really. The lack of substance is astonishing. I am trying to imagine any of us making even the most simple purchase of a service with this little comprehension of what we were buying. > reaction to your concern about ISOCs track record was that > the IETF itself has even less of a track record, and a poor That hardly seems like justification for handing the task to ISOC -- or anyone else who is inexperienced or has done the job badly. In fact I thought the whole idea was to have this change get things done better and more easily. How can we believe that is going to happen? > one at that. Despite the legal difference between the > Administrative office being a separate corporation vs. > incorporating the IETF itself, the backers of both of those > choices appear to assume the IETF will directly deal with the > financial issues because their arguments against outsourcing The key word is 'assume'. The problem is there is a) no substance to the assumptions, and b) each person seems to be making different assumptions about what the substance will turn out to be. Try imagine writing a protocol spec with that little shared understanding of what job it is to do. > all say 'they have a different focus'. As several people have > stated, the IETF participants have a technical skill set and > no demonstrable skills at financial administration. Why then > are people so quick to point out that outside organizations > have a different focus when our internal skill sets don't > match the need? Because it is our organization. Ultimately it is our responsibility to make it work. And, by the way, some of the IETF leadership pretty much explicitly expect the contractor to do all the financial work. Or at least that is what I have heard some of them say. > Yes before we go off and sign agreements we need to know what > the details of those agreements will be. Sorry, no. Before we make strategic choices it is our responsibility. And that means before we even go out for 'bids'. If we only worry about the details after we have chosen the contractor, we will probably choose the wrong contractor and we certainly will not have any negotiating leverage. > Others may add to the list, but taken collectively it should > be clear that scenario C is fundamentally the end of the IETF Whereas I guess I would say that the end of the IETF is working on the the list of scenarios, because that list is based on ignorance of the work to be done. When we know what the work is, we can consider how to get it done. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... www.brandenburg.com _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf