On the difference between scenarios A and B in Carl's report
Harald Tveit Alvestrand <harald@alvestrand.no> Mon, 06 September 2004 07:51 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 DAA09669; Mon, 6 Sep 2004 03:51:04 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4EKW-0000mX-6O; Mon, 06 Sep 2004 03:54:24 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4EEN-0003K8-0y; Mon, 06 Sep 2004 03:48:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4EDD-00038T-RL for ietf@megatron.ietf.org; Mon, 06 Sep 2004 03:46:52 -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 DAA09095 for <ietf@ietf.org>; Mon, 6 Sep 2004 03:46:50 -0400 (EDT)
Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4EGP-0000fF-Eh for ietf@ietf.org; Mon, 06 Sep 2004 03:50:09 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAC6761BA7 for <ietf@ietf.org>; Mon, 6 Sep 2004 09:46:19 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03404-06 for <ietf@ietf.org>; Mon, 6 Sep 2004 09:46:17 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3AC061AD4 for <ietf@ietf.org>; Mon, 6 Sep 2004 09:46:16 +0200 (CEST)
Date: Mon, 06 Sep 2004 09:32:02 +0200
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: ietf@ietf.org
Message-ID: <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 alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit
Subject: 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: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
Following up on Leslie's mail of Friday, and a number of posters (Brian, Scott, Margaret) who have said something on the order of "I think I prefer A or B, but I don't understand the difference"..... my particular perspective..... in order to avoid misunderstandings, I'll define a few terms first, as used in this memo: - Bylaws (a bylaw?) is a document that tells how a formally constituted organization expects itself to behave. - An MOU is a document that tells the reader how two organizations are supposed to behave in relation to each other. - An IETF (Procedure) BCP is a document that tells the IETF how the IETF expects the IETF to behave. So it may be something like a bylaw for the IETF. In the "Option A" scenario, we say that we have BCPs defining the function - IETF makes agreements with itself. This is necessary. We also say that it is sufficient. The key phrase from the report: o The responsibilities that the IETF Administrative Director would have with respect to IETF activities would be determined by standard IETF processes (BCPs, RFCs, etc.) These BCPs are the IETF's expectations on IETF behaviour. They cannot constrain the behaviour of ISOC, unless ISOC makes an explict commitment by Board resolution to do so, as it has done for its roles in the standards process, the Nomcom process and IPR issues. ISOC's behaviour continues to be governed by the ISOC bylaws and articles of incorporation (published as RFC 2134 and RFC 2135), as subsequently modified by ISOC. (current ISOC bylaws are at <http://www.isoc.org/isoc/general/trustees/bylaws.shtml>) (note - RFC 2031 describes the ISOC-IETF relationship, as it was understood at the time. This document is not an MoU.) In the "Option B" scenario, we say that this is not sufficient to give the transparency, clarity and stability of relationship that we desire. In addition to what ISOC's bylaws and board resolutions say now, we want commitments of ISOC. This commitment can take several forms, some of which are mentioned as mechanisms in the consultant report: - Declarations in the form of changes to ISOC bylaws to enshrine ISOC's commitment to the IETF support function (Mechanism 1) - Promises from ISOC to the IETF community in the form of an MoU between ISOC and the IETF (Mechanism 5) - Changes to the ISOC governance structure so that it is more likely that any potential conflict will be detected early, and that action will be taken to fix it in a manner that is satisfactory to the IETF (mechanisms 2, 3, 4, 6, 7) I, personally, think that if we want a stable, long term relationship, something more than the "Scenario A" status quo is necessary. I have great trust in the commitment to IETF of Lynn as President and Fred as Chairman of the Board. But ISOC has had 2 Presidents and several Chairmen of the Board while I have been watching. Enshrining the prinicples that Lynn and Fred are supporting in text that will endure beyond their tenure seems appropriate to me. Harald PS: This note is NOT a statement of opinion about the relative merit of scenarios A, B, C and D. It is only about scenarios A and B. _______________________________________________ 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