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
- On the difference between scenarios A and B in Ca… Harald Tveit Alvestrand
- Re: On the difference between scenarios A and B i… Brian E Carpenter
- Re: On the difference between scenarios A and B i… Margaret Wasserman
- Re: On the difference between scenarios A and B i… John C Klensin
- Re: On the difference between scenarios A and B i… Harald Tveit Alvestrand
- Re: On the difference between scenarios A and B i… Carl Malamud
- Re: On the difference between scenarios A and B i… Paul Hoffman / VPNC
- Re: On the difference between scenarios A and B i… John C Klensin
- RE: On the difference between scenarios A and B i… Thomas Gal
- Re: On the difference between scenarios A and B i… Leslie Daigle
- Re: On the difference between scenarios A and B i… Geoff Huston
- Re: On the difference between scenarios A and B i… Paul Vixie
- Re: On the difference between scenarios A and B i… Margaret Wasserman
- Re: On the difference between scenarios A and B i… scott bradner
- Re: On the difference between scenarios A and B i… Harald Tveit Alvestrand
- Re: On the difference between scenarios A and B i… Fred Baker
- Re: On the difference between scenarios A and B i… Erik Huizer