diff options
Diffstat (limited to 'doc/rfc/rfc1603.txt')
| -rw-r--r-- | doc/rfc/rfc1603.txt | 1627 |
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc1603.txt b/doc/rfc/rfc1603.txt new file mode 100644 index 0000000..7d2cf09 --- /dev/null +++ b/doc/rfc/rfc1603.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group E. Huizer +Request for Comments: 1603 SURFnet bv +Category: Informational D. Crocker + Silicon Graphics, Inc. + March 1994 + + + IETF Working Group + Guidelines and Procedures + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + The Internet Engineering Task Force (IETF) has responsibility for + developing and reviewing specifications intended as Internet + Standards. IETF activities are organized into working groups (WGs). + This document describes the guidelines and procedures for formation + and operation of IETF working groups. It describes the formal + relationship between IETF participants WG and the Internet + Engineering Steering Group (IESG). The basic duties of IETF + participants, including WG Chair and IESG Area Directors are defined. + +Table of Contents + + 1. INTRODUCTION.............................................. 2 + 1.1. IETF approach to standardization........................ 3 + 1.2. Acknowledgments......................................... 4 + 2. WORKING GROUP (WG) FORMATION.............................. 5 + 2.1. Criteria for formation.................................. 5 + 2.2. Charter................................................. 6 + 2.3. Charter review & approval............................... 9 + 2.4. Birds of a feather (BOF)................................ 9 + 3. WORKING GROUP OPERATION................................... 11 + 3.1. Session planning........................................ 11 + 3.2. Session venue........................................... 12 + 3.3. Session management...................................... 14 + 3.4. Contention and appeals overview......................... 15 + 4. WORKING GROUP TERMINATION................................. 16 + 5. STAFF ROLES............................................... 17 + 5.1. WG Chair................................................ 17 + 5.2. WG Editor/Secretary..................................... 19 + 5.3. WG Facilitator.......................................... 19 + 5.4. Design teams............................................ 19 + + + +Huizer & Crocker [Page 1] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + 5.5. Area Consultant......................................... 19 + 5.6. Area Director........................................... 20 + 5.7. Area Directorate........................................ 21 + 6. WORKING GROUP DOCUMENTS................................... 21 + 6.1. Session documents....................................... 21 + 6.2. IETF meeting document archive........................... 21 + 6.3. Internet-Drafts (I-D)................................... 23 + 6.4. Request For Comments (RFC).............................. 24 + 6.5. Submission of documents................................. 24 + 6.6. Review of documents..................................... 25 + 7. SECURITY CONSIDERATIONS................................... 26 + 8. REFERENCES................................................ 26 + 9. AUTHORS' ADDRESSES........................................ 27 + APPENDIX: SAMPLE WORKING GROUP CHARTER........................ 28 + +1. INTRODUCTION + + This document defines guidelines and procedures for Internet + Engineering Task Force working groups. The Internet is a loosely- + organized international collaboration 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". The Internet Standards Process is defined in [1]. + Development and review of potential Internet Standards from all + sources is conducted by the Internet Engineering Task Force (IETF). + + The IETF is a large, open community of network designers, operators, + vendors, users, and researchers concerned with the Internet and the + technology used on it. The IETF is managed by its Internet + Engineering Steering Group (IESG) whose membership includes an IETF + Chair, responsible for oversight of general IETF operations, and Area + Directors, each of whom is responsible for a set of IETF activities + and working groups. The IETF Executive Director and IESG Secretary + are ex-officio participants, as are the IAB Chair and a designated + Internet Architecture Board (IAB) member. At present there are 10 + areas, though the number and purview of areas changes over time: + + User Services (USV) + Applications (APP) + Service Applications (SAP) + Transport Services (TSV) + Internet (INT) + Routing (RTG) + Network Management (MGT) + Operational Requirements (OPS) + Security (SEC) + Standards & Processes (STD) + + + +Huizer & Crocker [Page 2] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Most areas have an advisory group or directorate. The specific name + and the details of the role for each group differs from area to area, + but the primary intent is that the group assist the Area Director, + e.g., with the review of specifications produced in the area. An + advisory group is formed by an Area Director (AD) and comprises + experienced members of the IETF and technical community represented + by the area. A small IETF Secretariat provides staff and + administrative support for the operation of the IETF. + + The primary activities of the IETF are performed by committees known + as working groups. There are currently more than 60 of these. + Working groups tend to have a narrow focus and a lifetime bounded by + completion of a specific task, although there are exceptions. + + There is no formal membership in the IETF. Participation is open to + all. This participation may be by on-line contribution, attendance + at face-to-face sessions, or both. Anyone from the Internet + community who has the time and interest is urged to participate in + IETF meetings and any of its on-line working group discussions. + Participation is by individual technical contributors, rather than by + formal representatives of organizations. + + This document defines procedures and guidelines for formation and + operation of working groups in the IETF. It defines the relations of + working groups to other bodies within the IETF. The duties of working + group Chairs and Area Directors with respect to the operation of the + working group are also defined. The document uses: "shall", "will", + "must" and "is required" where it describes steps in the process that + are essential, and uses: "suggested", "should" and "may" are where + guidelines are described that are not essential, but are strongly + recommended to help smooth WG operation. + +1.1. IETF approach to standardization + + The reader is encouraged to study The Internet Standards Process [1]. + Familiarity with this document is essential for a complete + understanding of the philosophy, procedures and guidelines described + in this document. + + The goals of the process are summarized in [1]: + + "In general, an Internet Standard is a specification that is + stable and well-understood, is technically competent, has + multiple, independent, and interoperable implementations + with operational experience, enjoys significant public + support, and is recognizably useful in some or all parts of + the Internet. + ... + + + +Huizer & Crocker [Page 3] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + "In outline, the process of creating an Internet Standard is + straightforward: a specification undergoes a period of + development and several iterations of review by the Internet + community and perhaps revision based upon experience, is + adopted as a Standard by the appropriate body (see below), + and is published. + + "In practice, the process is somewhat more complicated, due + to (1) the number and type of possible sources for + specifications; (2) the need to prepare and revise a + specification in a manner that preserves the interests of + all of the affected parties; (3) the importance of + establishing widespread community agreement on its technical + content; and (4) the difficulty of evaluating the utility of + a particular specification for the Internet community. + ... + "These procedures are explicitly aimed at developing and + adopting generally-accepted practices. Thus, a candidate + for Internet standardization is implemented and tested for + correct operation and interoperability by multiple, + independent parties, and utilized in increasingly demanding + environments, before it can be adopted as an Internet + Standard." + + The IETF standardization process has been marked by informality. As + the community of participation has grown it has become necessary to + document procedures, while continuing to avoid unnecessary + bureaucracy. This goals of this balancing act are summarized in [1] + as: + + "The procedures that are described here provide a great deal + of flexibility to adapt to the wide variety of circumstances + that occur in the Internet standardization process. + Experience has shown this flexibility to be vital in + achieving the following goals for Internet standardization: + + * high quality, + * prior implementation and testing, + * openness and fairness, and + * timeliness." + +1.2. Acknowledgments + + Much of this document is due to the copy-and-paste function of a word + processor. Several passages have been taken from the documents cited + in the reference section. The POISED WG provided discussion and + comments. Three people deserve special mention, as especially large + chunks of their documents have been integrated into this one: Vint + + + +Huizer & Crocker [Page 4] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Cerf [7] from whom we borrowed the description of the IETF; and Greg + Vaudreuil and Steve Coya who provided several paragraphs. Also, John + Stewart and Steve Crocker did a truly stellar job of proof-reading. + However, all the errors you'll find are probably ours. + +2. WORKING GROUP (WG) FORMATION + + IETF working groups (WGs) are the primary mechanism for development + of IETF specifications and guidelines, many of which are intended as + standards or recommendations. A working group may be established at + the initiative of an Area Director (AD) or it may be initiated by an + individual or group of individuals. Anyone interested in creating an + IETF working group must obtain the advice and consent of the + appropriate IETF Area Director under whose direction the working + group would fall and must proceed through the formal steps detailed + in this section. + + A working group is typically created to address a specific problem or + produce a deliverable (a guideline, standards specification, etc.) + and is expected to be short-lived in nature. Upon completion of its + goals and achievement of its objectives, the working group as a unit + is terminated. Alternatively at the discretion of the IESG, Area + Director, the WG Chair and the WG participants, the objectives or + assignment of the working group may be extended by enhancing or + modifying the working group's charter. + +2.1. Criteria for formation + + When determining whether it is appropriate to create a working group, + the Area Director and the IESG will consider several issues: + + - Are the issues that the working group plans to address clear + and relevant for the Internet community? + + - Are the goals specific and reasonably achievable, and + achievable within the time frame specified by the + milestones? + + - What are the risks and urgency of the work, to determine the + level of attention required? + + - Do the working group's activities overlap with those of + another working group? If so, it may still be appropriate to + create the working group, but this question must be + considered carefully by the Area Directors as subdividing + efforts often dilutes the available technical expertise. + + + + + +Huizer & Crocker [Page 5] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + - Is there sufficient interest and expertise in the working + group's topic with at least several people willing to expend + the effort to produce the desired result (e.g., a protocol + specification)? Working groups require considerable effort, + including management of the working group process, editing + of working group documents, and contribution to the document + text. IETF experience suggests that these roles typically + cannot all be handled by one person; four or five active + participants are typically required. + + - Does a base of interested consumers (end users) appear to + exist for the planned work? Consumer interest can be + measured by participation of end-users within the IETF + process, as well as by less direct means. + + Considering the above criteria, the Area Director will decide whether + to pursue the formation of the group through the chartering process. + +2.2. Charter + + The formation of a working group requires a charter which is + primarily negotiated between a prospective working group Chair and + the relevant Area Director, although final approval is made by the + IESG and all charters are reviewed by the Internet Architecture Board + (IAB). A charter is a contract between a working group and the IETF + to perform a set of tasks. A charter: + + 1. Lists relevant administrative aspects of the working group; + + 2. Specifies the direction or objectives of the working group + and describes the approach that will be taken to achieve the + goals; and + + 3. Enumerates a set of milestones together with time frames for + their completion. + + When the prospective Chair, the Area Director and the IESG Secretary + are satisfied with the charter form and content, it becomes the basis + for forming a working group. The AD may require an initial draft of a + charter to be available prior to holding an exploratory Birds of a + Feather (BOF) meeting, as described below. + + Charters may be renegotiated periodically to reflect the current + status, organization or goals of the working group. Hence, a charter + is a contract between the IETF and the working group which is + committing to meet explicit milestones and delivering concrete + "products". + + + + +Huizer & Crocker [Page 6] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Specifically, each charter consists of 6 sections: + + Working group name + + A working group name should be reasonably descriptive or + identifiable. Additionally, the group shall define an + acronym (maximum 8 printable ASCII characters) to reference + the group in the IETF directories, mailing lists, and + general documents. + + Chair(s) + + The working group may have one or two Chair(s) to perform + the administrative functions of the group. The email + address(es) of the Chair(s) shall be included. + + Area and Area Director(s) + + The name of the IETF area with which the working group is + affiliated and the name and electronic mail address of the + associated Area Director. + + Mailing list + + It is required that an IETF working group have a general + Internet mailing list. Most of the work of an IETF working + group will be conducted that. + + The charter shall include: + + The address to which a participant sends a + subscription request and the procedures to follow when + subscribing, + + The address to which a participant sends submissions + and special procedures, if any, and + + The location of the mailing list archive, if any. + + A message archive should be maintained in a public place + which can be accessed via FTP. The ability to retrieve from + the archive via electronic mail requests also is + recommended. Additionally, the address: + + ietf-archive@cnri.reston.va.us + + shall be included on the mailing list. + + + + +Huizer & Crocker [Page 7] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + NOTE: It is strongly suggested that the mailing list be on + a host directly connected to the IP Internet to facilitate + use of the SMTP expansion command (EXPN) and to allow mail + archive access via FTP, gopher and the like in keeping with + the general IETF rule for openness. If this is not possible, + the message archive and membership of the list must be made + available to those who request it by sending a message to + the list-request alias. + + Description of working group + + The focus and intent of the group shall be set forth briefly. By + reading this section alone, an individual should be able to decide + whether this group is relevant to their own work. The first paragraph + must give a brief summary of the problem area, basis, goal(s) and + approach(es) planned for the working group. This paragraph will + frequently be used as an overview of the working group's effort. + + The terms "they", "them" and "their" are used in this document as + third-person singular pronouns. + + To facilitate evaluation of the intended work and to provide + on-going guidance to the working group, the charter shall + describe the problem being solved and shall discuss + objectives and expected impact with respect to: + + - Architecture + - Operations + - Security + - Network management + - Transition (where applicable) + + Goals and milestones + + The working group charter must establish a timetable for + work. While this may be re-negotiated over time, the list + of milestones and dates facilitates the Area Director's + tracking of working group progress and status, and it is + indispensable to potential participants identifying the + critical moments for input. Milestones shall consist of + deliverables that can be qualified as showing specific + achievement; e.g., "Internet-Draft finished" is fine, but + "discuss via email" is not. It is helpful to specify + milestones for every 3-6 months, so that progress can be + gauged easily. This milestone list is expected to be + updated periodically. Updated milestones are re-negotiated + with the Area Director and the IESG, as needed, and then are + submitted to the IESG Secretary: + + + +Huizer & Crocker [Page 8] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + + IESG-secretary@cnri.reston.va.us + + An example of a WG charter is in Appendix A. + +2.3. Charter review & approval + + Working groups often comprise technically competent participants who + are not familiar with the history of Internet architecture or IETF + processes. This can, unfortunately, lead to good working group + consensus about a bad design. To facilitate working group efforts, + an Area Director may assign an Area Consultant from among the ranks + of senior IETF participants. (Area Consultants are described in the + section of Staff Roles.) At the discretion of the AD, approval of a + new WG may be withheld in the absence of sufficient Consultant + resources. + + Once the Area Director (and the Area Directorate, as the AD deems + appropriate) has approved the working group charter, the charter is + submitted for review by the IAB and approval by the Internet + Engineering Steering Group using the criteria described previously. + + The Internet Architecture Board (IAB) will review the charter of the + proposed WG to determine the relationship of the proposed work to the + overall architecture of the Internet Protocol Suite. + + The approved charter is submitted to the IESG Secretary who records + and enters the information into the IETF tracking database and + returns the charter in a form formatted by the database. The working + group is announced to the IETF mailing list by the IESG Secretary. + +2.4. Birds of a feather (BOF) + + Often it is not clear whether an issue merits the formation of a + working group. To facilitate exploration of the issues the IETF + offers the possibility of a Birds of a Feather (BOF) session, as well + as the early formation of an email list for preliminary discussion. + Alternatively, a BOF may serve as a forum for a single presentation + or discussion, without any intent to form a working group. + + A BOF is a session at an IETF meeting which permits "market research" + and technical "brainstorming". Any individual may request permission + to hold a BOF on a subject. The request must be filed with the + relevant Area Director. The person who requests the BOF is usually + appointed as Chair of the BOF. The Chair of the BOF is also + responsible for providing a report on the outcome of the BOF. + + + + + +Huizer & Crocker [Page 9] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + The AD may require the conduct of email discussion, prior to + authorizing a BOF. This permits initial exchanges and sharing of + framework, vocabulary and approaches, in order to make the time spent + in the BOF more productive. The AD may require that a BOF be held, + prior to establishing a working group, and the AD may require that + there be a draft of the WG charter prior to holding a BOF. + + Usually the outcome of a BOF will be one of the following: + + - There was enough interest and focus in the subject to + warrant the formation of a WG; + + - The discussion came to a fruitful conclusion, with results + to be written down and published, however there is no need + to establish a WG; or + + - There was not enough interest in the subject to warrant the + formation of a WG. + + There is an increasing demand for BOF sessions at IETF meetings. + Therefore the following rules apply for BOFs: + + - All BOFs must have the approval of the appropriate Area + Director. The Secretariat will NOT schedule or allocate time + slots without the explicit approval of the Area Director. + + - The purpose of a BOF is to conduct a single, brief + discussion or to ascertain interest and establish goals for + a working group. All BOF organizers are required to submit a + brief written report of what transpired during the BOF + session together with a roster of attendees to the IESG + Secretary for inclusion in the Proceedings. + + - A BOF may be held only once (ONE slot at one IETF Plenary + meeting). + + - Under unusual circumstances an Area Director may, at their + discretion, allow a BOF to meet for a second time. Typically + (though not a requirement) this is to develop a charter to + be submitted to the IESG. + + - BOFs are not permitted to meet three times. + + + + + + + + + +Huizer & Crocker [Page 10] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + - A BOF may be held for single-event discussion, or may pursue + creation of normal IETF working groups for on-going + interactions and discussions. When the request for a BOF + comes from a formally-constituted group, rather than from an + individual, the rules governing the handling of the request + are the same as for all other BOFs and working groups. + + - When necessary, WGs will be given priority for meeting space + over BOFs. + +3. WORKING GROUP OPERATION + + The IETF has basic requirements for open and fair participation and + for thorough consideration of technical alternatives. Within those + constraints, working groups are autonomous and each determines most + of the details of its own operation with respect to session + participation, reaching closure, etc. The core rule for operation is + that acceptance or agreement is achieved via working group "rough + consensus". + + A number of procedural questions and issues will arise over time, and + it is the function of the Working Group Chair to manage the group + process, keeping in mind that the overall purpose of the group is to + make progress towards reaching rough consensus in realizing the + working group's goals and objectives. + + There are few hard and fast rules on organizing or conducting working + group activities, but a set of guidelines and practices have evolved + over time that have proven successful. These are listed here, with + actual choices typically determined by the working group participants + and the Chair. + +3.1. Session planning + + For coordinated, structured WG interactions, the Chair must publish a + draft agenda well in advance of the actual session. 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 session in order to be well + prepared. + + + + + + +Huizer & Crocker [Page 11] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Publication shall include sending a copy to the working group mailing + list and to the IETF-Announce list. Notices for the IETF-Announce + list should be sent to: + + ietf-announce-post@cnri.reston.va.us + + All working group actions shall be taken in a public forum, and wide + participation is encouraged. A working group will conduct much of + its business via electronic mail distribution lists but may meet + periodically to discuss and review task status and progress, to + resolve specific issues and to direct future activities. It is + common, but not required, that a working group will meet at the + trimester IETF Plenary events. Additionally, interim sessions may be + scheduled for telephone conference, video teleconference, or for + face-to-face (physical) sessions. + + All working group sessions (including those held outside of the IETF + meetings) shall be reported by making minutes available. These + minutes should include the agenda for the session, an account of the + discussion including any decisions made, and a list of attendees. The + Working Group Chair is responsible for insuring that session minutes + are written and distributed, though the actual task may be performed + by someone designated by the Working Group Chair. The minutes shall + be submitted in printable ASCII text for publication in the IETF + Proceedings, and for posting in the IETF Directories and are to be + sent to: + + minutes@cnri.reston.va.us + +3.2. Session venue + + Each working group will determine the balance of email and face-to- + face sessions that is appropriate for achieving its milestones. + Electronic mail permits the widest participation; face-to-face + meetings often permit better focus and therefore can be more + efficient for reaching a consensus among a core of the working group + participants. In determining the balance, the WG must ensure that + its process does not serve to exclude contribution by email-only + participants. Also note that decisions reached during IETF meetings + are NOT final, but must be conveyed to the mailing list to verify WG + consensus. + +IETF Meetings + + If a WG needs a session at an IETF meeting, the Chair must apply for + time-slots as soon as the first announcement of that IETF meeting is + made by the IETF Secretariat to the WG-chairs list. Session time is + a scarce resource at IETF meetings, so placing requests early will + + + +Huizer & Crocker [Page 12] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + facilitate schedule coordination for WGs requiring the same set of + experts. + + The application for a WG session at an IETF meeting shall be made to + the IETF Secretariat. Alternatively some Area Directors may want to + coordinate WG sessions in their area and request that time slots be + coordinated through them. After receiving all requests for time + slots by WGs in the area, the Area Director(s) form a draft session- + agenda for their area, which is then sent to the WG chairs of the + area. After approval it will be sent to the IETF Secretariat. + + An application must contain: + + - The amount of time requested; + + - The rough outline of the WG agenda that is expected to be + covered; + + - The estimated number of people that will attend the WG + session; + + - Related WGs that must not be scheduled for the same time + slot(s); and + + - Individuals whose attendance is desired. + + The Secretariat allots time slots on the basis of the session-agenda + made by the Area Director(s). If the proposed session- agenda for an + area does not fit into the IETF meeting-agenda, the IETF Secretariat + will adjust it to fit, after consulting the Area Director(s) and the + relevant chairs. The Secretariat will then form a draft session- + agenda and distribute it among the Working Group Chairs for final + approval. + + NOTE: While open discussion and contribution is essential to working + group success, the Chair is responsible for ensuring forward + progress. When acceptable to the WG, the Chair may call for + restricted participation (but not restricted attendance!) at IETF + working group sessions for the purpose of achieving progress. The + Working Group Chair then has the authority to refuse to grant the + floor to any individual who is unprepared or otherwise covering + inappropriate material. + +On-line + + It can be quite useful to conduct email exchanges in the same manner + as a face-to-face session, with published schedule and agenda, as + well as on-going summarization and consensus polling. + + + +Huizer & Crocker [Page 13] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Many working group participants hold that mailing list discussion is + the best place to consider and resolve issues and make decisions. + Choice of operational style is made by the working group itself. It + is important to note, however, that Internet email discussion is + possible for a much wider base of interested persons than is + attendance at IETF meetings, due to the time and expense required to + attend. + +3.3. Session management + + Working groups make decisions through a "rough consensus" process. + IETF consensus does not require that all participants agree although + this is, of course, preferred. In general the dominant view of the + working group shall prevail. (However, it must be noted that + "dominance" is not to be determined on the basis of volume or + persistence, but rather a more general sense of agreement.) + Consensus can be determined by balloting, humming, or any other means + on which the WG agrees (by rough consensus, of course). + + The challenge to managing working group sessions is to balance the + need for open and fair consideration of the issues against the need + to make forward progress. The working group, as a whole, has the + final responsibility for striking this balance. The Chair has the + responsibility for overseeing the process but may delegate direct + process management to a formally-designated Facilitator. + + It is occasionally appropriate to revisit a topic, to re-evaluate + alternatives or to improve the group's understanding of a relevant + decision. However, unnecessary repeated discussions on issues can be + avoided if the Chair makes sure that the main arguments in the + discussion (and the outcome) are summarized and archived after a + discussion has come to conclusion. It is also good practice to note + important decisions/consensus reached by email in the minutes of the + next 'live' session, and to summarize briefly the decision-making + history in the final documents the WG produces. + + To facilitate making forward progress, a Working Group Chair may wish + to direct a discussion to reject or defer the input from a member, + based upon the following criteria: + + Old + + The input pertains to a topic that already has been resolved + and is redundant with information previously available; + + + + + + + +Huizer & Crocker [Page 14] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Minor + + The input is new and pertains to a topic that has already + been resolved, but it is felt to be of minor import to the + existing decision; + + Timing + + The input pertains to a topic that the working group has not + yet opened for discussion; or + + Scope + + The input is outside of the scope of the working group + charter. + +3.4. Contention and appeals overview + + In the course of group design processes, strife happens. Strife and + contention are particularly likely when working groups comprise many + constituencies. On the other hand differences in view are vital to + the success of the IETF and healthy debate is encouraged. Sometimes + debates degenerate into something akin to warfare. For these + circumstances, the IETF has an extensive review and appeals process. + + Formal procedures for requesting review and conducting appeals are + documented in The Internet Standards Process [1]. A brief summary is + provided, here. + + In fact the IETF approach to reviews and appeals is quite simple: + When an IETF participant feels that matters have not been conducted + properly, they should state their concern to a member of IETF + management. In other words, the process relies upon those who have + concerns raising them. If the result is not satisfactory, there are + several levels of appeal available, to ensure that review is possible + by a number of people uninvolved in the matter in question. + + Reviews and appeals step through four levels, each in turn: + + WG Chair + + An appeal must begin with the management closest to the + operation of the working group, even if the concern applies + to their own handling of working group process. + + + + + + + +Huizer & Crocker [Page 15] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Area + + If discussion and review with the WG Chair do not produce a + satisfactory result, the complainant may bring their concern + to the cognizant Area Director. + + IESG + + If a concerned party is not satisfied with the results of + the area-level review, then they may bring the matter to the + IESG Chair and the Area Director for Standards & Processes. + The IESG Chair and the Standards & Processes AD will bring + the issue before the full IESG for an additional review and + will report the resolution back to the parties. + + IAB + + The IAB provides a final opportunity to appeal the results + of previous reviews. If a concerned party does not accept + the outcome of the IESG review, then they may take their + concern to the IAB, by contacting the IAB Chair. + + Concerns entail either a disagreement with technical decisions by the + working group or with the process by which working group business has + been conducted. Technical disagreements may be about specific + details or about basic approach. When an issue pertains to + preference, it should be resolved within the working group. When a + matter pertains to the technical adequacy of a decision, review is + encouraged whenever the perceived deficiency is noted. For matters + having to do with preference, working group rough consensus will + dominate. + + When a matter pertains to working group process, it is important that + those with a concern be clear about the manner in which the process + was not open or fair and that they be willing to discuss the issue + openly and directly. In turn, the IETF management will make every + effort to understand how the process was conducted, what deficiencies + were present (if any) and how the matter should be corrected. The + IETF functions on the good will and mutual respect of its + participants; continued success requires continued attention to + working group process. + +4. WORKING GROUP TERMINATION + + Working groups are typically chartered to accomplish a specific task. + After that task is complete, the group will be disbanded. However if + a WG produces a Proposed or Draft Standard, the WG will become + dormant rather than disband (i.e., the WG will no longer conduct + + + +Huizer & Crocker [Page 16] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + formal activities, but the mailing list will remain available to + review the work as it moves to Draft Standard and Standard status.) + + If, at some point, it becomes evident that a working group is unable + to complete the work outlined in the charter, the group, in + consultation with its Area Director can either: + + 1. Recharter to refocus on a smaller task, + + 2. Choose new Chair(s), or + + 3. Disband. + + If the working group disagrees with the Area Director's choice, it + may appeal to the IESG. + +5. STAFF ROLES + + Working groups require considerable care and feeding. In addition to + general participation, successful working groups benefit from the + efforts of participants filling specific functional roles. + +5.1. WG Chair + + The Working Group Chair is concerned with making forward progress + through a fair and open process, and has wide discretion in the + conduct of WG business. The Chair must ensure that a number of tasks + are performed, either directly or by others assigned to the tasks. + This encompasses at the very least the following: + + Ensure WG process and content management + + The Chair has ultimate responsibility for ensuring that a + working group achieves forward progress and meets its + milestones. For some working groups, this can be + accomplished by having the Chair perform all management- + related activities. In other working groups -- particularly + those with large or divisive participation -- it is helpful + to allocate process and/or secretarial functions to other + participants. Process management pertains strictly to the + style of working group interaction and not to its content. + It ensures fairness and detects redundancy. The secretarial + function encompasses document editing. It is quite common + for a working group to assign the task of specification + Editor to one or two participants. Often, they also are + part of the design team, described below. + + + + + +Huizer & Crocker [Page 17] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Moderate the WG email list + + The Chair should attempt to ensure that the discussions on + this list are relevant and that they converge to consensus + agreements. The Chair should make sure that discussions on + the list are summarized and that the outcome is well + documented (to avoid repetition). The Chair also may choose + to schedule organized on-line "sessions" with agenda and + deliverables. These are structured as true meetings, + conducted over the course of several days (to allow + participation across the Internet.) Participants are + expected to allocate time to the meeting, usually in the + range of 1-2 hours per day of the "meeting". + + Organize, prepare and chair face-to-face & on-line formal sessions + + The Chair should plan and announce sessions well in advance. + (See section on Session Planning for exact procedures.) + + Communicate results of sessions + + The Chair and/or Secretary must ensure that minutes of a + session are taken and that an attendance list is circulated. + See the section on Session Documents for detailed + procedures. + + Immediately after a session, the WG Chair must immediately + provide the Area Director with a very short report + (approximately one paragraph, via email) on the session. + This is used in an Area Report as presented in the + Proceedings of each IETF meeting. + + Distribute the work + + Of course each WG will have participants who may not be able + (or want) to do any work at all. Most of the time the bulk + of the work is done by a few dedicated participants. It is + the task of the Chair to motivate enough experts to allow + for a fair distribution of the workload. + + Document development + + Working groups produce documents and documents need authors. + The Chair will make sure that authors of WG documents + incorporate changes as discussed by the WG. See the section + on Session Documents for details procedures. + + + + + +Huizer & Crocker [Page 18] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Document publication + + The Chair and/or Secretary will work with the RFC Editor to + ensure document conformance with RFC publication + requirements and to coordinate any editorial changes + suggested by the RFC Editor. A particular concern is that + all participants are working from the same version of a + document at the same time. + +5.2. WG Editor/Secretary + + Taking minutes and editing working group documents often is performed + by a specifically-designated participant or set of participants. In + this role, the Editor's job is to record WG decisions, rather than to + perform basic specification. + +5.3. WG Facilitator + + When meetings tend to become distracted or divisive, it often is + helpful to assign the task of "process management" to one + participant. Their job is to oversee the nature, rather than the + content, of participant interactions. That is, they attend to the + style of the discussion and to the schedule of the agenda, rather + than making direct technical contributions themselves. + +5.4. Design teams + + The majority of the detailed specification effort within a working + group may be done by self-selecting sub-groups, called design teams, + with the (implicit or explicit) approval of the working group. The + team may hold closed sessions for conducting portions of the + specification effort. In some cases design teams are necessary to + make forward progress when preparing a document. All work conducted + by a design team must be available for review by all working group + participants and the design team must be responsive to the direction + of the working group's consensus. + +5.5. Area Consultant + + At the discretion of the AD, a Consultant may be assigned to a + working group. Consultants are senior participants in the IETF + community. They have technical background appropriate to the WG and + experience in Internet architecture and IETF process. + + + + + + + + +Huizer & Crocker [Page 19] + +RFC 1603 IETF Working Group Guidelines March 1994 + + +5.6. Area Director + + Area Directors are responsible for ensuring that working groups in + their area produce coherent, coordinated, architecturally consistent + and timely output as a contribution to the overall results of the + IETF. This very general description encompasses at the very least + these detailed tasks related to working groups: + + Area planning + + The Area Director determines activities appropriate to the + area. This may include initiating working groups directly, + rather than waiting for proposals from IETF participants. + + Coordination of WGs + + The Area Director coordinates the work done by the various + WGs within (and sometimes even outside) the relevant area. + + IETF Meeting Schedule + + The Director tries to coordinate sessions in such a way that + experts can attend the relevant sessions with a minimum of + overlap and gaps between sessions. (See section on WG + sessions for details.) + + Reporting + + The Area Director reports to the IETF on progress in the + area. + + Reviewing + + The Area Director may appoint independent reviewers prior to + document approval. The Area Director tracks the progress of + documents from the area through the IESG review process, and + report back on this to the WG Chair(s). + + Progress tracking + + The Area Director tracks and manages the progress of the + various WGs with the aid of a regular status report on + documents and milestones that is generated by the IESG + Secretary. The Area Director forwards this report to the WG + chairs. This in turn helps the chairs to manage their WGs. + + + + + + +Huizer & Crocker [Page 20] + +RFC 1603 IETF Working Group Guidelines March 1994 + + +5.7. Area Directorate + + An area directorate consists of senior members of the technical + community and are appointed by the Area Director who then tasks them + with technical oversight and review of specific area activities. An + Area Director chairs the directorate. At the request of the AD, + directorate members conduct specification reviews and may be assigned + as Area Consultants, to provide architectural assistance. + +6. WORKING GROUP DOCUMENTS + +6.1. Session documents + + All relevant documents for a session (including the final agenda) + should be published and available at least two weeks before a session + starts. + + It is strongly suggested that the WG Chair make sure that an + anonymous FTP directory be available for the upcoming session. All + relevant documents (including the final agenda and the minutes of the + last session) should be placed in this directory. This has the + advantage that all participants can FTP 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. IETF meeting document archive + + In preparing for an IETF meeting it is helpful to have ready access + to all documents that are being reviewed. While documents usually are + placed in the internet-drafts Internet Repository or in the + respective working group archives or just published in some mail- + lists, there are just too many things to browse or read through. + Also, many documents are modified immediately before a meeting. + + The InterNIC Directory and Database Services provides a current- + ietf-docs archive to enable people to get all documents that are + relevant for the up-coming IETF meeting. This document database will + be removed two weeks after the IETF meeting. + + The completeness of this archive depends on the authors and working + group chairs submitting the documents. Each WG Chair is requested to + submit the agenda to this archive. + + Structure of the archive: + + On ds.internic.net documents will be stored under the appropriate + working group name under the appropriate area name in the directory: + + + +Huizer & Crocker [Page 21] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + /pub/current-ietf-docs + + Each area will also have a directory called bof where a document to + be discussed in a BOF meeting will be placed. At the area level a + directory called plenary will be created to hold documents or + presentation material related to a plenary session. Any filename + conflicts will be resolved by the InterNIC's administrator and the + submitter will be informed via electronic mail. Example: + + /pub/current-ietf-docs/app/osids + /pub/current-ietf-docs/int/sip + + Access via anonymous FTP: + + Anonymous FTP to ds.internic.net and change directory to + + /pub/current-ietf-docs/ + + and browse and get the document of interest. + + Access via gopher: + + Connect to gopher.internic.net and select the menu item: + + 4. InterNIC Directory and Database Services (AT&T)/ + + and then the menu item: + + 3. Documents to be reviewed at the *** IETF + + One may use the public-access gopher client by: + + telnet gopher.internic.net + + Submission of documents via anonymous FTP: + + FTP to ds.internic.net and login as anonymous. Change directory to: + + /incoming/current-ietf-docs + + Put the document using the following filename convention, + + <area>.<wgname>.<filename> + e.g.: + + plenary.mondayVGs.ps + app.osids.agenda + app.osids.internic-talk-VGs.ps + + + +Huizer & Crocker [Page 22] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + Note that the names of areas and working groups are their official + short-form acronyms, + + Submission of documents via electronic mail: + + Send mail to + + admin@ds.internic.net + + with the following subject line: + + IETF - <area>.<wgname>.<filename> + + e.g.: + + IETF - app.osids.agenda + + NOTE: Instead of sending a fresh copy of an already available + document, you may ask the InterNIC's administrators to create a link + to an existing internet-draft/RFC/ID + + NOTE: If you do not remember your area or working group acronym get + the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous + FTP. + +6.3. Internet-Drafts (I-D) + + The Internet-Drafts directory is provided to working groups as a + resource for posting and disseminating early copies of working group + documents. This repository is replicated at various locations around + the Internet. It is encouraged that draft documents be posted as soon + as they become reasonably stable. + + It is stressed here that Internet-Drafts are working documents and + have no official standards status whatsoever. They may, eventually, + turn into a standards-track document or they may sink from sight. + Internet-Drafts are submitted to: + + internet-drafts@cnri.reston.va.us + + The format of an Internet-Draft must be the same as for an RFC [2]. + Further, an I-D must contain: + + - Beginning, standard, boilerplate text which is provided by + the Secretariat; + + - The I-D filename; and + + + + +Huizer & Crocker [Page 23] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + - The expiration date for the I-D. + + Complete specification of requirements for an Internet-Draft are + found in the file: + + 1id-guidelines.txt + + in the internet-drafts directory at an Internet Repository site. + +6.4. Request For Comments (RFC) + + The work of an IETF working group usually results in publication of + one or more documents, as part of the Request For Comments (RFCs) [2] + series. This series is the archival publication record for the + Internet community. A document can be written by an individual in a + working group, by a group as a whole with a designated Editor, or by + others not involved with the IETF. The designated author need not be + the group Chair(s). + + NOTE: The RFC series is a publication mechanism only and publication + does not determine the IETF status of a document. Status is + determined through separate, explicit status labels assigned by the + IESG on behalf of the IETF. In other words, the reader is reminded + that all Internet Standards are published as RFCs, but NOT all RFCs + specify standards. + + For a description on the various categories of RFCs the reader is + referred to [1, 4, 5, 6]. + +6.5. Submission of documents + + When a WG decides that a document is ready for publication, the + following must be done: + + - The version of the relevant document as approved by the WG + must be in the Internet-Drafts directory; + + - The relevant document must be formatted according to RFC + rules [2]. + + - The WG Chair sends email to the relevant Area Director, with + a copy to the IESG Secretary. The mail should contain the + reference to the document, and the request that it be + progressed as an Informational, Experimental, Prototype or + standards-track (Proposed, Draft or Internet Standard) RFC. + + The IESG Secretary will acknowledge receipt of the email. Unless + returned to the WG for further development, progressing of the + + + +Huizer & Crocker [Page 24] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + document is then the responsibility of the IESG. After IESG + approval, responsibility for final disposition is the joint + responsibility of the RFC Editor and the WG Chair and Editor. + +6.6. Review of documents + + Usually in case of a submission intended as an Informational or + Experimental RFC minimal review is necessary. However, if the WG or + the RFC Editor thinks that an extensive review is appropriate, the + Area Director may be asked to conduct one. This review may either be + done by the AD and other IESG participants or the IESG may ask for an + independent review (e.g., by someone not part of the WG in question) + from the Area Directorate or elsewhere. + + A review will lead to one of three possible conclusions: + + 1. The document is accepted as is. + + This fact will be announced by the IESG Secretary to the + IETF mailing list and to the RFC Editor. Publication is then + further handled between the RFC Editor and the author(s). + + 2. Changes regarding content are suggested to the author(s)/WG. + + Suggestions must be clear and direct, so as to facilitate + working group and author correction of the specification. + Once the author(s)/WG have made these changes or have + explained to the satisfaction of the reviewers why the + changes are not necessary, the document will be accepted for + publication as under point 1, above. + + 3. The document is rejected. + + This will need strong and thorough arguments from the + reviewers. The whole IETF and working group process is + structured such that this alternative is not likely to arise + for documents coming from a working group. After all, the + intentions of the document will already have been described + in the WG charter, and reviewed at the start of the WG. + + If any individual or group of individuals feels that the review + treatment has been unfair, there is the opportunity to make a + procedural complaint. The mechanism for procedural complaints is + described in the section on Contention and Appeal. + + Before the IESG makes a final decision on a standards-track document, + the IESG Secretary will issue a "Last Call" to the IETF mailing list. + This Last Call will announce the intention of the IESG to consider + + + +Huizer & Crocker [Page 25] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + the document, and it will solicit final comments from the IETF within + a period of two weeks. It is important to note that a Last Call is + intended as a brief, final check with the Internet community, to make + sure that no important concerns have been missed or misunderstood. + The Last Call cannot serve as a more general, in-depth review. + +7. SECURITY CONSIDERATIONS + + 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. + + [2] Postel, J., "Instructions to RFC Authors", RFC 1543, + USC/Information Sciences Institute, October 1993. + + [3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction to + the F.Y.I. Notes", RFC 1150, Proteon, USC/Information Sciences + Institute, March 1990. + + [4] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311, + USC/Information Sciences Institute, March 1992. + + [5] Postel, J., Editor, "Internet Official Protocol Standards", STD + 1, RFC 1600, IAB, March 1994. + + [6] Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May + 1990. + + + + + + + + + + + + + + + + + + + + +Huizer & Crocker [Page 26] + +RFC 1603 IETF Working Group Guidelines March 1994 + + +9. AUTHORS' ADDRESSES + + Erik Huizer + SURFnet bv + P.O. Box 19035 + 3501 DA Utrecht + The Netherlands + + Phone: +31 30 310290 + Fax: +31 30 340903 + EMail: Erik.Huizer@SURFnet.nl + + + Dave Crocker + Silicon Graphics, Inc. + 2011 N. Shoreline Blvd. + P.O. Box 7311 + Mountain View, CA 94039 + + Phone: +1 415 390 1804 + Fax: +1 415 962 8404 + EMail: dcrocker@sgi.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Huizer & Crocker [Page 27] + +RFC 1603 IETF Working Group Guidelines March 1994 + + +APPENDIX: SAMPLE WORKING GROUP CHARTER + + Multiparty Multimedia Session Control (mmusic) + + Charter + + Chair(s): + Eve Schooler <schooler@isi.edu> + Abel Weinrib <abel@bellcore.com> + + Transport Area Director(s) + Allison Mankin <mankin@cmf.nrl.navy.mil> + + Mailing lists: + General Discussion:confctrl@isi.edu + To Subscribe: confctrl-request@isi.edu + Archive: venera.isi.edu:~/confctrl/confcrtl.mail + + Description of Working Group: + + The demand for Internet teleconferencing has arrived, yet an + infrastructure to support this demand is barely in place. + Multimedia session control, defined as the management and + coordination of multiple sessions and their multiple users in + multiple media (e.g., audio, video), is one component of the + infrastructure. The Multiparty Multimedia Session Control + Working Group is chartered to design and specify a protocol to + perform these functions. + + The protocol will provide negotiation for session membership, + underlying communication topology and media configuration. In + particular, the protocol will support a user initiating a + multimedia multiparty session with other users ("calling" other + users) over the Internet by allowing a teleconferencing + application on one workstation to explicitly rendezvous with + teleconferencing applications running on remote workstations. + Defining a standard protocol will enable session-level + interoperability between different teleconferencing + implementations. + + The focus of the working group is to design a session negotiation + protocol that is tailored to support tightly-controlled + conferences. The MBONE currently carries primarily loosely- + controlled sessions, i.e., sessions with little to no interaction + among members and with no arbitration facility, security, or + coordination of quality-of-service options for time-critical + media. Users may learn of available sessions using the "sd" + utility or other out of band mechanisms (e.g., email). However, + + + +Huizer & Crocker [Page 28] + +RFC 1603 IETF Working Group Guidelines March 1994 + + + there is clearly also a need for tightly-controlled sessions that + provide mechanisms for directly contacting other users to + initiate a session and for negotiating conference parameters such + as membership, media encodings and encryption keys. In addition, + these sessions should support renegotiation during a session, for + example to add or delete members or change the media encoding. + It is possible that the protocol will, in the limiting case, also + support loosely-controlled sessions. + + The main goal of the working group will be to specify the session + control protocol for use within teleconferencing software over + the Internet. The working group will focus on the aspects of the + session control problem that are well understood, while keeping + an eye on evolving research issues. Toward this end, the working + group has made an inventory of existing conferencing systems and + their session control protocols. The working group will document + the requirements of the existing prototypes as a basis for the + protocol development. The working group will iteratively refine + the protocol based on implementation and operational experience. + + Furthermore, the working group will coordinate with other efforts + related to multimedia conferencing, such as directory services + for cataloguing users and conferences, the RTP and RTCP protocols + developed by the Audio/Video Transport Working Group, resource + reservation and management at the network level, and schemes for + multicast address allocation. + + Goals and Milestones: + + May 93 Hold an on-line working group meeting to discuss + the conference control framework, the relevant + terminology, a functional taxonomy and how + different conversational styles place + requirements on session protocols. + + Jun 93 Submit the Conference Session Control Protocol to + the IESG for consideration as an Experimental + Protocol. + + Aug 93 Post an Internet-Draft describing the Session + Control Requirements. + + Nov 93 Post an Internet-Draft of the Session Control + Protocol. + + Mar 94 Submit a revised Internet-Draft based on + implementation experience. + + + + +Huizer & Crocker [Page 29] + |