idnits 2.17.1 draft-aboba-sg-experiment-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 October 2007) is 6023 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba 3 Internet-Draft Microsoft Corporation 4 Intended Status: Experimental L. Dondeti 5 Expires: April 14, 2008 QUALCOMM, Inc. 6 22 October 2007 8 Experiment in Exploratory Group Formation within the 9 Internet Engineering Task Force (IETF) 10 draft-aboba-sg-experiment-04.txt 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 14, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes an RFC 3933 experiment in the Working Group 42 formation process, known as the Exploratory Group. Exploratory 43 Groups may be created as the first step toward Working Group 44 formation, or as an intermediate step between a Birds of a Feather 45 (BOF) session and Working Group creation. Exploratory Groups are 46 focused on completion of prerequisites for Working Group formation, 47 and as a result they have a short life-time, with limited 48 opportunities for milestone extension. 50 Table of Contents 52 1. Introduction ................................................. 3 53 1.1 Requirements ........................................... 4 54 2. Exploratory Group Formation .................................. 4 55 3. The Experiment ............................................... 6 56 3.1 Success Metrics ......................................... 6 57 4. Security Considerations ...................................... 7 58 5. IANA Considerations .......................................... 7 59 6. References ................................................... 7 60 6.1 Normative References .................................... 7 61 6.2 Informative References .................................. 7 62 Acknowledgments .................................................. 8 63 Author's Addresses ............................................... 8 64 Full Copyright Statement ......................................... 9 65 Intellectual Property ............................................ 9 66 1. Introduction 68 "IETF Working Group Guidelines and Procedures" [RFC2418] describes 69 the Working Group formation process within the Internet Engineering 70 Task Force (IETF). As noted in RFC 2418 [RFC2418] Section 2.1: 72 When determining whether it is appropriate to create a working 73 group, the Area Director(s) and the IESG will consider several 74 issues: 76 - Are the issues that the working group plans to address 77 clear and relevant to the Internet community? 79 - Are the goals specific and reasonably achievable, and 80 achievable within a reasonable time frame? 82 - What are the risks and urgency of the work, to determine 83 the level of effort required? 85 - Do the working group's activities overlap with those of 86 another working group? 87 ... 89 - Is there sufficient interest within the IETF in the working 90 group's topic with enough people willing to expend the effort 91 to produce the desired result (e.g., a protocol specification)? 92 ... 94 - Is there enough expertise within the IETF in the working 95 group's topic, and are those people interested in 96 contributing in the working group? 97 ... 99 - Does a base of interested consumers (end-users) appear to 100 exist for the planned work? 101 ... 103 - Does the IETF have a reasonable role to play in the 104 determination of the technology? 105 ... 107 - Are all known intellectual property rights relevant to 108 the proposed working group's efforts issues understood? 110 - Is the proposed work plan an open IETF effort or is it an 111 attempt to "bless" non-IETF technology where the effect of 112 input from IETF participants may be limited? 114 - Is there a good understanding of any existing work that is 115 relevant to the topics that the proposed working group is to 116 pursue? This includes work within the IETF and elsewhere. 118 - Do the working group's goals overlap with known work in 119 another standards body, and if so is adequate liaison 120 in place? 122 In some situations, while interest on the part of IETF participants 123 and end-users may be evident, and the relevance to the Internet 124 community may be demonstrated, the answer to other questions (such as 125 an understanding of existing work, clarity or achievability of goals, 126 or overlap with existing working groups or standards bodies) may not 127 be as clear. In the past, the likely outcome in this circumstance 128 has been to postpone Working Group formation or even Birds of a 129 Feather (BOF) sessions until satisfactory answers are forthcoming. 130 However, in practice this may leave the status of the potential 131 Working Group officially undetermined for months or even years. 132 While the Area Directors should provide potential Working Group 133 participants timely updates on the status of the potential Working 134 Group and insight into IESG or IAB concerns, currently there is no 135 mechanism to track progress toward Working Group creation, and as a 136 result, participants may not have a clear understanding of the status 137 or the next steps. Also, the lack of formal recognition may 138 negatively affect the motivation of the participants, and may leave 139 those who have not followed the effort closely with an impression 140 that no work is going on. 142 This document describes an RFC 3933 [RFC3933] experiment in the 143 Working Group (WG) formation process, known as the Exploratory Group 144 (EG). Exploratory Group milestones are focused on completion of 145 prerequisites for Working Group formation, and as a result they are 146 expected to conclude within a short time frame, with limited 147 opportunities for milestone extension. 149 This Exploratory Group experiment does not alter the Working Group 150 formation guidelines described in RFC 2418 [RFC2418] Section 2.1, or 151 the Internet Standards Process described in RFC 2026 [RFC2026]. 152 Rather it builds on these existing processes, introducing an element 153 of formality which may be useful in clarifying IESG and/or IAB 154 concerns relating to Working Group formation criteria and motivating 155 more rapid progress toward their resolution. Since Exploratory Group 156 documents (including the EG Charter and potential WG Charter) are 157 reviewed and comments are tracked using existing tools and processes, 158 feedback is available to Exploratory Group chairs and authors, 159 providing for transparency and accountability. 161 1.1. Requirements 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 2. Exploratory Group Formation 169 If at any point during the Working Group formation process, relevance 170 to the Internet community and interest within the IETF and end-user 171 community has been demonstrated, but one or more Working Group 172 formation criteria outlined in RFC 2418 [RFC2418] Section 2.1 has not 173 yet been met, the IESG MAY propose that an Exploratory Group be 174 formed. Exploratory Groups MAY be created as the first step toward 175 Working Group formation, or as an intermediate step between an 176 initial Birds of a Feather (BOF) session and Working Group creation. 177 The formation of an Exploratory Group after a second BoF is NOT 178 RECOMMENDED. 180 Since the goal of an Exploratory Group is to put in place the 181 prerequisites for formation of a Working Group more rapidly than 182 might otherwise be possible, Exploratory Groups SHOULD initially be 183 chartered for a period of six months to twelve months, with six 184 months being the default. While the IESG MAY extend the initial 185 Exploratory Group milestones by an additional six months, extensions 186 beyond this are NOT RECOMMENDED. The Exploratory Group Charter 187 SHOULD include at least the following "basic milestones": 189 o Development of a Working Group Charter. 191 o Development of a document demonstrating fulfillment of 192 the Working Group formation criteria described in 193 RFC 2418 [RFC2418] Section 2.1. 195 The IESG MAY also include additional milestones within an Exploratory 196 Group charter (such as development of a problem statement or 197 requirements document and/or completion of a review of the literature 198 or current practices), as long as these additional milestones do not 199 compromise the ability of the Exploratory Group to deliver on the 200 basic milestones in a timely way. A Exploratory Group charter MUST 201 NOT include milestones relating to development of standards track 202 documents or protocol specifications. 204 Since the Exploratory Group experiment is not intended as a 205 substitute for the existing Working Group formation process, 206 Exploratory Groups SHOULD be formed only in situations where the 207 prerequisites for formation of a WG are likely to be met if the EG 208 successfully completes the basic milestones. 210 3. The Experiment 212 This experiment runs for a period of 18 months from IESG approval of 213 the experiment. During the period of the experiment, the IESG MAY 214 approve formation of as many as three Exploratory Groups. The IESG 215 MUST inform the community in a public statement of any decisions for 216 Exploratory Group formation approved under this experiment. Such a 217 statement SHOULD include a description of specific Exploratory Group 218 that was formed. 220 Given that this is an experiment, the intent is for Exploratory 221 Groups to be handled identically to Working Groups in terms of IETF 222 process, tools and infrastructure; no additional burden is to be 223 imposed on the IETF Secretariat. Other than the abbreviated 224 Exploratory Group charter, the process for formation of an 225 Exploratory Group is identical to that of a Working Group, including 226 review by the IAB and IESG, announcement of the potential Exploratory 227 Group, and request for review by the IETF community. The operating 228 rules of an Exploratory Group (openness, meeting requirements, etc.) 229 are identical to Working Groups. From the point of view of IETF 230 infrastructure (tools, membership in the WGCHAIRS mailing list, 231 process rules, Exploratory Group Charter pages, etc.) Exploratory 232 Groups are treated identically to Working Groups, with the exception 233 that Exploratory Group names should include "EG" within the name 234 (e.g. "EXAMPLEEG"), so as to clearly differentiate them from Working 235 Groups. 237 Review of Exploratory Group documents will utilize the same tracking 238 tools and processes (including PROTO sheparding) as other IETF 239 documents; this allows feedback to be viewed by Exploratory Group 240 Chairs and participants, as well as providing additional clarity on 241 next steps. Formation of an Exploratory Group requires the 242 appointment of an Exploratory Group Chair, and a well defined set of 243 Working Group formation criteria (agreement on the Working Group 244 Charter, review of the formation criteria, problem statement or 245 requirements document, etc. ) 247 3.1. Success Metrics 249 Since one of the goals of this experiment is to enable the more rapid 250 formation of Working Groups, the success of an individual Exploratory 251 Group, as well as the experiment, can be measured based on the 252 progress made toward Working Group formation. Useful metrics 253 include: 255 Progress on Basic Milestones 256 A Exploratory Group that does not make progress on its basic 257 milestones cannot be judged successful, regardless of its other 258 achievements, such as progress on a literature review or 259 requirements document. Progress on the basic milestones is 260 measured by whether they are completed within the time-frame 261 specified in the initial Exploratory Group Charter, and whether 262 feedback from the IESG, IAB and IETF community is positive, leading 263 the IESG to vote to form a Working Group. 265 Mailing List Activity 266 Since one of the goals of the Exploratory Group experiment is to 267 avoid a potential loss of interest among participants, evidence of 268 continued engagement on the part of Exploratory Group participants 269 based on mailing list activity is a potential success metric. 270 Conversely, an Exploratory Group whose mailing list shows minimal 271 traffic would probably not be a good candidate for milestone 272 extension. 274 4. Security Considerations 276 This document describes an experiment in the formation of Exploratory 277 Groups. It has no security considerations. 279 5. IANA Considerations 281 This draft requires no action by IANA. 283 6. References 285 6.1. Normative References 287 [RFC2026] 288 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 289 2026, October 1996. 291 [RFC2418] 292 Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 293 25, RFC 2418, September 1998. 295 [RFC2119] 296 Bradner, S., "Key words for use in RFCs to Indicate Requirement 297 Levels", BCP 14, RFC 2119, March 1997. 299 [RFC3933] 300 Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", 301 BCP 93, RFC 3933, November 2004. 303 Acknowledgments 305 The authors would like to thank Jari Arkko, Brian Carpenter, Thomas 306 Narten, Lars Eggert, Eric Rescorla, Sam Hartman and John Klensin for 307 valuable input. 309 Authors' Addresses 311 Bernard Aboba 312 Microsoft Corporation 313 One Microsoft Way 314 Redmond, WA 98052 316 EMail: bernarda@microsoft.com 317 Phone: +1 425 706 6605 318 Fax: +1 425 936 7329 320 Lakshminath Dondeti 321 QUALCOMM, Inc. 322 5775 Morehouse Dr 323 San Diego, CA 324 USA 326 Phone: +1 858-845-1267 327 Email: ldondeti@qualcomm.com 329 Full Copyright Statement 331 Copyright (C) The IETF Trust (2007). 333 This document is subject to the rights, licenses and restrictions 334 contained in BCP 78, and except as set forth therein, the authors 335 retain all their rights. 337 This document and the information contained herein are provided on an 338 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 339 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 340 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 341 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 342 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 343 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 345 Intellectual Property 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at 367 ietf-ipr@ietf.org. 369 Acknowledgment 371 Funding for the RFC Editor function is provided by the IETF 372 Administrative Support Activity (IASA).