TOC 
Current AdminRest Plan DocumentL. Daigle
 November 29, 2004

Proposed Transition Plan for IETF Administrative Restructuring

Abstract

This document outlines the 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 see http://www.alvestrand.no/ietf/adminrest/ .

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.

This version has NOT been published as an Internet-Draft.



Table of Contents

1.  Introduction
2.  Transition Plan Goals
3.  Transition Plan Overview
    3.1  Approval by the IETF Community and ISOC
    3.2  Selecting the IASA Transition Team
        3.2.1  IASA Transition Team Lifespan
        3.2.2  Recruiting the IETF Administrative Director
    3.3  Establishing Agreement with Service Providers
4.  Establishing a 2005 Operating Budget
5.  Proposed Schedule for IASA Transition
6.  References
§  Author's Address




 TOC 

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

This transition plan was originally put forth as a "straw proposal". 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.



 TOC 

2. Transition Plan Goals

This transition plan is intended to satisfy four goals:



 TOC 

3. Transition Plan Overview

There are four major elements to this transition plan which can, to some degree, take place in parallel now that we have established 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. DONE -- 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. DONE -- 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 was established through community discussion and a formal two-week consensus call issued by the IETF chair on the IETF mailing list. Consensus was declared on November 10, 2004.
  2. Establishment of IETF community consensus on a BCP that formalizes the IASA as described. This consensus will be established through public discussion, a four week IETF Last Call and IESG review and approval. A draft 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.

3.2 Selecting the IASA Transition Team

We have appointed an IASA transition team to begin working on the groundwork for the IASA. The transition team will 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 is not empowered to make binding agreements, but will 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, the transition team has been established to consist of:

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

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:

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.



 TOC 

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.



 TOC 

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 Board.
  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. DONE -- 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 consensus.
  5. DONE -- Rough community consensus declared on 8-Nov-04 to pursue Scenario O (IASA) and appoint the transition team.
  6. DONE -- IASA transition team constituted on 15-Nov-04.
  7. 24-Nov-04 Transition team begins interim work outlined above, including establishment of estimated 2005 budget and IAD recruitment.
  8. 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 01-Dec-04.
  9. Four week IETF Last Call issued for BCP on 01-Dec-04 -- extends through 28-Dec-04.
  10. Simultaneous IESG and ISOC Board approvals by 06-Jan-04.
  11. Initial IAOC selection processes started upon approval of BCP.
  12. Initial board selected and seated within 45 days of approval of the BCP.
  13. Transition team is disbanded; all subsequent work carried out by the IAOC.
  14. IAD hired in late-Jan/early-Feb-05.
  15. Formal agreements with all service providers in-place by Jun-05.


 TOC 

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.


 TOC 

Author's Address

  Leslie Daigle
EMail:  leslie@verisignlabs.com, leslie@thinkingcat.com