idnits 2.17.1 draft-iab-irtf-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 December 2005) is 6700 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 3160 (Obsoleted by RFC 4677) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Floyd 2 INTERNET-DRAFT V. Paxson 3 draft-iab-irtf-02.txt A. Falk 4 Expires: June 2006 Editors 5 20 December 2005 7 IAB Thoughts on the Role of the Internet Research Task Force 8 (IRTF) 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 2006. 35 Abstract 37 This document is an IAB (Internet Architecture Board) report on the 38 role of the IRTF (Internet Research Task Force), both on its own and 39 in relationship to the IETF. This document evolved from a 40 discussion within the IAB as part of a process of appointing a new 41 chair of the IRTF. 43 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 44 Changes from draft-iab-irtf-01.txt: 45 * Changes in response to feedback from Ran Atkinson: 46 - NSRG requiring consensus decisions. 47 - Updated list of IAB members. 48 - Added a reference to RFC 3932. 49 * Changes in responses to feedback from J.P. Martin-Flatin: 50 - Clarified phrase about "IETF-related informational RFCs". 51 - Clarified phrase about "gateways controlling the 52 advancement of [...] RFCs in the IETF" 53 - Clarified discussion in "Range of activities". 54 - Moved section on "What's in a Name" to an earlier 55 subsection. 56 - Deleted sentence about where IRTF internet-drafts are 57 listed on the internet-drafts web page. 58 * Editing changes in response to feedback from Spencer Dawkins: 59 - Clarified discussion of implications of IRTF members being 60 volunteers. 61 - Clarified that "new chair of the IRTF" referred to Aaron. 62 * Changes for Aaron to make: 63 - Addressing Ran's feedback about the IRTF publication process. 64 Changes from draft-iab-irtf-00.txt: 65 * Added the following sentence: "One of the goals of the IAB is 66 to make more use of the IRTF in investigating 67 architectural issues." 68 * Added list of past IRTF chairs. 69 * Revised Abstract and first paragraph of Introduction. 70 * Corrected typos. 71 * Added a section on "Relationships between the Research and 72 Development Communities" 73 * Topics suggested that have not been added to the document: 74 - Adding a section about the IRTF and SDOs. 75 - Non-ASCII formats for IRTF documents? 76 More transitory communication? 77 Is there a need for tools for the IRTF? 78 - RGs such as MOBOPTS are becoming too much a part of the 79 standardization process? 80 (We say in this document that this shouldn't happen...) 81 Table of Contents 83 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. The Relationship between the IRTF, the IAB, and 85 the IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 86 2.1. Differences between IRTF and IETF Groups . . . . . . . . 5 87 2.2. Research Groups as Non-blocking Entities . . . . . . . . 5 88 3. The Range of IRTF Groups. . . . . . . . . . . . . . . . . . . 5 89 4. Issues for the Future . . . . . . . . . . . . . . . . . . . . 6 90 4.1. IRTF Groups and Network Architecture . . . . . . . . . . 7 91 4.2. The Relationship between the IETF and the 92 IRTF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 4.3. Relationships between the Research and 94 Development Communities . . . . . . . . . . . . . . . . . . . 10 95 4.3.1. What's in a Name: on the Name 96 `Research Group' . . . . . . . . . . . . . . . . . . . . . 10 97 4.4. The RFC Track for IRTF Documents . . . . . . . . . . . . 10 98 5. Security. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 99 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 11 100 Normative References . . . . . . . . . . . . . . . . . . . . . . 11 101 Informative References . . . . . . . . . . . . . . . . . . . . . 11 102 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 12 103 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 12 104 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13 105 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 13 107 1. Introduction 109 As part of the process of appointing a new chair of the Internet 110 Research Task Force (IRTF), the IAB considered the future role of 111 the IRTF both on its own, and in relationship to the IETF. The IAB 112 has expanded this discussion into this IAB report on the role of the 113 IRTF, and circulated this document for wider community review. [As 114 one result of this discussion, Aaron Falk was appointed the new 115 chair of the IRTF in March 2005.] 117 2. The Relationship between the IRTF, the IAB, and the IETF 119 Before 1989, the IAB (then the Internet Activities Board, and now 120 the Internet Architecture Board) oversaw a number of task forces. 121 In 1989, organizational changes were made to coalesce these task 122 forces into two groups, the IETF and the IRTF. The IRTF was tasked 123 to consider long-term research problems in the Internet, and the 124 IETF was to concentrate on short-to-medium term engineering issues 125 related to the Internet. At this time, all of the task forces 126 except the IETF were restructured as IRTF research groups. For 127 example, the End-to-End Task Force became the IRTF's End-to-End 128 Research Group (E2ERG) and the Privacy & Security Task Force became 129 the IRTF's Privacy & Security Research Group (PSRG) [IAB Web Pages] 130 [RFC 3160] [E2ERG]. 132 Much of the early participation in the IETF as well as in the IRTF 133 was from the academic and research communities. (We don't have a 134 citation from this, but a look at the members of the IAB from the 135 80's and early 90's shows IAB members from institutions such as MIT, 136 UCLA, BBN, UCL, SDSC, and the like, while IAB members from the last 137 few years were more likely to list their organizations at the time 138 of service as Cisco, IBM, Microsoft, Nokia, Qualcomm, and Verisign 139 [IAB Web Pages]. We expect that a study of authors of RFCs would 140 show a similar trend over time, with fewer authors from the academic 141 and research communities, and more authors from the commercial 142 world.) While the IRTF has continued to have significant 143 participation from the academic and research communities, the IETF 144 has focused on standards development, and has become dominated by 145 the needs of the commercial sector. 147 The IRTF has generally focused on investigation into areas that are 148 not considered sufficiently mature for IETF standardization, as well 149 as investigation of areas that are not specifically the subject of 150 standardization, but could guide future standards efforts. 152 The IRTF Research Groups guidelines and procedures are described in 153 RFC 2014. The IRTF Chair is appointed by the Internet Architecture 154 Board (IAB), and charters IRTF Research Groups (RGs) in consultation 155 with the Internet Research Steering Group (IRSG) and with approval 156 of the IAB. The chairs of the RGs comprise the main part of the 157 Internet Research Steering Group (IRSG), although the IRTF Chair can 158 also appoint at-large members to the IRSG. 160 As RFC 2014 states, the IRTF does not set standards. While 161 technologies developed in a Research Group (RG) can be brought to 162 the IETF for possible standardization, "Research Group input carries 163 no more weight than other community input, and goes through the same 164 standards setting process as any other proposal" [RFC 2014] (Section 165 1.1). This is necessary to ensure that RGs don't become a part of 166 the standards process itself. 168 RFC 2014 continues to say that "since the products are research 169 results, not Internet standards, consensus of the group is not 170 required" [RFC 2014] (Section 3). However, the NameSpace Research 171 Group was one RG that did require consensus decisions; this group 172 was chartered exclusively to make a recommendation to the IETF. 174 RFC 2014 goes on to describe Research Group operation, meeting 175 management, staff roles, group documents, and the like. This 176 document is not a revision of RFC 2014, but instead a more wide- 177 ranging discussion of the possible roles of the IRTF. 179 The past history of IRTF Chairs is as follows: Dave Clark 180 (1989-1992); Jon Postel (1992-1995); Abel Weinrib (1995-1999); Erik 181 Huizer (1999-2001); Vern Paxson (2001-2005). 183 2.1. Differences between IRTF and IETF Groups 185 A key difference between IRTF research groups and IETF working 186 groups is that IRTF groups are not trying to produce standards of 187 any kind, and that the output of IRTF groups does not require 188 consensus within the RG, or broad consensus from the IETF. 190 In some cases, IRTF groups have acted as research groups with 191 minimal constraints, creating a community for discussing research 192 proposals, with mature proposals "tossed over the fence" to an IETF 193 group for standardization. The RMRG (Reliable Multicast Research 194 Group) was an example of such a group, with standardization efforts 195 in RMT (the Reliable Multicast Transport working group). 197 2.2. Research Groups as Non-blocking Entities 199 As stated in RFC 2014, the IRTF does not set standards. It is 200 important that, unless clearly specified otherwise by the IESG, 201 research groups do not act as gateways controlling the advancement 202 of standards, experimental RFCs, or informational RFCs produced by 203 working groups in the IETF. 205 Similarly, as stated in RFC 2014, existing research groups also do 206 not necessarily prevent the creation of new research groups in 207 related areas. Of course, when considering a proposal for a new 208 research group, it is perfectly appropriate for the IRTF and the IAB 209 to consider the relationship with existing research groups. 210 However, "multiple Research Groups working in the same general area 211 may be formed if appropriate" [RFC 2014] (Sections 1.1,2.1). 213 3. The Range of IRTF Groups 215 There is a wide range of ways that IRTF groups can currently be 216 structured. Some of the most significant are: 218 * Membership: Groups might be open or closed (in terms of 219 membership). The End-to-End Research Group and the NameSpace 220 Research Group are both past examples of closed RGs. 222 * Time-scale: While RGs are generally long-term, groups could be 223 either long-term (on-going), or short-term with a specific goal; the 224 NameSpace Research Group is an example of an RG that was chartered 225 as a short-lived group [NSRG]. We note that RFC 2014, written in 226 1996, assumed that RGs would be long-term: "Research Groups are 227 expected to have the stable long term membership needed to promote 228 the development of research collaboration and teamwork in exploring 229 research issues" [RFC 2014] (Section 1). 231 * Relationship to IETF: Groups can include a goal of producing 232 proposals to be considered in the IETF (e.g., the Anti-Spam Research 233 Group), or can be independent of any current or proposed work in the 234 IETF (e.g., the Delay-Tolerant Networking Research Group). 236 * Range of activities: IRTF activities could consist not only of 237 research groups and their associated meetings, workshops, and other 238 activities, but also of separate workshops or other one-time 239 activities organized directly by the IRTF. To date, however, the 240 IRTF has not organized such activities other than in the form of 241 BOFs at IETF meetings. 243 * Both research and development: IRTF groups can focus on 244 traditional research activities, but they could also focus on 245 development, on tool-building, on operational testing or protocol 246 interoperability testing, or on other activities that don't fit the 247 framework of a Working Group (WG). Instead of having a specific 248 plan for the evolution of the IRTF, we think that this will have to 249 be explored over time, with discussions between the IRTF Chair, the 250 IRSG, and the IAB (and with the IESG as appropriate). 252 As discussed above, the IAB believes that the range of research 253 groups could be expanded further, in terms of timescale, 254 relationship to the IETF, range of activities, and range between 255 research and development. 257 4. Issues for the Future 259 This section discusses some of the issues in the future evolution of 260 the IRTF. A key issue, discussed in Section 4.1 below, concerns how 261 the IRTF can best contribute on questions of network architecture. 263 Similar issues could be raised in how the IRTF can best contribute 264 to incubating technology for later development in the IETF. We 265 emphasize that we are not proposing that the IRTF should become a 266 de-facto holding point for technologies that are not making clear 267 progress in the WGs. Some technologies might not make progress in 268 WGs because of key open issues, making an RG an appropriate step. 270 Other technologies, however, might not make progress in WGs because 271 of a lack of interest, inherent design weaknesses, or some other 272 reason that does not justify moving it into an RG instead. 274 4.1. IRTF Groups and Network Architecture 276 One interest of the IAB is how progress is made on issues of network 277 architecture. This includes help in developing and evaluating new 278 architectures, and in understanding the evolving architecture and 279 architectural issues of the decentralized, deployed Internet 280 infrastructure. This also includes developing tools that could be 281 used in the above tasks. 283 The spectrum of potential activities for IRTF groups ranges from the 284 visionary to the specific, including the following: 286 * Architecture: where are we, and where do we go from here? 288 * Incubation: we think we know where to go, but we don't yet have 289 the tools to get there. 291 * Problem focus: We have some specific problems to solve or 292 potential solutions to evaluate. 294 Some RGs have addressed broad architectural issues, with a mixed set 295 of results; examples of such RGs include the End-to-End Research 296 Group, the NameSpace Research group, and the Routing Research Group. 297 For other RGs (e.g., the Host Identity Protocol Research Group), the 298 focus of the group is to study a specific proposal, with wider 299 architectural issues raised at workshops held by the RG. Finally, 300 some RGs are in specific areas with well-defined boundaries, with 301 topics that don't have broad impact on the wider Internet 302 architecture. 304 Where an IRTF RG lies on the spectrum of possible activities depends 305 in part on where the IETF and the field itself lies. For example, 306 in areas such as network management where the IETF community has 307 doubts or concerns about where we should be going with management 308 technology, it would be useful for the IETF to be able to look to 309 the IRTF for architectural evaluation. In contrast, in areas where 310 the architectural approach is better established, an RG with an 311 incubation approach might be more appropriate. Finally, where many 312 pieces of the puzzle are in place, but some significant problems 313 remain, an RG with a problem focus might make sense. 315 For those RGs with an architectural focus, it would not be 316 appropriate for the IAB to charter an RG to come up with *the* 317 architectural perspective on some topic; any such result would 318 necessarily have to pass through the wide feedback and consensus 319 procedures of the IETF. However, it is appropriate for the IAB to 320 ask an RG for exploration and discussion of an architectural issue; 321 e.g., the IAB has asked the Routing Research Group for feedback 322 about research objectives for inter-domain routing improvements [IAB 323 Minutes]. It is also possible for RGs to make recommendations on 324 architectural or other issues, with or without the request of the 325 IAB; e.g., the End-to-End Research Group [RFC 2309] and the Crypto 326 Forum Research Group have both made recommendations to the general 327 IETF community. However, some RGs function better as a breeding 328 ground for ideas, and not as a consensus-building community. For 329 example, while the NameSpace Research Group was "an invitational 330 research group chartered exclusively to make a recommendation to the 331 IETF" [NSRG], the group never achieved a clear consensus. 333 While the IAB doesn't have clear answers on the evolving role of the 334 IRTF in addressing and understanding open architectural issues, this 335 is an area that will be explored in the upcoming years, in 336 collaboration with the IRTF Chair. One of the goals of the IAB is 337 to make more use of the IRTF in investigating architectural issues. 339 4.2. The Relationship between the IETF and the IRTF 341 Another area that could use more attention is making the 342 relationship between the IETF and the IRTF more productive. For 343 many (though not all) of the research groups in the IRTF, part of 344 the power of the RG lies in its relationship to the IETF. Of 345 current and recent RGs, for example, this is true of the ASRG (Anti- 346 Spam), the CFRG (Crypto Forum), HIP (Host Identity Protocol), and a 347 number of others. 349 The interchange between the IETF and the IRTF could be improved in 350 both directions: from the IETF to the IRTF in terms of information 351 about IETF problems that could be helped by further research and 352 development, and IETF evaluation of RG efforts and direction; and 353 from the IRTF to the IETF in terms of reports, documents, proposals, 354 BOFs, and the like. Current paths for this interchange include IRTF 355 reports at IETF plenary meetings; RG meetings before or after the 356 IETF, or in one of the scheduled sessions during the IETF; 357 workshops; and IRTF documents. 359 One possibility (for some research groups, not for all of them) 360 could be for an RG to have a design-team-like relationship to the 361 IETF or to an IETF working group, with an RG charter that includes 362 an agreement of deliverables, with some notion of the timeframe for 363 those deliverables. An issue that would need to be resolved here is 364 when is it appropriate for an RG to undertake such a relationship 365 vs. an IETF WG doing it directly, as is sometimes already done. 367 We note that as in WGs, RGs are composed of volunteers who make 368 their own choices of research and engineering topics. RGs are 369 usually started by a proposal from individuals who want to form the 370 RG. Thus, it is important to realize that IRTF activity often will 371 not be viable in the absence of individuals who would like to take 372 on the particular work, and this tempers the usefulness of IETF WGs 373 providing input to the IRTF regarding desired IRTF directions or 374 activities. For example, while the IETF can request specific 375 research activities from IRTF RGs, results will require individuals 376 within the RGs willing to undertake this work. 378 IRTF RGs have been of significant benefit to the IETF; a number of 379 IETF proposals began as discussions in the End-to-End Research 380 Group, for example. At the same time, the interchange with RGs can 381 take significant time and effort from WG chairs and from ADs, 382 sometimes with little to show for it if the RG's direction is at 383 odds with that desired by the WG chairs or ADs. One task for the 384 future is to improve the dialogue between the IETF and the IRTF 385 while not increasing the load on WG chairs and ADs. 387 One role of the IRTF could be to open some new communication paths 388 between the research community and the IETF. Over the last ten 389 years, as the Internet has grown and matured, and the difficulties 390 of making changes to the Internet architecture have increased, the 391 research community's participation in the IETF has dropped. We are 392 not necessarily expecting to reverse this trend, but it would be 393 good for the output of the research community to reach the IETF 394 somewhat more than it does now, and for the research community to 395 hear more from the IETF. 397 We would like to shape an IRTF that meets the needs of researchers 398 in this domain, providing interaction both with other researchers 399 and with other industry technologists. In this respect we would 400 like to see an IRTF that has momentum that is self-sustaining from 401 voluntary efforts, that undertakes (some) work on topics that align 402 to the interests of the IETF, and in such a fashion continues to be 403 of material assistance to the IETF standardization effort. We would 404 also like to see an IRTF that continues to give thoughtful 405 consideration and input to the development of the Internet 406 architecture. 408 4.3. Relationships between the Research and Development Communities 410 One of the current and future roles played by the IRTF is that of a 411 bridge between the research and development communities; the 412 research community in general is less of an active force in the IETF 413 than it was in the beginning of the IETF's history. At the risk of 414 resorting to stereotypes, IETFers sometimes view the network 415 research community as irrelevant or disconnected from reality, while 416 researchers sometimes view the IETF as insufficiently thoughtful or 417 as an unproductive place for investing one's research energies. 418 There is also a natural difference in time scales, with the IETF 419 more focused on near-to-medium-term issues, and researchers often 420 more focused on longer-term issues. 422 Unfortunately, disconnections between the research and development 423 communities can hurt both the research and the development. Just as 424 one example, from "Failure to Thrive: QoS and the Culture of 425 Operational Networking" [B03] : "Remarkable intelligence and energy 426 have been lavished upon the architectural design of QoS, but much 427 less attention has been devoted to careful analysis of the relevant 428 problem space from an operational or economic perspective. This 429 discrepancy is symptomatic of a broken (or attenuated) feedback loop 430 between network operations and research." Thus one potential role 431 of the IRTF is to help provide a productive forum that improves the 432 communication in both directions between the two communities. 434 4.3.1. What's in a Name: on the Name `Research Group' 436 There have been proposals that for some groups the name "Research 437 Group" is incorrect or unnecessarily off-putting to some potential 438 participants, and that other names such as "Architecture Group" 439 might in some cases be more useful. Such a terminology change is 440 potentially quite significant, and needs to be evaluated in terms of 441 the IAB's overall role and responsibility for guiding the 442 development of architectural considerations within the IETF. 443 Another issue is that different RGs have different mixes of people, 444 in terms of researchers from academia, industry practitioners, and 445 IETF WG participants; it is not clear how changing the names would 446 affect this. 448 4.4. The RFC Track for IRTF Documents 450 Currently, RFCs produced by RGs are published as individual 451 submissions, under the review of the RFC Editor [RFC 3932]. There 452 is currently a discussion (and pending internet-draft) about the 453 need for a venue for publishing RG output that is clearly marked as 454 research, as opposed to the output of an IETF WG. This is both to 455 more clearly distinguish RG output from standards documents of the 456 IETF, and to give RG output more visibility than that of individual 457 submissions. Similarly, RG output might have different reviewing 458 criteria from that of other documents considered as individual 459 submissions. This discussion is on-going. 461 More visibility for RG internet drafts could increase the level of 462 interchange between the RG and the rest of the community. 464 It would also be helpful to decrease the delay in the publication 465 time for IRTF RFCs. Anything that *increased* the publication time 466 would probably be counterproductive. 468 5. Security 470 There are no security considerations in this document. 472 6. Acknowledgements 474 This document comes out of discussions in the IAB. Many thanks for 475 Bob Braden, Aaron Falk, Rajeev Koodli, J.P. Martin-Flatin, and 476 Gabriel Montenegro for feedback on this document. 478 Normative References 480 [RFC 2014] A. Weinrib and J. Postel, IRTF Research Group Guidelines 481 and Procedures, RFC 2014, October 1996. Best Current Practice. 483 Informative References 485 [B03] G. Bell, "Failure to Thrive: QoS and the Culture of 486 Operational Networking", Proceedings of the ACM SIGCOMM Workshop on 487 Revisiting IP QoS: What Have We Learned, Why Do We Care?, August 488 2003. 490 [E2ERG] B. Braden, "The End-to-end Research Group - Internet 491 Philosophers and Physicists", Presentation to the IETF plenary, 492 March 1998. 494 [IAB Minutes] Minutes, IAB Teleconference -- June 12, 2001, URL 495 "http://www.iab.org/documents/iabmins/IABmins.2001-06-12.html". 497 [IAB Web Pages] A Brief History of the Internet Advisory / 498 Activities / Architecture Board, URL 499 "http://www.garykessler.net/library/ietf_hx.html". 501 [NSRG] Web page, NameSpace Research Group (NSRG), URL 502 "http://www.irtf.org/historical/namespace.html". 504 [RFC 2309] B. Braden et al., Recommendations on Queue Management and 505 Congestion Avoidance in the Internet, RFC 2309, April 1998. 507 [RFC 3160] S. Harris, "The Tao of IETF - A Novice's Guide to the 508 Internet Engineering Task Force", RFC 3160, August 2001. 510 [RFC 3932] H. Alvestrand, The IESG and RFC Editor Documents: 511 Procedures, RFC 3932, October 2004. 513 IANA Considerations 515 There are no IANA considerations in this document. 517 AUTHORS' ADDRESSES 519 Internet Architecture Board 520 EMail: iab@iab.org 522 Internet Architecture Board Members 523 at the time this document was published were: 525 Bernard Aboba 526 Loa Andersson 527 Brian Carpenter (IETF Chair) 528 Leslie Daigle (IAB Chair) 529 Patrik Faltstrom 530 Bob Hinden 531 Kurtis Lindqvist 532 David Meyer 533 Pekka Nikander 534 Eric Rescorla 535 Pete Resnick 536 Jonathan Rosenberg 537 Lixia Zhang 539 The IRTF Chair at the time this document was published was Aaron 540 Falk. 542 We note that when this document was begun, Sally Floyd was a member 543 of the IAB, and Vern Paxson, as IRTF chair at the time, was an ex- 544 officio member of the IAB. 546 Full Copyright Statement 548 Copyright (C) The Internet Society (2005). This document is subject 549 to the rights, licenses and restrictions contained in BCP 78, and 550 except as set forth therein, the authors retain all their rights. 552 This document and the information contained herein are provided on 553 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 554 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 555 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 556 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 557 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 558 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 560 Intellectual Property 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed 564 to pertain to the implementation or use of the technology described 565 in this document or the extent to which any license under such 566 rights might or might not be available; nor does it represent that 567 it has made any independent effort to identify any such rights. 568 Information on the procedures with respect to rights in RFC 569 documents can be found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use 574 of such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository 576 at http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at ietf- 582 ipr@ietf.org.