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

Margaret Wasserman <margaret@thingmagic.com> Wed, 08 September 2004 00:19 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 UAA20687; Tue, 7 Sep 2004 20:19:01 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4qEU-0003Gf-01; Tue, 07 Sep 2004 20:22:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4q9B-0006ED-A0; Tue, 07 Sep 2004 20:17:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4q3n-0004lV-6B for ietf@megatron.ietf.org; Tue, 07 Sep 2004 20:11:39 -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 UAA20278 for <ietf@ietf.org>; Tue, 7 Sep 2004 20:11:37 -0400 (EDT)
Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4q79-00038y-3J for ietf@ietf.org; Tue, 07 Sep 2004 20:15:18 -0400
Received: from [66.228.91.169] (account margaret HELO [192.168.1.103]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 153526; Tue, 07 Sep 2004 20:07:09 -0400
Mime-Version: 1.0
X-Sender: margaret@mail.thingmagic.com
Message-Id: <p0602045abd63f8ae138e@[192.168.1.103]>
In-Reply-To: <413E3186.2070003@thinkingcat.com>
References: <129F9C12EAF23C28123178C5@B50854F0A9192E8EC6CDA126> <98BC694FC738F25CDDD1F057@scan.jck.com> <D861C55CC192D6F9BC2304DD@B50854F0A9192E8EC6CDA126> <86C7112A74A3781897BD5D70@scan.jck.com> <413E3186.2070003@thinkingcat.com>
Date: Tue, 07 Sep 2004 20:09:39 -0400
To: Leslie Daigle <leslie@thinkingcat.com>
From: Margaret Wasserman <margaret@thingmagic.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: ietf@ietf.org
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: 4adaf050708fb13be3316a9eee889caa

>Putting an MoU-like agreement on the table could shift the "center
>of gravity" of the responsibility for the future of the administrative
>activity further from the centre of the ISOC organization.  The
>further out it gets, the less sense it makes to undertake
>(anything like) the other mechanisms in Scenario B that get
>IETF participation right into the ISOC organization.

IMO, a similar shift could be achieved by forming an IETF 
community-selected board to manage this function and housing that 
board within the ISOC corporate umbrella (like the IAB is today).  I 
don't think that housing our administrative functions within ISOC has 
to mean that those functions are directly managed by the ISOC BoTs. 
And, in fact, I would prefer that they are not.

>Now, I (as a generic IETF participant) would want to see a real
>draft of such an MoU before I called it a scenario and
>had an opinion as to whether I thought it could solve the problems
>we're looking at.

Scenario B includes the MOU mechanism as one of the choices for 
defining a relationship between ISOC and the IETF.  The draft says 
that some or all of the mechanisms could be used, so we're still 
talking about Scenario B, aren't we?  Since ISOC would clearly be one 
of the parties to this MOU, I'm not sure how useful it would be for 
the IETF to produce a draft MOU in the absence of ISOC input.

>By the way, it doesn't seem to make a lot of sense to me, personally,
>to talk about an MoU between ISOC and "the IETF", which either
>doesn't exist or is an activity of ISOC.  I wonder if this is
>something that would be better framed as an IETF process document
>  -- requires IETF consensus process to change, and ISOC BoT
>approval to put into effect, per our current rules.

I agree with you that an IETF BCP that is published through the IETF 
document process and formally accepted by the ISOC BoTs would make 
sense as a way to formalize any changes or extensions to  ISOC-IETF 
relationship.  This model has been used to define the ISOC-IETF 
relationship in the past and it seems to be working well, IMO.

Margaret

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