Movatterモバイル変換

Internet Research Task Force (IRTF)                      S. Dawkins, Ed.Request for Comments: 7418                                        HuaweiCategory: Informational                                    December 2014ISSN: 2070-1721An IRTF Primer for IETF ParticipantsAbstract   This document provides a high-level description of things for   Internet Engineering Task Force (IETF) participants to consider when   bringing proposals for new research groups (RGs) into the Internet   Research Task Force (IRTF).  This document emphasizes differences in   expectations between the two organizations.Status of This Memo   This document is not an Internet Standards Track specification; it is   published for informational purposes.   This document is a product of the Internet Research Task Force   (IRTF).  The IRTF publishes the results of Internet-related research   and development activities.  These results might not be suitable for   deployment.  This RFC represents the individual opinion(s) of one or   more members of the IRSG Research Group of the Internet Research Task   Force (IRTF).  Documents approved for publication by the IRSG are not   a candidate for any level of Internet Standard; see Section 2 ofRFC5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7418.Copyright Notice   Copyright (c) 2014 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.Dawkins                       Informational                     [Page 1]

RFC 7418                  IRTF Primer for IETF             December 2014Table of Contents1.  Introduction and Scope  . . . . . . . . . . . . . . . . . . .22.  The IRTF Is Not the IETF  . . . . . . . . . . . . . . . . . .22.1.  Research and Engineering  . . . . . . . . . . . . . . . .32.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .32.3.  Time Frames . . . . . . . . . . . . . . . . . . . . . . .32.4.  Alternatives  . . . . . . . . . . . . . . . . . . . . . .42.5.  Process . . . . . . . . . . . . . . . . . . . . . . . . .42.6.  Charters  . . . . . . . . . . . . . . . . . . . . . . . .42.7.  Deliverables  . . . . . . . . . . . . . . . . . . . . . .52.8.  Completion  . . . . . . . . . . . . . . . . . . . . . . .53.  Now That You Know What Not to Do  . . . . . . . . . . . . . .54.  Security Considerations . . . . . . . . . . . . . . . . . . .65.  References  . . . . . . . . . . . . . . . . . . . . . . . . .65.1.  Normative References  . . . . . . . . . . . . . . . . . .65.2.  Informative References  . . . . . . . . . . . . . . . . .6   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .7   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .71.  Introduction and Scope   This document provides a high-level description of things for   Internet Engineering Task Force (IETF) participants to consider when   bringing proposals for new research groups (RGs) into the Internet   Research Task Force (IRTF).  This document emphasizes differences in   expectations between the two organizations.   IRTF RG guidelines and procedures are described inBCP 8 [RFC2014],   and this document does not change those guidelines and procedures in   any way.2.  The IRTF Is Not the IETF   A number of proposals from experienced IETF participants for new IRTF   RGs have encountered problems because the IETF participants were   making proposals appropriate for the IETF, but not for the IRTF.   [RFC2014] describes the origin of IRTF RGs but doesn't provide much   detail about the process, which is intended to be flexible and   accommodate new types of RGs.  Lacking that detail, experienced IETF   participants fall back on what they know, assume that chartering an   IRTF RG will be similar to chartering an IETF working group (WG),   follow the suggestions in [RFC6771] to gather a group of interested   parties, and then follow the suggestions in [RFC5434] to prepare for   a successful BOF and eventually, a chartered WG.Dawkins                       Informational                     [Page 2]

RFC 7418                  IRTF Primer for IETF             December 2014   Both of these documents are excellent references for proposals in the   IETF, but their suggestions may result in a proposal that is almost   the opposite of what the IRTF Chair is looking for in a proposal for   an IRTF RG.  The mismatches fall into some consistent categories, and   this document lists the ones that come up repeatedly.   The target audience of this document is IETF participants bringing   proposals to the IRTF.   It's worth noting that the IRTF Chair has substantial autonomy on   what RGs are chartered and how they reach that stage.  The IRTF Chair   at the time of writing is Lars Eggert.2.1.  Research and Engineering      "To me, the fundamental outcome of research is understanding, and      the fundamental outcome of engineering is a product." - Fred Baker   In some ways, research is about a journey, and engineering is about a   destination.  If a researcher answers a question in a way that opens   another question, that can be success.  If an engineer keeps working   on a product without finishing it, that is usually a failure.   Research can be open-ended, while engineering can come to a stopping   point when the result is "good enough" -- good enough to ship.      "If it has to work when you're finished, it wasn't research, it      was engineering." - attributed to Dave Clark2.2.  Scope   IRTF RGs have a scope large enough to interest researchers, attract   them to the IRTF, and keep them busy doing significant work.  Their   charters are therefore usually much broader than IETF WG charters,   and RGs often discuss different topics underneath the charter   umbrella at different times, based on current research interests in   the field.   IETF WGs are chartered with a limited scope and specific   deliverables.  If deliverables and milestones are known, the proposal   is likely too limited for the IRTF.2.3.  Time Frames   IRTF RGs bring researchers together to work on significant problems.   That takes time.  The effort required by a RG is likely to take at   least three to five years, significantly longer than IETF WGs   envision when they are chartered.Dawkins                       Informational                     [Page 3]

RFC 7418                  IRTF Primer for IETF             December 20142.4.  Alternatives   IRTF RGs are encouraged to explore more than one alternative approach   to the chartered problem area.  There is no expectation that the RG   will "come to consensus" on one approach.  The RG may publish   multiple competing proposals as research produces results.   IETF WGs normally use the IETF consensus process (as described in   [RFC7282]) to drive interoperable solutions into the market place.   That often includes reducing the number of approaches to something   manageable for an implementer, preferably one, whether that means   starting with an approach the WG participants agree on, or   considering alternatives with a view to picking one rather than   spending significant effort on alternatives that won't go forward.   The IRTF, as an organization, may also charter multiple RGs with   somewhat overlapping areas of interest, which the IETF tries very   hard to avoid.2.5.  Process   All IRTF participants have the obligation to disclose IPR and   otherwise follow the IRTF's IPR policies, which closely mirror the   IETF's IPR policies; in all other aspects, IRTF RG operation is much   less constrained than IETF WG operation.   Each IRTF RG is permitted (and encouraged) to agree on a way of   working together that best supports the specific needs of the group.   This freedom allows IRTF RGs to bypass fundamental IETF ways of   working, such as the need to reach at least rough consensus, which   IRTF RGs need not do.  Therefore, the mode of operation of IRTF RGs   can also change over time, for example, perhaps becoming more like   IETF WG operation as the research the group has been progressing   matures.2.6.  Charters   The purpose of charters in the IRTF is to broadly sketch the field of   research that a group is interested in pursuing and to serve as an   advertisement to other researchers who may be wondering if the group   is the right place to participate.   IETF WG charters tend to be very narrow.  They are intended to   constrain the work that the working group will be doing, and they may   contain considerable text about what the working group will not be   working on.Dawkins                       Informational                     [Page 4]

RFC 7418                  IRTF Primer for IETF             December 20142.7.  Deliverables   There is no expectation that IRTF RGs publish RFCs, although many do.   Some IRTF research groups produce IRTF-stream RFCs, while others   produce Internet-Drafts that form the basis of IETF-stream RFCs, and   still others may deliver reports, white papers, academic journal   articles, or even carry out relevant high-level discussions that   aren't ever published but influence other research.  IRTF RGs are   successful when they stimulate discussion, produce relevant outputs,   and impact the research community.   IETF WG deliverables tend to be specific protocol, deployment, and   operational specifications, along with problem statements, use cases,   requirements, and architectures that inform those specifications.   Almost all IETF working groups are chartered to deliver Internet   standards, which isn't an option for IRTF RGs.2.8.  Completion   IRTF RGs may produce the outputs they expected to produce when they   were chartered, but it also happens that researchers consider what   they've learned and start work on better solutions.  This can happen   whether or not the research underway has been completed, and the   process can continue until the RG itself decides that it is time to   conclude or when the IRTF Chair determines that there is no more   energy in the group to do research.   IETF WGs will typically conclude when they meet their chartered   milestones, allowing participants to focus on implementation and   deployment, although the WG mailing list may remain open for a time.3.  Now That You Know What Not to Do   The current IRTF Chair, Lars Eggert, is fond of saying, "Just act   like an IRTF research group for a year, and we'll see if you are   one."   There are many ways to "act like an IRTF research group".  [RFC4440]   contains a number of points to consider when proposing a new RG.   Some possibilities include:   1.  Identify and recruit a critical mass of researchers who can       review and build off each other's work.   2.  Identify other venues that may overlap the proposed RG, and       understand what value the proposed RG provides beyond what's       already underway elsewhere.Dawkins                       Informational                     [Page 5]

RFC 7418                  IRTF Primer for IETF             December 2014   3.  Hold a workshop to survey work that might set the stage for a RG       on questions of interest, perhaps in concert with existing       academic events.   4.  If the proposed RG expects to have outputs that will ultimately       be standardized in the IETF, identify and recruit engineers who       can review and provide feedback on intermediate results.   But every proposed RG is different, so e-mailing the IRTF Chair to   start the conversation is a perfectly reasonable strategy.4.  Security Considerations   This document provides guidance about the IRTF chartering process to   IETF participants and has no direct Internet security implications.5.  References5.1.  Normative References   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines              and Procedures",BCP 8,RFC 2014, October 1996,              <http://www.rfc-editor.org/info/rfc2014>.5.2.  Informative References   [RFC4440]  Floyd, S., Paxson, V., Falk, A., and IAB, "IAB Thoughts on              the Role of the Internet Research Task Force (IRTF)",RFC4440, March 2006,              <http://www.rfc-editor.org/info/rfc4440>.   [RFC5434]  Narten, T., "Considerations for Having a Successful Birds-              of-a-Feather (BOF) Session",RFC 5434, February 2009,              <http://www.rfc-editor.org/info/rfc5434>.   [RFC6771]  Eggert, L. and G. Camarillo, "Considerations for Having a              Successful "Bar BOF" Side Meeting",RFC 6771, October              2012, <http://www.rfc-editor.org/info/rfc6771>.   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",RFC7282, June 2014, <http://www.rfc-editor.org/info/rfc7282>.Dawkins                       Informational                     [Page 6]

RFC 7418                  IRTF Primer for IETF             December 2014Acknowledgements   Thanks go to Lars Eggert, who became IRTF Chair in 2011 and has been   carrying this information around in his head ever since.  Lars also   provided helpful comments on early versions of this document.   Thanks especially to Fred Baker for sharing thoughts about the   motivations of research and engineering that resulted in a complete   rewrite ofSection 2.1.   Thanks also to Scott Brim, Kevin Fall, Eliot Lear, David Meyer, and   Stephen Farrell for providing helpful review comments, and to Denis   Ovsienko for careful proofreading.Author's Address   Spencer Dawkins (editor)   Huawei Technologies   EMail: spencerdawkins.ietf@gmail.comDawkins                       Informational                     [Page 7]