Network Working Group                                      S. Floyd, Ed.
Request for Comments: 4440                                V. Paxson, Ed.
Category: Informational                                     A. Falk, Ed.
                                                              March 2006
Network Working Group                                      S. Floyd, Ed.
Request for Comments: 4440                                V. Paxson, Ed.
Category: Informational                                     A. Falk, Ed.
                                                              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).




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
   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
1. Introduction
1. 介绍

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

IRTF研究小组指南和程序见RFC 2014。IRTF主席由互联网体系结构委员会(IAB)任命,并与互联网研究指导小组(IRSG)协商并经批准成立IRTF研究小组(RGs)

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所述,IRTF没有制定标准。虽然在RG中开发的技术可以提交给IETF进行可能的标准化,“研究小组的投入并不比其他社区的投入更重要,并且与任何其他提案经历相同的标准制定过程”[RFC2014](第1.1节)。这对于确保RGs不会成为标准流程本身的一部分是必要的。

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继续表示,“由于产品是研究成果,而非互联网标准,因此不需要集团的共识”[RFC2014](第3节)。然而,名称空间研究小组是一个需要一致决定的研究小组;该小组被特许专门向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.

RFC 2014接着描述了研究小组的运作、会议管理、员工角色、小组文件等。本文件不是RFC 2014的修订版,而是对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).

IRTF主席的历史如下:Dave Clark(1989-1992);乔恩·波斯特尔(1992-1995);Abel Weinrib(1995-1999);埃里克·惠泽(1999-2001);弗恩·帕克森(2001-2005)。

2.1. Differences between IRTF and IETF Groups
2.1. IRTF和IETF组之间的差异

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
2.2. 作为非阻塞实体的研究小组

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.

如RFC 2014所述,IRTF未制定标准。重要的是,除非IESG另有明确规定,否则研究小组不得充当控制IETF工作组产生的标准、实验RFC或信息RFC进展的网关。

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).

同样,如RFC 2014所述,现有研究小组也不一定阻止在相关领域创建新的研究小组。当然,当考虑到一个新的研究小组的建议时,IRTF和IAB完全考虑与现有研究组的关系是完全合适的。但是,“如果合适,可在同一一般领域成立多个研究小组”[RFC2014](第1.1节和第2.1节)。

3. The Range of IRTF Groups
3. IRTF群的范围

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.

* 成员资格:组可以是开放的,也可以是封闭的(就成员资格而言)。端到端研究组和名称空间研究组都是封闭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).

* 时间尺度:虽然RG通常是长期的,但团队可以是长期的(持续的)或有特定目标的短期的;名称空间研究组是特许作为短期组[NSRG]的RG的一个示例。我们注意到,1996年编写的RFC 2014假设RGs是长期的:“预计研究小组将拥有稳定的长期成员资格,以促进研究协作和团队合作的发展,探索研究问题”[RFC2014](第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).

* 与IETF的关系:小组可以包括制定IETF(如反垃圾邮件研究小组)中考虑的提案的目标,也可以独立于IETF(如耐延迟网络研究小组)中的任何当前或拟议工作。

* 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.

* 活动范围:研究小组的活动不仅包括研究小组及其相关会议、讲习班和其他活动,还包括研究小组直接组织的单独讲习班或其他一次性活动。然而,迄今为止,IRTF除了在IETF会议上以BOF的形式组织此类活动外,尚未组织其他活动。

* 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).

* 研究和开发:IRTF小组可以专注于传统的研究活动,但也可以专注于开发、工具构建、操作测试或协议互操作性测试,或其他不符合工作组(WG)框架的活动。我们认为,与制定IRTF发展的具体计划不同,这需要随着时间的推移进行探索,由IRTF主席、IRSG和IAB(并酌情与IESG)进行讨论。

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
4. 未来的问题

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
4.1. IRTF组与网络结构

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,


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.

IRTF RG在可能活动范围内的位置部分取决于IETF和现场本身的位置。例如,在网络管理等领域,IETF社区对管理技术的发展方向存在疑问或担忧,因此IETF可以向IRTF寻求架构评估。相反,在架构方法建立得更好的领域,带有孵化方法的RG可能更合适。最后,当许多谜题已经解决,但仍存在一些重大问题时,有问题焦点的RG可能是有意义的。

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.

对于那些关注体系结构的RG,IAB不适合特许RG就某个主题提出*体系结构观点;任何此类结果都必须通过IETF的广泛反馈和协商一致程序。然而,IAB要求RG对架构问题进行探索和讨论是合适的;e、 例如,IAB已要求路由研究小组就域间路由改进的研究目标提供反馈[IAB分钟]。RGs也可以就建筑或其他问题提出建议,无论是否有IAB的要求;e、 例如,端到端研究小组[RFC2309]和加密论坛研究小组都向IETF社区提出了建议。然而,一些RG更适合作为想法的温床,而不是建立共识的社区。例如,尽管名称空间研究小组是“一个特许专门向IETF提出建议的邀请研究小组”[NSRG],但该小组从未达成明确的共识。

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
4.2. IETF和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.


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.

我们注意到,与WGs一样,RGs由志愿者组成,他们自己选择研究和工程主题。RG通常由希望组成RG的个人提出的建议开始。因此,重要的是要认识到,如果没有愿意承担特定工作的个人,IRTF活动通常是不可行的,这就削弱了IETF工作组向IRTF提供所需IRTF方向或活动信息的有用性。例如,虽然IETF可以要求IRTF RGs开展特定的研究活动,但结果将要求RGs内愿意承担这项工作的个人。

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.

IRTF RGs对IETF有显著的好处;例如,许多IETF提案是在端到端研究小组中开始讨论的。同时,与RGs的交流可能需要工作组主席和广告的大量时间和精力,有时,如果RG的方向与工作组主席或广告所期望的方向不一致,则几乎没有证据表明。未来的一项任务是改进IETF和IRTF之间的对话,同时不增加工作组主席和广告的负荷。

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. Relationships between the Research and Development Communities
4.3. 研究和开发社区之间的关系

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'
4.3.1. 名字里有什么:关于“研究小组”的名字

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.


4.4. The RFC Track for IRTF Documents
4.4. IRTF文档的RFC跟踪

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.

这也有助于减少IRTF RFC发布时间的延迟。任何增加出版时间的事情都可能适得其反。

5. Security Considerations
5. 安全考虑

There are no security considerations in this document.


6. Acknowledgements
6. 致谢

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.

本文件来自IAB的讨论。非常感谢Bob Braden、Rajeev Koodli、J.P.Martin Flatin和Gabriel Montegon对本文件的反馈。

7. Normative References
7. 规范性引用文件

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

[RFC2014]Weinrib,A.和J.Postel,“IRTF研究小组指南和程序”,BCP 8,RFC 2014,1996年10月。

8. Informative References
8. 资料性引用

[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.

[B03]Bell,G.“发展失败:QoS和运营网络文化”,ACM SIGCOMM研讨会论文集,重温IP QoS:我们学到了什么,我们为什么关心?2003年8月。

[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, IABmins.2001-06-12.html.

国际律师协会电话会议记录——2001年6月12日, IABmins.2001-06-12.html。

[IABWebPages] A Brief History of the Internet Advisory / Activities / Architecture Board,


[NSRG] Web page, NameSpace Research Group (NSRG),


[RFC2309] Braden, B., et al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.

[RFC2309]Braden,B.,等人,“关于互联网中队列管理和拥塞避免的建议”,RFC 2309,1998年4月。

[RFC3160] Harris, S., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", FYI 17, RFC 3160, August 2001.

[RFC3160]Harris,S.,“IETF之道-互联网工程任务组新手指南”,第17期,RFC 3160,2001年8月。

[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.

[RFC3932]Alvestrand,H.,“IESG和RFC编辑文件:程序”,BCP 92,RFC 3932,2004年10月。

Authors' Addresses


Internet Architecture Board EMail:


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

Bernard Aboba Loa Andersson Brian Carpenter(IETF主席)Leslie Daigle(IAB主席)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.

本文件发布时,IRTF主席是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是IAB的成员,Vern Paxson当时担任IRTF主席,是IAB的当然成员。

Sally Floyd, Editor International Computer Science Institute 1947 Center St., Suite 600 Berkeley, CA 94704

Sally Floyd,编辑国际计算机科学研究所1947中心街,600室伯克利,加利福尼亚州94704

   Phone: +1 510-666-2989
   Phone: +1 510-666-2989

Vern Paxson, Editor International Computer Science Institute 1947 Center St., Suite 600 Berkeley, CA 94704

Vern Paxson,编辑国际计算机科学研究所1947中心街600室,加利福尼亚州伯克利94704

   Phone: +1 510-666-2882
   Phone: +1 510-666-2882

Aaron Falk, Editor USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292

Aaron Falk,南加州大学/信息科学研究所编辑,地址:加利福尼亚州滨海大道4676号,邮编:90292

   Phone: +1 310-822-1511
   Phone: +1 310-822-1511

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.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和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


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




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