diff options
Diffstat (limited to 'doc/rfc/rfc4440.txt')
| -rw-r--r-- | doc/rfc/rfc4440.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc4440.txt b/doc/rfc/rfc4440.txt new file mode 100644 index 0000000..01fc898 --- /dev/null +++ b/doc/rfc/rfc4440.txt @@ -0,0 +1,731 @@ + + + + + + +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] + |