Subject: Upcoming: further thoughts on where from here

From: Leslie Daigle <[email-masked]>
Date: Mon, 20 Sep 2004 09:26:58 -0400

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
[email-masked]
-------------------------------------------------------------------

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 20 Sep 2004 15:57:27 -0400

Following up on my note from this morning...

> a viable path or what further work needs to be done.

Here is some text describing a scenario derived from Carl's
Scenarios A & B.

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.

Daigle & Wasserman                                              [Page 1]

                           AdminRest Scenario O            September 2004

Table of Contents

    1.  Overview of Scenario O . . . . . . . . . . . . . . . . . . . .  3
    2.  Draft of Administrative Support BCP  . . . . . . . . . . . . .  4
      2.1   Definition of the IETF Administrative Support Activity
            (IASA) . . . . . . . . . . . . . . . . . . . . . . . . . .  4
        2.1.1   Structure of the IASA  . . . . . . . . . . . . . . . .  5
        2.1.2   IAD Responsibilities . . . . . . . . . . . . . . . . .  6
        2.1.3   IAOC Responsibilities  . . . . . . . . . . . . . . . .  6
        2.1.4   IASA Funding . . . . . . . . . . . . . . . . . . . . .  7
      2.2   IAOC Membership, Selection and Accountability  . . . . . .  7
      2.3   IASA Budget Process  . . . . . . . . . . . . . . . . . . .  9
      2.4   Relationship of the IAOC to Existing IETF Leadership . . . 10
      2.5   ISOC Responsibilities for IASA . . . . . . . . . . . . . . 10
    3.  Workplan for Formalizing the IETF Administrative Support
        Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
      3.1   Workplan Goals . . . . . . . . . . . . . . . . . . . . . . 12
      3.2   Workplan Overview  . . . . . . . . . . . . . . . . . . . . 12
      3.3   Approval by the IETF Community and ISOC  . . . . . . . . . 13
      3.4   Selecting IASA Leadership  . . . . . . . . . . . . . . . . 13
      3.5   Recruiting the IETF Administrative Director  . . . . . . . 14
      3.6   Establishing Agreement with Service Providers  . . . . . . 14
      3.7   Establishing a 2005 Operating Budget . . . . . . . . . . . 15
      3.8   Proposed Schedule for IASA Transition  . . . . . . . . . . 15
    4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    7.1   Normative References . . . . . . . . . . . . . . . . . . . . 17
    7.2   Informative References . . . . . . . . . . . . . . . . . . . 17
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17

Daigle & Wasserman                                              [Page 2]

                           AdminRest Scenario O            September 2004

1.  Overview of Scenario O

    IETF community discussions of the scenarios for administrative
    restructuring presented in Carl Malamud's consultant report
    [I-D.malamud-consultant-report] have led to the identification of a
    potentially viable alternative that is not included in that report --
    an IETF-defined and directed administrative support function housed
    under the ISOC legal umbrella (called "IASA" hereafter).  This new
    scenario retains some properties of the original ISOC-based
    scenarios, Scenarios A and B.  However, this new scenario aims to
    provide:

    o  continued close relationship with ISOC

    o  a clear basis from which the IETF can define (and, over time,
       refine) the administrative activity in terms of IETF community
       needs, using existing IETF/ISOC processes

    o  an operational oversight board that is accountable to the IETF
       community

    o  continued separation between the IETF standards activity and any
       fund-raising for standards work (within ISOC)

    o  appropriate ISOC oversight of its standards activities funds

    This scenario is nicknamed "Scenario O" -- it is derived from, but
    does not entirely encompass, Scenario A or Scenario B.

    In Scenario O, the IETF administrative support function would be
    defined in a BCP that would be created via the IETF standards process
    [RFC2026] and approved by the ISOC Board of Trustees.  This BCP would
    describe the scope of an IETF Administrative Support Activity (IASA)
    and would define the structure and responsibilities of the IETF
    Administrative Oversight Committee (IAOC), an IETF-selected body
    responsible for overseeing the IASA.  Like the Internet Architecture
    Board (IAB), the IASA would be housed within the ISOC legal umbrella.
    The BCP would also describe ISOC's responsibilities within this
    scenario, including requirements for financial accounting and
    transparency.  A draft of this BCP is included in the next section of
    this document.

    Scenario O allows us to establish IETF control over our
    administrative support functions in terms of determining that they
    meet the community's needs,  and adjusting them from time to time
    using IETF processes.  At the same time, it does not require that the
    IETF community determine, create and undertake the risks associated
    with an appropriate corporate structure (with similar financial

Daigle & Wasserman                                              [Page 3]

                           AdminRest Scenario O            September 2004

    infrastructure and tax-exempt status to ISOC's) in order to solve the
    pressing administrative issues outlined in [RFC3716].  This proposal
    also defines the boundaries of the IASA so that it could be
    encapsulated and moved elsewhere at some future date, should that
    ever be desirable.

2.  Draft of Administrative Support BCP

    This section proposes draft text for a BCP that would define the
    scope and structure of the IASA.  Although this text would require
    further refinement within the IETF community, this section is
    intended to be clear and complete enough to allow the community to
    reach a well-informed opinion regarding this scenario.

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.

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.

    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.

    The IAD will be responsible for administering the IETF finances,
    managing a separate bank account for the IASA, and establishing and
    administering the IASA budget.  To perform these activities, the IAD
    is expected to have signing authority comparable to other ISOC
    director-level employees.  Generally, expenses or agreements outside
    that authority to be approved for financial soundness as determined
    by ISOC policy.  The joint expectation is that ISOC's policies will
    be consistent with allowing the IAD to carry out IASA work
    effectively and efficiently.  Should the IAOC have concerns about
    that, the IAOC and ISOC commit to working out other policies that are
    mutually agreeable.

    The IAD will also fill the role of the IETF Executive Director, as
    described in various IETF process BCPs.  All other administrative
    functions will be outsourced via well-defined contracts.  The IAD

Daigle & Wasserman                                              [Page 5]

                           AdminRest Scenario O            September 2004

    will be responsible for negotiating and maintaining those contracts,
    as well as providing any coordination that is necessary to make sure
    the IETF administrative support functions are properly covered.

2.1.2  IAD Responsibilities

    The day to day responsibilities of the IAD will focus on managing
    contracts with the entities providing the work supporting the IETF
    technical activity.

    The IAD will provide regular (monthly and quarterly) reports to the
    IAOC and ISOC.

    All contracts will be negotiated by the IAD (with input from any
    other appropriate bodies), and reviewed by the IAOC.  The contracts
    will be executed by ISOC, on behalf of the IETF, after whatever
    review ISOC requires (e.g., legal, Board of Trustees).

    The IAD will prepare an annual budget, which will be reviewed and
    approved by the IAOC.  The IAD will be responsible for presenting
    this budget to the ISOC Board of Trustees, as part of ISOC's annual
    financial planning process.  The partnering is such that the IAOC is
    responsible for ensuring the suitability of the budget for meeting
    the IETF community's needs, but it does not bear fiduciary
    responsibility; the ISOC board needs to review and understand the
    budget and planned activity in have enough detail of the budget and
    proposed plans to properly carry out its fiduciary responsibility.

2.1.3  IAOC Responsibilities

    The role of the IAOC is to provide appropriate input to the IAD, and
    oversight of the IASA functioning.  The IAOC is not expected to be
    regularly engaged in IASA work, but rather to provide appropriate
    approval and oversight.

    Therefore, the IAOC's responsibilities are:

    o  Select the IAD, as described above.

    o  Review the IAD's financial reports, and provide approval of the
       IAD's budget proposals in terms of fitness for IETF purposes.

    o  Review IASA functioning with respect to meeting the IETF
       community's working needs.

    The IAOC's role is to review, not carry out the work of,  the IAD and
    IASA.  As such, it is expected the IAOC will have monthly
    teleconferences and periodic face to face meetings, probably

Daigle & Wasserman                                              [Page 6]

                           AdminRest Scenario O            September 2004

    coincident with IETF plenary meetings, consistent with ensuring an
    efficient and effective operation.

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.

2.2  IAOC Membership, Selection and Accountability

    Note:  This section is particularly subject to change as we work to
    find the best way to achieve the key principles.  The key principles

Daigle & Wasserman                                              [Page 7]

                           AdminRest Scenario O            September 2004

    being adhered to are that while this should be reasonably separate
    from IETF Standards process management:

    o  the IETF and IAB Chairs need to be involved to a level that
       permits them to be involved in and oversee the aspects pertinent
       to their roles in managing the technical work (e.g., the IAB looks
       after the RFC Editor relationship)

    o  the IETF and IAB Chairs must not be critical path to getting
       decisions to and through the IASA.

    The current draft, below, therefore makes the IETF Chair ex officio
    voting member of the IAOC, and the IAB Chair a non-voting liaison.
    Future versions may change either or both, depending on what makes
    sense to the IETF community in its deliberations.

    The IAOC will consist of seven voting members who will be selected as
    follows:

    o  2 members chosen by the IETF Nominations Committee (NomCom)

    o  1 member chosen by the IESG

    o  1 member chosen by the IAB

    o  1 member chosen by the ISOC Board of Trustees

    o  The IETF Chair (ex officio)

    o  The ISOC President/CEO (ex officio)

    There will also be two non-voting, ex officio liaisons:

    o  The IAB Chair

    o  The IETF Administrative Director

    The voting members of the IAOC will choose their own chair each year
    using a consensus mechanism of its choosing.  Any appointed voting
    member of the IAOC may serve as the IAOC Chair (i.e., not the IETF
    Chair or the ISOC President/CEO).  The role of the IAOC Chair is to
    organize the IAOC.  The IAOC Chair has no formal duties for
    representing the IAOC, except as directed by IAOC consensus.

    The members of the IAOC will typically serve two year terms.
    Initially, the IESG and ISOC Board will make one-year appointments,
    the IAB will make a two-year appointment, and the Nomcom will make
    one one-year appointment and one two-year appointment to establish a

Daigle & Wasserman                                              [Page 8]

                           AdminRest Scenario O            September 2004

    pattern where approximately half of the IAOC is selected each term.

    The two NomCom selected members will be selected using the procedures
    described in RFC 3777.  For the initial selection, the IESG will
    provide the list of desired qualifications for these positions.  In
    later years, this list will be provided by the IAOC.

    While there are no hard rules regarding how the IAB and the IESG
    should select members of the IAOC, it is not expected that they will
    typically choose current IAB or IESG members, if only to avoid
    overloading existing leadership.  However, they should choose people
    who are familiar with the administrative support needs of the IAB,
    the IESG and/or the IETF standards process.  It is suggested that a
    fairly open process be followed for these selections, perhaps with an
    open call for nominations and/or a period of public comment on the
    candidates.  The IAB and IESG are encouraged to look at the procedure
    for IAB selection of ISOC Trustees for an example of how this might
    work.

    Although the IAB and IESG will choose some members of the IAOC, those
    members will not directly represent the bodies that chose them.  All
    members of the IAOC are accountable directly to the IETF community.
    To receive direct feedback from the community, the IAOC will hold an
    open meeting at least once per year at an IETF meeting.  This may
    take the form of an open IAOC plenary or a working meeting held
    during an IETF meeting slot.  The form and contents of this meeting
    are left to the discretion of the IAOC Chair.

    Decisions of IAOC members or the entire IAOC are subject to appeal
    using the procedures described in RFC 2026.  The initial appeal of an
    individual decision will go to the full IAOC.  Appeals of IAOC
    decisions will go to the IESG and continue up the chain as necessary
    (to the IAB and the ISOC Board).  The IAOC will play no role (aside
    from possible administrative support) in appeals of WG Chair, IESG or
    IAB decisions.

    In the event that an IAOC member abrogates his duties or acts against
    the bests interests of the IETF community, IAOC members are subject
    to recall using the recall procedure defined in RFC 3777.  IAB and
    IESG-appointed members of the IAOC are not subject to recall by their
    appointing bodies.

2.3  IASA Budget Process

    While the IASA sets a budget for the IETF's administrative needs, its
    budget process clearly needs to be closely coordinated with ISOC's.
    The specific timeline will be established each year, before the
    second IETF meeting.  A general annual timeline for budgeting will

Daigle & Wasserman                                              [Page 9]

                           AdminRest Scenario O            September 2004

    be:

    July 1 The IAD presents a budget proposal (for the following fiscal
       year, with 3 year projections) to the IAOC.

    August 1 The IAOC approves the budget proposal for IETF purposes,
       after any appropriate revisions.  As the ISOC President is part of
       the IAOC, the IAOC should have a preliminary indication of how the
       budget will fit with ISOC's own budgetary expectations.  The
       budget proposal is passed to the ISOC Board of Trustees for review
       in accordance with their fiduciary duty.

    September 1 The ISOC Board of Trustees approves the budget proposal
       provisionally.  During the next 2 months, the budget may be
       revised to be integrated in ISOC's overall budgeting process.

    November 1 Final budget to the ISOC Board for approval.

    The IAD will provide monthly accountings of expenses, and will update
    forecasts of expenditures quarterly.  This may necessitate the
    adjustment of the IASA budget.  The revised budget will need to be
    approved by the IAOC and ISOC Board of Trustees.

2.4  Relationship of the IAOC to Existing IETF Leadership

    The IAOC will be directly accountable to the IETF Community.
    However, the nature of the IAOC's work will involve treating the IESG
    and IAB as internal customers.  The IAOC should not consider its work
    successful unless the IESG and IAB are satisfied with the
    administrative support that they are receiving.

2.5  ISOC Responsibilities for IASA

    Within ISOC, support for the IASA should be structured to meet the
    following goals:

    Transparency: The IETF community should have complete visibility into
       the financial and legal structure of the ISOC standards activity.
       In particular, the IETF community should have access to a detailed
       budget for the entire standards activity, quarterly financial
       reports and audited annual financials.  In addition, key contract
       material and MOUs should be publicly available.  Most of these
       goals are already met by ISOC today.  The IAOC will be responsible
       for providing the IETF community with regular overviews of the
       state of affairs.

Daigle & Wasserman                                             [Page 10]

                           AdminRest Scenario O            September 2004

    Unification: As part of this arrangement, ISOC's sponsorship of the
       RFC Editor, IAB and IESG, as well as insurance coverage for the
       IETF will be managed as part of the IASA under the IAOC.

    Independence: The IASA should be financially and legally distinct
       from other ISOC activities.  IETF meeting fees should be deposited
       in a separate IETF-specific bank account and used to fund the IASA
       under the direction and oversight of the IAOC.  Any fees or
       payments collected from IETF meeting sponsors should also be
       deposited into this account.  This account will be administered by
       the IAD and used to fund the IASA in accordance with a budget and
       policies that are developed as described above.

    Support: ISOC may, from time to time, choose to transfer other funds
       into this account to fund IETF administrative projects or to cover
       IETF meeting revenue shortfalls.  There may also be cases where
       ISOC chooses to loan money to the IASA to help with temporary cash
       flow issues.  These cases should be carefully documented and
       tracked on both sides.  ISOC will work to provide the 6 month
       operational reserve for IASA functioning described above.

    Removability: While there is no current plan to transfer the legal
       and financial home of the IASA to another corporation, the IASA
       should be structured to enable a clean transition in the event
       that the IETF community decides, through BCP publication, that
       such a transition is required.  In that case, the IAOC will give
       ISOC a minimum six months notice before the transition formally
       occurs.  During that period, the IAOC and ISOC will work together
       to create a smooth transition that does not result in any
       significant service outages or missed IETF meetings.  All
       contracts that are executed by ISOC as part of the IASA should
       either include a clause allowing termination or transfer by ISOC
       with six months notice, or should be transferrable to another
       corporation in the event that the IASA is transitioned away from
       ISOC in the future.  Any accrued funds, and IETF-specific
       intellectual property rights (concerning administrative data and/
       or tools) would also be expected to be transitioned to any new
       entity, as well.

    Within the constraints outlined above, all other details of how to
    structure this activity within ISOC (as a cost center, a department
    or a formal subsidiary) should be determined by ISOC in consultation
    with the IAOC.

3.  Workplan for Formalizing the IETF Administrative Support Activity

    This section proposes a workplan and schedule for formalizing the
    IETF administrative support activity (IASA) for the remainder of 2004

Daigle & Wasserman                                             [Page 11]

                           AdminRest Scenario O            September 2004

    and 2005.

3.1  Workplan Goals

    This workplan is intended to satisfy four goals:

    o  Satisfy the IETF's need for support functions through 2005, with a
       careful transition that minimizes the risk of substantial
       disruption to the IETF standards process.

    o  Establish IETF community consensus and ISOC approval of a BCP
       formalizing the IASA as described in this scenario before any
       actions are taken that will have long term effects (hiring,
       contacts, etc.)

    o  Make sure that decisions with long term impact, such as hiring the
       IAD and establishing contracts for administrative support, are
       made by people chosen for that purpose who will be responsible to
       the community for the effectiveness of this effort (the IAD and
       members of the IAOC) -- not by our already overloaded technical
       leadership.

    o  Within the above constraints, move as quickly as possible towards
       a well-defined administrative support structure that is
       transparent and accountable to the IETF community.

3.2  Workplan Overview

    There are three major elements to this workplan which can, to some
    degree, take place in parallel after we establish IETF community
    consensus to pursue Scenario O:

    o  Finalizing the BCP text and getting it approved by the IETF
       community and ISOC.

    o  Selecting IASA leadership.  This includes appointing an interim
       IAOC, recruiting the IAD, and eventually appointing the full IAOC.

    o  Negotiating agreements with service providers.  This includes
       determining the structure and work flow of the IASA, deciding
       which portions of the IASA should be staffed via an open request
       for proposals (RFP) process, and issuing a RFP for those portions,
       as well as establishing sole source contracts or MOUs for other
       portions of the IASA.

    Each of the three items listed above is described in more detail in
    the following sections.

Daigle & Wasserman                                             [Page 12]

                           AdminRest Scenario O            September 2004

3.3  Approval by the IETF Community and ISOC

    In scenario O, the IASA is formalized in a BCP that is approved by
    the IETF community and accepted by the ISOC Board of Trustees.  There
    are three steps in this process:

    1.  Establishment of IETF community consensus that we should pursue
        Scenario O as defined in a joint IAB/IESG recommendation based on
        this proposal.  This consensus will be established through
        community discussion and a formal two-week consensus call issued
        by the IETF chair on the IETF mailing list.

    2.  Establishment of IETF community consensus on a BCP that
        formalizes the IASA as described.  This consensus would be
        established through public discussion, a four week IETF Last Call
        and IESG review and approval.

    3.  ISOC approval of the BCP and acceptance of ISOC's
        responsibilities as described therein.  This approval and
        acceptance would be signified by an ISOC Board resolution.

    The timeline for these three stages is rather long, but there is
    significant progress that can be made in other areas once we have
    established IETF community consensus to pursue this scenario.

3.4  Selecting IASA Leadership

    Once we have IETF consensus to pursue this scenario, we can appoint
    an interim IAOC to begin working on the IASA transition.  The interim
    IAOC could do substantial work on non-binding tasks, such as
    beginning the recruitment process for an IAD, determining the
    structure of the IASA work, issuing RFPs and negotiating potential
    agreements with service providers.  The interim IAOC would not be
    empowered to make binding agreements, but could work appropriate
    consultants and advisors to make a lot of progress towards
    determining the initial structure and work flow of the IASA.

    Because the IETF Nominations Commitee (NomCom) process for new
    positions will consume a lot of resources and take a long time to
    complete, we propose that the interim IAOC consist of:

    o  1 IESG selected member

    o  1 IAB selected member

    o  1 ISOC selected member

    o  The IETF Chair

Daigle & Wasserman                                             [Page 13]

                           AdminRest Scenario O            September 2004

    o  The ISOC President/CEO

    The IAB chair will serve as a liaison, as described above.

    The IESG and ISOC Board appointments will be expected to serve until
    the first IETF meeting of 2006, and the IAB appointment will be
    expected to serve until the first IETF meeting of 2007, assuming that
    the BCP is approved and the IAOC continues to have appointed members
    from these bodies.

    After all of the interim IAOC members are selected, they will choose
    an interim IAOC chair from among the appointed members.

    When the BCP is approved, if the BCP indicates that there will be
    NomCom selected IAOC members they will be chosen at that time.  Any
    adjustments to appointed members based on the BCP contents will also
    be made at that time.  The IAOC will transition from interim to
    non-interim status when all non-interim members are seated.  A new,
    non-interim chair selection process will then commence.

3.5  Recruiting the IETF Administrative Director

    The interim IAOC should appoint an IAD selection committee to recruit
    and select the IETF Administrative Director.  This committee will
    consist entirely of IAOC members or liaisons, and will, at minimum,
    include the IETF chair and the ISOC President.  If the IAOC chooses,
    this committee could include the entire IAOC.

    The IAD selection committee should determine a job description for
    the IAD, in consultation with other IETF leaders and the IETF
    community.  Once the job description is established, the IAD
    selection committee should recruiting candidates for the position.

    Although the interim IAOC is not empowered to hire the IAD as a
    full-time employee, it might be possible for the IAOC to ask ISOC to
    engage the potential IAD as a consultant to help with other tasks
    during the interim period.

3.6  Establishing Agreement with Service Providers

    The most important activity of the IAOC during late 2004 and early
    2005 will be to determine the structure and work flow of the IASA and
    to establish contracts or other agreements with service providers to
    do the required work.  This work includes the following functions as
    defined in the consultant's report:

    o  Technical infrastructure

Daigle & Wasserman                                             [Page 14]

                           AdminRest Scenario O            September 2004

    o  Meeting management

    o  Clerk's office

    o  RFC Editor services to support  IETF standards publication

    o  IANA services to support IETF standards publication

    The interim IAOC should work with IETF leaders and other
    knowledgeable members of the community to determine the structure and
    work flow required for the IASA activity and make corresponding
    adjustments to the above list, if necessary.  The interim IAOC can
    also identify which areas of IASA work should continue to be provided
    by existing IETF service providers, and work with those providers to
    establish proposed contracts or agreements for later approval by the
    non-interim IAOC.  The IAOC can also choose to start an RFP process
    for any services that they believe should be filled through an open
    RFP process.

3.7  Establishing a 2005 Operating Budget

    Because the ISOC 2005 budgeting process will be finalized before the
    non-interim IAOC is seated, the interim IAOC should work with the
    ISOC staff and President to establish a proposed 2005 operating
    budget for the IASA.  Since this will happen in advance of full
    knowledge regarding the costs of 2005 operations, it may be subject
    to significant adjustment later.

3.8  Proposed Schedule for IASA Transition

    As described above, the three stages of the IETF community and ISOC
    approval process will take some time.  If the community chooses
    scenario O and we reach quick consensus on the details, an optimistic
    schedule for this approval would be:

    1.  IETF discussion of this proposal and other scenarios through
         1-Oct-2005.  IAB/IESG discusses this proposal with ISOC Board.

    2.  IAB/IESG joint recommendation issued on 8-Oct-04, including full
         BCP proposal.

    3.  Community discussion of the joint IAB/IESG recommendation through
         22-Oct-04.

    4.  Two-week community consensus call issued on the IETF list on
         23-Oct-04 regarding rough community consensus to pursue this
         direction and appoint an interim IAOC -- extends through IETF
         61.  IAOC selecting bodies begin search, based on expected

Daigle & Wasserman                                             [Page 15]

                           AdminRest Scenario O            September 2004

         community consensus.

    5.  Rough community consensus declared on 8-Nov-04 to pursue Scenario
         O and appoint the interim IAOC.

    6.  Interim IAOC seated on 15-Nov-04.  Interim IAOC begins interim
         work outlined above, including establishment of estimated 2005
         budget and IAD recruitment.

    7.  BCP text  discussed by community, IETF leadership and ISOC Board
         until we have something that represents rough community
         consensus that is acceptable to all.  We hope that this could be
         completed by 6-Dec-04.

    8.  Four week IETF Last Call issued for BCP on 6-Dec-04 -- extends
         through 3-Jan-04.

    9.  Simultaneous IESG and ISOC Board approvals by 17-Jan-04.

    10.  IAD officially hired in Jan 2005.

    11.  NomCom seats IAOC members at the first IETF of 2005, moving the
         IAOC from interim to non-interim status.

    12.  Formal agreements with all service providers in-place by June
         2005.

4.  Security Considerations

    This document describes a scenario for the structure of the IETF's
    administrative support activities.  It introduces no security
    considerations for the Internet.

5.  IANA Considerations

    This document has no IANA considerations in the traditional sense.
    As part of the extended IETF family, though, IANA may be interested
    in the contents.

6.  Acknowledgements

    Most of the ideas in this document are not new, and many of them did
    not originate with the authors.  This scenario represents a
    combination of ideas discussed within the IAB, the IESG and the IETF
    Community.

    This document was written using the xml2rfc tool described in RFC

Daigle & Wasserman                                             [Page 16]

                           AdminRest Scenario O            September 2004

    2629 [RFC2629].

7.  References

7.1  Normative References

    [I-D.malamud-consultant-report]
               Malamud, C., "IETF Administrative Support Functions",
               draft-malamud-consultant-report-01 (work in progress),
               September 2004.

    [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
               3", BCP 9, RFC 2026, October 1996.

    [RFC3716]  Advisory, IAB., "The IETF in the Large: Administration and
               Execution", RFC 3716, March 2004.

7.2  Informative References

    [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
               June 1999.

    [RFC3667]  Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
               3667, February 2004.

    [RFC3668]  Bradner, S., "Intellectual Property Rights in IETF
               Technology", BCP 79, RFC 3668, February 2004.

Authors' Addresses

    Leslie Daigle
    VeriSign

    EMail: [email-masked], [email-masked]

    Margaret Wasserman
    ThingMagic
    One Broadway, 14th Floor
    Cambridge, MA  02142
    USA

    Phone: +1 617 758-4177
    EMail: [email-masked]
    URI:   http://www.thingmagic.com

Daigle & Wasserman                                             [Page 17]


--

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Sep 2004 11:10:22 +0200

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.)

Regards
     Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 21 Sep 2004 12:04:12 +0200

Brian,

I've seen some argument that Scenario C, being more well-defined, is 
actually less complex than Scenario O.

Also, I was surprised to find that of the two timelines in the writeups, 
the one for Scenario C was the shorter one. (That may reflect the writers' 
degree of optimism, however!)

So the outcome is not settled in my mind yet.

I'd like your comments on why you find Scenario O simpler, and VERY much 
like your comments on where the details of Scenario O need "hacking", if 
that's the conclusion of the community.

                       Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Sep 2004 13:19:15 +0200

> actually less complex than Scenario O.

I would really dispute that. There are layers of complexity in either
case, and I think the scenario O analysis, because it's based on a
real, existing organisation rather than a hypothetical one, simply
contains more detail.

> the one for Scenario C was the shorter one. (That may reflect the 
> writers' degree of optimism, however!)

Yes, it's unrealistic in my view. Setting up such an entity is
not straightforward. The timeline in O seems attainable.

> I'd like your comments on why you find Scenario O simpler, 

As noted above, the text digs into more detail than C. For example,
C needs a lot more lawyering than O since it creates a completely new
legal (and tax and insurance) structure. All the details described
in O would have to be worked as internal procedures in C. I really see
C as pure incremental work on top of O.

> ...and VERY much 

I prefer to wait, to hack on whichever one we choose.

    Brian

>                       Harald
> 
> 
> 
> --On 21. september 2004 11:10 +0200 Brian E Carpenter 
> <[email-masked]> wrote:
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Sep 2004 08:21:41 -0400

Harald,

FWIW, with one qualification, I tend to agree with Brian.  While
Scenario C seems to contain more detail and definition, a great
deal of it appears to be handwaving that tends to conceal more
complexity and more risk.  I suspect that both schedules are too
optimistic (which one is "more" too optimistic is something I'll
try to generate a note exploring when I have a bit more time)
and that, while O is missing a risk analysis, as a subsequent
note from Brian points out, the risk analysis of C seems to
underestimate some of the risks.  More on that in a bit too.

And, as you can guess from previous conversations we've had, I'm
not wild about the degree of control and involvement both
scenarios give the IETF standards leadership over financial
matters.  More on that soon, too.

   john

--On Tuesday, 21 September, 2004 12:04 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

> Brian,
> 
> I've seen some argument that Scenario C, being more
> well-defined, is actually less complex than Scenario O.
> 
> Also, I was surprised to find that of the two timelines in the
> writeups, the one for Scenario C was the shorter one. (That
> may reflect the writers' degree of optimism, however!)
> 
> I'd like your comments on why you find Scenario O simpler, and
> VERY much like your comments on where the details of Scenario
> O need "hacking", if that's the conclusion of the community.
> 
>                        Harald
> 
> 
> 
>> (My only regret is that Scenario O text doesn't include a
>> short risk analysis, like Sceanrio C.)
> 
> 
> 
> 
>

---

From: Scott W Brim <[email-masked]>
Date: Tue, 21 Sep 2004 08:33:43 -0400

> real, existing organisation rather than a hypothetical one, simply

I'm with Brian, in favor of O.  The way I see it, the critical issue is
tightening up *our* processes, not who we deal with.  Once we do that we
can work out contracts with anyone who meet our criteria, and it will be
at least as easy to do so with an entity we have experience with and
whose actions we can predict well.  We will be much less at risk once
our own procedures are clearly established.

swb

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 21 Sep 2004 09:07:51 -0400

Hi Harald,

>actually less complex than Scenario O.

I share Brian's belief that Scenario C is more complex.  The document 
for Scenario C currently focuses on the mechanics of incorporation 
(as it should, I think) so it doesn't delve into some of the topics 
that Scenario O covers, such as what decisions will be made at each 
level of the resulting corporation. Since we will maintain a 
relationship with ISOC for funding, the work required for Scenario C 
is really a superset of Scenario O.

For example, I think that there is a lot that needs to be clarified 
regarding the duties of the BoT, Treasurer and IAD regarding fiscal 
management of the IASF.

The IASF BoT is a corporate board with full "buck stops here" 
fiduciary responsibility for the fiscal and legal management of the 
IASF corporation.  We haven't indicated that the IASF would have a 
President/CEO or that the IAD would be an officer of the IASF.  So, a 
lot responsibility for direct fiscal management may fall on the 
Treasurer (chosen by the IASF Board) and the Board itself.  Unless 
the IASF board authorizes the IAD to write checks on behalf of the 
IASF (with only a single signature), the Treasurer or an authorized 
BoT member will have to sign every check.  The IASF BoT would need to 
make employment policies, decide what types of benefits their 
employee(s) should get, review and approve tax exempt filings, handle 
payroll, etc.

So, at least one of the IASF BoT should probably be an accountant, 
maybe we should include a lawyer, and some reasonable number of them 
should have executive-level business skills including an 
understanding of employment law, etc.

I think that the current Scenario C document underestimates the 
complexity of selecting such a BoT and setting up the internal 
structures and policies that would make a corporation operational.

>writeups, the one for Scenario C was the shorter one. (That may 
>reflect the writers' degree of optimism, however!)

What do you consider to be the end of the Scenario O timeline?

I see a few dates for contracts in Scenario C, but most of those 
dates seem to be for actions that the IETF leadership (by which I 
assume you mean the IAB/IESG) will take in parallel with setting up 
the IASF corporation.  Is there a target date for incorporation of 
the IASF or a timeline for the BoT selection?

The Scenario O timeline is (IMO, as the person who wrote it) 
extremely aggressive -- it is a push goal, not a likely outcome.  One 
principle of the Scenario O timeline that makes the contract work 
happen later than the dates in the Scenario C document is that the 
initial contracts and major decisions about the structure of the IASA 
effort should be worked out by the people who need to manage them 
longer term, not by the already overloaded IETF technical leadership.

I think that the community will need to weigh these trade-offs (quick 
start using existing technical leadership vs. waiting until we 
appoint the people whose job this will be and let them do it).  We 
will have to make this trade-off in either Scenario, independent of 
which one we choose.  Our choice may depend on our assessment of how 
urgent it is to get these contracts formalized.

Margaret

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Sep 2004 10:55:28 -0700

At 9:07 AM -0400 9/21/04, Margaret Wasserman wrote:
>>I've seen some argument that Scenario C, being more well-defined, 
>>is actually less complex than Scenario O.
>
>I share Brian's belief that Scenario C is more complex.  The 
>document for Scenario C currently focuses on the mechanics of 
>incorporation (as it should, I think) so it doesn't delve into some 
>of the topics that Scenario O covers, such as what decisions will be 
>made at each level of the resulting corporation. Since we will 
>maintain a relationship with ISOC for funding, the work required for 
>Scenario C is really a superset of Scenario O.

For what it is worth, I think "superset of Scenario O" is the wrong way to
capture this.  The work required for Scenario C may be greater than Scenario
O, but there are ways in which it is different.  The main difference here is
that any variant of "IASF is part of ISOC" deals with ISOC's corporate
realities, where any variant of "IASF is not part of ISOC" deals with
creating the appropriate corporate realities.  A major disagreement
that we seem to have is whether any additional work that may be required to
create the appropriate corporate realities is worth the options it
buys now and options it allows us to buy in the future.

I, personally, believe it does.  The functions intended for IASF are
different from those associated with ISOC, and I believe that it
will need to evolve over the next 25 years of the IETF's history
in ways that will either 1) constrain how ISOC must evolve,
2) constrain they ways in which the IASF can evolve, 3) cause
some later set of poor bozos to have to go through this same
exercise again.  I think 1) is a bad idea because I believe it will
reduce the effectiveness of ISOC (because fate-sharing with
IASF will mean the ISOC will have to be more risk-averse and/or distracted);
I also believe it is out of the IETF community's control.  I think
2) implies a risk that IASF will be constrained in ways that means
it will not meet the IETF community's needs (though I freely grant
that assessing the extent of that risk is nearly impossible).  I
think 3) is tempting, but that we ought to be nicer to our
successors than that.

Again, none of this is any criticism of ISOC in its role in the standards
process, policy, or educational realms.  I just don't see the need
to yoke these two horses together; to me, they do or may need to
pull in different directions.

Speaking personally,
			regards,
				Ted Hardie

---

From: Erik Huizer <[email-masked]>
Date: Tue, 21 Sep 2004 23:21:32 +0200

FWIW, I too read the scenario C as more complex, certainly with respect to 
establishing a new organization. That really takes a lot of time and 
flushing out of details.

I see scenario O as doable, though I agree with John that even there the 
timeline is optimistic.

Erik

[Disclaimer: I am on the ISOC BoT. However I am also an IETF-er]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Sep 2004 16:30:28 +0200

Leslie and Harald somewhat challenged me in private to review
Scenario O more deeply, to indicate the bits of it that may need
more work - since otherwise we might miss showstoppers.

So I have sone so, below, but with the proviso that this
is the scenario I prefer - so my comments should be taken in
that context. I am too busy just now to do a similar review on
the alternative scenario, which I like much less for reasons
already stated.

Leslie Daigle wrote:
...
>                  Internet Society (ISOC) Legal Umbrella
...
>    o  a clear basis from which the IETF can define 

and control

>       ...(and, over time,
>    using IETF processes.  

It will also provide financial transparency of IETF operations,
which has been lacking in the past.

>    At the same time, it does not require that the
>    IAB and working groups.  

IRTF too?

I would also suggest, subject to legal advice, adding something like
"in the public interest" at the end of this sentence.

>    ...This includes the financial activities

I would take legal advice whether to insert a line here about the
non-profit aspect - maybe stating that any operating surplus will be
carried forward strictly to support future operations.
>    or on the technical contents of IETF work.

Is this strong enough? We could say that the IASA "has no influence..."?
>    ISOC, the IETF Administrative Director (IAD).  The IAD will require a

Very good acronym, since this person may spend a fair amount of time
in IAD airport :-)

>    Although the IAD will be a full-time ISOC employee, he will work

she?

>    committee after the fact.

I think the idea here is right, but it seems to be expressed clumsily, and
it needs to be made clear that this is really the exception case. Also,
these conditions have to be spelled out in the contract of employment
or the formal annual objectives for the IAD, rather than written in stone
in the BCP.

>    managing a separate bank account for the IASA, and establishing and

Is it really a separate bank account? It's certainly a separate accounting
pillar inside ISOC (one that already exists, as a matter of fact). This is
a practical question - if cash flow difficulties ever arise, a separate
bank account might be a definite disadvantage.

>    that, the IAOC and ISOC commit to working out other policies that are

The actual signing limit in $k has to be defined somewhere, presumably
as an ISOC internal operating procedure. Above some limit, it's normal
good practice to require two signatures anyway, so the only real
argument is about how many $k that is.

>    described in various IETF process BCPs.  

unless explicitly delegated with consent of the IAOC?

>    ...All other administrative

I appreciate Harald's argument for the strength of the word "contract"
but I can imagine trivial cases where it might be an intra-office
agreement within ISOC or something. How about "contracts or
equivalent instruments"?

>    The IAD will provide regular (monthly and quarterly) reports to the

Published?
>    other appropriate bodies), and reviewed by the IAOC.

Are you sure that *all* contracts will be subject to such review?
How about "those over $Nk" will be reviewed by the IAOC? Where N is
a single digit, probably.

>    The contracts
>    approved by the IAOC. 

And published?

>    ...The IAD will be responsible for presenting

An annual financial report should be published too.

One thing I miss above is how the IAD learns what the IETF wants.
Something like

  The IAD will be responsible for recording administrative requirements
  stated for the IETF by the IESG, investigating their feasibility and
  cost, and when possible and appropriate managing their implementation.

Maybe the channel for this should be the IAOC, not the IESG??

>    funds associated with such reserve will be held in the IASA bank

Exactly my point about having a separate bank account in the first place.

>    There will also be two non-voting, ex officio liaisons:

I'm not sure of the logic of the IAB Chair being non-voting.
I don't think it's a big deal since hopefully consensus will
be the normal approach anyway, but I'm curious about the
logic.
>    the IESG and/or the IETF standards process.  

and have some knowledge of contract and financial procedures (please!)

>    ...It is suggested that a

I think this needs to be a bit less vague, at least after the first
year's experience.

>    from possible administrative support) 

I don't see that - the IASA might provide support, but never the IAOC.

>    ...in appeals of WG Chair, IESG or
>    IAB decisions.
> 

I think minor adjustments wouldn't need to go to the Board, so I would
rephrase as
    ...by the IAOC, the ISOC CEO, and if necessary the ISOC Board of Trustees.

>       IETF will be managed as part of the IASA under the IAOC.

I agree in principle; there is a subtlety for the insurance which
is part of ISOC's general Directors and Officers insurance.

>       policies that are developed as described above.

Again, I agree in principle. But if you delete the word "bank" it would
allow for a pragmatic decision to use the general ISOC bank account
as mentioned above.

>       or tools) would also be expected to be transitioned to any new

Sure. But you aren't asking for the 6 month operating reserve to be
in a separate bank account, so in any case there would have to be a
financial settlement as part of any such separation.
>    or a formal subsidiary) should be determined by ISOC in consultation

It's pretty clear to me that the cost center already exists, and hiring
the IAD as a Director would create a department. I don't see any real
argument for a subsidiary.

...

>    schedule for this approval would be:

I agree with those who say that the schedule is aggressive. But that
may be the only way to go - as long as you have continuing arrangements
in place to cover any slippage. Who *owns and drives* this process,
especially since there is potentially a change of IETF Chair en route?

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Sep 2004 16:03:38 -0400

I'd like to express general support for scenario O.

I probably will not have time to read the document in sufficient
detail to agree with every point, but this looks like a good
direction.

--Sam

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 23 Sep 2004 01:08:48 -0700

Some comments:

2.1.4 - 6 months for the reserve is a funny number for an organization where
the nominal income period is 4 months. Wouldn't it make more sense to spell
out a reserve that covered a disaster case of a canceled meeting after the
contracts had been signed? Something like:
Also, in normal operating circumstances, the IASA would look to have a 6
month operating reserve for its non-meeting activities plus twice the recent
average for meeting contract guarantees.

2.2 - IAOC openness
   While an annual face-to-face is a good idea, the normal IETF concept of
openness is a public mail list. 

> ... IAB and IESG-appointed members of the IAOC are not subject
>  to recall by their appointing bodies.

The placement of that statement at the end of the paragraph is really
awkward and can be read to imply that those appointments are imune to
recall. How about:
In the event that an IAOC member abrogates his duties or acts against the
bests interests of the IETF community, IAOC members are subject to recall.
Any member, including those appointed by the IAB & IESG, may only be
recalled using the recall procedure defined in RFC 3777. 

2.3 Budget -
>     second IETF meeting.  

Wouldn't it be cleaner to just specify that the budget process will be
completed in the first half of the calendar year? That would be more
consistent with the July 1 date in the outline and avoid the issue of the
occasional mid-June meeting. If the goal was really to have it ready for the
potnetial mid-June meeting, then make it 'first 5 months'. 

3.4 
> ... issuing RFPs and negotiating potential agreements with service
providers.

I don't think we can do that before we get the IAD on board. If we are
hiring someone to do those tasks we should not only expect them to do the
task, we should LET THEM do the task. I realize there is a desire to move
quickly, but that step as written is probably counter productive. The more
appropriate thing would be:
... documenting the expected deliverables for use in RFPs. 

3.6
>     o  IANA services to support IETF standards publication

What about I-D editor???

>     considerations for the Internet.

Wouldn't failure of the administrative functions of the IETF adversly affect
the overall security of the Internet?  ;)

>     As part of the extended IETF family, though, IANA may be interested

Doesn't it officially move the logical home of the IANA function along with
the RFC Editor? If so I would think they would both be more than a little
interested in the contents.

Tony

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Sep 2004 10:35:10 -0400

I think that this (scenario 0) is the right approach to follow.  It appears 
to me to be the lowest risk path consistent with the needs that have been 
identified.

Two minor comments:
1) The references to "the IASF bank account" should probably be relaxed to 
"IASF fund accounts" or "IASF accounts".  As written, it presumes that 
there is exactly one bank account, and that separation of funds is by bank 
control.  While the later is probably a good idea, I don't think this BCP 
is the place to call that out.  And the exact number of bank accounts used 
by IASF (0, 1, 5, or ...) is not a concern for this BCP.

2) The schedule calls for seating the IAOC on January 15, and hiring the 
IAD by the end of January.  Given that the search committee can not be 
appointed until the board is seated, it seems that item is either an 
impossible schedule or assumes facts not in evidence.

Yours,
Joel M. Halpern

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 23 Sep 2004 11:40:15 -0400

Hi Joel,

At 10:35 AM -0400 9/23/04, Joel M. Halpern wrote:
>Two minor comments:
>1) The references to "the IASF bank account" should probably be 
>relaxed to "IASF fund accounts" or "IASF accounts".  As written, it 
>presumes that there is exactly one bank account, and that separation 
>of funds is by bank control.  While the later is probably a good 
>idea, I don't think this BCP is the place to call that out.  And the 
>exact number of bank accounts used by IASF (0, 1, 5, or ...) is not 
>a concern for this BCP.

Yes.  Someone else also pointed this out.  If we go forward with 
Scenario O, the BCP should probably just say that the money will be 
kept in separate account(s) and let the business management folks 
determine the right form and structure for those accounts.

>2) The schedule calls for seating the IAOC on January 15, and hiring 
>the IAD by the end of January.  Given that the search committee can 
>not be appointed until the board is seated, it seems that item is 
>either an impossible schedule or assumes facts not in evidence.

Actually, the schedule calls for the interim IAOC to be seated on 
15-Nov and for that group to begin the recruitment process.  The 
actual hiring wouldn't occur until after the BCP is approved by the 
IESG and ISOC (Jan 17th).  So, this is a ~2-month recruitment 
process. which is still aggressive but perhaps not impossible.

There are some compromises involved for quick start-up (like having 
the nomcom appointed members join later), but we've tried to be 
careful to make any major decisions (appointments, hiring, contracts) 
follow the appropriate levels of community approval and to have all 
of the major decisions made by people who will be responsible for the 
long-term consequences (good or bad) of those decisions.  I'd be very 
interested to know if folks think that we've gotten this wrong -- 
either the principles/priorities, or the details of schedule we've 
put forward...

Margaret

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 23 Sep 2004 16:49:59 +0100

> impossible schedule or assumes facts not in evidence.

I don't see why there's a linkage here. Why does a search committe need to 
be picked by the board?
The board can choose to accept or ignore the recommendation.

               Harald

---

From: [email-masked] (Kai Henningsen)
Date: 23 Sep 2004 08:55:00 +0200

> buys now and options it allows us to buy in the future.

Right now, it seems to me the relevant point is not so much "additional  
work" as "additional serious risk", as has already been pointed out by  
others.

As for the benefits, most of them seem to be purely theoretical to me; the  
"development of ISOC" one is, IMO, pure fantasy - if ISOC decides that a  
split would be beneficial, this could certainly be arranged at any time  
after doing scenario O; there's really nothing in there to prevent that,  
and the timing on that would be much more realistic.

Given how long it took the German finance authorities to decide that the  
supporting organization for westfalen.de didn't meet tax exempt status,  
and given how closely this matches predictions for the US case, I'd rather  
the IETF didn't start out on this particular reckless adventure,  
especially as I really don't see any actual benefits. At least we didn't  
have an alternative back then. The IETF has scenario O.

MfG Kai

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Sun, 26 Sep 2004 22:55:11 +0100

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
snip

>     (IANA), and the IETF standards process itself.

>The IASA is not
> >

no influence?

>     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.

>     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.

snip...

>     funds associated with such reserve will be held in the IASA bank

A startup fund or endowment for cashflow is likely to be needed?

snip to end...