Network Working Group M. Wasserman Internet-Draft ThingMagic Expires: April 17, 2005 L. Daigle VeriSign October 17, 2004 Proposed Transition Plan for IETF Administrative Restructuring draft-wasserman-adminrest-plan-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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. 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document proposes a transition plan and schedule for the administrative restructuring effort currently underway in the IETF. This transition plan was originally put forth in an e-mail message, but has been moved to an Internet-Draft because that seems to be the simplest way to produce a well-formatted, version-controlled document that is accessible to everyone in the IETF community. Wasserman & Daigle Expires April 17, 2005 [Page 1] Internet-Draft AdminRest Transition Plan October 2004 If the IETF community reaches consensus to pursue some version of this plan, this plan will become a living document that will be updated from time-to-time to reflect community feedback and/or to track the actual progress of our administrative restructuring efforts. 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 . . . . . . . . . . . . . . . . . . . 4 3.1 Approval by the IETF Community and ISOC . . . . . . . . . 4 3.2 Selecting IASA Leadership . . . . . . . . . . . . . . . . 5 3.2.1 Seating the Interim IAOC . . . . . . . . . . . . . . . 5 3.2.2 Recruiting the IETF Administrative Director . . . . . 6 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 Intellectual Property and Copyright Statements . . . . . . . . 10 Wasserman & Daigle Expires April 17, 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 a proposed BCP (draft-wasserman-iasa-bcp-00.txt) that will be submitted for publication along with this document. The 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: http://www1.ietf.org/mail-archive/web/ietf/current/msg31326.html This transition plan was originally put forth as part of the e-mail message cited above, but has been moved to an Internet-Draft because that seems to be the simplest way to produce a well-formatted, version-controlled document that is accessible to everyone in the IETF community. If the IETF community reaches consensus to pursue some version of this plan, this plan will become a living document that will be updated from time-to-time to reflect community feedback and/or to track the actual progress of our administrative restructuring efforts. It is not expected that any version of this document will be published as an RFC. 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 (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. Wasserman & Daigle Expires April 17, 2005 [Page 3] Internet-Draft AdminRest Transition Plan October 2004 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 three major elements to this transition plan which can, to some degree, take place in parallel only after we establish IETF community consensus to pursue an administrative structure similar to that described in the "Scenario O"-based BCP proposal: o Finalizing the BCP text and getting it approved by the IETF community and ISOC. o Selecting IASA leadership. This includes appointing the IAOC, and recruiting and hiring the IAD. 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. 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 a "Scenario O"-based 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 a "Scenario O"-based 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 Wasserman & Daigle Expires April 17, 2005 [Page 4] Internet-Draft AdminRest Transition Plan October 2004 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 IASA Leadership Once we have IETF consensus to pursue the basic proposal, 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 with appropriate consultants and advisors to make a lot of progress towards determining the initial structure and work flow of the IASA. 3.2.1 Seating the Interim IAOC Because the IETF Nominations Committee (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 o The ISOC President/CEO The IAB chair will serve as a non-voting liaison, as described in the BCP. If the interim IAOC chooses to do so, they may appoint an interim IAOC chair from among the appointed members to serve until the full IAOC is seated. The IESG and ISOC Board appointees 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. The IAOC will shift from interim to non-interim status when the BCP Wasserman & Daigle Expires April 17, 2005 [Page 5] Internet-Draft AdminRest Transition Plan October 2004 is formally approved by the IETF and ISOC. When the BCP is approved, if the BCP indicates that there will be NomCom-selected IAOC members the NomCom selection process will begin at that time. Any adjustments to appointed members based on the BCP contents will also be made at that time. After all members are seated, the IAOC will choose a chair, as described in the BCP. 3.2.2 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 interim 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 start 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.3 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 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 interim IAOC should work with IETF leaders and other Wasserman & Daigle Expires April 17, 2005 [Page 6] Internet-Draft AdminRest Transition Plan October 2004 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. 4. Establishing a 2005 Operating Budget Because the ISOC 2005 budgeting process will be finalized before the final BCP approval, the interim IAOC 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 a "Scenario O"-based approach and we reach quick consensus on the details, a highly optimistic schedule for this approval would be: 1. IETF discussion of this proposal and other scenarios through 17-Oct-2005. IAB/IESG discusses this proposal with ISOC Board. 2. IAB/IESG joint recommendation and the -00 version of a proposed BCP both issued on 18-Oct-04. 3. 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 interim IAOC. IAOC selecting bodies will begin a search for potential IAOC members in parallel, based on expected 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. Wasserman & Daigle Expires April 17, 2005 [Page 7] Internet-Draft AdminRest Transition Plan October 2004 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. 9. Simultaneous IESG and ISOC Board approvals by 17-Dec-04. IAOC moves from interim to non-interim status. 10. IAD hired in Jan 2005. 11. NomCom seats remaining IAOC members as quickly as possible, definitely by the first IETF meeting of 2005. 12. Formal agreements with all service providers in-place by June 2005. 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 ThingMagic One Broadway, 14th Floor Cambridge, MA 02142 USA Phone: +1 617 758-4177 EMail: margaret@thingmagic.com URI: http://www.thingmagic.com Wasserman & Daigle Expires April 17, 2005 [Page 8] Internet-Draft AdminRest Transition Plan October 2004 Leslie Daigle VeriSign 21355 Ridgetop Circle Dulles, VA 20176 USA EMail: leslie@verisignlabs.com, leslie@thinkingcat.com Wasserman & Daigle Expires April 17, 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 http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wasserman & Daigle Expires April 17, 2005 [Page 10]