Re: Upcoming: further thoughts on where from here

Brian E Carpenter <> Tue, 21 September 2004 09:23 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id FAA26268; Tue, 21 Sep 2004 05:23:04 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9gxv-0006m5-O1; Tue, 21 Sep 2004 05:29:40 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C9gkX-00031e-Oy; Tue, 21 Sep 2004 05:15:49 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C9gfn-0001n3-Mi for; Tue, 21 Sep 2004 05:10:55 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id FAA25428 for <>; Tue, 21 Sep 2004 05:10:53 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9gm8-0006WJ-99 for; Tue, 21 Sep 2004 05:17:28 -0400
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id i8L9AMFW108448; Tue, 21 Sep 2004 09:10:22 GMT
Received: from ( []) by (8.12.10/NCO/VER6.6) with ESMTP id i8L9AMYi110312; Tue, 21 Sep 2004 11:10:22 +0200
Received: from ( []) by (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA41712; Tue, 21 Sep 2004 11:10:21 +0200
Message-ID: <>
Date: Tue, 21 Sep 2004 11:10:22 +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: Leslie Daigle <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand <>,
Subject: Re: Upcoming: further thoughts on where from here
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: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit

Thanks, to you and the various authors, for this effort
and for reducing the choice to a binary one.

To me, this clarifies that it's a one-horse race. I just can't
see any argument for the extra complexity, overhead cost, and
risk of Scenario C.

Obviously we would need to hack at the details of Scenario O,
but for me there is no doubt that it's the way to go.

(My only regret is that Scenario O text doesn't include a short
risk analysis, like Sceanrio C.)


Leslie Daigle wrote:
> Folks,
> 10 days ago, some members of the IAB and IESG started to review
> the IETF discussion on the adminrest subject, attempting to
> determine what recommendations to draw, or how to elicit more
> discussion to lead to being able to provide some recommendations
> for moving forward.  It seemed like the 2 paths that were seriously
> under consideration by the community were:
>     . establishing a separate corporate entity for the
>       administrative function, with continued strong relations with
>       and funding from ISOC  (this is basically Scenario C from Carl's
>       document, with some adjustments).
>     . carrying the administrative function out within ISOC
>       itself, as an activity that was formalized by IETF
>       process and largely overseen by IETF-accountable
>       appointees. This has aspects of Scenarios A and B
>       from Carl's document, but differs in that it doesn't
>       make any suggestion of change to the ISOC structure,
>       while it attempts to define and encapsulate the IETF
>       administrative activity.  This is referred to as
>       Scenario O, below.
> It seemed that the best way to stimulate further discussion
> on the IETF mailing list about these paths was to provide a more
> fleshed out view of how they each might be accomplished.
> Accordingly, some people volunteered to write down some text
> for each, drawing on and extending Carl's documents.  The
> outcome of that writing exercise will be circulated here
> later today -- i.e., a note describing a possible implementation
> of Scenario C in more detail, and a separate note describing
> the derived scenario (dubbed "Scenario O").
> One thing that is important to note about these notes
> is that there is a lot of commonality in their structure,
> and a number of places where the text could have been
> copied from one to the other.  For example, both have
> some form of oversight board or committee.  The details as
> written, however, *do* differ between the notes.  This
> is because the contexts are slightly different for the
> 2 scenarios, and because the differences amount to details
> we can debate and fix if we pick one of these to move
> forward with.  I.e., "who is a voting member of the oversight
> group" should not be a deciding factor in whether you
> think the revised Scenario C is better than Scenario O, or
> vice versa.
> The IAB and IESG have not discussed these extensively, but have
> helped to try and get better and clarified documentation of each
> of those Scenarios.  The IESG and IAB are now reviewing them
> in detail. We are also following your discussions/comments
> very carefully, and based on that they will evaluate to try
> and come to a recommendation.  So we are eagerly awaiting your
> thoughts and inputs on whether either of these seems to be
> a viable path or what further work needs to be done.
> Leslie.

Ietf mailing list