Internet Engineering Task Force S. Floyd INTERNET-DRAFT V. Paxson draft-iab-irtf-00.txt Editors Expires: July 2005 27 January 2005 IAB Thoughts on the Role of the Internet Research Task Force (IRTF) Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, we accept the provisions of Section 3 of RFC 3667 (BCP 78). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract As part of the process of appointing a new chair of the Internet Research Task Force (IRTF) (due to the resignation of the current chair, Vern Paxson), the IAB is considering the future role of the Floyd et al. [Page 1]
INTERNET-DRAFT Expires: July 2005 January 2005 IRTF both on its own, and in relationship to the IETF. The IAB decided to expand this discussion into an IAB report on the role of the IRTF, and to circulate this document for wider community review. 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 . . . . . . . . 4 2.2. Research Groups as Non-blocking Entities . . . . . . . . 4 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. The RFC Track for IRTF Documents . . . . . . . . . . . . 8 4.4. What's in a Name: on the Name `Research Group'. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . . 9 Informative References . . . . . . . . . . . . . . . . . . . . . 9 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 10 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction As part of the process of appointing a new chair of the Internet Research Task Force (IRTF) (due to the resignation of the current chair, Vern Paxson), the IAB is considering the future role of the IRTF both on its own, and in relationship to the IETF. The IAB decided to expand this discussion into an IAB report on the role of the IRTF, and to circulate this document for wider community review. 2. The Relationship between the IRTF, the IAB, and the IETF Before 1989, the IAB (then the Internet Activities Board, and now the Internet Architecture 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, some of the task forces 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 Floyd et al. Section 2. [Page 2]
INTERNET-DRAFT Expires: July 2005 January 2005 the Privacy & Security Task Force became the IRTF's Privacy & Security Research Group (PSRG) [IAB Web Pages] [RFC 3160] [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 80's and early 90'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 [IAB Web Pages]. 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 the IAB. The chairs of the RGs comprise the main part of the Internet Research Steering Group (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 a Research Group (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" [RFC 2014] (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" [RFC 2014] (Section 3). We are not aware of any RGs that require consensus decisions in their operation. 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. Floyd et al. Section 2. [Page 3]
INTERNET-DRAFT Expires: July 2005 January 2005 2.1. Differences between IRTF and IETF Groups A key difference between IRTF research groups and IETF working groups is 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 RMRG (Reliable Multicast Research Group) was an example of such a group, with standardization efforts in RMT (the Reliable Multicast Transport working group). 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 other IETF-related informational RFCs in the IETF. Similarly, as stated in RFC 2014, existing research groups also do not necessarily prevent the creating 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" [RFC 2014] (Sections 1.1,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. * Time-scale: While RGs are generally long-term, groups could be either long-term (on-going), 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" [RFC 2014] (Section 1). Floyd et al. Section 3. [Page 4]
INTERNET-DRAFT Expires: July 2005 January 2005 * 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, but also of workshops or of other one-time activities. 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). 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 in 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 Floyd et al. Section 4.1. [Page 5]
INTERNET-DRAFT Expires: July 2005 January 2005 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, 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 lies. 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 knotty 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 [IAB Minutes]. 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 [RFC 2309] and the Crypto Forum Research Floyd et al. Section 4.1. [Page 6]
INTERNET-DRAFT Expires: July 2005 January 2005 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. 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 ASRG (Anti- Spam), the CFRG (Crypto Forum), HIP (Host Identity Protocol), NMRG (Network Management), and a number of others. 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 timeframe 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 Floyd et al. Section 4.2. [Page 7]
INTERNET-DRAFT Expires: July 2005 January 2005 activities. 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 takes 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. 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. The RFC Track for IRTF Documents Currently, RFCs produced by RGs are published as individual submissions, under the review of the RFC Editor. 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 on-going. More visibility for RG internet drafts could increase the level of interchange between the RG and the rest of the community. Floyd et al. Section 4.3. [Page 8]
INTERNET-DRAFT Expires: July 2005 January 2005 Currently, RG internet drafts for the "XYZ" research group are labeled as draft-irtf-XYZ, but are listed on the Internet-drafts web page as Individual Submissions (along with the other 1042 individual submissions, at the time of this writing) [ID Web Page]. 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. 4.4. 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 researchers from academia, industry practitioners, and IETF WG participants; it is not clear how changing the names would affect this. 5. Acknowledgements This document comes out of discussions in the IAB. Normative References [RFC 2014] A. Weinrib and J. Postel, IRTF Research Group Guidelines and Procedures, RFC 2014, October 1996. Best Current Practice. Informative References [E2ERG] "The End-to-end Research Group - Internet Philosophers and Physicists", Presentation to the IETF plenary, March 1998. [IAB Minutes] Minutes, IAB Teleconference -- June 12, 2001, URL "http://www.iab.org/documents/iabmins/IABmins.2001-06-12.html". [IAB Web Pages] A Brief History of the Internet Advisory / Activities / Architecture Board, URL "http://www.garykessler.net/library/ietf_hx.html". [ID Web Page] Current Internet-Drafts. URL Floyd et al. [Page 9]
INTERNET-DRAFT Expires: July 2005 January 2005 "http://www.ietf.cnri.reston.va.us/1id-abstracts.html". [NSRG] Web page, NameSpace Research Group (NSRG), URL "http://www.irtf.org/historical/namespace.html". [RFC 2309] B. Braden et al., Recommendations on Queue Management and Congestion Avoidance in the Internet, RFC 2309, April 1998. [RFC 3160] S. Harris, "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", RFC 3160, August 2001. IANA Considerations There are no IANA considerations in this document. AUTHORS' ADDRESSES Internet Architecture Board EMail: iab@iab.org Internet Architecture Board Members at the time this document was published were: Bernard Aboba Harald Alvestrand (IETF chair) Rob Austein Leslie Daigle (IAB chair) Patrik Faltstrom Sally Floyd Mark Handley Bob Hinden Geoff Huston (IAB Executive Director) Jun-ichiro Itojun Hagino Eric Rescorla Pete Resnick Jonathan Rosenberg We note that Vern Paxson, the IRTF chair, is an ex-officio member of the IAB. Full Copyright Statement Copyright (C) The Internet Society 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and Floyd et al. [Page 10]
INTERNET-DRAFT Expires: July 2005 January 2005 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. Floyd et al. [Page 11]
