Appendix: Scenario O

   This Appendix reproduces the contents of an Internet-Draft defining
   Scenario O, as it was posted on 20 September 2004.  A table of
   contents has been removed from this copy and the text has been
   reformatted to fit within IETF publication guidelines.  Each line is
   prefixed with "O>>".

O>>                                                            L. Daigle
O>>                                                             VeriSign
O>>                                                         M. Wasserman
O>>                                                           ThingMagic
O>>                                                   September 20, 2004
O>>
O>>     AdminRest Scenario O: An IETF-Directed Activity Housed Under the
O>>                  Internet Society (ISOC) Legal Umbrella
O>>
O>> Abstract
O>>
O>>    This document defines an alternative proposal for the structure
O>>    of the IETF's administrative support activity (IASA) -- an IETF-
O>>    defined and directed activity that operates within the ISOC legal
O>>    umbrella. It proposes the creation of an IETF Administrative
O>>    Oversight Committee (IAOC) that is selected by and accountable to
O>>    the IETF community.  This committee would provide oversight for
O>>    the IETF administrative support activity, which would be housed
O>>    within the ISOC legal umbrella.  In order to allow the community
O>>    to properly evaluate this scenario, some draft BCP wording is
O>>    included.
O>>
O>>    1.  Overview of Scenario O
O>>
O>>    IETF community discussions of the scenarios for administrative
O>>    restructuring presented in Carl Malamud's consultant report [I-
O>>    D.malamud-consultant-report] have led to the identification of a
O>>    potentially viable alternative that is not included in that
O>>    report -- an IETF-defined and directed administrative support
O>>    function housed under the ISOC legal umbrella (called "IASA"
O>>    hereafter).  This new scenario retains some properties of the
O>>    original ISOC-based scenarios, Scenarios A and B.  However, this
O>>    new scenario aims to provide:
O>>
O>>    o  continued close relationship with ISOC
O>>
O>>    o  a clear basis from which the IETF can define (and, over time,
O>>       refine) the administrative activity in terms of IETF community
O>>       needs, using existing IETF/ISOC processes
O>>

O>>    o  an operational oversight board that is accountable to the IETF
O>>       community
O>>
O>>    o  continued separation between the IETF standards activity and
O>>       any fund-raising for standards work (within ISOC)
O>>
O>>    o  appropriate ISOC oversight of its standards activities funds
O>>
O>>    This scenario is nicknamed "Scenario O" -- it is derived from,
O>>    but does not entirely encompass, Scenario A or Scenario B.
O>>
O>>    In Scenario O, the IETF administrative support function would be
O>>    defined in a BCP that would be created via the IETF standards
O>>    process [RFC2026] and approved by the ISOC Board of Trustees.
O>>    This BCP would describe the scope of an IETF Administrative
O>>    Support Activity (IASA) and would define the structure and
O>>    responsibilities of the IETF Administrative Oversight Committee
O>>    (IAOC), an IETF-selected body responsible for overseeing the
O>>    IASA.  Like the Internet Architecture Board (IAB), the IASA would
O>>    be housed within the ISOC legal umbrella. The BCP would also
O>>    describe ISOC's responsibilities within this scenario, including
O>>    requirements for financial accounting and transparency.  A draft
O>>    of this BCP is included in the next section of this document.
O>>
O>>    Scenario O allows us to establish IETF control over our
O>>    administrative support functions in terms of determining that
O>>    they meet the community's needs,  and adjusting them from time to
O>>    time using IETF processes.  At the same time, it does not require
O>>    that the IETF community determine, create and undertake the risks
O>>    associated with an appropriate corporate structure (with similar
O>>    financial infrastructure and tax-exempt status to ISOC's) in
O>>    order to solve the pressing administrative issues outlined in
O>>    [RFC3716].  This proposal also defines the boundaries of the IASA
O>>    so that it could be encapsulated and moved elsewhere at some
O>>    future date, should that ever be desirable.
O>>
O>> 2.  Draft of Administrative Support BCP
O>>
O>>    This section proposes draft text for a BCP that would define the
O>>    scope and structure of the IASA.  Although this text would
O>>    require further refinement within the IETF community, this
O>>    section is intended to be clear and complete enough to allow the
O>>    community to reach a well-informed opinion regarding this
O>>    scenario.
O>>

O>> 2.1  Definition of the IETF Administrative Support Activity (IASA)
O>>
O>>    The IETF undertakes its technical activities as an ongoing, open,
O>>    consensus-based process.  The Internet Society has long been a
O>>    part of the IETF's standards process, and this document does not
O>>    affect the ISOC-IETF working relationship concerning standards
O>>    development or communication of technical advice.  The purpose of
O>>    this memo is to define an administrative support activity that is
O>>    responsive to the IETF technical community's needs, as well as
O>>    consistent with ISOC's operational, financial and fiduciary
O>>    requirements while supporting the IETF technical activity.
O>>
O>>    The IETF Administrative Support Activity (IASA) provides
O>>    administrative support for the technical work of the IETF.  This
O>>
O>>    includes, as appropriate,  undertaking or contracting for the
O>>    work described in (currently, [RFC3716] but the eventual BCP
O>>    should include the detail as an appendix), covering IETF document
O>>    and data management, IETF meetings, any operational agreements or
O>>    contracts with the RFC Editor and IANA.  This provides the
O>>    administrative backdrop required to support the IETF standards
O>>    process and to support the IETF organized technical activities,
O>>    including the IESG, IAB and working groups.  This includes the
O>>    financial activities associated with such IETF support
O>>    (collecting IETF meeting fees, payment of invoices, appropriate
O>>    financial management, etc).  The IASA is responsible for ensuring
O>>    that the IETF's administrative activities are done and done well;
O>>    it is not the expectation that the IASA will undertake the work
O>>    directly, but rather contract the work from others, and manage
O>>    the contractual relationships in line with key operating
O>>    principles such as efficiency, transparency and cost
O>>    effectiveness.
O>>
O>>    The IASA is distinct from other IETF-related technical functions,
O>>    such as the RFC editor, the Internet Assigned Numbers Authority
O>>    (IANA), and the IETF standards process itself.  The IASA is not
O>>    intended to have any influence on the technical decisions of the
O>>    IETF or on the technical contents of IETF work.
O>>
O>> 2.1.1  Structure of the IASA
O>>
O>>    The IASA will be structured to allow accountability to the IETF
O>>    community.  It will determine the ongoing success of the activity
O>>    in meeting IETF community needs laid out in this BCP, as well as
O>>    ISOC oversight of its financial and resource contributions.  The
O>>    supervisory body defined for this will be called the IETF
O>>    Administrative Oversight Committee (IAOC).  The IAOC will consist
O>>    of volunteers, all chosen directly or indirectly by the IETF

O>>    community, as well as appropriate ex officio appointments from
O>>    ISOC and IETF leadership.  The IAOC will be accountable to the
O>>    IETF community for the effectiveness, efficiency and transparency
O>>    of the IASA.
O>>
O>>    The IASA will initially consist of a single full-time employee of
O>>    ISOC, the IETF Administrative Director (IAD).  The IAD will
O>>    require a variety of financial, legal and administrative support,
O>>    and it is expected that this support will be provided by ISOC
O>>    support staff following an expense and/or allocation model TBD.
O>>
O>>    Although the IAD will be a full-time ISOC employee, he will work
O>>    under the direction of the IAOC.  The IAD will be selected by a
O>>    committee of the IAOC, consisting minimally of the ISOC President
O>>    and the IETF Chair.  This same committee will be responsible for
O>>    periodically reviewing the performance of the IAD and determining
O>>    any changes to his employment and compensation.  In certain cases
O>>    (to be defined clearly -- chiefly cases where the ISOC employee
O>>    is determined to have contravened basic ISOC policies), the ISOC
O>>    President may make summary decisions, to be reviewed by the
O>>    hiring committee after the fact.
O>>
O>>    The IAD will be responsible for administering the IETF finances,
O>>    managing a separate bank account for the IASA, and establishing
O>>    and administering the IASA budget.  To perform these activities,
O>>    the IAD is expected to have signing authority comparable to other
O>>    ISOC director-level employees.  Generally, expenses or agreements
O>>    outside that authority to be approved for financial soundness as
O>>    determined by ISOC policy.  The joint expectation is that ISOC's
O>>    policies will be consistent with allowing the IAD to carry out
O>>    IASA work effectively and efficiently.  Should the IAOC have
O>>    concerns about that, the IAOC and ISOC commit to working out
O>>    other policies that are mutually agreeable.
O>>
O>>    The IAD will also fill the role of the IETF Executive Director,
O>>    as described in various IETF process BCPs.  All other
O>>    administrative functions will be outsourced via well-defined
O>>    contracts.  The IAD will be responsible for negotiating and
O>>    maintaining those contracts, as well as providing any
O>>    coordination that is necessary to make sure the IETF
O>>    administrative support functions are properly covered.
O>>
O>> 2.1.2  IAD Responsibilities
O>>
O>>    The day to day responsibilities of the IAD will focus on managing
O>>    contracts with the entities providing the work supporting the
O>>    IETF technical activity.
O>>

O>>    The IAD will provide regular (monthly and quarterly) reports to
O>>    the IAOC and ISOC.
O>>
O>>    All contracts will be negotiated by the IAD (with input from any
O>>    other appropriate bodies), and reviewed by the IAOC.  The
O>>    contracts will be executed by ISOC, on behalf of the IETF, after
O>>    whatever review ISOC requires (e.g., legal, Board of Trustees).
O>>
O>>    The IAD will prepare an annual budget, which will be reviewed and
O>>    approved by the IAOC.  The IAD will be responsible for presenting
O>>    this budget to the ISOC Board of Trustees, as part of ISOC's
O>>    annual financial planning process.  The partnering is such that
O>>    the IAOC is responsible for ensuring the suitability of the
O>>    budget for meeting the IETF community's needs, but it does not
O>>    bear fiduciary responsibility; the ISOC board needs to review and
O>>
O>>    understand the budget and planned activity in have enough detail
O>>    of the budget and proposed plans to properly carry out its
O>>    fiduciary responsibility.
O>>
O>> 2.1.3  IAOC Responsibilities
O>>
O>>    The role of the IAOC is to provide appropriate input to the IAD,
O>>    and oversight of the IASA functioning.  The IAOC is not expected
O>>    to be regularly engaged in IASA work, but rather to provide
O>>    appropriate approval and oversight.
O>>
O>>    Therefore, the IAOC's responsibilities are:
O>>
O>>    o  Select the IAD, as described above.
O>>
O>>    o  Review the IAD's financial reports, and provide approval of
O>>       the IAD's budget proposals in terms of fitness for IETF
O>>       purposes.
O>>
O>>    o  Review IASA functioning with respect to meeting the IETF
O>>       community's working needs.
O>>
O>>    The IAOC's role is to review, not carry out the work of,  the IAD
O>>    and IASA.  As such, it is expected the IAOC will have monthly
O>>    teleconferences and periodic face to face meetings, probably
O>>    coincident with IETF plenary meetings, consistent with ensuring
O>>    an efficient and effective operation.
O>>

O>> 2.1.4  IASA Funding
O>>
O>>    The IASA is supported financially in 3 ways:
O>>
O>>    1.  IETF meeting revenues.  The IAD, in consultation with the
O>>        IAOC, sets the meeting fees as part of the budgeting process.
O>>        All meeting revenues go to the IASA.
O>>
O>>    2.  Designated ISOC donations.  The IETF and IASA do no specific
O>>        fund raising activities; this maintains separation between
O>>        fundraising and standards activities.  Any organization
O>>        interested in supporting the IETF activity will continue to
O>>        be directed to ISOC, and any funds ISOC receives specifically
O>>        for IETF activities (as part of an ISOC program that allows
O>>        for specific designation) will be put in the IASA bank
O>>        account for IASA management.
O>>
O>>    3.  Other ISOC support.  ISOC will deposit in the IASA account,
O>>        each quarter, the funds committed to providing as part of the
O>>        IASA budget (where the meeting revenues and specific
O>>
O>>        donations do not cover the budget).  These funds may come
O>>        from member fees or from other revenue streams ISOC may
O>>        create.
O>>
O>>    Note that the goal is to achieve and maintain a viable IETF
O>>    support function based on meeting fees and specified donations,
O>>    and the IAOC and ISOC are expected to work together to attain
O>>    that goal.  (I.e., dropping the meeting fees to $0 and expecting
O>>    ISOC to pick up the slack is not desirable; nor is raising the
O>>    meeting fees to prohibitive levels to fund all non-meeting-
O>>    related activities!).
O>>
O>>    Also, in normal operating circumstances, the IASA would look to
O>>    have a 6 month operating reserve for its activities.  Rather than
O>>    having the IASA attempt to accrue that in its bank account, the
O>>    IASA looks to ISOC to build and provide that operational reserve
O>>    (through whatever mechanism instrument ISOC deems appropriate --
O>>    line of credit, financial reserves, etc).  Such reserves do not
O>>    appear instantaneously; the goal is to reach that level of
O>>    reserve by 3 years after the creation of the IASA.  It is not
O>>    expected that any funds associated with such reserve will be held
O>>    in the IASA bank account.
O>>

O>> 2.2  IAOC Membership, Selection and Accountability
O>>
O>>    Note:  This section is particularly subject to change as we work
O>>    to find the best way to achieve the key principles.  The key
O>>    principles being adhered to are that while this should be
O>>    reasonably separate from IETF Standards process management:
O>>
O>>    o  the IETF and IAB Chairs need to be involved to a level that
O>>       permits them to be involved in and oversee the aspects
O>>       pertinent to their roles in managing the technical work (e.g.,
O>>       the IAB looks after the RFC Editor relationship)
O>>
O>>    o  the IETF and IAB Chairs must not be critical path to getting
O>>       decisions to and through the IASA.
O>>
O>>    The current draft, below, therefore makes the IETF Chair ex
O>>    officio voting member of the IAOC, and the IAB Chair a non-voting
O>>    liaison. Future versions may change either or both, depending on
O>>    what makes sense to the IETF community in its deliberations.
O>>
O>>    The IAOC will consist of seven voting members who will be
O>>    selected as follows:
O>>
O>>    o  2 members chosen by the IETF Nominations Committee (NomCom)
O>>
O>>    o  1 member chosen by the IESG
O>>
O>>    o  1 member chosen by the IAB
O>>
O>>    o  1 member chosen by the ISOC Board of Trustees
O>>
O>>    o  The IETF Chair (ex officio)
O>>
O>>    o  The ISOC President/CEO (ex officio)
O>>
O>>    There will also be two non-voting, ex officio liaisons:
O>>
O>>    o  The IAB Chair
O>>
O>>    o  The IETF Administrative Director
O>>
O>>    The voting members of the IAOC will choose their own chair each
O>>    year using a consensus mechanism of its choosing.  Any appointed
O>>    voting member of the IAOC may serve as the IAOC Chair (i.e., not
O>>    the IETF Chair or the ISOC President/CEO).  The role of the IAOC
O>>    Chair is to organize the IAOC.  The IAOC Chair has no formal
O>>    duties for representing the IAOC, except as directed by IAOC
O>>    consensus.

O>>
O>>    The members of the IAOC will typically serve two year terms.
O>>    Initially, the IESG and ISOC Board will make one-year
O>>    appointments, the IAB will make a two-year appointment, and the
O>>    Nomcom will make one one-year appointment and one two-year
O>>    appointment to establish a pattern where approximately half of
O>>    the IAOC is selected each term.
O>>
O>>    The two NomCom selected members will be selected using the
O>>    procedures described in RFC 3777.  For the initial selection, the
O>>    IESG will provide the list of desired qualifications for these
O>>    positions.  In later years, this list will be provided by the
O>>    IAOC.
O>>
O>>    While there are no hard rules regarding how the IAB and the IESG
O>>    should select members of the IAOC, it is not expected that they
O>>    will typically choose current IAB or IESG members, if only to
O>>    avoid overloading existing leadership.  However, they should
O>>    choose people who are familiar with the administrative support
O>>    needs of the IAB, the IESG and/or the IETF standards process.  It
O>>    is suggested that a fairly open process be followed for these
O>>    selections, perhaps with an open call for nominations and/or a
O>>    period of public comment on the candidates.  The IAB and IESG are
O>>    encouraged to look at the procedure for IAB selection of ISOC
O>>    Trustees for an example of how this might work.
O>>
O>>    Although the IAB and IESG will choose some members of the IAOC,
O>>    those members will not directly represent the bodies that chose
O>>    them.  All members of the IAOC are accountable directly to the
O>>    IETF community. To receive direct feedback from the community,
O>>    the IAOC will hold an open meeting at least once per year at an
O>>    IETF meeting.  This may take the form of an open IAOC plenary or
O>>    a working meeting held during an IETF meeting slot.  The form and
O>>    contents of this meeting are left to the discretion of the IAOC
O>>    Chair.
O>>
O>>    Decisions of IAOC members or the entire IAOC are subject to
O>>    appeal using the procedures described in RFC 2026.  The initial
O>>    appeal of an individual decision will go to the full IAOC.
O>>    Appeals of IAOC decisions will go to the IESG and continue up the
O>>    chain as necessary (to the IAB and the ISOC Board).  The IAOC
O>>    will play no role (aside from possible administrative support) in
O>>    appeals of WG Chair, IESG or IAB decisions.
O>>

O>>    In the event that an IAOC member abrogates his duties or acts
O>>    against the bests interests of the IETF community, IAOC members
O>>    are subject to recall using the recall procedure defined in RFC
O>>    3777.  IAB and IESG-appointed members of the IAOC are not subject
O>>    to recall by their appointing bodies.
O>>
O>> 2.3  IASA Budget Process
O>>
O>>    While the IASA sets a budget for the IETF's administrative needs,
O>>    its budget process clearly needs to be closely coordinated with
O>>    ISOC's. The specific timeline will be established each year,
O>>    before the second IETF meeting.  A general annual timeline for
O>>    budgeting will be:
O>>
O>>    July 1 The IAD presents a budget proposal (for the following
O>>       fiscal year, with 3 year projections) to the IAOC.
O>>
O>>    August 1 The IAOC approves the budget proposal for IETF purposes,
O>>       after any appropriate revisions.  As the ISOC President is
O>>       part of the IAOC, the IAOC should have a preliminary
O>>       indication of how the budget will fit with ISOC's own
O>>       budgetary expectations.  The budget proposal is passed to the
O>>       ISOC Board of Trustees for review in accordance with their
O>>       fiduciary duty.
O>>
O>>    September 1 The ISOC Board of Trustees approves the budget
O>>       proposal provisionally.  During the next 2 months, the budget
O>>       may be revised to be integrated in ISOC's overall budgeting
O>>       process.
O>>
O>>
O>>    November 1 Final budget to the ISOC Board for approval.
O>>
O>>    The IAD will provide monthly accountings of expenses, and will
O>>    update forecasts of expenditures quarterly.  This may necessitate
O>>    the adjustment of the IASA budget.  The revised budget will need
O>>    to be approved by the IAOC and ISOC Board of Trustees.
O>>
O>> 2.4  Relationship of the IAOC to Existing IETF Leadership
O>>
O>>    The IAOC will be directly accountable to the IETF Community.
O>>    However, the nature of the IAOC's work will involve treating the
O>>    IESG and IAB as internal customers.  The IAOC should not consider
O>>    its work successful unless the IESG and IAB are satisfied with
O>>    the administrative support that they are receiving.
O>>

O>> 2.5  ISOC Responsibilities for IASA
O>>
O>>    Within ISOC, support for the IASA should be structured to meet
O>>    the following goals:
O>>
O>>    Transparency: The IETF community should have complete visibility
O>>       into the financial and legal structure of the ISOC standards
O>>       activity. In particular, the IETF community should have access
O>>       to a detailed budget for the entire standards activity,
O>>       quarterly financial reports and audited annual financials.  In
O>>       addition, key contract material and MOUs should be publicly
O>>       available.  Most of these goals are already met by ISOC today.
O>>       The IAOC will be responsible for providing the IETF community
O>>       with regular overviews of the state of affairs.
O>>
O>>    Unification: As part of this arrangement, ISOC's sponsorship of
O>>       the RFC Editor, IAB and IESG, as well as insurance coverage
O>>       for the IETF will be managed as part of the IASA under the
O>>       IAOC.
O>>
O>>    Independence: The IASA should be financially and legally distinct
O>>       from other ISOC activities.  IETF meeting fees should be
O>>       deposited in a separate IETF-specific bank account and used to
O>>       fund the IASA under the direction and oversight of the IAOC.
O>>       Any fees or payments collected from IETF meeting sponsors
O>>       should also be deposited into this account.  This account will
O>>       be administered by the IAD and used to fund the IASA in
O>>       accordance with a budget and policies that are developed as
O>>       described above.
O>>
O>>    Support: ISOC may, from time to time, choose to transfer other
O>>       funds into this account to fund IETF administrative projects
O>>       or to cover IETF meeting revenue shortfalls.  There may also
O>>
O>>       be cases where ISOC chooses to loan money to the IASA to help
O>>       with temporary cash flow issues.  These cases should be
O>>       carefully documented and tracked on both sides.  ISOC will
O>>       work to provide the 6 month operational reserve for IASA
O>>       functioning described above.
O>>
O>>    Removability: While there is no current plan to transfer the
O>>       legal and financial home of the IASA to another corporation,
O>>       the IASA should be structured to enable a clean transition in
O>>       the event that the IETF community decides, through BCP
O>>       publication, that such a transition is required.  In that
O>>       case, the IAOC will give ISOC a minimum six months notice
O>>       before the transition formally occurs.  During that period,
O>>       the IAOC and ISOC will work together to create a smooth

O>>       transition that does not result in any significant service
O>>       outages or missed IETF meetings.  All contracts that are
O>>       executed by ISOC as part of the IASA should either include a
O>>       clause allowing termination or transfer by ISOC with six
O>>       months notice, or should be transferrable to another
O>>       corporation in the event that the IASA is transitioned away
O>>       from ISOC in the future.  Any accrued funds, and IETF-specific
O>>       intellectual property rights (concerning administrative data
O>>       and/ or tools) would also be expected to be transitioned to
O>>       any new entity, as well.
O>>
O>>    Within the constraints outlined above, all other details of how
O>>    to structure this activity within ISOC (as a cost center, a
O>>    department or a formal subsidiary) should be determined by ISOC
O>>    in consultation with the IAOC.
O>>
O>> 3.  Workplan for Formalizing the IETF Administrative Support
O>> Activity
O>>
O>>    This section proposes a workplan and schedule for formalizing the
O>>    IETF administrative support activity (IASA) for the remainder of
O>>    2004 and 2005.
O>>
O>> 3.1  Workplan Goals
O>>
O>>    This workplan is intended to satisfy four goals:
O>>
O>>    o  Satisfy the IETF's need for support functions through 2005,
O>>       with a careful transition that minimizes the risk of
O>>       substantial disruption to the IETF standards process.
O>>
O>>    o  Establish IETF community consensus and ISOC approval of a BCP
O>>       formalizing the IASA as described in this scenario before any
O>>       actions are taken that will have long term effects (hiring,
O>>
O>>       contacts, etc.)
O>>
O>>    o  Make sure that decisions with long term impact, such as hiring
O>>       the IAD and establishing contracts for administrative support,
O>>       are made by people chosen for that purpose who will be
O>>       responsible to the community for the effectiveness of this
O>>       effort (the IAD and members of the IAOC) -- not by our already
O>>       overloaded technical leadership.
O>>
O>>    o  Within the above constraints, move as quickly as possible
O>>       towards a well-defined administrative support structure that
O>>       is transparent and accountable to the IETF community.
O>>

O>> 3.2  Workplan Overview
O>>
O>>    There are three major elements to this workplan which can, to
O>>    some degree, take place in parallel after we establish IETF
O>>    community consensus to pursue Scenario O:
O>>
O>>    o  Finalizing the BCP text and getting it approved by the IETF
O>>       community and ISOC.
O>>
O>>    o  Selecting IASA leadership.  This includes appointing an
O>>       interim IAOC, recruiting the IAD, and eventually appointing
O>>       the full IAOC.
O>>
O>>    o  Negotiating agreements with service providers.  This includes
O>>       determining the structure and work flow of the IASA, deciding
O>>       which portions of the IASA should be staffed via an open
O>>       request for proposals (RFP) process, and issuing a RFP for
O>>       those portions, as well as establishing sole source contracts
O>>       or MOUs for other portions of the IASA.
O>>
O>>    Each of the three items listed above is described in more detail
O>>    in the following sections.
O>>
O>> 3.3  Approval by the IETF Community and ISOC
O>>
O>>    In scenario O, the IASA is formalized in a BCP that is approved
O>>    by the IETF community and accepted by the ISOC Board of Trustees.
O>>    There are three steps in this process:
O>>
O>>    1.  Establishment of IETF community consensus that we should
O>>        pursue Scenario O as defined in a joint IAB/IESG
O>>        recommendation based on this proposal.  This consensus will
O>>        be established through community discussion and a formal two-
O>>        week consensus call issued by the IETF chair on the IETF
O>>        mailing list.
O>>
O>>    2.  Establishment of IETF community consensus on a BCP that
O>>        formalizes the IASA as described.  This consensus would be
O>>        established through public discussion, a four week IETF Last
O>>        Call and IESG review and approval.
O>>
O>>    3.  ISOC approval of the BCP and acceptance of ISOC's
O>>        responsibilities as described therein.  This approval and
O>>        acceptance would be signified by an ISOC Board resolution.
O>>
O>>    The timeline for these three stages is rather long, but there is
O>>    significant progress that can be made in other areas once we have
O>>    established IETF community consensus to pursue this scenario.

O>>
O>> 3.4  Selecting IASA Leadership
O>>
O>>    Once we have IETF consensus to pursue this scenario, we can
O>>    appoint an interim IAOC to begin working on the IASA transition.
O>>    The interim IAOC could do substantial work on non-binding tasks,
O>>    such as beginning the recruitment process for an IAD, determining
O>>    the structure of the IASA work, issuing RFPs and negotiating
O>>    potential agreements with service providers.  The interim IAOC
O>>    would not be empowered to make binding agreements, but could work
O>>    appropriate consultants and advisors to make a lot of progress
O>>    towards determining the initial structure and work flow of the
O>>    IASA.
O>>
O>>    Because the IETF Nominations Commitee (NomCom) process for new
O>>    positions will consume a lot of resources and take a long time to
O>>    complete, we propose that the interim IAOC consist of:
O>>
O>>    o  1 IESG selected member
O>>
O>>    o  1 IAB selected member
O>>
O>>    o  1 ISOC selected member
O>>
O>>    o  The IETF Chair
O>>
O>>    o  The ISOC President/CEO
O>>
O>>    The IAB chair will serve as a liaison, as described above.
O>>
O>>    The IESG and ISOC Board appointments will be expected to serve
O>>    until the first IETF meeting of 2006, and the IAB appointment
O>>    will be expected to serve until the first IETF meeting of 2007,
O>>    assuming that the BCP is approved and the IAOC continues to have
O>>    appointed members from these bodies.
O>>
O>>
O>>    After all of the interim IAOC members are selected, they will
O>>    choose an interim IAOC chair from among the appointed members.
O>>
O>>    When the BCP is approved, if the BCP indicates that there will be
O>>    NomCom selected IAOC members they will be chosen at that time.
O>>    Any adjustments to appointed members based on the BCP contents
O>>    will also be made at that time.  The IAOC will transition from
O>>    interim to non-interim status when all non-interim members are
O>>    seated.  A new, non-interim chair selection process will then
O>>    commence.
O>>

O>> 3.5  Recruiting the IETF Administrative Director
O>>
O>>    The interim IAOC should appoint an IAD selection committee to
O>>    recruit and select the IETF Administrative Director.  This
O>>    committee will consist entirely of IAOC members or liaisons, and
O>>    will, at minimum, include the IETF chair and the ISOC President.
O>>    If the IAOC chooses, this committee could include the entire
O>>    IAOC.
O>>
O>>    The IAD selection committee should determine a job description
O>>    for the IAD, in consultation with other IETF leaders and the IETF
O>>    community.  Once the job description is established, the IAD
O>>    selection committee should recruiting candidates for the
O>>    position.
O>>
O>>    Although the interim IAOC is not empowered to hire the IAD as a
O>>    full-time employee, it might be possible for the IAOC to ask ISOC
O>>    to engage the potential IAD as a consultant to help with other
O>>    tasks during the interim period.
O>>
O>> 3.6  Establishing Agreement with Service Providers
O>>
O>>    The most important activity of the IAOC during late 2004 and
O>>    early 2005 will be to determine the structure and work flow of
O>>    the IASA and to establish contracts or other agreements with
O>>    service providers to do the required work.  This work includes
O>>    the following functions as defined in the consultant's report:
O>>
O>>    o  Technical infrastructure
O>>
O>>    o  Meeting management
O>>
O>>    o  Clerk's office
O>>
O>>    o  RFC Editor services to support  IETF standards publication
O>>
O>>    o  IANA services to support IETF standards publication
O>>
O>>    The interim IAOC should work with IETF leaders and other
O>>    knowledgeable members of the community to determine the structure
O>>    and work flow required for the IASA activity and make
O>>    corresponding adjustments to the above list, if necessary.  The
O>>    interim IAOC can also identify which areas of IASA work should
O>>    continue to be provided by existing IETF service providers, and
O>>    work with those providers to establish proposed contracts or
O>>    agreements for later approval by the non-interim IAOC.  The IAOC
O>>    can also choose to start an RFP process for any services that
O>>    they believe should be filled through an open RFP process.

O>>
O>> 3.7  Establishing a 2005 Operating Budget
O>>
O>>    Because the ISOC 2005 budgeting process will be finalized before
O>>    the non-interim IAOC is seated, the interim IAOC should work with
O>>    the ISOC staff and President to establish a proposed 2005
O>>    operating budget for the IASA.  Since this will happen in advance
O>>    of full knowledge regarding the costs of 2005 operations, it may
O>>    be subject to significant adjustment later.
O>>
O>> 3.8  Proposed Schedule for IASA Transition
O>>
O>>    As described above, the three stages of the IETF community and
O>>    ISOC approval process will take some time.  If the community
O>>    chooses scenario O and we reach quick consensus on the details,
O>>    an optimistic schedule for this approval would be:
O>>
O>>    1.  IETF discussion of this proposal and other scenarios through
O>>         1-Oct-2005.  IAB/IESG discusses this proposal with ISOC
O>>         Board.
O>>
O>>    2.  IAB/IESG joint recommendation issued on 8-Oct-04, including
O>>         full BCP proposal.
O>>
O>>    3.  Community discussion of the joint IAB/IESG recommendation
O>>         through 22-Oct-04.
O>>
O>>    4.  Two-week community consensus call issued on the IETF list on
O>>         23-Oct-04 regarding rough community consensus to pursue this
O>>         direction and appoint an interim IAOC -- extends through
O>>         IETF 61.  IAOC selecting bodies begin search, based on
O>>         expected community consensus.
O>>
O>>    5.  Rough community consensus declared on 8-Nov-04 to pursue
O>>         Scenario O and appoint the interim IAOC.
O>>
O>>    6.  Interim IAOC seated on 15-Nov-04.  Interim IAOC begins
O>>         interim work outlined above, including establishment of
O>>
O>>         estimated 2005 budget and IAD recruitment.
O>>
O>>    7.  BCP text  discussed by community, IETF leadership and ISOC
O>>         Board until we have something that represents rough
O>>         community consensus that is acceptable to all.  We hope that
O>>         this could be completed by 6-Dec-04.
O>>
O>>    8.  Four week IETF Last Call issued for BCP on 6-Dec-04 --
O>>         extends through 3-Jan-04.

O>>
O>>    9.  Simultaneous IESG and ISOC Board approvals by 17-Jan-04.
O>>
O>>    10.  IAD officially hired in Jan 2005.
O>>
O>>    11.  NomCom seats IAOC members at the first IETF of 2005, moving
O>>         the IAOC from interim to non-interim status.
O>>
O>>    12.  Formal agreements with all service providers in-place by
O>>         June 2005.
O>>
O>> 4.  Security Considerations
O>>
O>>    This document describes a scenario for the structure of the
O>>    IETF's administrative support activities.  It introduces no
O>>    security considerations for the Internet.
O>>
O>> 5.  IANA Considerations
O>>
O>>    This document has no IANA considerations in the traditional
O>>    sense. As part of the extended IETF family, though, IANA may be
O>>    interested in the contents.
O>>
O>> 6.  Acknowledgements
O>>
O>>    Most of the ideas in this document are not new, and many of them
O>>    did not originate with the authors.  This scenario represents a
O>>    combination of ideas discussed within the IAB, the IESG and the
O>>    IETF Community.
O>>
O>>    This document was written using the xml2rfc tool described in RFC
O>>    2629 [RFC2629].
O>>
O>> 7.  References
O>>
O>> 7.1  Normative References
O>>
O>>    [I-D.malamud-consultant-report] Malamud, C., "IETF Administrative
O>>               Support Functions", draft-malamud-consultant-report-01
O>>
O>>               (work in progress), September 2004.
O>>
O>>    [RFC2026]  Bradner, S., "The Internet Standards Process --
O>>               Revision 3", BCP 9, RFC 2026, October 1996.
O>>
O>>    [RFC3716]  Advisory, IAB., "The IETF in the Large: Administration
O>>               and Execution", RFC 3716, March 2004.
O>>

O>> 7.2  Informative References
O>>
O>>    [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
O>>               June 1999.
O>>
O>>    [RFC3667]  Bradner, S., "IETF Rights in Contributions", BCP 78,
O>>               RFC 3667, February 2004.
O>>
O>>    [RFC3668]  Bradner, S., "Intellectual Property Rights in IETF
O>>               Technology", BCP 79, RFC 3668, February 2004.
O>>
O>> Authors' Addresses
O>>
O>>    Leslie Daigle
O>>    VeriSign
O>>    EMail: leslie at verisignlabs.com, leslie at thinkingcat.com
O>>
O>>    Margaret Wasserman
O>>    ThingMagic
O>>    One Broadway, 14th Floor
O>>    Cambridge, MA 02142 USA
O>>
O>>    Phone: +1 617 758-4177
O>>    EMail: margaret at thingmagic.com
O>>    URI: http://www.thingmagic.com

Informative References

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

   [2]  Malamud, C., "IETF Administrative Support Functions",
        Work in Progress, September 2004.

   [3]  <http://www.ietf.org/mail-archive/web/ietf/current/
        msg31321.html>

   [4]  <http://www.ietf.org/mail-archive/web/ietf/current/
        msg31326.html>

   [5]  <http://www.ietf.org/mail-archive/web/ietf/current/
        msg31493.html>

   [6]  <http://www.ietf.org/mail-archive/web/ietf/current/
        msg31609.html>

Author's Address

   Scott Hollenbeck, Editor
   IAB and IESG

   EMail: sah@428cobrajet.net

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.