Upcoming: further thoughts on where from here

Leslie Daigle <leslie@thinkingcat.com> Mon, 20 September 2004 13:45 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 JAA02748; Mon, 20 Sep 2004 09:45:10 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9OZr-0006Hi-0w; Mon, 20 Sep 2004 09:51:35 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9OGG-0006Y7-JM; Mon, 20 Sep 2004 09:31:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9OBe-0005sA-Ln for ietf@megatron.ietf.org; Mon, 20 Sep 2004 09:26:34 -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 JAA01488 for <ietf@ietf.org>; Mon, 20 Sep 2004 09:26:33 -0400 (EDT)
Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9OHo-0005wF-RF for ietf@ietf.org; Mon, 20 Sep 2004 09:32:57 -0400
Received: from [192.168.0.235] ([::ffff:69.170.18.186]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zak.ecotroph.net with esmtp; Mon, 20 Sep 2004 09:26:30 -0400 id 001B7A93.414EDA87.00004319
Message-ID: <414EDAA2.9080205@thinkingcat.com>
Date: Mon, 20 Sep 2004 09:26:58 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand <harald@alvestrand.no>
Subject: Upcoming: further thoughts on where from here
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: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit

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.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------

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