Re: On the difference between scenarios A and B in Carl's report

John C Klensin <john-ietf@jck.com> Mon, 06 September 2004 21:02 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 RAA01992; Mon, 6 Sep 2004 17:02:50 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4Qgq-0004uL-RW; Mon, 06 Sep 2004 17:06:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4QXu-0005jP-Hv; Mon, 06 Sep 2004 16:57:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4QTq-0004oY-RD for ietf@megatron.ietf.org; Mon, 06 Sep 2004 16:52: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 QAA01567 for <ietf@ietf.org>; Mon, 6 Sep 2004 16:52:48 -0400 (EDT)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4QX9-0004kK-I2 for ietf@ietf.org; Mon, 06 Sep 2004 16:56:16 -0400
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1C4QTp-0008cx-Po; Mon, 06 Sep 2004 16:52:49 -0400
Date: Mon, 06 Sep 2004 16:52:49 -0400
From: John C Klensin <john-ietf@jck.com>
To: Harald Tveit Alvestrand <harald@alvestrand.no>, ietf@ietf.org
Message-ID: <86C7112A74A3781897BD5D70@scan.jck.com>
In-Reply-To: <D861C55CC192D6F9BC2304DD@B50854F0A9192E8EC6CDA126>
References: <129F9C12EAF23C28123178C5@B50854F0A9192E8EC6CDA126> <98BC694FC738F25CDDD1F057@scan.jck.com> <D861C55CC192D6F9BC2304DD@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Subject: Re: On the difference between scenarios A and B in Carl's report
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: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit


--On Monday, 06 September, 2004 19:57 +0200 Harald Tveit
Alvestrand <harald@alvestrand.no> wrote:

> Thanks, John!
> 
> --On 6. september 2004 12:08 -0400 John C Klensin
> <john-ietf@jck.com> wrote:
> 
>> So I am left close to the question that prompted your
>> response, with little additional information from that
>> response.  I can't parse the difference between "scenario A
>> with MOU and maybe some other things to be developed as
>> needed" and "scenario B with MOU but without pointless or
>> risky tampering with how ISOC is organized" ... that is,
>> unless we take Scenario B as requiring that everything be
>> figured out and chiseled into granite before we do anything.
>> And I suggest (and will suggest in more detail in an upcoming
>> note) that anything that can wait long enough for the
>> granite-chiseling is something that probably doesn't need to
>> be done at all.
> 
> It seems to me that we are rapidly converging on one point of
> total IETF consensus:
> 
>   Putting the IETF administrative function under ISOC requires
> a documented 
>   IETF-ISOC agreement (call it an MoU, a contract or something
> else - it IS
>   a document, it IS an agreement and it DOES have two parties).
> 
> Agreed?

I think so, although I think, given some of the text in the
report and some other conversations, that I would add to "DOES
have two parties", "each of whom is assumed to be acting in good
faith, out of good intentions, and with the best interests of
the other in mind".   I don't know that needs to be explicit,
and I think those conditions are generally met today, but, as I
tried to say in my note, relying on legal agreements to protect
us if there isn't general agreement about behavior strikes me as
a bad idea.   And, incidentally, if there is a problem in that
area, I think we would hit it with Scenario C as well.

> The thing that left me most uncomfortable with Scenario B as
> described was that it presented a smorgasboard of options
> ("here are ten menu choices - take your pick"), where some of
> them (the MoU) were totally obvious, and some had (in my mind)
> severe disadvantages. So we can't say "we go for scenario B"
> and have the discussion be finished, we have to be able to say
> "Options 1, 3, 5 and 7 make sense, the rest does not, and
> besides, here's option 17 that wasn't in the original
> document".

So, to get a stake in the ground, only the MOU "mechanism" makes
obvious sense to me.   The others seem either harmful or
sufficiently muddled in the details of what they might mean that
I think significant clarification would be needed to even
evaluate them properly.   And I think I'd like to see more
discussion about what real problem we are trying to solve before
I'd think that added effort would be worth putting in.

     john


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