diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2418.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2418.txt | 1459 |
1 files changed, 0 insertions, 1459 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2418.txt b/contrib/bind9/doc/rfc/rfc2418.txt deleted file mode 100644 index 9bdb2c5..0000000 --- a/contrib/bind9/doc/rfc/rfc2418.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -Network Working Group S. Bradner -Request for Comments: 2418 Editor -Obsoletes: 1603 Harvard University -BCP: 25 September 1998 -Category: Best Current Practice - - - IETF Working Group - Guidelines and Procedures - -Status of this Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -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 also describes the formal - relationship between IETF participants WG and the Internet - Engineering Steering Group (IESG) and the basic duties of IETF - participants, including WG Chairs, WG participants, and IETF Area - Directors. - -Table of Contents - - Abstract ......................................................... 1 - 1. Introduction .................................................. 2 - 1.1. IETF approach to standardization .......................... 4 - 1.2. Roles within a Working Group .............................. 4 - 2. Working group formation ....................................... 4 - 2.1. Criteria for formation .................................... 4 - 2.2. Charter ................................................... 6 - 2.3. Charter review & approval ................................. 8 - 2.4. Birds of a feather (BOF) .................................. 9 - 3. Working Group Operation ....................................... 10 - 3.1. Session planning .......................................... 11 - 3.2. Session venue ............................................. 11 - 3.3. Session management ........................................ 13 - 3.4. Contention and appeals .................................... 15 - - - -Bradner Best Current Practice [Page 1] - -RFC 2418 Working Group Guidelines September 1998 - - - 4. Working Group Termination ..................................... 15 - 5. Rechartering a Working Group .................................. 15 - 6. Staff Roles ................................................... 16 - 6.1. WG Chair .................................................. 16 - 6.2. WG Secretary .............................................. 18 - 6.3. Document Editor ........................................... 18 - 6.4. WG Facilitator ............................................ 18 - 6.5. Design teams .............................................. 19 - 6.6. Working Group Consultant .................................. 19 - 6.7. Area Director ............................................. 19 - 7. Working Group Documents ....................................... 19 - 7.1. Session documents ......................................... 19 - 7.2. Internet-Drafts (I-D) ..................................... 19 - 7.3. Request For Comments (RFC) ................................ 20 - 7.4. Working Group Last-Call ................................... 20 - 7.5. Submission of documents ................................... 21 - 8. Review of documents ........................................... 21 - 9. Security Considerations ....................................... 22 - 10. Acknowledgments .............................................. 23 - 11. References ................................................... 23 - 12. Editor's Address ............................................. 23 - Appendix: Sample Working Group Charter .......................... 24 - Full Copyright Statement ......................................... 26 - -1. Introduction - - The Internet, a loosely-organized international collaboration of - autonomous, interconnected networks, supports host-to-host - communication through voluntary adherence to open protocols and - procedures defined by Internet Standards. There are also many - isolated interconnected networks, which are not connected to the - global Internet but use the Internet Standards. Internet Standards - are developed in the Internet Engineering Task Force (IETF). This - document defines guidelines and procedures for IETF working groups. - The Internet Standards Process of the IETF is defined in [1]. The - organizations involved in the IETF Standards Process are described in - [2] as are the roles of specific individuals. - - 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 primary activities of the IETF are - performed by committees known as working groups. There are currently - more than 100 working groups. (See the IETF web page for an up-to- - date list of IETF Working Groups - http://www.ietf.org.) Working - groups tend to have a narrow focus and a lifetime bounded by the - completion of a specific set of tasks, although there are exceptions. - - - - - -Bradner Best Current Practice [Page 2] - -RFC 2418 Working Group Guidelines September 1998 - - - For management purposes, the IETF working groups are collected - together into areas, with each area having a separate focus. For - example, the security area deals with the development of security- - related technology. Each IETF area is managed by one or two Area - Directors (ADs). There are currently 8 areas in the IETF but the - number changes from time to time. (See the IETF web page for a list - of the current areas, the Area Directors for each area, and a list of - which working groups are assigned to each area.) - - In many areas, the Area Directors have formed an advisory group or - directorate. These comprise experienced members of the IETF and the - technical community represented by the area. The specific name and - the details of the role for each group differ from area to area, but - the primary intent is that these groups assist the Area Director(s), - e.g., with the review of specifications produced in the area. - - The IETF area directors are selected by a nominating committee, which - also selects an overall chair for the IETF. The nominations process - is described in [3]. - - The area directors sitting as a body, along with the IETF Chair, - comprise the Internet Engineering Steering Group (IESG). The IETF - Executive Director is an ex-officio participant of the IESG, as are - the IAB Chair and a designated Internet Architecture Board (IAB) - liaison. The IESG approves IETF Standards and approves the - publication of other IETF documents. (See [1].) - - A small IETF Secretariat provides staff and administrative support - for the operation of the IETF. - - 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 the 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. When used in this document the key - words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", - "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be - interpreted as described in RFC 2119 [6]. RFC 2119 defines the use - of these key words to help make the intent of standards track - documents as clear as possible. The same key words are used in this - - - -Bradner Best Current Practice [Page 3] - -RFC 2418 Working Group Guidelines September 1998 - - - document to help smooth WG operation and reduce the chance for - confusion about the processes. - -1.1. IETF approach to standardization - - Familiarity with The Internet Standards Process [1] is essential for - a complete understanding of the philosophy, procedures and guidelines - described in this document. - -1.2. Roles within a Working Group - - The document, "Organizations Involved in the IETF Standards Process" - [2] describes the roles of a number of individuals within a working - group, including the working group chair and the document editor. - These descriptions are expanded later in this document. - -2. Working group formation - - IETF working groups (WGs) are the primary mechanism for development - of IETF specifications and guidelines, many of which are intended to - be standards or recommendations. A working group may be established - at the initiative of an Area Director 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 IETF - Area Director(s) in whose area the working group would fall and MUST - proceed through the formal steps detailed in this section. - - Working groups are typically created to address a specific problem or - to produce one or more specific deliverables (a guideline, standards - specification, etc.). Working groups are generally expected to be - short-lived in nature. Upon completion of its goals and achievement - of its objectives, the working group is terminated. A working group - may also be terminated for other reasons (see section 4). - Alternatively, with the concurrence of the IESG, Area Director, the - WG Chair, and the WG participants, the objectives or assignment of - the working group may be extended by modifying the working group's - charter through a rechartering process (see section 5). - -2.1. Criteria for formation - - When determining whether it is appropriate to create a working group, - the Area Director(s) and the IESG will consider several issues: - - - Are the issues that the working group plans to address clear and - relevant to the Internet community? - - - Are the goals specific and reasonably achievable, and achievable - within a reasonable time frame? - - - -Bradner Best Current Practice [Page 4] - -RFC 2418 Working Group Guidelines September 1998 - - - - What are the risks and urgency of the work, to determine the level - of effort 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. - - - Is there sufficient interest within the IETF in the working - group's topic with enough 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 contributing to the document text. IETF experience suggests - that these roles typically cannot all be handled by one person; a - minimum of four or five active participants in the management - positions are typically required in addition to a minimum of one - or two dozen people that will attend the working group meetings - and contribute on the mailing list. NOTE: The interest must be - broad enough that a working group would not be seen as merely the - activity of a single vendor. - - - Is there enough expertise within the IETF in the working group's - topic, and are those people interested in contributing in the - working group? - - - 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. - - - Does the IETF have a reasonable role to play in the determination - of the technology? There are many Internet-related technologies - that may be interesting to IETF members but in some cases the IETF - may not be in a position to effect the course of the technology in - the "real world". This can happen, for example, if the technology - is being developed by another standards body or an industry - consortium. - - - Are all known intellectual property rights relevant to the - proposed working group's efforts issues understood? - - - Is the proposed work plan an open IETF effort or is it an attempt - to "bless" non-IETF technology where the effect of input from IETF - participants may be limited? - - - - - -Bradner Best Current Practice [Page 5] - -RFC 2418 Working Group Guidelines September 1998 - - - - Is there a good understanding of any existing work that is - relevant to the topics that the proposed working group is to - pursue? This includes work within the IETF and elsewhere. - - - Do the working group's goals overlap with known work in another - standards body, and if so is adequate liaison in place? - - Considering the above criteria, the Area Director(s), using his or - her best judgement, 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(s), although final approval is made by the - IESG with advice from 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 information for 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(s), the Area Director and the IETF - Secretariat are satisfied with the charter form and content, it - becomes the basis for forming a working group. Note that an Area - Director MAY require holding an exploratory Birds of a Feather (BOF) - meeting, as described below, to gage the level of support for a - working group before submitting the charter to the IESG and IAB for - approval. - - Charters may be renegotiated periodically to reflect the current - status, organization or goals of the working group (see section 5). - Hence, a charter is a contract between the IETF and the working group - which is committing to meet explicit milestones and delivering - specific "products". - - Specifically, each charter consists of the following 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. - - - -Bradner Best Current Practice [Page 6] - -RFC 2418 Working Group Guidelines September 1998 - - - Chair(s) - The working group may have one or more Chairs to perform the - administrative functions of the group. The email address(es) of - the Chair(s) shall be included. Generally, a working group is - limited to two chairs. - - 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(s). - - Responsible Area Director - The Area Director who acts as the primary IESG contact for the - working group. - - Mailing list - An IETF working group MUST have a general Internet mailing list. - Most of the work of an IETF working group will be conducted on the - mailing list. The working group charter MUST include: - - 1. The address to which a participant sends a subscription request - and the procedures to follow when subscribing, - - 2. The address to which a participant sends submissions and - special procedures, if any, and - - 3. The location of the mailing list archive. A message archive - MUST be maintained in a public place which can be accessed via - FTP or via the web. - - As a service to the community, the IETF Secretariat operates a - mailing list archive for working group mailing lists. In order - to take advantage of this service, working group mailing lists - MUST include the address "wg_acronym-archive@lists.ietf.org" - (where "wg_acronym" is the working group acronym) in the - mailing list in order that a copy of all mailing list messages - be recorded in the Secretariat's archive. Those archives are - located at ftp://ftp.ietf.org/ietf-mail-archive. For - robustness, WGs SHOULD maintain an additional archive separate - from that maintained by the Secretariat. - - 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 can be used as an overview of the working group's - - - -Bradner Best Current Practice [Page 7] - -RFC 2418 Working Group Guidelines September 1998 - - - effort. - - To facilitate evaluation of the intended work and to provide on- - going guidance to the working group, the charter must describe the - problem being solved and should discuss objectives and expected - impact with respect to: - - - Architecture - - Operations - - Security - - Network management - - Scaling - - Transition (where applicable) - - Goals and milestones - The working group charter MUST establish a timetable for specific - work items. While this may be renegotiated 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 (see section 5). - - An example of a WG charter is included as Appendix A. - -2.3. Charter review & approval - - Proposed 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 a Consultant from - among the ranks of senior IETF participants. (Consultants are - described in section 6.) At the discretion of the Area Director, - 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 Area - Director deems appropriate) has approved the working group charter, - the charter is submitted for review by the IAB and approval by the - IESG. After a review period of at least a week the proposed charter - is posted to the IETF-announce mailing list as a public notice that - the formation of the working group is being considered. At the same - time the proposed charter is also posted to the "new-work" mailing - - - -Bradner Best Current Practice [Page 8] - -RFC 2418 Working Group Guidelines September 1998 - - - list. This mailing list has been created to let qualified - representatives from other standards organizations know about pending - IETF working groups. After another review period lasting at least a - week the IESG MAY approve the charter as-is, it MAY request that - changes be made in the charter, or MAY decline to approve chartering - of the working group - - If the IESG approves the formation of the working group it remands - the approved charter to the IETF Secretariat who records and enters - the information into the IETF tracking database. The working group - is announced to the IETF-announce a by the IETF Secretariat. - -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. - In addition, 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 a relevant - Area Director who must approve a BOF before it can be scheduled. The - person who requests the BOF may be asked to serve as Chair of the - BOF. - - The Chair of the BOF is also responsible for providing a report on - the outcome of the BOF. If the Area Director approves, the BOF is - then scheduled by submitting a request to agenda@ietf.org with copies - to the Area Director(s). A BOF description and agenda are required - before a BOF can be scheduled. - - Available time for BOFs is limited, and BOFs are held at the - discretion of the ADs for an area. The AD(s) may require additional - assurances before authorizing a BOF. For example, - - - The Area Director MAY require the establishment of an open email - list 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 Area Director MAY require that a BOF be held, prior to - establishing a working group (see section 2.2). - - - The Area Director MAY require that there be a draft of the WG - charter prior to holding a BOF. - - - -Bradner Best Current Practice [Page 9] - -RFC 2418 Working Group Guidelines September 1998 - - - - The Area Director MAY require that a BOF not be held until an - Internet-Draft describing the proposed technology has been - published so it can be used as a basis for discussion in the BOF. - - In general, a BOF on a particular topic is held only once (ONE slot - at one IETF Plenary meeting). Under unusual circumstances Area - Directors may, at their discretion, allow a BOF to meet for a second - time. BOFs are not permitted to meet three times. Note that all - other things being equal, WGs will be given priority for meeting - space over BOFs. Also, occasionally BOFs may be held for other - purposes than to discuss formation of a working group. - - 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; - - - While there was a reasonable level of interest expressed in the - BOF some other criteria for working group formation was not met - (see section 2.1). - - - 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. - -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". WG participants should specifically note the - requirements for disclosure of conflicts of interest in [2]. - - A number of procedural questions and issues will arise over time, and - it is the function of the Working Group Chair(s) 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 has evolved - over time that have proven successful. These are listed here, with - - - -Bradner Best Current Practice [Page 10] - -RFC 2418 Working Group Guidelines September 1998 - - - actual choices typically determined by the working group participants - and the Chair(s). - -3.1. Session planning - - For coordinated, structured WG interactions, the Chair(s) MUST - publish a draft agenda well in advance of the actual session. The - agenda should 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. - - Publication of the working group agenda shall include sending a copy - of the agenda to the working group mailing list and to - agenda@ietf.org. - - 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. IETF - Plenary meetings are the primary venue for these face-to-face working - group sessions, and it is common (though not required) that active - "interim" face-to-face meetings, telephone conferences, or video - conferences may also be held. Interim meetings are subject to the - same rules for advance notification, reporting, open participation, - and process, which apply to other working group meetings. - - 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@ietf.org - -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 - - - -Bradner Best Current Practice [Page 11] - -RFC 2418 Working Group Guidelines September 1998 - - - participants. In determining the balance, the WG must ensure that - its process does not serve to exclude contribution by email-only - participants. Decisions reached during a face-to-face meeting about - topics or issues which have not been discussed on the mailing list, - or are significantly different from previously arrived mailing list - consensus MUST be reviewed on the mailing list. - - 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 - facilitate schedule coordination for WGs requiring the same set of - experts. - - The application for a WG session at an IETF meeting MUST be made to - the IETF Secretariat at the address agenda@ietf.org. Some Area - Directors may want to coordinate WG sessions in their area and - request that time slots be coordinated through them. If this is the - case it will be noted in the IETF meeting announcement. A WG - scheduling request MUST contain: - - - The working group name and full title; - - 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 should not be scheduled for the same time slot(s); - and - - Optionally a request can be added for the WG session to be - transmitted over the Internet in audio and video. - - 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, or who, in the opinion of the Chair is - disrupting the WG process. The Chair should consult with the Area - Director(s) if the individual persists in disruptive behavior. - - 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. - - - - - -Bradner Best Current Practice [Page 12] - -RFC 2418 Working Group Guidelines September 1998 - - - Many working group participants hold that mailing list discussion is - the best place to consider and resolve issues and make decisions. The - 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. - - As with face-to-face sessions occasionally one or more individuals - may engage in behavior on a mailing list which disrupts the WG's - progress. In these cases the Chair should attempt to discourage the - behavior by communication directly with the offending individual - rather than on the open mailing list. If the behavior persists then - the Chair must involve the Area Director in the issue. As a last - resort and after explicit warnings, the Area Director, with the - approval of the IESG, may request that the mailing list maintainer - block the ability of the offending individual to post to the mailing - list. (If the mailing list software permits this type of operation.) - Even if this is done, the individual must not be prevented from - receiving messages posted to the list. Other methods of mailing list - control may be considered but must be approved by the AD(s) and the - IESG. - -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 a show of hands, humming, or any other means on - which the WG agrees (by rough consensus, of course). Note that 51% - of the working group does not qualify as "rough consensus" and 99% is - better than rough. It is up to the Chair to determine if rough - consensus has been reached. - - It can be particularly challenging to gauge the level of consensus on - a mailing list. There are two different cases where a working group - may be trying to understand the level of consensus via a mailing list - discussion. But in both cases the volume of messages on a topic is - not, by itself, a good indicator of consensus since one or two - individuals may be generating much of the traffic. - - In the case where a consensus which has been reached during a face- - to-face meeting is being verified on a mailing list the people who - were in the meeting and expressed agreement must be taken into - account. If there were 100 people in a meeting and only a few people - - - -Bradner Best Current Practice [Page 13] - -RFC 2418 Working Group Guidelines September 1998 - - - on the mailing list disagree with the consensus of the meeting then - the consensus should be seen as being verified. Note that enough - time should be given to the verification process for the mailing list - readers to understand and consider any objections that may be raised - on the list. The normal two week last-call period should be - sufficient for this. - - The other case is where the discussion has been held entirely over - the mailing list. The determination of the level of consensus may be - harder to do in this case since most people subscribed to mailing - lists do not actively participate in discussions on the list. It is - left to the discretion of the working group chair how to evaluate the - level of consensus. The most common method used is for the working - group chair to state what he or she believes to be the consensus view - and. at the same time, requests comments from the list about the - stated conclusion. - - 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 decide 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; - - 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; - - - - - -Bradner Best Current Practice [Page 14] - -RFC 2418 Working Group Guidelines September 1998 - - - 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 - - Disputes are possible at various stages during the IETF process. As - much as possible the process is designed so that compromises can be - made, and genuine consensus achieved; however, there are times when - even the most reasonable and knowledgeable people are unable to - agree. To achieve the goals of openness and fairness, such conflicts - must be resolved by a process of open review and discussion. - - Formal procedures for requesting a review of WG, Chair, Area Director - or IESG actions and conducting appeals are documented in The Internet - Standards Process [1]. - -4. Working Group Termination - - Working groups are typically chartered to accomplish a specific task - or tasks. After the tasks are complete, the group will be disbanded. - However, if a WG produces a Proposed or Draft Standard, the WG will - frequently become dormant rather than disband (i.e., the WG will no - longer conduct 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, or if the assumptions - which that work was based have been modified in discussion or by - experience, the Area Director, in consultation with the working group - can either: - - 1. Recharter to refocus its tasks, - 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 (see section 3.4). - -5. Rechartering a Working Group - - Updated milestones are renegotiated with the Area Director and the - IESG, as needed, and then are submitted to the IESG Secretariat: - iesg-secretary@ietf.org. - - - -Bradner Best Current Practice [Page 15] - -RFC 2418 Working Group Guidelines September 1998 - - - Rechartering (other than revising milestones) a working group follows - the same procedures that the initial chartering does (see section 2). - The revised charter must be submitted to the IESG and IAB for - approval. As with the initial chartering, the IESG may approve new - charter as-is, it may request that changes be made in the new charter - (including having the Working Group continue to use the old charter), - or it may decline to approve the rechartered working group. In the - latter case, the working group is disbanded. - -6. 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. The Area - Director must agree to the specific people performing the WG Chair, - and Working Group Consultant roles, and they serve at the discretion - of the Area Director. - -6.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. - - The Chair has the responsibility and the authority to make decisions, - on behalf of the working group, regarding all matters of working - group process and staffing, in conformance with the rules of the - IETF. The AD has the authority and the responsibility to assist in - making those decisions at the request of the Chair or when - circumstances warrant such an intervention. - - The Chair's responsibility encompasses at 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. The - Chair is also responsible to ensure that the working group - operates in an open and fair manner. 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 - - - -Bradner Best Current Practice [Page 16] - -RFC 2418 Working Group Guidelines September 1998 - - - group to assign the task of specification Editor to one or two - participants. Sometimes, they also are part of the design team, - described below. - - 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 can be - structured as true meetings, conducted over the course of several - days (to allow participation across the Internet). - - Organize, prepare and chair face-to-face and on-line formal - sessions. - - Plan WG Sessions - - The Chair must plan and announce all WG sessions well in advance - (see section 3.1). - - 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 section - 3.1). - - Immediately after a session, the WG Chair MUST provide the Area - Director with a very short report (approximately one paragraph, - via email) on the session. - - Distribute the workload - - 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 must make sure that authors of WG documents incorporate - changes as agreed to by the WG (see section 6.3). - - - - - -Bradner Best Current Practice [Page 17] - -RFC 2418 Working Group Guidelines September 1998 - - - Document publication - - The Chair and/or Document Editor will work with the RFC Editor to - ensure document conformance with RFC publication requirements [5] - 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. - - Document implementations - - Under the procedures described in [1], the Chair is responsible - for documenting the specific implementations which qualify the - specification for Draft or Internet Standard status along with - documentation about testing of the interoperation of these - implementations. - -6.2. WG Secretary - - Taking minutes and editing working group documents often is performed - by a specifically-designated participant or set of participants. In - this role, the Secretary's job is to record WG decisions, rather than - to perform basic specification. - -6.3. Document Editor - - Most IETF working groups focus their efforts on a document, or set of - documents, that capture the results of the group's work. A working - group generally designates a person or persons to serve as the Editor - for a particular document. The Document Editor is responsible for - ensuring that the contents of the document accurately reflect the - decisions that have been made by the working group. - - As a general practice, the Working Group Chair and Document Editor - positions are filled by different individuals to help ensure that the - resulting documents accurately reflect the consensus of the working - group and that all processes are followed. - -6.4. 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. - - - - - - -Bradner Best Current Practice [Page 18] - -RFC 2418 Working Group Guidelines September 1998 - - -6.5. Design teams - - It is often useful, and perhaps inevitable, for a sub-group of a - working group to develop a proposal to solve a particular problem. - Such a sub-group is called a design team. In order for a design team - to remain small and agile, it is acceptable to have closed membership - and private meetings. Design teams may range from an informal chat - between people in a hallway to a formal set of expert volunteers that - the WG chair or AD appoints to attack a controversial problem. The - output of a design team is always subject to approval, rejection or - modification by the WG as a whole. - -6.6. Working Group Consultant - - At the discretion of the Area Director, a Consultant may be assigned - to a working group. Consultants have specific technical background - appropriate to the WG and experience in Internet architecture and - IETF process. - -6.7. 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. - -7. Working Group Documents - -7.1. Session documents - - All relevant documents to be discussed at a session should be - published and available as Internet-Drafts at least two weeks before - a session starts. Any document which does not meet this publication - deadline can only be discussed in a working group session with the - specific approval of the working group chair(s). Since it is - important that working group members have adequate time to review all - documents, granting such an exception should only be done under - unusual conditions. The final session agenda should be posted to the - working group mailing list at least two weeks before the session and - sent at that time to agenda@ietf.org for publication on the IETF web - site. - -7.2. Internet-Drafts (I-D) - - The Internet-Drafts directory is provided to working groups as a - resource for posting and disseminating in-process copies of working - group documents. This repository is replicated at various locations - around the Internet. It is encouraged that draft documents be posted - - - -Bradner Best Current Practice [Page 19] - -RFC 2418 Working Group Guidelines September 1998 - - - 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@ietf.org - - 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 on their web site and in the ftp directory; - - The I-D filename; and - - 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. The organization of the - Internet-Drafts directory is found in the file "1id-organization" in - the Internet-Drafts directory at an Internet Repository site. This - file also contains the rules for naming Internet-Drafts. (See [1] - for more information about Internet-Drafts.) - -7.3. Request For Comments (RFC) - - The work of an IETF working group often results in publication of one - or more documents, as part of the Request For Comments (RFCs) [1] - 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. - - 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 [4]. - -7.4. Working Group Last-Call - - When a WG decides that a document is ready for publication it may be - submitted to the IESG for consideration. In most cases the - determination that a WG feels that a document is ready for - publication is done by the WG Chair issuing a working group Last- - Call. The decision to issue a working group Last-Call is at the - discretion of the WG Chair working with the Area Director. A working - group Last-Call serves the same purpose within a working group that - - - -Bradner Best Current Practice [Page 20] - -RFC 2418 Working Group Guidelines September 1998 - - - an IESG Last-Call does in the broader IETF community (see [1]). - -7.5. Submission of documents - - Once that a WG has determined at least rough consensus exists within - the WG for the advancement of a document the following must be done: - - - The version of the relevant document exactly as agreed to by the WG - MUST be in the Internet-Drafts directory. - - - The relevant document MUST be formatted according to section 7.3. - - - The WG Chair MUST send email to the relevant Area Director. A copy - of the request MUST be also sent to the IESG Secretariat. The mail - MUST contain the reference to the document's ID filename, and the - action requested. The copy of the message to the IESG Secretariat - is to ensure that the request gets recorded by the Secretariat so - that they can monitor the progress of the document through the - process. - - Unless returned by the IESG to the WG for further development, - progressing of the document is then the responsibility of the IESG. - After IESG approval, responsibility for final disposition is the - joint responsibility of the RFC Editor, the WG Chair and the Document - Editor. - -8. Review of documents - - The IESG reviews all documents submitted for publication as RFCs. - Usually minimal IESG review is necessary in the case of a submission - from a WG intended as an Informational or Experimental RFC. More - extensive review is undertaken in the case of standards-track - documents. - - Prior to the IESG beginning their deliberations on standards-track - documents, IETF Secretariat will issue a "Last-Call" to the IETF - mailing list (see [1]). This Last Call will announce the intention of - the IESG to consider 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 should not serve as a more - general, in-depth review. - - The IESG review takes into account responses to the Last-Call and - will lead to one of these possible conclusions: - - - - - -Bradner Best Current Practice [Page 21] - -RFC 2418 Working Group Guidelines September 1998 - - - 1. The document is accepted as is for the status requested. - This fact will be announced by the IETF Secretariat to the IETF - mailing list and to the RFC Editor. - - 2. The document is accepted as-is but not for the status requested. - This fact will be announced by the IETF Secretariat to the IETF - mailing list and to the RFC Editor (see [1] for more details). - - 3. Changes regarding content are suggested to the author(s)/WG. - Suggestions from the IESG must be clear and direct, so as to - facilitate working group and author correction of the - specification. If the author(s)/WG can explain to the - satisfaction of the IESG why the changes are not necessary, the - document will be accepted for publication as under point 1, above. - If the changes are made the revised document may be resubmitted - for IESG review. - - 4. Changes are suggested by the IESG and a change in status is - recommended. - The process described above for 3 and 2 are followed in that - order. - - 5. The document is rejected. - Any document rejection will be accompanied by specific and - thorough arguments from the IESG. Although the IETF and working - group process is structured such that this alternative is not - likely to arise for documents coming from a working group, the - IESG has the right and responsibility to reject documents that the - IESG feels are fatally flawed in some way. - - 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 this type of complaints is - described in [1]. - -9. Security Considerations - - Documents describing IETF processes, such as this one, do not have an - impact on the security of the network infrastructure or of Internet - applications. - - It should be noted that all IETF working groups are required to - examine and understand the security implications of any technology - they develop. This analysis must be included in any resulting RFCs - in a Security Considerations section. Note that merely noting a - significant security hole is no longer sufficient. IETF developed - technologies should not add insecurity to the environment in which - they are run. - - - -Bradner Best Current Practice [Page 22] - -RFC 2418 Working Group Guidelines September 1998 - - -10. Acknowledgments - - This revision of this document relies heavily on the previous version - (RFC 1603) which was edited by Erik Huizer and Dave Crocker. It has - been reviewed by the Poisson Working Group. - -11. References - - [1] Bradner, S., Editor, "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - [2] Hovey, R., and S. Bradner, "The Organizations involved in the - IETF Standards Process", BCP 11, RFC 2028, October 1996. - - [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall - Process: Operation of the Nominating and Recall Committees", BCP - 10, RFC 2282, February 1998. - - [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards", - RFC 1796, April 1995. - - [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC - 2223, October 1997. - - [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Level", BCP 14, RFC 2119, March 1997. - - -12. Editor's Address - - Scott Bradner - Harvard University - 1350 Mass Ave. - Cambridge MA - 02138 - USA - - Phone +1 617 495 3864 - EMail: sob@harvard.edu - - - - - - - - - - - - -Bradner Best Current Practice [Page 23] - -RFC 2418 Working Group Guidelines September 1998 - - - Appendix: Sample Working Group Charter - - Working Group Name: - IP Telephony (iptel) - - IETF Area: - Transport Area - - Chair(s): - Jonathan Rosenberg <jdrosen@bell-labs.com> - - Transport Area Director(s): - Scott Bradner <sob@harvard.edu> - Allyn Romanow <allyn@mci.net> - - Responsible Area Director: - Allyn Romanow <allyn@mci.net> - - Mailing Lists: - General Discussion:iptel@lists.research.bell-labs.com - To Subscribe: iptel-request@lists.research.bell-labs.com - Archive: http://www.bell-labs.com/mailing-lists/siptel - - Description of Working Group: - - Before Internet telephony can become a widely deployed service, a - number of protocols must be deployed. These include signaling and - capabilities exchange, but also include a number of "peripheral" - protocols for providing related services. - - The primary purpose of this working group is to develop two such - supportive protocols and a frameword document. They are: - - 1. Call Processing Syntax. When a call is setup between two - endpoints, the signaling will generally pass through several servers - (such as an H.323 gatekeeper) which are responsible for forwarding, - redirecting, or proxying the signaling messages. For example, a user - may make a call to j.doe@bigcompany.com. The signaling message to - initiate the call will arrive at some server at bigcompany. This - server can inform the caller that the callee is busy, forward the - call initiation request to another server closer to the user, or drop - the call completely (among other possibilities). It is very desirable - to allow the callee to provide input to this process, guiding the - server in its decision on how to act. This can enable a wide variety - of advanced personal mobility and call agent services. - - - - - - -Bradner Best Current Practice [Page 24] - -RFC 2418 Working Group Guidelines September 1998 - - - Such preferences can be expressed in a call processing syntax, which - can be authored by the user (or generated automatically by some - tool), and then uploaded to the server. The group will develop this - syntax, and specify means of securely transporting and extending it. - The result will be a single standards track RFC. - - 2. In addition, the group will write a service model document, which - describes the services that are enabled by the call processing - syntax, and discusses how the syntax can be used. This document will - result in a single RFC. - - 3. Gateway Attribute Distribution Protocol. When making a call - between an IP host and a PSTN user, a telephony gateway must be used. - The selection of such gateways can be based on many criteria, - including client expressed preferences, service provider preferences, - and availability of gateways, in addition to destination telephone - number. Since gateways outside of the hosts' administrative domain - might be used, a protocol is required to allow gateways in remote - domains to distribute their attributes (such as PSTN connectivity, - supported codecs, etc.) to entities in other domains which must make - a selection of a gateway. The protocol must allow for scalable, - bandwidth efficient, and very secure transmission of these - attributes. The group will investigate and design a protocol for this - purpose, generate an Internet Draft, and advance it to RFC as - appropriate. - - Goals and Milestones: - - May 98 Issue first Internet-Draft on service framework - Jul 98 Submit framework ID to IESG for publication as an RFC. - Aug 98 Issue first Internet-Draft on Call Processing Syntax - Oct 98 Submit Call processing syntax to IESG for consideration - as a Proposed Standard. - Dec 98 Achieve consensus on basics of gateway attribute - distribution protocol - Jan 99 Submit Gateway Attribute Distribution protocol to IESG - for consideration as a RFC (info, exp, stds track TB - - - - - - - - - - - - - - -Bradner Best Current Practice [Page 25] - -RFC 2418 Working Group Guidelines September 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Bradner Best Current Practice [Page 26] - |
