doc: Add RFC documents

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]
+