On 9/6/04 at 3:11 PM +0200, Brian E Carpenter wrote:
The benefit of C is (in my opinion) that it does not assume a default (strong) relationship, but that it requires both organisations to actively want to continue/renew the relationship every so many years. And such checkpoints are nice and good points where the relationship can (and in my view will) be evaluated and if any friction has developed then at such checkpoints the friction can (timely and naturally) be corrected.
That is true enough, but is it really enough to justify the overhead costs and work of creating a new legal entity? Certainly the agreements under scenario B (or even A) should include "explosive bolts" in case the IETF becomes unsatisfied, and regular reviews are an execllent idea.
I absolutely agree with Brian (and disagree with Scott) about the need for "explosive bolts" in case the IETF (or ISOC for that matter) becomes unsatisfied under solution A or B. With such a set of explosive bolts, I'd more than likely be happy with solution A or B. The problem I have, and the reason to this point I've been leaning toward C along with Bert, is that nobody has even given me a hint of what those explosive bolts might look like. For example, in the A vs. B discussion that's been going on, there has been quite a bit of talk about an "MoU between ISOC and IETF." But as Margaret points out:
I don't understand what legal entity would hold up the "IETF" end of this MOU. Currently when someone needs to make a contract with the IETF (the RFC Editor, another standards group, a hotel, etc.) that contract is signed by either ISOC or CNRI/Foretec acting on behalf of the IETF. Do you know of some way that the IETF (by which I think you mean the standards development portion) can be an MOU signatory?
Down the road, if the make-up of the ISOC BoT and ISOC by-laws change significantly and they become dissatisfied, what is to stop them from simply saying, "We've decided to exit this MoU and take your support services with us."? Or if the IETF becomes dissatisfied with the relationship, what would there be to allow us to say, "We'd like our support services out of the control of ISOC."? As others have said, there's no sign of either of these things happening, but we do need to plan for the contingencies. If there is no legal entity on the other end of that MoU, I'm afraid we could end up having to repeat this entire process again in what will surely be (should this terrible scenario come to pass) another state great angst. I think it would be irresponsible to leave that legacy to our descendants.
In scenario C, it's easy for me to see what happens if all hell breaks loose: We have a legal administrative entity whose entire raison d'etre is "provide administrative services to the IETF standards body." If the relationship with (or mission of) the ISOC changes, that won't change a bit the relationship between the administrative entity and the IETF standards body. The administrative entity can simply say, "So long, and thanks for all the fish." Or ISOC could say, "Sorry, we don't like the way your spending our money anymore; go find your own money." However unpleasant a time that would be, the IETF would still have an administrative support entity that can continue its administrative support mission without having to go through yet another administrative restructuring.
(Note that even if all hell did break loose, the IETF standards body could even conceivably maintain its current process relationship with ISOC--choosing NomCom chairs, being an appeals body, etc.--at that point if it so desired.)
I understand that C is additional cost for an insurance policy that we may never need to cash in, but at this point it seems worth it. If someone could describe to me what the explosive bolts look like that would get us a similar result with scenarios A & B, I would be much more at ease with those choices.
pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf