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

Brian E Carpenter <> Mon, 06 September 2004 09:32 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id FAA17203; Mon, 6 Sep 2004 05:32:05 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C4FuH-0002oW-Q8; Mon, 06 Sep 2004 05:35:27 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C4FkQ-0007q0-Gg; Mon, 06 Sep 2004 05:25:14 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C4Fh2-0007Gn-GF for; Mon, 06 Sep 2004 05:21:44 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id FAA16582 for <>; Mon, 6 Sep 2004 05:21:41 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C4Fjq-0002dy-Ep for; Mon, 06 Sep 2004 05:25:03 -0400
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id i869JrLi088808; Mon, 6 Sep 2004 09:19:53 GMT
Received: from ( []) by (8.12.10/NCO/VER6.6) with ESMTP id i869JqF8110510; Mon, 6 Sep 2004 11:19:53 +0200
Received: from ( []) by (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA69096; Mon, 6 Sep 2004 11:19:51 +0200
Message-ID: <>
Date: Mon, 06 Sep 2004 11:19:51 +0200
From: Brian E Carpenter <>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Harald Tveit Alvestrand <>
References: <129F9C12EAF23C28123178C5@B50854F0A9192E8EC6CDA126>
In-Reply-To: <129F9C12EAF23C28123178C5@B50854F0A9192E8EC6CDA126>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
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: 32b73d73e8047ed17386f9799119ce43
Content-Transfer-Encoding: 7bit

Just to clarify my opinion: I think that B is the desirable end
state, for the reasons Harald gives, but that A with a solemn
commitment to migrate to B is the best way to get started

Incidentally, it occurs to me that starting with A and migrating
to B doesn't exclude a further migration to C later.


Harald Tveit Alvestrand wrote:
> 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 
> 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 
> <>)
> (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 mailing list