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

Harald Tveit Alvestrand <> Mon, 06 September 2004 19:57 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA28521; Mon, 6 Sep 2004 15:57:43 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C4Pfq-0003xX-6X; Mon, 06 Sep 2004 16:01:10 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C4PaE-0005GD-Me; Mon, 06 Sep 2004 15:55:22 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C4PWd-0003Xt-TV for; Mon, 06 Sep 2004 15:51:40 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA28246 for <>; Mon, 6 Sep 2004 15:51:37 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C4PZv-0003kp-6R for; Mon, 06 Sep 2004 15:55:04 -0400
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id D9B9F61AD4; Mon, 6 Sep 2004 21:51:06 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 16966-03; Mon, 6 Sep 2004 21:51:05 +0200 (CEST)
Received: from (localhost.localdomain []) by (Postfix) with ESMTP id 6590961B92; Mon, 6 Sep 2004 21:51:04 +0200 (CEST)
Date: Mon, 06 Sep 2004 19:57:14 +0200
From: Harald Tveit Alvestrand <>
To: John C Klensin <>,
Message-ID: <D861C55CC192D6F9BC2304DD@B50854F0A9192E8EC6CDA126>
In-Reply-To: <>
References: <129F9C12EAF23C28123178C5@B50854F0A9192E8EC6CDA126> <>
X-Mailer: Mulberry/3.1.5 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Subject: Re: On the difference between scenarios A and B in Carl's report
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit

Thanks, John!

--On 6. september 2004 12:08 -0400 John C Klensin <> 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 

  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).


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".

Ietf mailing list