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 RAA02533;
 Sun, 26 Sep 2004 17:56:19 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
 by ietf-mx.ietf.org with esmtp (Exim 4.33)
 id 1CBh7m-0000JB-R4; Sun, 26 Sep 2004 18:04:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
 by megatron.ietf.org with esmtp (Exim 4.32)
 id 1CBgxr-0002e1-1s; Sun, 26 Sep 2004 17:53:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
 by megatron.ietf.org with esmtp (Exim 4.32) id 1CBgwA-0002Ts-UE
 for ietf@megatron.ietf.org; Sun, 26 Sep 2004 17:52:07 -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 RAA02360
 for <ietf@ietf.org>; Sun, 26 Sep 2004 17:52:04 -0400 (EDT)
Received: from smtp.nildram.co.uk ([195.112.4.54])
 by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBh3U-0000Dn-LK
 for ietf@ietf.org; Sun, 26 Sep 2004 17:59:51 -0400
Received: from pcgz600re (foxcombe.gotadsl.co.uk [81.6.215.107])
 by smtp.nildram.co.uk (Postfix) with ESMTP
 id 3B40124E181; Sun, 26 Sep 2004 22:51:42 +0100 (BST)
From: "Christian de Larrinaga" <cdel@firsthand.net>
To: "Leslie Daigle" <leslie@thinkingcat.com>, <ietf@ietf.org>
Date: Sun, 26 Sep 2004 22:55:11 +0100
Message-ID: <OLEPILDGDKGAPONGCBEOIEFHCJAA.cdel@firsthand.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <414F3627.6050407@thinkingcat.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Content-Transfer-Encoding: quoted-printable
Cc: Margaret Wasserman <margaret@thingmagic.com>
Subject: RE: Scenario O Re: 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: f60fbf3dbcaca652b6d10036f0630412
Content-Transfer-Encoding: quoted-printable


Scenario O promises a distinctive IETF administrative entity within ISOC'=
s
legal framework.

The problems establishing a directly IETF controlled entity emerge from t=
he
informality and porous boundaries of the IETF. It is perfectly possible t=
o
resolve these but it will take a lot of time and effort and in the
circumstances today where IETF doesn't have a very detailed understanding=
 of
the secretariat it is likely to lead to establishing structures (forms)
before the tasks (functions) are adequately defined. This seems to me to =
be
a complete waste of our time.

Having said this for those who remain concerned about maintaining clear a=
ir
between IETF and ISOC (I am one!) placing IETF administrative functions
within the ISOC umbrella does not necessarily preclude the proposed IASA
being separately incorporated at a later date. This could be within or
outside ISOC.

There are today distinct legal entities created within the ISOC family ow=
ned
and managed by their specific 'local' communities.

To give an example. When I established the ISOC England chapter the team
that got involved put together a formal corporate entity that was owned b=
y
the chapter's members, governed under UK law but adopting common ISOC
chapter rules.

I am not suggesting the IETF administrative function should become an "IS=
OC
Chapter" but to point out existing practice within ISOC for self governin=
g
activities using formal incorporated structures where this is appropriate
and which interface within ISOC at Board of Trustee level.

So as I see it Scenario O gives IETF what is needed.

I have one further comment to make.

I would strongly recommend that IETF participants join ISOC! A Society is
governed by its members.

For background check on me. I will just add that I was briefly a VP at IS=
OC
and am a past chair of a chapter.


Christian de Larrinaga
Network Brokers Ltd

p.s., A few inline thoughts included below.



> From Leslie Daigle
>
> Not an Internet-Draft                                          L. Daigl=
e
>                                                                  VeriSi=
gn
>                                                              M. Wasserm=
an
>                                                                ThingMag=
ic
>                                                        September 20, 20=
04
>
>
>      AdminRest Scenario O: An IETF-Directed Activity Housed Under the
>                   Internet Society (ISOC) Legal Umbrella
>
>
> Abstract
>
>     This document defines an alternative proposal for the structure of
>     the IETF's administrative support activity (IASA) -- an IETF-define=
d
>     and directed activity that operates within the ISOC legal umbrella.
>     It proposes the creation of an IETF Administrative Oversight
>     Committee (IAOC) that is selected by and accountable to the IETF
>     community.  This committee would provide oversight for the IETF
>     administrative support activity, which would be housed within the
>     ISOC legal umbrella.  In order to allow the community to properly
>     evaluate this scenario, some draft BCP wording is included.
>
>
snip

>
> 2.1  Definition of the IETF Administrative Support Activity (IASA)
>
>     The IETF undertakes its technical activities as an ongoing, open,
>     consensus-based process.  The Internet Society has long been a part
>     of the IETF's standards process, and this document does not affect
>     the ISOC-IETF working relationship concerning standards development
>     or communication of technical advice.  The purpose of this memo is =
to
>     define an administrative support activity that is responsive to the
>     IETF technical community's needs, as well as consistent with ISOC's
>     operational, financial and fiduciary requirements while supporting
>     the IETF technical activity.
>
>     The IETF Administrative Support Activity (IASA) provides
>     administrative support for the technical work of the IETF.  This
>     includes, as appropriate,  undertaking or contracting for the work
>     described in (currently, [RFC3716] but the eventual BCP should
>     include the detail as an appendix), covering IETF document and data
>     management, IETF meetings, any operational agreements or contracts
>     with the RFC Editor and IANA.  This provides the administrative
>     backdrop required to support the IETF standards process and to
>     support the IETF organized technical activities, including the IESG=
,
>     IAB and working groups.  This includes the financial activities
>     associated with such IETF support (collecting IETF meeting fees,
>     payment of invoices, appropriate financial management, etc).  The
>     IASA is responsible for ensuring that the IETF's administrative
>     activities are done and done well; it is not the expectation that t=
he
>     IASA will undertake the work directly, but rather contract the work
>     from others, and manage the contractual relationships in line with
>     key operating principles such as efficiency, transparency and cost
>     effectiveness.
>
>     The IASA is distinct from other IETF-related technical functions,
>     such as the RFC editor, the Internet Assigned Numbers Authority
>     (IANA), and the IETF standards process itself.

>The IASA is not
>
>
>
> Daigle & Wasserman                                              [Page 4=
]
> =0C>
>                            AdminRest Scenario O            September 20=
04
>
>
>     intended to have any influence on the technical decisions of the IE=
TF
>     or on the technical contents of IETF work.


no influence?


>
> 2.1.1  Structure of the IASA
>
>     The IASA will be structured to allow accountability to the IETF
>     community.  It will determine the ongoing success of the activity i=
n
>     meeting IETF community needs laid out in this BCP, as well as ISOC
>     oversight of its financial and resource contributions.  The
>     supervisory body defined for this will be called the IETF
>     Administrative Oversight Committee (IAOC).  The IAOC will consist o=
f
>     volunteers, all chosen directly or indirectly by the IETF community=
,
>     as well as appropriate ex officio appointments from ISOC and IETF
>     leadership.  The IAOC will be accountable to the IETF community for
>     the effectiveness, efficiency and transparency of the IASA.
>
>     The IASA will initially consist of a single full-time employee of
>     ISOC, the IETF Administrative Director (IAD).  The IAD will require=
 a
>     variety of financial, legal and administrative support, and it is
>     expected that this support will be provided by ISOC support staff
>     following an expense and/or allocation model TBD.

IASA managed as a division of ISOC with IAD holding full profit and loss =
and
management responsibility.


>
>     Although the IAD will be a full-time ISOC employee, he will work
>     under the direction of the IAOC.  The IAD will be selected by a
>     committee of the IAOC, consisting minimally of the ISOC President a=
nd
>     the IETF Chair.  This same committee will be responsible for
>     periodically reviewing the performance of the IAD and determining a=
ny
>     changes to his employment and compensation.  In certain cases (to b=
e
>     defined clearly -- chiefly cases where the ISOC employee is
>     determined to have contravened basic ISOC policies), the ISOC
>     President may make summary decisions, to be reviewed by the hiring
>     committee after the fact.
>

ISOC president & IAD should be on good terms, and ensure that IAD reports=
 as
required for public funds (allocated by ISOC) to show they are being used
for purpose.

There needs to be some clear process agreed where funds are withheld by I=
SOC
for any reason.

Firing issues should be as for hiring - an IAOC decision. It might be use=
ful
for emergency use to the IAOC to have a procedure for the ISOC President =
to
suspend the IAD for a short period subject to review in cases of suspecte=
d
gross misconduct.

The role of the IAD in ISOC staff should be limited to the IASA only and
once a budget is agreed for the IASA within ISOC the IAD should have
divisional autonomy and be able to hire any additional members of his / h=
er
team and manage the IASA within the parameters set by the IAOC.


snip...

> 2.1.4  IASA Funding
>
>     The IASA is supported financially in 3 ways:
>
>     1.  IETF meeting revenues.  The IAD, in consultation with the IAOC,
>         sets the meeting fees as part of the budgeting process.  All
>         meeting revenues go to the IASA.
>
>     2.  Designated ISOC donations.  The IETF and IASA do no specific fu=
nd
>         raising activities; this maintains separation between fundraisi=
ng
>         and standards activities.  Any organization interested in
>         supporting the IETF activity will continue to be directed to
>         ISOC, and any funds ISOC receives specifically for IETF
>         activities (as part of an ISOC program that allows for specific
>         designation) will be put in the IASA bank account for IASA
>         management.
>
>     3.  Other ISOC support.  ISOC will deposit in the IASA account, eac=
h
>         quarter, the funds committed to providing as part of the IASA
>         budget (where the meeting revenues and specific donations do no=
t
>         cover the budget).  These funds may come from member fees or fr=
om
>         other revenue streams ISOC may create.
>
>     Note that the goal is to achieve and maintain a viable IETF support
>     function based on meeting fees and specified donations, and the IAO=
C
>     and ISOC are expected to work together to attain that goal.  (I.e.,
>     dropping the meeting fees to $0 and expecting ISOC to pick up the
>     slack is not desirable; nor is raising the meeting fees to
>     prohibitive levels to fund all non-meeting-related activities!).
>
>     Also, in normal operating circumstances, the IASA would look to hav=
e
>     a 6 month operating reserve for its activities.  Rather than having
>     the IASA attempt to accrue that in its bank account, the IASA looks
>     to ISOC to build and provide that operational reserve (through
>     whatever mechanism instrument ISOC deems appropriate -- line of
>     credit, financial reserves, etc).  Such reserves do not appear
>     instantaneously; the goal is to reach that level of reserve by 3
>     years after the creation of the IASA.  It is not expected that any
>     funds associated with such reserve will be held in the IASA bank
>     account.
>


A startup fund or endowment for cashflow is likely to be needed?

snip to end...


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

