idnits 2.17.1 draft-weinrib-irtf-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 438 has weird spacing: '...uthored docum...' -- 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 (June 11, 1996) is 10179 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1602 (ref. '1') (Obsoleted by RFC 2026) ** Obsolete normative reference: RFC 1603 (ref. '2') (Obsoleted by RFC 2418) Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 A. Weinrib 2 INTERNET-DRAFT Intel Corporation 3 Category: Informational J. Postel 4 ISI 5 Expires December 11, 1996 June 11, 1996 7 IRTF Research Group Guidelines and Procedures 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as ``work in 22 progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 26 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 The Internet Research Task Force (IRTF) has responsibility for 33 organizing groups to investigate research topics related to the 34 Internet protocols, applications, and technology. IRTF activities are 35 organized into Research Groups. This document describes the 36 guidelines and procedures for formation and operation of IRTF 37 Research Groups. It describes the relationship between IRTF 38 participants, Research Groups, the Internet Research Steering Group 39 (IRSG) and the Internet Architecture Board (IAB). The basic duties 40 of IRTF participants, including the IRTF Chair, Research Group Chairs 41 and IRSG members are defined. 43 1. INTRODUCTION 45 This document defines guidelines and procedures for Internet Research 46 Task Force (IRTF) Research Groups. The IRTF focuses on longer term 47 research issues related to the Internet while the parallel 48 organization, the Internet Engineering Task Force (IETF), focuses on 49 the shorter term issues of engineering and standards making. 51 The Internet is a loosely-organized international collaboration of 52 autonomous, interconnected networks; it supports host-to-host 53 communication through voluntary adherence to open protocols and 54 procedures defined by Internet Standards, a collection of which are 55 commonly known as "the TCP/IP protocol suite". Development and 56 review of potential Internet Standards from all sources is conducted 57 by the Internet Engineering Task Force (IETF). The Internet 58 Standards Process is defined in [1]. 60 The IRTF is a composed of a number of focused, long-term, small 61 Research Groups. These groups work on topics related to Internet 62 protocols, applications, architecture and technology. Research Groups 63 are expected to have the stable long term membership needed to 64 promote the development of research collaboration and teamwork in 65 exploring research issues. Participation is by individual 66 contributors, rather than by representatives of organizations. 68 The IRTF is managed by the IRTF Chair in consultation with the 69 Internet Research Steering Group (IRSG). The IRSG membership 70 includes the IRTF Chair, the chairs of the various Research Group and 71 possibly other individuals ("members at large") from the research 72 community. 74 The IRTF Chair is appointed by the IAB, the Research Group chairs are 75 appointed as part of the formation of Research Groups (as detailed 76 below) and the IRSG members at large are chosen by the IRTF Chair in 77 consultation with the rest of the IRSG and on approval by the IAB. 79 In addition to managing the Research Groups, the IRSG may from time 80 to time hold topical workshops focusing on research areas of 81 importance to the evolution of the Internet, or more general 82 workshops to, for example, discuss research priorities from an 83 Internet perspective. 85 This document defines procedures and guidelines for formation and 86 operation of Research Groups in the IRTF. The duties of the IRTF 87 Chair, the Research Group Chairs and IRSG members are also described. 88 Except for members at large of the IRSG, there is no general 89 participation in the IRTF, only participation in a specific Research 90 Group. 92 The document uses: "shall", "will", "must" and "is required" where it 93 describes steps in the process that are essential, and uses: 94 "suggested", "should" and "may" where guidelines are described that 95 are not essential, but are strongly recommended to help smooth 96 Research Group operation. The terms "they", "them" and "their" are 97 used in this document as third-person singular pronouns. 99 1.1. IRTF approach 101 The reader is encouraged to study The Internet Standards Process [1] 102 to gain a complete understanding of the philosophy, procedures and 103 guidelines of the IETF and its approach to standards making. 105 The IRTF does not set standards, and thus has somewhat different and 106 complementary philosophy and procedures. In particular, an IRTF 107 Research Group is expected to be long-lived, producing a sequence of 108 "products" over time. The products of a Research Group are research 109 results that may be disseminated by publication in scholarly journals 110 and conferences, as white papers for the community, as Informational 111 RFCs, and so on. In addition, it is expected that technologies 112 developed in a Research Group will be brought to the IETF as input to 113 IETF Working Group(s) for possible standardization. However, 114 Research Group input carries no more weight than other community 115 input, and goes through the same standards setting process as any 116 other proposal. 118 IRTF Research Groups are formed to encourage research in areas of 119 importance to the evolution of the Internet. Clearly, anyone may 120 conduct such research, whether or not they are members of a Research 121 Group. The expectation is that by sponsoring Research Groups, the 122 IRTF can foster cross-organizational collaboration, help to create 123 "critical mass" in important research areas, and add to the 124 visibility and impact of the work. 126 IRTF Research Groups may have open or closed memberships. Limited 127 membership may be advantageous to the formation of the long term 128 working relationships that are critical to successful collaborative 129 research. However, limited membership must be used with care and 130 sensitivity to avoid unnecessary fragmentation of the work of the 131 research community. Allowing limited membership is in stark contrast 132 to IETF Working Groups, which are always open; this contrast reflects 133 the different goals and environments of the two organizations- 134 research vs. standards setting. 136 To ameliorate the effects of closed membership, all Research Groups 137 are required to regularly report progress to the community, and are 138 encouraged to hold occasional open meetings (most likely co-located 139 with IETF meetings). In addition, the IRTF may host open plenaries at 140 regular IETF meetings during which research results of interest to 141 the community are presented. Finally, multiple Research Groups 142 working in the same general area may be formed if appropriate. 144 Even more than the IETF, the work of the IRSG is expected to be 145 marked by informality. The goal is to encourage and foster valuable 146 research, not to add burdensome bureaucracy to the endeavor. 148 1.2. Acknowledgments 150 This document is based on the March 1994 RFC "IETF Working Group 151 Guidelines and Procedures" by E. Huizer and D. Crocker [2]. 153 2. RESEARCH GROUP FORMATION 155 Research Groups are the activity centers in the IRTF. A Research 156 Group is typically created to address a research area related to 157 Internet protocols, applications, architecture or technology area. 158 Research Groups have the stable long term membership needed to 159 promote the development of research collaboration and teamwork in 160 exploring research issues. Participation is by individual 161 contributors, rather than by representatives of organizations. 163 A Research Group may be established at the initiative of an 164 individual or group of individuals. Anyone interested in creating an 165 IRTF Research Group must submit a charter for the proposed group to 166 the IRTF Chair along with a list of proposed founding members. The 167 charter will be reviewed by the IRSG and then forwarded to the IAB 168 for approval. 170 If approved, the charter is placed on the IRTF Web site, and 171 published in the Internet Monthly Report (IMR). 173 2.1. Criteria for formation 175 In determining whether it is appropriate to create a Research Group, 176 the IRTF Chair, the IRSG and the IAB will consider several issues: 178 - Is the research area that the Research Group plans to address 179 clear and relevant for the Internet community? 181 - Will the formation of the Research Group foster work that would 182 not be done otherwise. For instance, membership drawn from more 183 than a single institution, more than a single country, and so on, 184 is to be encouraged. 186 - Do the Research Group's activities overlap with those of another 187 Research Group? If so, it may still be appropriate to create the 188 Research Group, but this question must be considered carefully 189 since subdividing efforts often dilutes the available technical 190 expertise. 192 - Is there sufficient interest and expertise in the Research Group's 193 topic with at least several people willing to expend the effort 194 that is likely to produce significant results over time? Research 195 Groups require considerable effort, including management of the 196 Research Group process, editing of Research Group documents, and 197 contribution to the document text. IRTF experience suggests that 198 these roles typically cannot all be handled by one person; at 199 least four or five active participants are typically required. To 200 help in this determination, a proposal to create a Research Group 201 should include a list of potential charter members. 203 The Internet Architecture Board (IAB) will also review the charter of 204 the proposed Research Group to determine the relationship of the 205 proposed work to the overall architecture of the Internet Protocol 206 Suite. 208 2.2. Charter 210 A charter is a contract between a Research Group and the IRTF to 211 conduct research in the designated area. Charters may be renegotiated 212 periodically to reflect changes to the current status, organization 213 or goals of the Research Group. 215 The formation of a Research Group requires a charter which is 216 initially negotiated between a prospective Research Group Chair and 217 the IRTF Chair. When the prospective Chair and the IRTF Chair are 218 satisfied with the charter form and content, it becomes the basis for 219 forming a Research Group. 221 A IRTF Research Group charter consists of five sections: 223 1. Research Group Name 225 A Research Group name should be reasonably descriptive or 226 identifiable. Additionally, the group shall define an acronym 227 (maximum 8 printable ASCII characters) to reference the group in 228 the IRTF directories, mailing lists, and general documents. The 229 name and acronym must not conflict with any IETF names and 230 acronyms. 232 2. Chair(s) 234 The Research Group may have one or two Chair(s) to perform the 235 administrative functions of the group. The email address(es) of 236 the Chair(s) shall be included 238 3. Mailing list(s) 239 Each Research Group shall have an address (possibly the Chair's) 240 for members of the Internet community to send queries regarding 241 the Research Group. For instance, for requests to join the 242 group. 244 A Research Group, whether limited membership or open, will have an 245 "interest" Internet mailing list open to all interested parties. 246 This list is used for an open discussion of the issues and 247 announcements of results as they become available. Included 248 should be the address to which an interested party sends a 249 subscription request for the interest list and the procedures to 250 follow when subscribing, and the location of the interest mailing 251 list archive. 253 It is expected that a Research Group may also have a mailing list 254 limited to the regular meeting participants on which substantial 255 part of the work of a Research Group is likely to be conducted via 256 e-mail. 258 4. Membership Policy 260 The Charter must define the membership policy (whether open or 261 limited), and the procedure to apply for membership in the group. 262 While limited membership is permitted, it is in no way encouraged 263 or required. 265 5. Description of Research Group 267 The focus and intent of the group shall be set forth briefly. By 268 reading this section alone, an individual should be able to decide 269 whether this group is relevant to their own work. The first 270 paragraph must give a brief summary of the research area, basis, 271 goal(s) and approach(es) planned for the Research Group. This 272 paragraph will frequently be used as an overview of the Research 273 Group's effort. 275 To facilitate evaluation of the intended work and to provide on- 276 going guidance to the Research Group, the charter shall describe 277 the proposed research and shall discuss objectives and expected 278 impact with respect to the Internet Architecture. 280 3. RESEARCH GROUP OPERATION 282 Research Groups are autonomous and each determines most of the 283 details of its own operation with respect to session participation, 284 reaching closure, norms of behavior, etc. Since the products are 285 research results, not Internet standards, consensus of the group is 286 not required. Rather, the measure of success is the quality and 287 impact of the research results. 289 A number of procedural questions and issues will arise over time, and 290 it is the function of the Research Group Chair to manage the group 291 process, keeping in mind that the overall purpose of the group is to 292 make progress towards realizing the Research Group's goals and 293 objectives. 295 There are few hard and fast rules on organizing or conducting 296 Research Group activities, but a set of guidelines and practices have 297 evolved over time that have proven successful. These are listed here, 298 with actual choices typically determined by the Research Group 299 members and the Chair. 301 3.1. Meeting planning 303 For coordinated, structured Research Group interactions, the Chair 304 must publish to the group mailing list a draft agenda well in advance 305 of the actual meeting. The agenda needs to contain at least: 307 - The items for discussion; 309 - The estimated time necessary per item; and 311 - A clear indication of what documents the participants will 312 need to read before the meeting in order to be well 313 prepared. 315 A Research Group will conduct much of its business via its electronic 316 mail distribution list(s). It is also likely to meet periodically to 317 accomplish those things that are better achieved in more interactive 318 meetings, such as brainstorming, heated altercations, etc. Meetings 319 may be scheduled as telephone conference, video teleconference, or 320 face-to-face (physical) meetings. 322 It is strongly encouraged that all Research Group meetings be 323 recorded in written minutes, to keep informed members who were not 324 present and the community at large and to document the proceedings 325 for present and future members. These minutes should include the 326 agenda for the meeting, an account of the high points of the 327 discussion, and a list of attendees. Unless the Research Group chair 328 decides otherwise, the minutes should be sent to the interest group 329 and made available through the IRTF Web and ftp sites. 331 3.2. Meeting venue 333 Each Research Group will determine the balance of email and face-to- 334 face meetings that is appropriate for making progress on its goals. 336 Electronic mail permits the easiest and most affordable 337 participation; face-to-face meetings often permit better focus, more 338 productive debate and enhanced working relationships. 340 Face-to-face meetings are encouraged to be held co-located with the 341 regular IETF meetings to minimize travel, since IRTF members are 342 often also active in the IETF and to encourage the cross- 343 fertilization that occurs during hallway and after-hours 344 interactions. Furthermore, as described above, even limited- 345 membership Research Groups are encouraged to hold occasional open 346 meetings; an IETF meeting would serve as an ideal venue for such an 347 event. 349 3.3. Meeting management 351 The challenge to managing Research Group meetings is to balance the 352 need for consideration of the various issues, opinions and approaches 353 against the need to allow forward progress. The Research Group, as a 354 whole, has the final responsibility for striking this balance. 356 4. RESEARCH GROUP TERMINATION 358 If, at some point, it becomes evident that a Research Group is not 359 making progress in the research areas defined in its charter, or 360 fails to regularly report the results of its research to the 361 community, the IRTF Chair can, in consultation with Group, either: 363 1. Require that the group recharter to refocus on a different set of problems, 365 2. Request that the group choose new Chair(s), or 367 3. Disband the group. 369 If the Research Group disagrees with the IRTF Chair's choice, it may 370 appeal to the IAB. 372 5. STAFF ROLES 374 Research Groups require considerable care and feeding. In addition 375 to general participation, successful Research Groups benefit from 376 the efforts of participants filling specific functional roles. 378 5.1. IRTF Chair 380 The IRTF Chair is responsible for ensuring that Research Groups 381 produce coherent, coordinated, architecturally consistent and timely 382 output as a contribution to the overall evolution of the Internet 383 architecture. In addition to the detailed tasks related to Research 384 Groups outlined below, the IRTF Chair may also from time to time 385 arrange for topical workshops attended by the IRSG and perhaps other 386 experts in the field. 388 Planning 390 The IRTF Chair monitors the range of activities. This may include 391 encouraging the formation of Research Groups directly, rather than 392 waiting for proposals from IRTF participants. 394 Coordination of Research Groups 396 The IRTF Chair coordinates the work done by the various Research 397 Groups. 399 Reporting 401 The IRTF Chair reports on IRTF progress to the to the IAB and the 402 wider Internet community (including via the IMR). 404 Progress tracking 406 The IRTF Chair tracks and manages the progress of the various 407 Research Groups with the aid of a regular status report on 408 documents and accomplishments from the Research Group Chairs. The 409 resulting reports are made available to the community at large at 410 regular intervals. 412 5.2. IRSG Member 414 Members of the IRSG are responsible for advising the IRTF Chair on 415 the chartering of new Research Groups and other matters relating to 416 the smooth operation of the IRTF. In addition, most IRSG members are 417 also Research Group chairs. 419 5.3. Research Group Chair 421 The Research Group Chair is concerned with making forward progress in 422 the areas under investigation, and has wide discretion in the conduct 423 of Research Group business. The Chair must ensure that a number of 424 tasks are performed, either directly or by others assigned to the 425 tasks. This encompasses at the very least the following: 427 Ensuring the Research Group process and content management 429 The Chair has ultimate responsibility for ensuring that a Research 430 Group achieves forward progress. For some Research Groups, this 431 can be accomplished by having the Chair perform all management- 432 related activities. In other Research Groups -- particularly 433 those with large or divisive participation -- it is helpful to 434 allocate process and/or secretarial functions to other 435 participants. Process management pertains strictly to the style 436 of Research Group interaction and not to its content. The 437 secretarial function encompasses preparation of minutes, and 438 possibly editing of group-authored documents. 440 Moderate the Research Group email list 442 The Chair should attempt to ensure that the discussions on this 443 list are relevant and that not devolve to "flame" attacks or rat- 444 hole into technical trivia. The Chair should make sure that 445 discussions on the list are summarized and that the outcome is 446 well documented (to avoid repetition). 448 Organize, prepare and chair face-to-face and on-line formal meetings 450 The Chair should plan and announce meetings well in advance. (See 451 section on Meeting Planning for procedures.) 453 Communicate results of meetings 455 The Chair and/or Secretary must ensure that minutes of a meeting 456 are taken. 458 Distribute the work 460 It is expected that all Research Group participants will actively 461 contribute to the work of the group. Research Group membership is 462 expected to be a long term commitment by a set of motivated 463 members of the research community. Of course, at any given time 464 more of the work is likely to be done by a few participants with 465 particular interests, set of skills and ideas. It is the task of 466 the Chair to motivate enough experts to allow for a fair 467 distribution of the workload. 469 Document development 471 Research Groups produce documents and documents need authors. 472 However, authorship of papers related to the work of a Research 473 Group is one of the primary reasons that researchers become 474 members, so finding motivated authors should not be a problem. 476 It is up to the Research Group to decide the authorship of papers 477 resulting from Research Group activities. In particular, 478 authorship by the entire group is not required. 480 Document publication 482 The Chair and/or Secretary will work with the RFC Editor to ensure 483 documents to be published as RFCs conform with RFC publication 484 requirements and to coordinate any editorial changes suggested by 485 the RFC Editor. 487 5.2. Research Group Editor/Secretary 489 Taking minutes and editing jointly-authored Research Group documents 490 often is performed by a specifically-designated participant or set of 491 participants. 493 6. RESEARCH GROUP DOCUMENTS 495 6.1. Meeting documents 497 All relevant documents for a meeting (including the final agenda) 498 should be published to the group mailing list and available at least 499 two weeks before a meeting starts. 501 It is strongly suggested that the Research Group Chair make sure that 502 an anonymous FTP directory or Web site be available for the upcoming 503 meeting. All relevant documents (including the final agenda and the 504 minutes of the last meeting) should be placed in this directory. 505 This has the advantage that all participants can retrieve all files 506 in this directory and thus make sure they have all relevant 507 documents. Also, it will be helpful to provide electronic mail-based 508 retrieval for those documents. 510 6.2. Request For Comments (RFC) 512 The work of an IRTF Research Group usually results in publication of 513 research papers and other documents, as well as documents as part of 514 the Informational or Experimental Request For Comments (RFCs) series 515 [1]. This series is the archival publication record for the Internet 516 community. A document can be written by an individual in a Research 517 Group, by a group as a whole with a designated Editor, or by others 518 not involved with the IRTF. The designated author(s) need not 519 include the group Chair(s). 521 NOTE: The RFC series is a publication mechanism only and publication 522 does not determine the status of a document. Status is determined 523 through separate, explicit status labels. In other words, the reader 524 is reminded that all Internet Standards are published as RFCs, but 525 NOT all RFCs specify standards. 527 The RFC's authors are expected to work with the RFC Editor to meet 528 all formatting, review and other requirements that the Editor may 529 impose. Usually, in case of a submission intended as an Informational 530 or Experimental RFC minimal review is necessary, although publication 531 in the Experimental track generally requires IESG review. However, 532 in all cases initial publication as an Internet Draft is preferred. 534 If the Research Group or the RFC Editor thinks that an extensive 535 review is appropriate, the IRTF Chair may be asked to conduct one. 536 This review may either be done by the IRTF Chair, the IRSG, or an 537 independent reviewer selected by the IRTF Chair. Occasionally, 538 review by the IETF or IESG may be appropriate. 540 7. SECURITY CONSIDERATIONS 542 Security issues are not discussed in this memo. 544 8. REFERENCES 546 [1] Internet Architecture Board and Internet Engineering Steering 547 Group, "The Internet Standards Process -- Revision 2", RFC 1602, 548 IAB, IESG, March 1994. Soon to be replaced by "The Internet 549 Standards Process -- Revision 3" currently in draft form; see 550 . 552 [2] Huizer, E. and Crocker, D., "IETF Working Group Guidelines and 553 Procedures", RFC 1603, March 1994. 555 9. AUTHORS' ADDRESSES 557 Abel Weinrib 558 Intel Corporation, MS JF2-74 559 2111 NE 25th Ave. 560 Hillsboro, OR 97124 562 Phone: 503-264-8972 563 EMail: weinrib@intel.com 565 Jon Postel 566 USC - ISI, Suite 1001 567 4676 Admiralty Way 568 Marina del Rey, CA 90292-6695 570 Phone: 310-822-1511 571 EMail: postel@isi.edu 573 INTERNET-DRAFT 574 Expires December 11, 1996