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

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

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

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

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

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

Is this strong enough? We could say that the IASA "has no influence..."?
> 
> 2.1.1  Structure of the IASA
> 
>    The IASA will be structured to allow accountability to the IETF
>    community.  It will determine the ongoing success of the activity in
>    meeting IETF community needs laid out in this BCP, as well as ISOC
>    oversight of its financial and resource contributions.  The
>    supervisory body defined for this will be called the IETF
>    Administrative Oversight Committee (IAOC).  The IAOC will consist of
>    volunteers, all chosen directly or indirectly by the IETF community,
>    as well as appropriate ex officio appointments from ISOC and IETF
>    leadership.  The IAOC will be accountable to the IETF community for
>    the effectiveness, efficiency and transparency of the IASA.
> 
>    The IASA will initially consist of a single full-time employee of
>    ISOC, the IETF Administrative Director (IAD).  The IAD will require a

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

>    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

she?

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

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.

> 
>    The IAD will be responsible for administering the IETF finances,
>    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.

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

> 
>    The IAD will also fill the role of the IETF Executive Director, as
>    described in various IETF process BCPs.  

unless explicitly delegated with consent of the IAOC?

>    ...All other administrative
>    functions will be outsourced via well-defined contracts.  The IAD

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"?

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

Published?
> 
>    All contracts will be negotiated by the IAD (with input from any
>    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
>    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. 

And published?

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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.

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

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

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.

...

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

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?

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

    Brian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf