Explosive bolts [Re: Options for IETF administrative restructuring]

Brian E Carpenter <brc@zurich.ibm.com> Tue, 07 September 2004 06:16 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 CAA20544; Tue, 7 Sep 2004 02:16:50 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4ZL3-0004oz-Ur; Tue, 07 Sep 2004 02:20:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ZFL-0000JN-AL; Tue, 07 Sep 2004 02:14:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ZD6-0007N9-09 for ietf@megatron.ietf.org; Tue, 07 Sep 2004 02:12:09 -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 CAA18317 for <ietf@ietf.org>; Tue, 7 Sep 2004 02:12:06 -0400 (EDT)
Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4ZGQ-0004k4-7G for ietf@ietf.org; Tue, 07 Sep 2004 02:15:37 -0400
Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i876BVnO145356 for <ietf@ietf.org>; Tue, 7 Sep 2004 06:11:31 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i876BUAa219274 for <ietf@ietf.org>; Tue, 7 Sep 2004 08:11:31 +0200
Received: from zurich.ibm.com (sig-9-145-230-227.de.ibm.com [9.145.230.227]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA71598 for <ietf@ietf.org>; Tue, 7 Sep 2004 08:11:29 +0200
Message-ID: <413D5111.9010807@zurich.ibm.com>
Date: Tue, 07 Sep 2004 08:11:29 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ietf@ietf.org
References: <7D5D48D2CAA3D84C813F5B154F43B1550526B0E7@nl0006exch001u.nl.lucent.com> <413C61EF.3080208@zurich.ibm.com> <p06200912bd62c7318705@[216.43.25.67]>
In-Reply-To: <p06200912bd62c7318705@[216.43.25.67]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: 7bit
Subject: Explosive bolts [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: 2857c5c041d6c02d7181d602c22822c8
Content-Transfer-Encoding: 7bit

Here's a version of what the explosive bolts could look like.

Firstly, note that the IETF (*not* the ISOC) signed an MOU
with ICANN on March 1st 2000. Fred Baker signed it as IETF Chair,
I signed it as IAB Chair, and Mike Roberts signed it as ICANN
President. The IETF lawyer and the ICANN lawyer were both
consulted, and there was no suggestion that the IETF couldn't
sign an MOU. Not being a lawyer myself, I don't want to argue
that point.

Secondly, that MOU contains explosive bolts. So far, we haven't
had to explode them.

>    2. This MOU will remain in effect until either modified or cancelled
>    by mutual consent of the Internet Engineering Task Force and the
>    Internet Corporation for Assigned Names and Numbers, or cancelled by
>    either party with at least six (6) months notice.

If you're wondering what the IETF is, the MOU also defines it
for you:

>    IETF - the Internet Engineering Task Force, the unincorporated
>    association operating under such name that creates Internet Standards
>    and related documents.

These things are not hard. (See RFC 2860 for the full text.)

    Brian


Pete Resnick wrote:
> 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