Re: Options for IETF administrative restructuring

Pete Resnick <presnick@qualcomm.com> Tue, 07 September 2004 02:41 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23222; Mon, 6 Sep 2004 22:41:39 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4Vyn-0001LX-PD; Mon, 06 Sep 2004 22:45:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4VsG-0004Sh-Rm; Mon, 06 Sep 2004 22:38:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4VrJ-0004Fp-7P for ietf@megatron.ietf.org; Mon, 06 Sep 2004 22:37:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22906 for <ietf@ietf.org>; Mon, 6 Sep 2004 22:37:22 -0400 (EDT)
Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4Vub-0001GJ-QU for ietf@ietf.org; Mon, 06 Sep 2004 22:40:53 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Mon, 6 Sep 2004 21:36:49 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com (Unverified)
Message-Id: <p06200912bd62c7318705@[216.43.25.67]>
In-Reply-To: <413C61EF.3080208@zurich.ibm.com>
References: <7D5D48D2CAA3D84C813F5B154F43B1550526B0E7@nl0006exch001u.nl.lucent.com> <413C61EF.3080208@zurich.ibm.com>
X-Mailer: Eudora [Macintosh version 6.2a9]
Date: Mon, 06 Sep 2004 21:36:48 -0500
To: Brian E Carpenter <brc@zurich.ibm.com>
From: Pete Resnick <presnick@qualcomm.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: Aaron Falk <falk@isi.edu>, ietf@ietf.org
Subject: Re: Options for IETF administrative restructuring
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024

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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf