RE: Scenario O Re: Upcoming: further thoughts on where from here

"Christian de Larrinaga" <> Sun, 26 September 2004 21:56 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA02533; Sun, 26 Sep 2004 17:56:19 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CBh7m-0000JB-R4; Sun, 26 Sep 2004 18:04:07 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CBgxr-0002e1-1s; Sun, 26 Sep 2004 17:53:51 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1CBgwA-0002Ts-UE for; Sun, 26 Sep 2004 17:52:07 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA02360 for <>; Sun, 26 Sep 2004 17:52:04 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CBh3U-0000Dn-LK for; Sun, 26 Sep 2004 17:59:51 -0400
Received: from pcgz600re ( []) by (Postfix) with ESMTP id 3B40124E181; Sun, 26 Sep 2004 22:51:42 +0100 (BST)
From: Christian de Larrinaga <>
To: Leslie Daigle <>,
Date: Sun, 26 Sep 2004 22:55:11 +0100
Message-ID: <>
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: <>
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 <>
Subject: RE: Scenario O 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: 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 the
informality and porous boundaries of the IETF. It is perfectly possible to
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 air
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 owned
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 by
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 "ISOC
Chapter" but to point out existing practice within ISOC for self governing
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 ISOC
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. Daigle
>                                                                  VeriSign
>                                                              M. Wasserman
>                                                                ThingMagic
>                                                        September 20, 2004
>      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-defined
>     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.

> 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 the
>     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]
> >
>                            AdminRest Scenario O            September 2004
>     intended to have any influence on the technical decisions of the IETF
>     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 in
>     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 of
>     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 and
>     the IETF Chair.  This same committee will be responsible for
>     periodically reviewing the performance of the IAD and determining any
>     changes to his employment and compensation.  In certain cases (to be
>     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 ISOC
for any reason.

Firing issues should be as for hiring - an IAOC decision. It might be useful
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 suspected
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 / her
team and manage the IASA within the parameters set by the IAOC.


> 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 fund
>         raising activities; this maintains separation between fundraising
>         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, each
>         quarter, the funds committed to providing as part of the IASA
>         budget (where the meeting revenues and specific donations do not
>         cover the budget).  These funds may come from member fees or from
>         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 IAOC
>     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 have
>     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