summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7418.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7418.txt')
-rw-r--r--doc/rfc/rfc7418.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc7418.txt b/doc/rfc/rfc7418.txt
new file mode 100644
index 0000000..eaed6a4
--- /dev/null
+++ b/doc/rfc/rfc7418.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF) S. Dawkins, Ed.
+Request for Comments: 7418 Huawei
+Category: Informational December 2014
+ISSN: 2070-1721
+
+
+ An IRTF Primer for IETF Participants
+
+Abstract
+
+ 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 of RFC
+ 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://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 to BCP 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 2014
+
+
+Table of Contents
+
+ 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
+ 2. The IRTF Is Not the IETF . . . . . . . . . . . . . . . . . . 2
+ 2.1. Research and Engineering . . . . . . . . . . . . . . . . 3
+ 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.3. Time Frames . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.4. Alternatives . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.5. Process . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.6. Charters . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.7. Deliverables . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.8. Completion . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Now That You Know What Not to Do . . . . . . . . . . . . . . 5
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Normative References . . . . . . . . . . . . . . . . . . 6
+ 5.2. Informative References . . . . . . . . . . . . . . . . . 6
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+1. 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 in BCP 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 Clark
+
+2.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 2014
+
+
+2.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 2014
+
+
+2.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. References
+
+5.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)", RFC
+ 4440, 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", RFC
+ 7282, June 2014, <http://www.rfc-editor.org/info/rfc7282>.
+
+
+
+
+
+
+
+
+
+
+Dawkins Informational [Page 6]
+
+RFC 7418 IRTF Primer for IETF December 2014
+
+
+Acknowledgements
+
+ 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 of Section 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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawkins Informational [Page 7]
+