Internet DRAFT - draft-wasserman-adminrest-plan


Network Working Group                                       M. Wasserman
Internet-Draft                                                ThingMagic
Expires: April 25, 2005                                        L. Daigle
                                                        October 25, 2004

     Proposed Transition Plan for IETF Administrative Restructuring

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   This document proposes a transition plan and schedule for the
   administrative restructuring effort currently underway in the IETF.

Status and Evolution -- YOU MUST READ THIS SECTION

   This plan has become a living document that will be updated from
   time-to-time to as needed to reflect events and any changes in
   requirements.  To see the most recent version of the plan, you must

Wasserman & Daigle       Expires April 25, 2005                 [Page 1]
Internet-Draft         AdminRest Transition Plan            October 2004

   see .

   Subsequent versions of the plan will be published as Internet-Drafts
   only if, as, and when circumstances require it.  It is not expected
   that any version of this document will be published as an RFC.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Transition Plan Goals  . . . . . . . . . . . . . . . . . . . .  3
   3.  Transition Plan Overview . . . . . . . . . . . . . . . . . . .  3
     3.1   Approval by the IETF Community and ISOC  . . . . . . . . .  4
     3.2   Selecting the IASA Transition Team . . . . . . . . . . . .  5
       3.2.1   IASA Transition Team Lifespan  . . . . . . . . . . . .  5
       3.2.2   Recruiting the IETF Administrative Director  . . . . .  5
     3.3   Establishing Agreement with Service Providers  . . . . . .  6
   4.  Establishing a 2005 Operating Budget . . . . . . . . . . . . .  7
   5.  Proposed Schedule for IASA Transition  . . . . . . . . . . . .  7
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  8
   A.  Significant changes from -00 to -01  . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . 10

Wasserman & Daigle       Expires April 25, 2005                 [Page 2]
Internet-Draft         AdminRest Transition Plan            October 2004

1.  Introduction

   This document proposes a work plan and schedule for formalizing the
   IETF Administrative Support Activity (IASA) as described in the
   proposed BCP (draft-wasserman-iasa-bcp).  The IASA BCP is based on
   the original "Scenario O" proposal that was sent to the IETF list as
   an e-mail message.  The original message can be found at:

   This transition plan was originally put forth as a "straw proposal"
   in the e-mail message cited above.  While the BCP will be edited,
   reviewed, approved and published for the purpose of defining an
   ongoing relationship, this plan/timeline is useful only during the
   transition phase, and will be adjusted from time to time as decisions
   are made and implementation begins.  Therefore, it made sense to move
   the plan description to a separately maintained document.

2.  Transition Plan Goals

   This transition plan is intended to satisfy four goals:

   o  Satisfy the IETF's need for support functions through 2005 and
      beyond, 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.

   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.

   Community feedback is requested on the appropriateness of these goals
   and whether or not they are likely to be met by following the plan
   described below.

3.  Transition Plan Overview

   There are four major elements to this transition plan which can, to
   some degree, take place in parallel only after we establish IETF

Wasserman & Daigle       Expires April 25, 2005                 [Page 3]
Internet-Draft         AdminRest Transition Plan            October 2004

   community consensus to pursue an administrative structure similar to
   that described in the IASA BCP proposal:

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

   2.  Selecting an IASA transition team, to work on the transition to
       the IASA/IAOC structure as soon as is practically possible.

   3.  Selecting IASA leadership.  This includes appointing the IAOC,
       and recruiting and hiring the IAD.

   4.  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.  It may also include 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.

3.1  Approval by the IETF Community and ISOC

   The IASA will be formalized in an IASA  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
       the IASA approach, as discussed in a joint IAB/IESG
       recommendation that was also published simultaneously with 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.  A -00 version of this BCP is
       available now (see above).

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

Wasserman & Daigle       Expires April 25, 2005                 [Page 4]
Internet-Draft         AdminRest Transition Plan            October 2004

3.2  Selecting the IASA Transition Team

   Once we have IETF consensus to pursue the basic proposal, we can
   appoint an IASA transition team to begin working on the groundwork
   for the IASA.  The transition team 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
   transition team would not be empowered to make binding agreements,
   but could work with appropriate consultants and advisors to make a
   lot of progress towards determining the initial structure and work
   flow of the IASA.

   As this work needs to be done reasonably quickly, and because the
   IASA transition team is specifically not expected to be a first IAOC,
   we propose that the transition team consist of:

   o  1 IESG selected member

   o  1 IAB selected member

   o  1 ISOC selected member

   o  The IETF Chair

   o  The IAB Chair

   o  The ISOC President/CEO

   The team is expected to operate in a consensus-based fashion.

   Additionally, the team may identify and work with other advisors and
   consultants as necessary.

3.2.1  IASA Transition Team Lifespan

   The BCP will define the process for appointing IAOC board members,
   including the process to seat the initial board (as quickly as is
   reasonable; this plan assumes that an acceptable process will be
   defined that allows an initial IAOC, or at least a provisional IAOC
   with decision-making authority,  to be seated within 45 days of the
   approval of the IASA BCP).  As soon as the initial IAOC is seated,
   the transition team will be disbanded.

3.2.2  Recruiting the IETF Administrative Director

   The IASA transition team will appoint an IAD selection committee to
   recruit and select the IETF Administrative Director.  This committee

Wasserman & Daigle       Expires April 25, 2005                 [Page 5]
Internet-Draft         AdminRest Transition Plan            October 2004

   will consist entirely of transition team members or advisors, and
   will, at minimum, include the IETF Chair and the ISOC President.  If
   the transition team chooses, this committee could include the entire
   transition team.

   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 start recruiting candidates for the

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

3.3  Establishing Agreement with Service Providers

   The most important activity of the transition team 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

   o  Meeting management

   o  Clerk's office

   o  Internet-Drafts administration

   o  RFC Editor services to support IETF standards publication

   o  IANA services to support IETF standards publication

   The transition team 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 transition team 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
   established IAOC.  The transition team can also choose to start an
   RFP process for any services that they believe should be filled
   through an open RFP process.

Wasserman & Daigle       Expires April 25, 2005                 [Page 6]
Internet-Draft         AdminRest Transition Plan            October 2004

4.  Establishing a 2005 Operating Budget

   Because the ISOC 2005 budgeting process will be finalized before the
   final BCP approval, the transition team should work with the ISOC
   staff and President/CEO 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.

5.  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 to
   pursue the IASA approach and we reach quick consensus on the details,
   a highly optimistic schedule for this approval would be:

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

   2.  DONE -- IAB/IESG joint recommendation and the -00 version of a
        proposed BCP both issued on 18-Oct-04.

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

   4.  Two week community consensus call issued on the IETF list on
        25-Oct-04 (through 8-Nov-04) regarding rough community consensus
        to pursue this direction and appoint an IASA transition team.
        IAOC selecting bodies may begin a search for potential
        transition team members in parallel, based on expected community

   5.  Rough community consensus declared on 8-Nov-04 to pursue Scenario
        O (IASA) and appoint the transition team.

   6.  IASA transition team constituted on 15-Nov-04.  Transition team
        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 15-Nov-04.

   8.  Four week IETF Last Call issued for BCP on 15-Nov-04 -- extends
        through 13-Dec-04.

Wasserman & Daigle       Expires April 25, 2005                 [Page 7]
Internet-Draft         AdminRest Transition Plan            October 2004

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

   10.  Initial IAOC selection processes started upon approval of BCP.

   11.  Initial board selected and seated within 45 days of approval of
        the BCP.

   12.  Transition team is disbanded; all subsequent work carried out by
        the IAOC.

   13.  IAD hired in late-Jan/early-Feb-05.

   14.  Formal agreements with all service providers in-place by Jun-05.

6  References

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

   [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

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

   Phone: +1 617 758-4177

   Leslie Daigle
   21355 Ridgetop Circle
   Dulles, VA  20176


Wasserman & Daigle       Expires April 25, 2005                 [Page 8]
Internet-Draft         AdminRest Transition Plan            October 2004

Appendix A.  Significant changes from -00 to -01

   The primary changes to the document from the -00 version to the -01
   version are:

   o  Changed from "interim IAOC" to "IASA transition team".  The group
      is expected to undertake (at least in a preliminary fashion) some
      work items that will be in the work of the IAOC, and others that
      will ultimately be tasked to the IAD.  I.e., its activities span a
      broader range than the IAOC will ultimately be responsible for.

   o  The composition of the transition team is modified from the
      interim IAOC proposal -- the IAB Chair is a full member.

   o  Since the transition team is not an interim IAOC, there is now an
      additional step in the process to constitute the first IAOC.

Wasserman & Daigle       Expires April 25, 2005                 [Page 9]
Internet-Draft         AdminRest Transition Plan            October 2004

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


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

Wasserman & Daigle       Expires April 25, 2005                [Page 10]