Network Working Group B. Aboba Internet-Draft Microsoft Corporation Intended Status: Experimental L. Dondeti Expires: April 14, 2008 QUALCOMM, Inc. 11 October 2007 Experiment in Study Group Formation within the Internet Engineering Task Force (IETF) draft-aboba-sg-experiment-03.txt 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes an RFC 3933 experiment in the Working Group formation process, known as the Study Group. Study Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation. Study Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. Aboba & Dondeti Experimental [Page 1] Internet-Draft Study Group Experiment 11 October 2007 Table of Contents 1. Introduction ................................................. 3 1.1 Requirements ........................................... 4 2. Study Group Formation ........................................ 4 3. The Experiment ............................................... 6 3.1 Success Metrics ......................................... 6 4. Security Considerations ...................................... 7 5. IANA Considerations .......................................... 7 6. References ................................................... 7 6.1 Normative References .................................... 7 6.2 Informative References .................................. 7 Acknowledgments .................................................. 8 Author's Addresses ............................................... 8 Full Copyright Statement ......................................... 9 Intellectual Property ............................................ 9 Aboba & Dondeti Experimental [Page 2] Internet-Draft Study Group Experiment 11 October 2007 1. Introduction "IETF Working Group Guidelines and Procedures" [RFC2418] describes the Working Group formation process within the Internet Engineering Task Force (IETF). As noted in RFC 2418 [RFC2418] Section 2.1: When determining whether it is appropriate to create a working group, the Area Director(s) and the IESG will consider several issues: - Are the issues that the working group plans to address clear and relevant to the Internet community? - Are the goals specific and reasonably achievable, and achievable within a reasonable time frame? - What are the risks and urgency of the work, to determine the level of effort required? - Do the working group's activities overlap with those of another working group? ... - Is there sufficient interest within the IETF in the working group's topic with enough people willing to expend the effort to produce the desired result (e.g., a protocol specification)? ... - Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group? ... - Does a base of interested consumers (end-users) appear to exist for the planned work? ... - Does the IETF have a reasonable role to play in the determination of the technology? ... - Are all known intellectual property rights relevant to the proposed working group's efforts issues understood? - Is the proposed work plan an open IETF effort or is it an attempt to "bless" non-IETF technology where the effect of input from IETF participants may be limited? Aboba & Dondeti Experimental [Page 3] Internet-Draft Study Group Experiment 11 October 2007 - Is there a good understanding of any existing work that is relevant to the topics that the proposed working group is to pursue? This includes work within the IETF and elsewhere. - Do the working group's goals overlap with known work in another standards body, and if so is adequate liaison in place? In some situations, while interest on the part of IETF participants and end-users may be evident, and the relevance to the Internet community may be demonstrated, the answer to other questions (such as an understanding of existing work, clarity or achievability of goals, or overlap with existing working groups or standards bodies) may not be as clear. In the past, the likely outcome in this circumstance has been to postpone Working Group formation or even Birds of a Feather (BOF) sessions until satisfactory answers are forthcoming. However, in practice this may leave the status of the potential Working Group officially undetermined for months or even years. While the Area Directors should provide potential Working Group participants timely updates on the status of the potential Working Group and insight into IESG or IAB concerns, currently there is no mechanism to track progress toward working group creation, and as a result, participants may not have a clear understanding of the status or the next steps. Also, the lack of formal recognition may negatively affect the motivation of the participants, and may leave those who have not followed the effort closely with an impression that no work is going on. This document describes an RFC 3933 [RFC3933] experiment in the Working Group formation process, known as the Study Group. Study Group milestones are focused on completion of prerequisites for Working Group formation, and as a result they are expected to conclude within a short time frame, with limited opportunities for milestone extension. This Study Group experiment does not alter the Working Group formation guidelines described in RFC 2418 [RFC2418] Section 2.1, or the Internet Standards Process described in RFC 2026 [RFC2026]. Rather it builds on these existing processes, introducing an element of formality which may be useful in clarifying IESG and/or IAB concerns relating to Working Group formation criteria and motivating more rapid progress toward their resolution. Since Study Group documents (including the SG Charter and potential WG Charter) are reviewed and comments are tracked using existing tools and processes, feedback is available to Study Group chairs and authors, providing for transparency and accountability. Aboba & Dondeti Experimental [Page 4] Internet-Draft Study Group Experiment 11 October 2007 1.1. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Study Group Formation If at any point during the Working Group formation process, relevance to the Internet community and interest within the IETF and end-user community has been demonstrated, but one or more Working Group formation criteria outlined in RFC 2418 [RFC2418] Section 2.1 has not yet been met, the IESG MAY propose that a Study Group be formed. Study Groups MAY be created as the first step toward Working Group formation, or as an intermediate step between an initial Birds of a Feather (BOF) session and Working Group creation. The formation of a Study Group after a second BoF is NOT RECOMMENDED. Since the goal of a Study Group is to put in place the prerequisites for formation of a Working Group more rapidly than might otherwise be possible, Study Groups SHOULD initially be chartered for a period of six months to twelve months, with six months being the default. While the IESG MAY extend the initial Study Group milestones by an additional six months, extensions beyond this are NOT RECOMMENDED. The Study Group Charter SHOULD include at least the following "basic milestones": o Development of a Working Group Charter. o Development of a document demonstrating fulfillment of the Working Group formation criteria described in RFC 2418 [RFC2418] Section 2.1. The IESG MAY also include additional milestones within a Study Group charter (such as development of a problem statement or requirements document and/or completion of a review of the literature or current practices), as long as these additional milestones do not compromise the ability of the Study Group to deliver on the basic milestones in a timely way. A Study Group charter MUST NOT include milestones relating to development of standards track documents or protocol specifications. Since the Study Group experiment is not intended as a substitute for the existing Working Group formation process, Study Groups SHOULD be formed only in situations where the prerequisites for formation of a WG are likely to be met if the SG successfully completes the basic milestones. Aboba & Dondeti Experimental [Page 5] Internet-Draft Study Group Experiment 11 October 2007 3. The Experiment This experiment runs for a period of 18 months from IESG approval of the experiment. During the period of the experiment, the IESG MAY approve formation of as many as three Study Groups. The IESG MUST inform the community in a public statement of any decisions for Study Group formation approved under this experiment. Such a statement SHOULD include a description of specific Study Group that was formed. Given that this is an experiment, the intent is for Study Groups to be handled identically to Working Groups in terms of IETF process, tools and infrastructure; no additional burden is to be imposed on the IETF Secretariat. Other than the abbreviated Study Group charter, the process for formation of a Study Group is identical to that of a Working Group, including review by the IAB and IESG, announcement of the potential Study Group, and request for review by the IETF community. The operating rules of a Study Group (openness, meeting requirements, etc.) are identical to Working Groups. From the point of view of IETF infrastructure (tools, membership in the WGCHAIRS mailing list, process rules, Study Group Charter pages, etc.) Study Groups are treated identically to Working Groups, with the exception that Study Group names should include "SG" within the name (e.g. "EXAMPLESG"), so as to clearly differentiate them from Working Groups. Review of Study Group documents will utilize the same tracking tools and processes (including PROTO sheparding) as other IETF documents; this allows feedback to be viewed by Study Group Chairs and participants, as well as providing additional clarity on next steps. Formation of a Study Group requires the appointment of a Study Group Chair, and a well defined set of Working Group formation criteria (agreement on the Working Group Charter, review of the formation criteria, problem statement or requirements document, etc. ) 3.1. Success Metrics Since one of the goals of this experiment is to enable the more rapid formation of Working Groups, the success of an individual Study Group, as well as the experiment, can be measured based on the progress made toward Working Group formation. Useful metrics include: Progress on Basic Milestones A Study Group that does not make progress on its basic milestones cannot be judged successful, regardless of its other achievements, such as progress on a literature review or requirements document. Progress on the basic milestones is measured by whether they are completed within the time-frame specified in the initial Study Aboba & Dondeti Experimental [Page 6] Internet-Draft Study Group Experiment 11 October 2007 Group Charter, and whether feedback from the IESG, IAB and IETF community is positive, leading the IESG to vote to form a Working Group. Mailing List Activity Since one of the goals of the Study Group experiment is to avoid a potential loss of interest among participants, evidence of continued engagement on the part of Study Group participants based on mailing list activity is a potential success metric. Conversely, a Study Group whose mailing list shows minimal traffic would probably not be a good candidate for milestone extension. 4. Security Considerations This document describes an experiment in the formation of Study Groups. It has no security considerations. 5. IANA Considerations This draft requires no action by IANA. 6. References 6.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004. Aboba & Dondeti Experimental [Page 7] Internet-Draft Study Group Experiment 11 October 2007 Acknowledgments The authors would like to thank Jari Arkko, Brian Carpenter, Thomas Narten, Lars Eggert, Eric Rescorla, Sam Hartman and John Klensin for valuable input. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Aboba & Dondeti Experimental [Page 8] Internet-Draft Study Group Experiment 11 October 2007 Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Aboba & Dondeti Experimental [Page 9]