Re: Options for IETF administrative restructuring

Brian E Carpenter <brc@zurich.ibm.com> Mon, 06 September 2004 13:27 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 JAA03649; Mon, 6 Sep 2004 09:27:39 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4JaI-0006oO-F7; Mon, 06 Sep 2004 09:31:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4JRz-0006iL-Fh; Mon, 06 Sep 2004 09:22:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4JHp-0005WD-JV for ietf@megatron.ietf.org; Mon, 06 Sep 2004 09:11:57 -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 JAA02948 for <ietf@ietf.org>; Mon, 6 Sep 2004 09:11:56 -0400 (EDT)
Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4JKy-0006b4-VX for ietf@ietf.org; Mon, 06 Sep 2004 09:15:18 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i86DBFFW158932; Mon, 6 Sep 2004 13:11:15 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i86DBEF8112846; Mon, 6 Sep 2004 15:11:14 +0200
Received: from zurich.ibm.com (sig-9-145-253-13.de.ibm.com [9.145.253.13]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA37140; Mon, 6 Sep 2004 15:11:11 +0200
Message-ID: <413C61EF.3080208@zurich.ibm.com>
Date: Mon, 06 Sep 2004 15:11:11 +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: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
References: <7D5D48D2CAA3D84C813F5B154F43B1550526B0E7@nl0006exch001u.nl.lucent.com>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550526B0E7@nl0006exch001u.nl.lucent.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit
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: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit

Wijnen, Bert (Bert) wrote:
> Aaron,
> 
> I hope you had noticed that I stated that IF we were to choose
> between A and B, that my preference would be for B. And indeed, 
> the below argument for C would then be (one of) my reason(s) for
> choosing B over A. 
> 
> I am not sure that C creates really so much more "distance" as what we 
> would create with B. Some of the extra safeguards that I see we would
> want with B would also create some "distance".
> 
> 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.

    Brian

> 
> Thanks, Bert
> 
> 
> 
>>-----Original Message-----
>>From: Aaron Falk [mailto:falk@ISI.EDU]
>>Sent: Monday, September 06, 2004 02:53
>>To: Wijnen, Bert (Bert)
>>Cc: Scott Bradner; ietf@ietf.org
>>Subject: Re: Options for IETF administrative restructuring
>>
>>
>>
>>On Sep 3, 2004, at 3:06 PM, Wijnen, Bert (Bert) wrote:
>>
>>
>>>If we were to go for option C, then in my personal view, it would have the
>>>serious benefit that we are ALWAYS (from day 1) responsible to make sure
>>>things work well. And we need to re-negotiate every so often if we want
>>>to keep the relationships that we have or if we want to change them.
>>>So in my view we would run far less risk to ever get in a similar situation
>>>as where we are today. Yep... initially it will cost us some more money and
>>>effort I suspect. But I think it is worth the price.
>>
>>Bert-
>>
>>It seems to me that this is an argument for option B as well s C.  My 
>>take from the history you laid out is that what was missing was a 
>>clearly articulated set of relationships which defined roles and 
>>responsibilities (and possibly instructions for disentangling if things 
>>went bad.  AFAICT, this could just as easily be put into option B 
>>without creating an (imo undesirable) increased distance between IETF 
>>and ISOC.
>>
>>--aaron
>>
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf