Re: Upcoming: further thoughts on where from here

Brian E Carpenter <brc@zurich.ibm.com> Tue, 21 September 2004 11:34 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 HAA05832; Tue, 21 Sep 2004 07:34:33 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9j19-0000kB-9X; Tue, 21 Sep 2004 07:41:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9iso-0003Z8-TW; Tue, 21 Sep 2004 07:32:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9igX-0001Rt-U0 for ietf@megatron.ietf.org; Tue, 21 Sep 2004 07:19:50 -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 HAA04957 for <ietf@ietf.org>; Tue, 21 Sep 2004 07:19:49 -0400 (EDT)
Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9imt-0000UZ-M7 for ietf@ietf.org; Tue, 21 Sep 2004 07:26:24 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8LBJGfQ055788; Tue, 21 Sep 2004 11:19:16 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 i8LBJFYi107562; Tue, 21 Sep 2004 13:19:16 +0200
Received: from zurich.ibm.com (sig-9-146-220-225.de.ibm.com [9.146.220.225]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA83782; Tue, 21 Sep 2004 13:19:15 +0200
Message-ID: <41500E33.5000808@zurich.ibm.com>
Date: Tue, 21 Sep 2004 13:19:15 +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: Harald Tveit Alvestrand <harald@alvestrand.no>
References: <414EDAA2.9080205@thinkingcat.com> <414FEFFE.7090404@zurich.ibm.com> <85DDA364DCE0FE2485763318@B50854F0A9192E8EC6CDA126>
In-Reply-To: <85DDA364DCE0FE2485763318@B50854F0A9192E8EC6CDA126>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: Leslie Daigle <leslie@thinkingcat.com>, ietf@ietf.org
Subject: Re: Upcoming: further thoughts on where from here
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: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit

Harald Tveit Alvestrand wrote:

> Brian,
> 
> I've seen some argument that Scenario C, being more well-defined, is 
> actually less complex than Scenario O.

I would really dispute that. There are layers of complexity in either
case, and I think the scenario O analysis, because it's based on a
real, existing organisation rather than a hypothetical one, simply
contains more detail.

> 
> Also, I was surprised to find that of the two timelines in the writeups, 
> the one for Scenario C was the shorter one. (That may reflect the 
> writers' degree of optimism, however!)

Yes, it's unrealistic in my view. Setting up such an entity is
not straightforward. The timeline in O seems attainable.

> 
> So the outcome is not settled in my mind yet.
> 
> I'd like your comments on why you find Scenario O simpler, 

As noted above, the text digs into more detail than C. For example,
C needs a lot more lawyering than O since it creates a completely new
legal (and tax and insurance) structure. All the details described
in O would have to be worked as internal procedures in C. I really see
C as pure incremental work on top of O.

> ...and VERY much 
> like your comments on where the details of Scenario O need "hacking", if 
> that's the conclusion of the community.

I prefer to wait, to hack on whichever one we choose.

    Brian

>                       Harald
> 
> 
> 
> --On 21. september 2004 11:10 +0200 Brian E Carpenter 
> <brc@zurich.ibm.com> wrote:
> 
>> Thanks, to you and the various authors, for this effort
>> and for reducing the choice to a binary one.
>>
>> To me, this clarifies that it's a one-horse race. I just can't
>> see any argument for the extra complexity, overhead cost, and
>> risk of Scenario C.
>>
>> Obviously we would need to hack at the details of Scenario O,
>> but for me there is no doubt that it's the way to go.
>>
>> (My only regret is that Scenario O text doesn't include a short
>> risk analysis, like Sceanrio C.)
> 
> 
> 
> 
> 

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