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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Following up on my note from this morning...

Leslie Daigle wrote:
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.

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: leslie@xxxxxxxxxxxxxxxx, leslie@xxxxxxxxxxxxxxx


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

   Phone: +1 617 758-4177
   EMail: margaret@xxxxxxxxxxxxxx
   URI:   http://www.thingmagic.com





Daigle & Wasserman                                             [Page 17]



--

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

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]