GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4440

Network Working Group S. Floyd, Ed. Request for Comments: 4440 V. Paxson, Ed. Category: Informational A. Falk, Ed.

                                                                   IAB
                                                            March 2006
IAB Thoughts on the Role of the Internet Research Task Force (IRTF)

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document is an Internet Architecture Board (IAB) report on the
 role of the Internet Research Task Force (IRTF), both on its own and
 in relationship to the IETF.  This document evolved from a discussion
 within the IAB as part of a process of appointing a new chair of the
 IRTF.

Table of Contents

 1. Introduction ....................................................2
 2. The Relationship between the IRTF, the IAB, and the IETF ........2
    2.1. Differences between IRTF and IETF Groups ...................3
    2.2. Research Groups as Non-blocking Entities ...................3
 3. The Range of IRTF Groups ........................................4
 4. Issues for the Future ...........................................5
    4.1. IRTF Groups and Network Architecture .......................5
    4.2. The Relationship between the IETF and the IRTF .............6
    4.3. Relationships between the Research and Development
         Communities ................................................8
         4.3.1. What's in a Name:  On the Name `Research Group' .....8
    4.4. The RFC Track for IRTF Documents ...........................9
 5. Security Considerations .........................................9
 6. Acknowledgements ................................................9
 7. Normative References ...........................................10
 8. Informative References .........................................10

Floyd, et al. Informational [Page 1] RFC 4440 IAB Thoughts on IRTF Role March 2006

1. Introduction

 As part of the process of appointing a new chair of the Internet
 Research Task Force (IRTF), the IAB considered the future role of the
 IRTF both on its own and in relationship to the IETF.  The IAB has
 expanded this discussion into this IAB report on the role of the
 IRTF, and circulated this document for wider community review.  (As
 one result of this discussion, Aaron Falk was appointed the new chair
 of the IRTF in March 2005.)

2. The Relationship between the IRTF, the IAB, and the IETF

 Before 1989, the IAB (then called the Internet Activities Board)
 oversaw a number of task forces.  In 1989, organizational changes
 were made to coalesce these task forces into two groups, the IETF and
 the IRTF.  The IRTF was tasked to consider long-term research
 problems in the Internet, and the IETF was to concentrate on short-
 to medium-term engineering issues related to the Internet.  At this
 time, all of the task forces except the IETF were restructured as
 IRTF research groups.  For example, the End-to-End Task Force became
 the IRTF's End-to-End Research Group (E2ERG) and the Privacy &
 Security Task Force became the IRTF's Privacy & Security Research
 Group (PSRG) [IABWebPages] [RFC3160] [E2ERG].
 Much of the early participation in the IETF as well as in the IRTF
 was from the academic and research communities.  (We don't have a
 citation from this, but a look at the members of the IAB from the
 1980's and early 1990's shows IAB members from institutions such as
 MIT, UCLA, BBN, UCL, SDSC, and the like, while IAB members from the
 last few years were more likely to list their organizations at the
 time of service as Cisco, IBM, Microsoft, Nokia, Qualcomm, and
 Verisign [IABWebPages].  We expect that a study of authors of RFCs
 would show a similar trend over time, with fewer authors from the
 academic and research communities, and more authors from the
 commercial world.)  While the IRTF has continued to have significant
 participation from the academic and research communities, the IETF
 has focused on standards development and has become dominated by the
 needs of the commercial sector.
 The IRTF has generally focused on investigation into areas that are
 not considered sufficiently mature for IETF standardization, as well
 as investigation of areas that are not specifically the subject of
 standardization, but could guide future standards efforts.
 The IRTF Research Groups guidelines and procedures are described in
 RFC 2014.  The IRTF Chair is appointed by the Internet Architecture
 Board (IAB), and charters IRTF research groups (RGs) in consultation
 with the Internet Research Steering Group (IRSG) and with approval of

Floyd, et al. Informational [Page 2] RFC 4440 IAB Thoughts on IRTF Role March 2006

 the IAB.  The chairs of the RGs comprise the main part of the IRSG,
 although the IRTF Chair can also appoint at-large members to the
 IRSG.
 As RFC 2014 states, the IRTF does not set standards.  While
 technologies developed in an RG can be brought to the IETF for
 possible standardization, "Research Group input carries no more
 weight than other community input, and goes through the same
 standards setting process as any other proposal" [RFC2014] (Section
 1.1).  This is necessary to ensure that RGs don't become a part of
 the standards process itself.
 RFC 2014 continues to say that "since the products are research
 results, not Internet standards, consensus of the group is not
 required" [RFC2014] (Section 3).  However, the NameSpace Research
 Group was one RG that did require consensus decisions; this group was
 chartered exclusively to make a recommendation to the IETF.
 RFC 2014 goes on to describe Research Group operation, meeting
 management, staff roles, group documents, and the like.  This
 document is not a revision of RFC 2014, but instead a more wide-
 ranging discussion of the possible roles of the IRTF.
 The past history of IRTF Chairs is as follows: Dave Clark
 (1989-1992); Jon Postel (1992-1995); Abel Weinrib (1995-1999); Erik
 Huizer (1999-2001); Vern Paxson (2001-2005).

2.1. Differences between IRTF and IETF Groups

 Two key differences between IRTF research groups and IETF working
 groups are that IRTF groups are not trying to produce standards of
 any kind and that the output of IRTF groups does not require
 consensus within the RG, or broad consensus from the IETF.
 In some cases, IRTF groups have acted as research groups with minimal
 constraints, creating a community for discussing research proposals,
 with mature proposals "tossed over the fence" to an IETF group for
 standardization.  The Reliable Multicast Research Group (RMRG) was an
 example of such a group, with standardization efforts in the Reliable
 Multicast Transport working group (RMT).

2.2. Research Groups as Non-blocking Entities

 As stated in RFC 2014, the IRTF does not set standards.  It is
 important that, unless clearly specified otherwise by the IESG,
 research groups do not act as gateways controlling the advancement of
 standards, experimental RFCs, or informational RFCs produced by
 working groups in the IETF.

Floyd, et al. Informational [Page 3] RFC 4440 IAB Thoughts on IRTF Role March 2006

 Similarly, as stated in RFC 2014, existing research groups also do
 not necessarily prevent the creation of new research groups in
 related areas.  Of course, when considering a proposal for a new
 research group, it is perfectly appropriate for the IRTF and the IAB
 to consider the relationship with existing research groups.  However,
 "multiple Research Groups working in the same general area may be
 formed if appropriate" [RFC2014] (Sections 1.1 and 2.1).

3. The Range of IRTF Groups

 There is a wide range of ways that IRTF groups can currently be
 structured.  Some of the most significant are:
  • Membership: Groups might be open or closed (in terms of

membership). The End-to-End Research Group and the NameSpace

   Research Group are both past examples of closed RGs.
  • Timescale: While RGs are generally long-term, groups could be

either long-term (ongoing) or short-term with a specific goal; the

   NameSpace Research Group is an example of an RG that was chartered
   as a short-lived group [NSRG].  We note that RFC 2014, written in
   1996, assumed that RGs would be long-term: "Research Groups are
   expected to have the stable long term membership needed to promote
   the development of research collaboration and teamwork in exploring
   research issues" [RFC2014] (Section 1).
  • Relationship to IETF: Groups can include a goal of producing

proposals to be considered in the IETF (e.g., the Anti-Spam

   Research Group) or can be independent of any current or proposed
   work in the IETF (e.g., the Delay-Tolerant Networking Research
   Group).
  • Range of activities: IRTF activities could consist not only of

research groups and their associated meetings, workshops, and other

   activities, but also of separate workshops or other one-time
   activities organized directly by the IRTF.  To date, however, the
   IRTF has not organized such activities other than in the form of
   BOFs at IETF meetings.
  • Both research and development: IRTF groups can focus on traditional

research activities, but they could also focus on development, on

   tool-building, on operational testing or protocol interoperability
   testing, or on other activities that don't fit the framework of a
   working group (WG).  Instead of having a specific plan for the
   evolution of the IRTF, we think that this will have to be explored
   over time, with discussions between the IRTF Chair, the IRSG, and
   the IAB (and with the IESG as appropriate).

Floyd, et al. Informational [Page 4] RFC 4440 IAB Thoughts on IRTF Role March 2006

 As discussed above, the IAB believes that the range of research
 groups could be expanded further, in terms of timescale, relationship
 to the IETF, range of activities, and range between research and
 development.

4. Issues for the Future

 This section discusses some of the issues in the future evolution of
 the IRTF.  A key issue, discussed in Section 4.1 below, concerns how
 the IRTF can best contribute on questions of network architecture.
 Similar issues could be raised in how the IRTF can best contribute to
 incubating technology for later development in the IETF.  We
 emphasize that we are not proposing that the IRTF should become a de
 facto holding point for technologies that are not making clear
 progress in the WGs.  Some technologies might not make progress in
 WGs because of key open issues, making an RG an appropriate step.
 Other technologies, however, might not make progress in WGs because
 of a lack of interest, inherent design weaknesses, or some other
 reason that does not justify moving it into an RG instead.

4.1. IRTF Groups and Network Architecture

 One interest of the IAB is how progress is made on issues of network
 architecture.  This includes help in developing and evaluating new
 architectures, and in understanding the evolving architecture and
 architectural issues of the decentralized, deployed Internet
 infrastructure.  This also includes developing tools that could be
 used in the above tasks.
 The spectrum of potential activities for IRTF groups ranges from the
 visionary to the specific, including the following:
  • Architecture: Where are we, and where do we go from here?
  • Incubation: We think we know where to go, but we don't yet have

the tools to get there.

  • Problem focus: We have some specific problems to solve or potential

solutions to evaluate.

 Some RGs have addressed broad architectural issues, with a mixed set
 of results;  examples of such RGs include the End-to-End Research
 Group, the NameSpace Research Group, and the Routing Research Group.
 For other RGs (e.g., the Host Identity Protocol Research Group), the
 focus of the group is to study a specific proposal, with wider
 architectural issues raised at workshops held by the RG.  Finally,

Floyd, et al. Informational [Page 5] RFC 4440 IAB Thoughts on IRTF Role March 2006

 some RGs are in specific areas with well-defined boundaries, with
 topics that don't have broad impact on the wider Internet
 architecture.
 Where an IRTF RG lies on the spectrum of possible activities depends
 in part on where the IETF and the field itself lie.  For example, in
 areas such as network management where the IETF community has doubts
 or concerns about where we should be going with management
 technology, it would be useful for the IETF to be able to look to the
 IRTF for architectural evaluation.  In contrast, in areas where the
 architectural approach is better established, an RG with an
 incubation approach might be more appropriate.  Finally, where many
 pieces of the puzzle are in place, but some significant problems
 remain, an RG with a problem focus might make sense.
 For those RGs with an architectural focus, it would not be
 appropriate for the IAB to charter an RG to come up with *the*
 architectural perspective on some topic; any such result would
 necessarily have to pass through the wide feedback and consensus
 procedures of the IETF.  However, it is appropriate for the IAB to
 ask an RG for exploration and discussion of an architectural issue;
 e.g., the IAB has asked the Routing Research Group for feedback about
 research objectives for inter-domain routing improvements
 [IABMinutes].  It is also possible for RGs to make recommendations on
 architectural or other issues, with or without the request of the
 IAB; e.g., the End-to-End Research Group [RFC2309] and the Crypto
 Forum Research Group have both made recommendations to the general
 IETF community.  However, some RGs function better as a breeding
 ground for ideas, and not as a consensus-building community.  For
 example, while the NameSpace Research Group was "an invitational
 research group chartered exclusively to make a recommendation to the
 IETF" [NSRG], the group never achieved a clear consensus.
 While the IAB doesn't have clear answers on the evolving role of the
 IRTF in addressing and understanding open architectural issues, this
 is an area that will be explored in the upcoming years, in
 collaboration with the IRTF Chair.  One of the goals of the IAB is to
 make more use of the IRTF in investigating architectural issues.

4.2. The Relationship between the IETF and the IRTF

 Another area that could use more attention is making the relationship
 between the IETF and the IRTF more productive.  For many (though not
 all) of the research groups in the IRTF, part of the power of the RG
 lies in its relationship to the IETF.  Of current and recent RGs, for
 example, this is true of the Anti-Spam (ASRG), the Crypto Forum
 (CFRG), Host Identity Protocol (HIP), and a number of others.

Floyd, et al. Informational [Page 6] RFC 4440 IAB Thoughts on IRTF Role March 2006

 The interchange between the IETF and the IRTF could be improved in
 both directions: from the IETF to the IRTF in terms of information
 about IETF problems that could be helped by further research and
 development, and IETF evaluation of RG efforts and direction; and
 from the IRTF to the IETF in terms of reports, documents, proposals,
 BOFs, and the like.  Current paths for this interchange include IRTF
 reports at IETF plenary meetings; RG meetings before or after the
 IETF, or in one of the scheduled sessions during the IETF; workshops;
 and IRTF documents.
 One possibility (for some research groups, not for all of them) could
 be for an RG to have a design-team-like relationship to the IETF or
 to an IETF working group, with an RG charter that includes an
 agreement of deliverables, with some notion of the time frame for
 those deliverables.  An issue that would need to be resolved here is
 when is it appropriate for an RG to undertake such a relationship vs.
 an IETF WG doing it directly, as is sometimes already done.
 We note that as in WGs, RGs are composed of volunteers who make their
 own choices of research and engineering topics.  RGs are usually
 started by a proposal from individuals who want to form the RG.
 Thus, it is important to realize that IRTF activity often will not be
 viable in the absence of individuals who would like to take on the
 particular work, and this tempers the usefulness of IETF WGs
 providing input to the IRTF regarding desired IRTF directions or
 activities.  For example, while the IETF can request specific
 research activities from IRTF RGs, results will require individuals
 within the RGs willing to undertake this work.
 IRTF RGs have been of significant benefit to the IETF; a number of
 IETF proposals began as discussions in the End-to-End Research Group,
 for example.  At the same time, the interchange with RGs can take
 significant time and effort from WG chairs and from ADs, sometimes
 with little to show for it if the RG's direction is at odds with that
 desired by the WG chairs or ADs.  One task for the future is to
 improve the dialogue between the IETF and the IRTF while not
 increasing the load on WG chairs and ADs.
 One role of the IRTF could be to open some new communication paths
 between the research community and the IETF.  Over the last ten
 years, as the Internet has grown and matured, and the difficulties of
 making changes to the Internet architecture have increased, the
 research community's participation in the IETF has dropped.  We are
 not necessarily expecting to reverse this trend, but it would be good
 for the output of the research community to reach the IETF somewhat
 more than it does now, and for the research community to hear more
 from the IETF.

Floyd, et al. Informational [Page 7] RFC 4440 IAB Thoughts on IRTF Role March 2006

 We would like to shape an IRTF that meets the needs of researchers in
 this domain, providing interaction both with other researchers and
 with other industry technologists.  In this respect, we would like to
 see an IRTF that has momentum that is self-sustaining from voluntary
 efforts, that undertakes (some) work on topics that align to the
 interests of the IETF, and in such a fashion continues to be of
 material assistance to the IETF standardization effort.  We would
 also like to see an IRTF that continues to give thoughtful
 consideration and input to the development of the Internet
 architecture.

4.3. Relationships between the Research and Development Communities

 One of the current and future roles played by the IRTF is that of a
 bridge between the research and development communities; the research
 community in general is less of an active force in the IETF than it
 was in the beginning of the IETF's history.  At the risk of resorting
 to stereotypes, IETFers sometimes view the network research community
 as irrelevant or disconnected from reality, while researchers
 sometimes view the IETF as insufficiently thoughtful or as an
 unproductive place for investing one's research energies.  There is
 also a natural difference in timescales, with the IETF more focused
 on near- to medium-term issues, and researchers often more focused on
 longer-term issues.
 Unfortunately, disconnections between the research and development
 communities can hurt both the research and the development.  Just as
 one example, from "Failure to Thrive: QoS and the Culture of
 Operational Networking" [B03]: "Remarkable intelligence and energy
 have been lavished upon the architectural design of QoS, but much
 less attention has been devoted to careful analysis of the relevant
 problem space from an operational or economic perspective.  This
 discrepancy is symptomatic of a broken (or attenuated) feedback loop
 between network operations and research."  Thus, one potential role
 of the IRTF is to help provide a productive forum that improves the
 communication in both directions between the two communities.

4.3.1. What's in a Name: On the Name `Research Group'

 There have been proposals that for some groups the name "Research
 Group" is incorrect or unnecessarily off-putting to some potential
 participants and that other names such as "Architecture Group" might
 in some cases be more useful.  Such a terminology change is
 potentially quite significant, and needs to be evaluated in terms of
 the IAB's overall role and responsibility for guiding the development
 of architectural considerations within the IETF.  Another issue is
 that different RGs have different mixes of people, in terms of

Floyd, et al. Informational [Page 8] RFC 4440 IAB Thoughts on IRTF Role March 2006

 researchers from academia, industry practitioners, and IETF WG
 participants; it is not clear how changing the names would affect
 this.

4.4. The RFC Track for IRTF Documents

 Currently, RFCs produced by RGs are published as individual
 submissions, under the review of the RFC Editor [RFC3932].  There is
 currently a discussion (and pending Internet-Draft) about the need
 for a venue for publishing RG output that is clearly marked as
 research, as opposed to the output of an IETF WG.  This is both to
 more clearly distinguish RG output from standards documents of the
 IETF and to give RG output more visibility than that of individual
 submissions.  Similarly, RG output might have different reviewing
 criteria from that of other documents considered as individual
 submissions.  This discussion is ongoing.
 More visibility for RG Internet-Drafts could increase the level of
 interchange between the RG and the rest of the community.
 It would also be helpful to decrease the delay in the publication
 time for IRTF RFCs.  Anything that *increased* the publication time
 would probably be counterproductive.

5. Security Considerations

 There are no security considerations in this document.

6. Acknowledgements

 This document comes out of discussions in the IAB.  Many thanks to
 Bob Braden, Rajeev Koodli, J.P. Martin-Flatin, and Gabriel Montenegro
 for feedback on this document.

Floyd, et al. Informational [Page 9] RFC 4440 IAB Thoughts on IRTF Role March 2006

7. Normative References

 [RFC2014]     Weinrib, A. and J. Postel, "IRTF Research Group
               Guidelines and Procedures", BCP 8, RFC 2014, October
               1996.

8. Informative References

 [B03]         Bell, G., "Failure to Thrive: QoS and the Culture of
               Operational Networking", Proceedings of the ACM SIGCOMM
               Workshop on Revisiting IP QoS: What Have We Learned,
               Why Do We Care?, August 2003.
 [E2ERG]       Braden, B., "The End-to-end Research Group - Internet
               Philosophers and Physicists", Presentation to the IETF
               plenary, March 1998.
 [IABMinutes]  Minutes, IAB Teleconference -- June 12, 2001,
               http://www.iab.org/documents/iabmins/
               IABmins.2001-06-12.html.
 [IABWebPages] A Brief History of the Internet Advisory / Activities /
               Architecture Board,
               http://www.garykessler.net/library/ietf_hx.html.
 [NSRG]        Web page, NameSpace Research Group (NSRG),
               http://www.irtf.org/charter?gtype=old-rg&group=nsrg.
 [RFC2309]     Braden, B., et al., "Recommendations on Queue
               Management and Congestion Avoidance in the Internet",
               RFC 2309, April 1998.
 [RFC3160]     Harris, S., "The Tao of IETF - A Novice's Guide to the
               Internet Engineering Task Force", FYI 17, RFC 3160,
               August 2001.
 [RFC3932]     Alvestrand, H., "The IESG and RFC Editor Documents:
               Procedures", BCP 92, RFC 3932, October 2004.

Floyd, et al. Informational [Page 10] RFC 4440 IAB Thoughts on IRTF Role March 2006

Authors' Addresses

 Internet Architecture Board
 EMail:  iab@iab.org
 Internet Architecture Board Members at the time this document was
 approved were:
 Bernard Aboba
 Loa Andersson
 Brian Carpenter (IETF Chair)
 Leslie Daigle (IAB Chair)
 Patrik Faltstrom
 Bob Hinden
 Kurtis Lindqvist
 David Meyer
 Pekka Nikander
 Eric Rescorla
 Pete Resnick
 Jonathan Rosenberg
 Lixia Zhang
 The IRTF Chair at the time this document was published was Aaron
 Falk.
 We note that when this document was begun, Sally Floyd was a member
 of the IAB, and Vern Paxson, as IRTF chair at the time, was an
 ex-officio member of the IAB.
 Sally Floyd, Editor
 International Computer Science Institute
 1947 Center St., Suite 600
 Berkeley, CA 94704
 Phone: +1 510-666-2989
 EMail: floyd@acm.org
 URL: http://www.icir.org/floyd/
 Vern Paxson, Editor
 International Computer Science Institute
 1947 Center St., Suite 600
 Berkeley, CA 94704
 Phone: +1 510-666-2882
 EMail: vern@icir.org

Floyd, et al. Informational [Page 11] RFC 4440 IAB Thoughts on IRTF Role March 2006

 Aaron Falk, Editor
 USC/Information Sciences Institute
 4676 Admiralty Way
 Marina del Rey, CA 90292
 Phone: +1 310-822-1511
 EMail: falk@isi.edu

Floyd, et al. Informational [Page 12] RFC 4440 IAB Thoughts on IRTF Role March 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Floyd, et al. Informational [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4440.txt · Last modified: 2006/03/23 18:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki