idnits 2.17.1 draft-dawkins-irtf-newrg-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (September 23, 2014) is 3474 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRSG S. Dawkins, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational September 23, 2014 5 Expires: March 27, 2015 7 An IRTF Primer for IETF Participants 8 draft-dawkins-irtf-newrg-05.txt 10 Abstract 12 This document provides a high-level description of things for 13 Internet Engineering Task Force (IETF) participants to consider when 14 bringing proposals for new research groups into the Internet Research 15 Task Force (IRTF). This document emphasizes differences in 16 expectations between the two organizations. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 27, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Table of Contents 49 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 50 2. The IRTF is not the IETF . . . . . . . . . . . . . . . . . . 2 51 2.1. Research and Engineering . . . . . . . . . . . . . . . . 3 52 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.3. Timeframes . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.4. Alternatives . . . . . . . . . . . . . . . . . . . . . . 4 55 2.5. Process . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.6. Charters . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.7. Deliverables . . . . . . . . . . . . . . . . . . . . . . 5 58 2.8. Completion . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Now That You Know What Not To DO . . . . . . . . . . . . . . 5 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction and Scope 70 This document provides a high-level description of things for 71 Internet Engineering Task Force (IETF) participants to consider when 72 bringing proposals for new research groups into the Internet Research 73 Task Force (IRTF). This document emphasizes differences in 74 expectations between the two organizations. 76 IRTF research group guidelines and procedures are described in 77 [RFC2014] (BCP 8), and this document does not change those guidelines 78 and procedures in any way. 80 2. The IRTF is not the IETF 82 A number of proposals from experienced IETF participants for new IRTF 83 research groups have encountered problems because the IETF 84 participants were making proposals appropriate for the IETF, but not 85 for the IRTF. [RFC2014] describes the origin of IRTF research 86 groups, but doesn't provide much detail about the process, which is 87 intended to be flexible and accommodate new types of research groups. 88 Lacking that detail, experienced IETF participants fall back on what 89 they know, assume that chartering an IRTF research group will be 90 similar to chartering an IETF working group, and follow the 91 suggestions in [RFC6771] to gather a group of interested parties, and 92 then follow the suggestions in [RFC5434] to prepare for a successful 93 BOF and eventually, a chartered working group. 95 Both of these documents are excellent references for proposals in the 96 IETF, but their suggestions may result in a proposal that is almost 97 the opposite of what the IRTF Chair is looking for in a proposal for 98 an IRTF research group. The mismatches fall into some consistent 99 categories, and this document lists the ones that come up repeatedly. 101 The target audience of this document is IETF participants bringing 102 proposals to the IRTF. 104 It's worth noting that the IRTF Chair has substantial autonomy on 105 what research groups are chartered and how they reach that stage. 106 This document reflects Lars Eggert as IRTF Chair. 108 2.1. Research and Engineering 110 "To me, the fundamental outcome of research is understanding, and 111 the fundamental outcome of engineering is a product" - Fred Baker. 113 In some ways, research is about a journey, and engineering is about a 114 destination. If a researcher answers a question in a way that opens 115 another question, that can be success. If an engineer keeps working 116 on a product without finishing it, that is usually a failure. 118 Research can be open-ended, while engineering can come to a stopping 119 point when the result is "good enough" - good enough to ship. 121 "If it has to work when you're finished, it wasn't research, it 122 was engineering" - attributed to Dave Clark. 124 2.2. Scope 126 IRTF research groups have a scope large enough to interest 127 researchers, attract them to the IRTF, and keep them busy doing 128 significant work. Their charters are therefore usually much broader 129 than IETF working group charters, and research groups often discuss 130 different topics underneath the charter umbrella at different times, 131 based on current research interests in the field. 133 IETF working groups are chartered with a limited scope and specific 134 deliverables. If deliverables and milestones are known, the proposal 135 is likely too limited for the IRTF. 137 2.3. Timeframes 139 IRTF research groups bring researchers together to work on 140 significant problems. That takes time. The effort required by a 141 research group is likely to take at least three to five years, 142 significantly longer than IETF working groups envision when they are 143 chartered. 145 2.4. Alternatives 147 IRTF research groups are encouraged to explore more than one 148 alternative approach to the chartered problem area. There is no 149 expectation that the research group will "come to consensus" on one 150 approach. The research group may publish multiple competing 151 proposals as research produces results. 153 IETF working groups normally use the IETF consensus process (as 154 described in [RFC7282] to drive interoperable solutions into the 155 market place. That often includes reducing the number of approaches 156 to something manageable for an implementer, preferably one, whether 157 that means starting with an approach the working group participants 158 agree on, or considering alternatives with a view to picking one 159 rather than spending significant effort on alternatives that won't go 160 forward. 162 The IRTF as an organization may also charter multiple research groups 163 with somewhat overlapping areas of interest, which the IETF tries 164 very hard to avoid. 166 2.5. Process 168 All IRTF participants have the obligation to disclose IPR and 169 otherwise follow the IRTF's IPR policies, which closely mirror the 170 IETF's IPR policies, but in all other aspects, IRTF research group 171 operation is much less constrained than IETF working group operation. 173 Each IRTF research group is permitted (and encouraged) to agree on a 174 way of working together that best supports the specific needs of the 175 group. This freedom allows IRTF research groups to bypass 176 fundamental IETF ways of working, such as the need to reach at least 177 rough consensus, which IRTF research groups need not do. The mode of 178 operation of IRTF research groups can therefore also change over 179 time, for example, perhaps becoming more like IETF working group 180 operation as the research the group has been progressing matures. 182 2.6. Charters 184 The purpose of charters in the IRTF is to broadly sketch the field of 185 research that a group is interested in pursuing, and to serve as an 186 advertisement to other researchers who may be wondering if the group 187 is the right place to participate. 189 IETF working group charters tend to be very narrow, intended to 190 constrain the work that the working group will be doing, and may 191 contain considerable text about what the working group will not be 192 working on. 194 2.7. Deliverables 196 There is no expectation that IRTF groups must publish any RFCs, 197 although many do. Some IRTF research groups produce IRTF-stream 198 RFCs, while others produce Internet-Drafts that form the basis of 199 IETF-stream RFCs, and still others may deliver reports, white papers, 200 academic journal articles, or even carry out relevant high-level 201 discussions that aren't ever published, but influence other research. 202 IRTF groups are successful when they stimulate discussion, produce 203 relevant outputs and impact the research community. 205 IETF working group deliverables tend to be specific protocol, 206 deployment and operational specifications, along with problem 207 statements, use cases, requirements and architectures that inform 208 those specifications. Almost all IETF working groups are chartered 209 to deliver Internet standards, which isn't an option for IRTF 210 research groups. 212 2.8. Completion 214 IRTF research groups may produce the outputs they expected to produce 215 when they were chartered, but it also happens that researchers 216 consider what they've learned and start work on better solutions. 217 This can happen whether or not research underway has been completed, 218 and the process can continue until the research group itself decides 219 that it is time to conclude, or IRTF chair determines that there is 220 no more energy in the group to do research. 222 IETF working groups will typically conclude when they meet their 223 chartered milestones, allowing participants to focus on 224 implementation and deployment, although the working group mailing 225 list may remain open for a time. 227 3. Now That You Know What Not To DO 229 The current IRTF Chair, Lars Eggert, is fond of saying, "just act 230 like an IRTF research group for a year, and we'll see if you are 231 one". 233 There are many ways to "act like an IRTF research group". [RFC4440] 234 contains a number of points to consider when proposing a new research 235 group. Some possibilities include: 237 1. Identify and recruit a critical mass of researchers who can 238 review and build off each other's work. 240 2. Identify other venues that may overlap the proposed research 241 group, and understand what value the proposed research group 242 provides beyond what's already underway elsewhere. 244 3. Hold a workshop to survey work that might set the stage for a 245 research group on questions of interest, perhaps in concert with 246 existing academic events. 248 4. If the proposed research group expects to have outputs that will 249 ultimately be standardized in the IETF, identify and recruit 250 engineers who can review and provide feedback on intermediate 251 results. 253 But every proposed research group is different, so e-mailing the IRTF 254 Chair to start the conversation is a perfectly reasonable strategy. 256 4. Security Considerations 258 This document provides guidance about the IRTF chartering process to 259 IETF participants and has no direct Internet security implications. 261 5. IANA Considerations 263 This document makes no requests of IANA and the RFC Editor can safely 264 remove this section during publication. 266 6. Acknowledgements 268 Thanks go to Lars Eggert, who became IRTF Chair in 2011 and has been 269 carrying this information around in his head ever since. Lars also 270 provided helpful comments on early versions of this document. 272 Thanks especially to Fred Baker for sharing thoughts about the 273 motivations of research and engineering that resulted in a complete 274 rewrite of Section 2.1. 276 Thanks also to Scott Brim, David Meyer, and Stephen Farrell for 277 helpful review comments, and to Denis Ovsienko for careful 278 proofreading. 280 7. References 281 7.1. Normative References 283 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 284 and Procedures", BCP 8, RFC 2014, October 1996. 286 7.2. Informative References 288 [RFC4440] Floyd, S., Paxson, V., Falk, A., and IAB, "IAB Thoughts on 289 the Role of the Internet Research Task Force (IRTF)", RFC 290 4440, March 2006. 292 [RFC5434] Narten, T., "Considerations for Having a Successful Birds- 293 of-a-Feather (BOF) Session", RFC 5434, February 2009. 295 [RFC6771] Eggert, L. and G. Camarillo, "Considerations for Having a 296 Successful "Bar BOF" Side Meeting", RFC 6771, October 297 2012. 299 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 300 7282, June 2014. 302 Author's Address 304 Spencer Dawkins (editor) 305 Huawei Technologies 307 Email: spencerdawkins.ietf@gmail.com