RFC 2014
IRTF Research Group Guidelines and Procedures
IRTF Research Group Guidelines and Procedures π
Part 1 of 3
Okay bestie, this is RFC 2014 π It's a Best Current Practice (BCP 8) published in October 1996, written by A. Weinrib of Intel Corporation and J. Postel of ISI. Its title block doesn't list any documents it obsoletes or updates, so it's standing completely on its own β¨
Status of this Memo
This doc specifies an Internet Best Current Practices for the Internet Community, and asks for discussion and suggestions for improvements. Distribution of this memo is unlimited πΈ
Abstract
The Internet Research Task Force (IRTF) is in charge of organizing groups that look into research topics about Internet protocols, applications, and technology. IRTF activity is organized into Research Groups. This doc lays out the guidelines and procedures for forming and running them, and explains how IRTF participants, Research Groups, the Internet Research Steering Group (IRSG), and the Internet Architecture Board (IAB) all fit together. It also defines the basic duties of IRTF participants, including the IRTF Chair, Research Group Chairs, and IRSG members π
1. Introduction π¦
This doc is all about the guidelines and procedures for IRTF Research Groups. The IRTF focuses on longer-term research issues about the Internet, while its sister org, the Internet Engineering Task Force (IETF), handles the shorter-term stuff: engineering and standards making β¨
The Internet is a loosely organized, international collab of autonomous, interconnected networks. It supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards, a collection of which are commonly known as "the TCP/IP protocol suite". Development and review of potential Internet Standards from all sources happens in the IETF. The Internet Standards Process is defined in [1] π
The IRTF is made up of a bunch of focused, long-term, small Research Groups. These groups work on topics related to Internet protocols, applications, architecture, and technology. Research Groups are expected to have the stable, long-term membership needed to build research collaboration and teamwork. Participation is by individual contributors, not by representatives of organizations π«Ά
The IRTF is managed by the IRTF Chair in consultation with the Internet Research Steering Group (IRSG). The IRSG includes the IRTF Chair, the chairs of the various Research Groups, and possibly other individuals ("members at large") from the research community π
The IRTF Chair is appointed by the IAB. Research Group chairs are appointed as part of forming Research Groups (more on that below), and IRSG members at large are chosen by the IRTF Chair in consultation with the rest of the IRSG, then approved by the IAB π
Besides managing the Research Groups, the IRSG MAY from time to time hold topical workshops on research areas that matter for the evolution of the Internet, or more general workshops to, for example, discuss research priorities from an Internet perspective π
This doc defines procedures and guidelines for forming and running Research Groups in the IRTF. It also describes the duties of the IRTF Chair, Research Group Chairs, and IRSG members. Except for members at large of the IRSG, there is no general participation in the IRTF, only participation in a specific Research Group π§
The doc uses SHALL, will, MUST, and REQUIRED where it describes steps in the process that are essential. It uses suggested, SHOULD, and MAY where it describes guidelines that aren't essential but are strongly recommended to help Research Group operation run smoothly. The terms "they", "them", and "their" are used in this document as third-person singular pronouns π
1.1. IRTF approach πΈ
The reader is encouraged to study The Internet Standards Process [1] to fully understand the philosophy, procedures, and guidelines of the IETF and its approach to standards making π
The IRTF does not set standards, so it has a somewhat different and complementary philosophy and set of procedures. In particular, an IRTF Research Group is expected to be long-lived, producing a sequence of "products" over time. Those products are research results that MAY be disseminated by publication in scholarly journals and conferences, as white papers for the community, as Informational RFCs, and so on. It's also expected that technologies developed in a Research Group will be brought to the IETF as input to IETF Working Group(s) for possible standardization. However, Research Group input carries no more weight than other community input, and goes through the same standards setting process as any other proposal π¦
IRTF Research Groups are formed to encourage research in areas important to the evolution of the Internet. Clearly, anyone MAY conduct such research, whether or not they're members of a Research Group. By sponsoring Research Groups, the IRTF can foster cross-organizational collaboration, help create "critical mass" in important research areas, and boost the visibility and impact of the work β¨
IRTF Research Groups MAY have open or closed memberships. Limited membership MAY be advantageous to forming the long-term working relationships that are critical to successful collaborative research. However, limited membership MUST be used with care and sensitivity to avoid unnecessary fragmentation of the work of the research community. Allowing limited membership is in stark contrast to IETF Working Groups, which are always open. This contrast reflects the different goals and environments of the two organizations: research vs. standards setting π
To ease the effects of closed membership, all Research Groups are REQUIRED to regularly report progress to the community, and are encouraged to hold occasional open meetings (most likely co-located with IETF meetings). In addition, the IRTF MAY host open plenaries at regular IETF meetings, where research results of interest to the community are presented. Finally, multiple Research Groups working in the same general area MAY be formed if appropriate π«Ά
Even more than the IETF, the work of the IRSG is expected to be marked by informality. The goal is to encourage and foster valuable research, not to add burdensome bureaucracy to the endeavor π·
1.2. Acknowledgments π
This document is based on the March 1994 RFC "IETF Working Group Guidelines and Procedures" by E. Huizer and D. Crocker [2] π
2. Research Group Formation π§
Research Groups are the activity centers in the IRTF. A Research Group is typically created to address a research area related to Internet protocols, applications, architecture, or technology. Research Groups have the stable, long-term membership needed to build research collaboration and teamwork. Participation is by individual contributors, not by representatives of organizations π
A Research Group MAY be established at the initiative of an individual or a group of individuals. Anyone interested in creating an IRTF Research Group MUST submit a charter for the proposed group to the IRTF Chair, along with a list of proposed founding members. The charter will be reviewed by the IRSG and then forwarded to the IAB for approval π
If approved, the charter is placed on the IRTF Web site and published in the Internet Monthly Report (IMR) π
2.1. Criteria for formation β¨
When deciding whether it's appropriate to create a Research Group, the IRTF Chair, the IRSG, and the IAB will consider several issues:
- Is the research area that the Research Group plans to address clear and relevant for the Internet community?
- Will the formation of the Research Group foster work that would not be done otherwise? For instance, membership drawn from more than a single institution, more than a single country, and so on, is to be encouraged.
- Do the Research Group's activities overlap with those of another Research Group? If so, it MAY still be appropriate to create the Research Group, but this question MUST be considered carefully, since subdividing efforts often dilutes the available technical expertise.
- Is there sufficient interest and expertise in the Research Group's topic, with at least several people willing to expend the effort that is likely to produce significant results over time? Research Groups require considerable effort, including management of the Research Group process, editing of Research Group documents, and contribution to the document text. IRTF experience suggests that these roles typically cannot all be handled by one person; at least four or five active participants are typically REQUIRED. To help in this determination, a proposal to create a Research Group SHOULD include a list of potential charter members. π₯°
The Internet Architecture Board (IAB) will also review the charter of the proposed Research Group to determine the relationship of the proposed work to the overall architecture of the Internet Protocol Suite π
2.2. Charter β¨
okay so a charter is basically a contract π between a Research Group and the IRTF to do research in the designated area. Charters MAY be renegotiated from time to time to reflect changes in the group's current status, organization or goals π.
Forming a Research Group takes a charter π. It starts out being negotiated between a prospective Research Group Chair and the IRTF Chair. Once both of them are happy with the charter's form and content, it becomes the basis for forming the group π.
An IRTF Research Group charter has five sections π :
- Research Group Name
A Research Group name SHOULD be reasonably descriptive or identifiable π·οΈ. The group SHALL also define an acronym (maximum 8 printable ASCII characters) so people can reference it in the IRTF directories, mailing lists and general documents. The name and acronym MUST NOT conflict with any IETF names and acronyms π«.
- Chair(s)
The Research Group MAY have one or two Chair(s) to handle the admin side of things π. The email address(es) of the Chair(s) SHALL be included.
- Mailing list(s)
Each Research Group SHALL have an address (possibly the Chair's) where members of the Internet community can send queries about the group. For instance, that's where you'd send requests to join π¬.
A Research Group, whether it's limited membership or open, will have an "interest" Internet mailing list that's open to all interested parties π¦. This list is for open discussion of issues and for announcing results as they come out. The charter SHALL include the address where an interested party sends a subscription request for the interest list, the procedures to follow when subscribing, and the location of the interest mailing list archive.
It is expected that a Research Group may also have a mailing list limited to its regular meeting participants π. A big chunk of the group's work is likely to happen over email on that list.
- Membership Policy
The Charter MUST define the membership policy (open or limited) and the procedure to apply for membership in the group ποΈ. Limited membership is permitted, but it's in no way encouraged or REQUIRED π.
- Description of Research Group
The focus and intent of the group SHALL be set forth briefly π. Reading this section alone should be enough for someone to decide whether the group is relevant to their own work. The first paragraph MUST give a brief summary of the research area, basis, goal(s) and approach(es) planned for the Research Group. This paragraph will often be used as the overview of the group's effort β¨.
To make the intended work easy to evaluate and to give the Research Group ongoing guidance, the charter SHALL describe the proposed research and SHALL discuss objectives and expected impact with respect to the Internet Architecture π.
3. RESEARCH GROUP OPERATION π§
Research Groups are autonomous, so each one figures out most of the details of its own operation πββοΈ. That covers session participation, reaching closure, norms of behavior and so on. The products are research results, not Internet standards, so group consensus is not REQUIRED π. The real measure of success is the quality and impact of the research results π.
Procedural questions and issues will pop up over time, and it's the Research Group Chair's job to manage the group process π―. Keep in mind that the big goal is to make progress toward the group's goals and objectives.
There are few hard and fast rules for organizing or running Research Group activities π€. There is, however, a set of guidelines and practices that evolved over time and have proven successful. They're listed here, though the actual choices are usually made by the Research Group members and the Chair.
3.1. Meeting planning π
For coordinated, structured Research Group interactions, the Chair MUST publish a draft agenda to the group mailing list well in advance of the meeting. The agenda needs to contain at least:
- The items for discussion;
- The estimated time necessary per item; and
- A clear indication of what documents the participants will need to read before the meeting in order to be well prepared.
Most of the business happens on the group's electronic mail distribution list(s) π§. The group will also likely meet periodically for stuff that's better done interactively, like brainstorming, heated altercations, etc. π₯ Meetings can be held as telephone conferences, video teleconferences, or face-to-face (physical) meetings.
It is strongly encouraged that all Research Group meetings be recorded in written minutes π. This keeps members who weren't there informed, lets the wider community follow along, and documents the proceedings for current and future members. The minutes SHOULD include the agenda for the meeting, an account of the high points of the discussion, and a list of attendees. Unless the Research Group Chair decides otherwise, the minutes SHOULD be sent to the interest group and made available through the IRTF Web and ftp sites π».
3.2. Meeting venue π‘
Each Research Group decides the balance of email and face-to-face meetings that works for making progress on its goals βοΈ.
Email is the easiest and most affordable way to take part π. Face-to-face meetings often give better focus, more productive debate and stronger working relationships π«Ά.
Face-to-face meetings are encouraged to be co-located with the regular IETF meetings π§³. That keeps travel down, since IRTF members are often active in the IETF too, and it encourages the cross-fertilization that happens during hallway and after-hours chats πΈ. Also, as described above, even limited-membership Research Groups are encouraged to hold occasional open meetings, and an IETF meeting would be the ideal venue for that πΈ.
3.3. Meeting management π
Managing Research Group meetings is a balancing act βοΈ. You have to weigh the need to consider the various issues, opinions and approaches against the need to keep things moving forward. The Research Group, as a whole, has the final responsibility for striking that balance π«.
4. RESEARCH GROUP TERMINATION π
If it becomes clear that a Research Group isn't making progress in the research areas defined in its charter, or it fails to regularly report its research results to the community, the IRTF Chair can, in consultation with the Group, do one of the following π¬:
- Require that the group recharter to refocus on a different set of problems,
- Request that the group choose new Chair(s), or
- Disband the group.
If the Research Group disagrees with the IRTF Chair's choice, it MAY appeal to the IAB ποΈ.
5. STAFF ROLES π©βπ»
Research Groups need a lot of care and feeding π±. On top of general participation, successful Research Groups benefit from participants who fill specific functional roles π§.
5.1. IRTF Chair π
The IRTF Chair makes sure Research Groups produce coherent, coordinated, architecturally consistent and timely output that contributes to the overall evolution of the Internet architecture π. Beyond the detailed tasks for Research Groups listed below, the IRTF Chair may also arrange topical workshops from time to time, attended by the IRSG and perhaps other experts in the field π€.
Planning πΊοΈ
The IRTF Chair monitors the range of activities. That can include encouraging the formation of Research Groups directly, rather than waiting for proposals from IRTF participants π‘.
Coordination of Research Groups π€
The IRTF Chair coordinates the work done by the various Research Groups π§©.
Reporting π£
The IRTF Chair reports on IRTF progress to the IAB and the wider Internet community (including via the IMR) π’.
Progress tracking π
The IRTF Chair tracks and manages the progress of the various Research Groups with the help of a regular status report on documents and accomplishments from the Research Group Chairs. The resulting reports are made available to the community at large at regular intervals ποΈ.
5.2. IRSG Member π«Ά
IRSG members are responsible for advising the IRTF Chair on chartering new Research Groups and on other matters relating to the smooth operation of the IRTF π§ . Most IRSG members are also Research Group chairs, so they're basically wearing two hats at once π©π.
5.3. Research Group Chair π
Okay bestie, the Research Group Chair is all about making forward progress on whatever the group is investigating, and they get WIDE discretion over how Research Group business runs π The Chair MUST make sure a bunch of tasks get done, either by doing them directly or by handing them to others. At the very least, that covers the following:
Ensuring the Research Group process and content management πΈ
The Chair has ultimate responsibility for making sure a Research Group actually moves forward β¨ For some groups, the Chair can handle all the management stuff themselves. In other groups, especially ones with big or divisive participation, it helps to hand out process and/or secretarial jobs to other participants π«Ά Process management is strictly about how the group interacts, not what it's talking about. The secretarial function covers writing up the minutes and maybe editing group-authored documents.
Moderate the Research Group email list π§
The Chair SHOULD attempt to make sure list discussions stay relevant and that they don't turn into "flame" attacks or rat-hole into technical trivia π The Chair SHOULD make sure discussions on the list get summarized and that the outcome is well documented, so nobody has to repeat the same thread forever π
Organize, prepare and chair face-to-face and on-line formal meetings ποΈ
The Chair SHOULD plan and announce meetings well in advance. (Check out the Meeting Planning section for the procedures π)
Communicate results of meetings π
The Chair and/or Secretary MUST ensure that minutes of a meeting are taken.
Distribute the work π§
It is expected that all Research Group participants will actively contribute to the work of the group. Research Group membership is expected to be a long-term commitment from a set of motivated members of the research community. Of course, at any given time, more of the work is likely to be done by a few participants with particular interests, skills and ideas. It's the Chair's job to motivate enough experts so the workload gets distributed fairly π«Ά
Document development βοΈ
Research Groups produce documents, and documents need authors. However, authorship of papers related to the group's work is one of the main reasons researchers become members, so finding motivated authors should not be a problem π
It's up to the Research Group to decide the authorship of papers resulting from Research Group activities. In particular, authorship by the entire group is NOT REQUIRED.
Document publication π
The Chair and/or Secretary will work with the RFC Editor to make sure documents to be published as RFCs conform to RFC publication requirements, and to coordinate any editorial changes suggested by the RFC Editor.
5.4. Research Group Editor/Secretary βοΈ
Taking minutes and editing jointly-authored Research Group documents is often done by a specifically-designated participant or set of participants π§
6. RESEARCH GROUP DOCUMENTS π
6.1. Meeting documents ποΈ
All relevant documents for a meeting (including the final agenda) SHOULD be published to the group mailing list and be available at least two weeks before a meeting starts.
It is strongly suggested that the Research Group Chair make sure an anonymous FTP directory or Web site is available for the upcoming meeting. All relevant documents (including the final agenda and the minutes of the last meeting) SHOULD be placed in this directory. This has the advantage that all participants can retrieve all files in this directory and thus make sure they have all relevant documents. Also, it will be helpful to provide electronic mail-based retrieval for those documents π¬
6.2. Request For Comments (RFC) π
The work of an IRTF Research Group usually results in publication of research papers and other documents, as well as documents as part of the Informational or Experimental Request For Comments (RFCs) series [1]. This series is the archival publication record for the Internet community. A document can be written by an individual in a Research Group, by a group as a whole with a designated Editor, or by others not involved with the IRTF. The designated author(s) need not include the group Chair(s) π¦
NOTE: The RFC series is a publication mechanism only and publication does not determine the status of a document. Status is determined through separate, explicit status labels. In other words, the reader is reminded that all Internet Standards are published as RFCs, but NOT all RFCs specify standards. π¨
The RFC's authors are expected to work with the RFC Editor to meet all formatting, review and other requirements that the Editor MAY impose. Usually, in case of a submission intended as an Informational or Experimental RFC, minimal review is necessary, although publication in the Experimental track generally requires IESG review. However, in all cases, initial publication as an Internet Draft is preferred π
If the Research Group or the RFC Editor thinks that an extensive review is appropriate, the IRTF Chair MAY be asked to conduct one. This review MAY either be done by the IRTF Chair, the IRSG, or an independent reviewer selected by the IRTF Chair. Occasionally, review by the IETF or IESG MAY be appropriate β¨
7. SECURITY CONSIDERATIONS π
Okay, the whole security section is one sentence π Security issues are not discussed in this memo.
8. REFERENCES π
[1] Internet Architecture Board and Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", RFC 1602, IAB, IESG, March 1994. Soon to be replaced by "The Internet Standards Process -- Revision 3", Work in Progress.
[2] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and Procedures", RFC 1603, March 1994.
9. AUTHORS' ADDRESSES π
Abel Weinrib
Intel Corporation, MS JF2-74
2111 NE 25th Ave.
Hillsboro, OR 97124
Phone: 503-264-8972
EMail: weinrib@intel.com
Jon Postel
USC - ISI, Suite 1001
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
EMail: postel@isi.edu
π¦ where this page comes from
- ietf: rfc2014 1996-10
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms