Skip to main content

IETF Working Group Guidelines and Procedures
draft-ietf-iesg-wgguidelines-01

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 1603.
Authors Dr. Erik Huizer , Dave Crocker
Last updated 2013-03-02 (Latest revision 1994-01-31)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 1603 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-iesg-wgguidelines-01
Network Working Group                                        IESG
        INTERNET-DRAFT                                        Erik Huizer
                                                              SURFnet  bv
                                                               D. Crocker
                                                   Silicon Graphics, Inc.
                                                                June 1993
                                        
                                        
                                        
                                        
                               IETF Working Group
                            Guidelines and Procedures
                                        
        
        
        
        STATUS OF THIS MEMO
        
        This document is an Internet Draft. Internet Drafts are working
        documents of the Internet Engineering Task Force (IETF), its
        Areas, and its Working Groups. Note that other groups may also
        distribute working documents as Internet Drafts.
        
        Internet Drafts are draft documents valid for a maximum of six
        months. Internet Drafts may be updated, replaced, or obsoleted by
        other documents at any time. It is not appropriate to use
        Internet Drafts as reference material or to cite them other than
        as a ``working draft'' or ``work in progress.''
        
        Please check the 1id-abstracts.txt listing contained in the
        internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
        nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
        current status of any Internet Draft.
        
        When finalized the draft document will be submitted to the RFC
        editor as an informational document. Distribution of this memo is
        unlimited. Please send comments to the author.
        
        
        
        ABSTRACT
        
        The Internet Engineering Task Force (IETF) has the primary
        responsibility for developing and review of specifications
        intended as Internet Standards. IETF activities are organized
        into Working Groups  (WG). This document describes the guidelines
        and procedures for formation and operation of an IETF Working
        Groups. It describes the formal relationship between a WG and the
        Internet Engineering and Steering Group (IESG). The basic duties
        of a WG chair and an IESG Area Director are defined.
        
        
        IESG                                                                1
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        The expiration date of this Internet Draft is December 1993.
        
        
        
        TABLE OF CONTENTS
        
        1.   INTRODUCTION
             1.1. IETF Approach to Standardization
             1.2. Acknowledgments
        
        2.   GROUP PROCESS
             2.1. Working Group Purpose & Scope
             2.2. Wg Policies And Procedures
             2.3. Birds Of A Feather (Bof)
             2.4. WG Formation
                  Criteria for Formation
                  Charter
                  Charter Review & Approval
             2.5. Working Group Sessions
             2.6. Termination Of A WG
        
        3.   MANAGEMENT
             3.1. WG Chair Duties
             3.2. Area Director Duties
             3.3. Contention And Appeals Overview
        
        4.   DOCUMENT PROCEDURES
             4.1. Internet Drafts
             4.2. Request For Comments (RFC)
             4.3. Submission Of Documents
             4.4. Review Of Documents
        
        5.   SECURITY CONSIDERATIONS
        
        6.   REFERENCES
        
        7.   AUTHORS ADDRESS
        
        APPENDIX: Sample Working Group charter
        
        
        
        1.  INTRODUCTION
        
        This document defines guidelines and procedures for Internet
        Engineering Task Force Working Groups.  The Internet, a loosely-
        organized international collaboration of autonomous,
        interconnected networks, supports host-to-host communication
        through voluntary adherence to open protocols and procedures
        
        IESG                                                                2
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        defined by Internet Standards, a collection of which are commonly
        known as "the TCP/IP protocol suite". The Internet Standards
        Process is defined in RFC 1310bis [1].  The primary
        responsibility for the development and review of potential
        Internet Standards from all sources is conducted by the Internet
        Engineering Task Force (IETF). The goals, structures and
        procedures of the IETF can be found in it's charter [3].
        
        The IETF is a large, open community of network designers,
        operators, vendors, 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. At present there are
        10 areas, though the number and purview of Areas changes over
        time:
             
             <<ARE THESE THESE EXACT NAMES OF THE AREAS??>>
        
                1)  User Services
                2)  Applications
                3)  Service Applications
                4)  Transport Services
                5)  Internet Services
                6)  Routing
                7)  Network Management
                8)  Operational Requirements
                9)  Security
               10)  Standards & Processes
        
        Most Areas have an advisory group, called the Area Directorate,
        to assist the Area Directors, e.g., with the review of
        specifications produced in the area. The Area Directorate is
        formed by the Area Director(s) from senior members of the
        community represented by the Area.  A small IETF Secretariat
        provides staff and administrative support for the operation of
        the IETF.
        
        The primary work of the IETF is performed by subcommittees 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.
        
        Membership in the IETF is established simply by the fact of
        participation in its activities.  This participation may be by on-
        line contribution, attendance at face-to-face sessions, or both.
        No formal rules govern this membership.  Any member of the
        Internet community with the time and interest is urged to
        
        IESG                                                                3
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        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 words like: "shall", "will", "must" and "is required" where
        it describes steps in the process that are essential. Words like
        "suggested", "should" and "may" are used 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 read The IETF Charter [3] and  The
        Internet Standards Process [1]. Familiarity with these documents
        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.
             
             ...
             
             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
        
        
        IESG                                                                4
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
             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 Cerf [8] from whom we borrowed the
        description of the IETF. And Greg Vaudreuil and Steve Coya [9]
        who provided several paragraphs. All the errors you'll find are
        probably ours.
        
        
        
        
        
        
        
        IESG                                                                5
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        
        2.  GROUP PROCESS
        
        
        
        2.1. Working Group Purpose & Scope
        
        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 instigation of an Area Director (AD), or
        its creation may be initiated by an individual or group of
        individuals. Anyone interested in creating an IETF working group
        must obtain the advise and consent of  the appropriate IETF Area
        Director under whose direction the working group would fall.
        
        A working group is typically created to address a specific
        problem or produce a specific deliverable (guideline, standard,
        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 Area Director and the working group chair and
        membership, the objectives or assignment of the working group may
        be extended by enhancing or modifying the working group's
        statement of objectives
        
        
        
        2.2. Wg Policies And Procedures
        
        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 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 no 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. Some of these
        
        
        
        IESG                                                                6
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        are listed here, with actual choices typically determined by the
        working group members and the chair.
             
             1. For face-to-face sessions, the chair should publish a
                draft WG-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. The  documents should be publicly
                    available (preferably as Internet drafts; see next
                    section) with information needed to access them.
             
             2. All relevant documents for a session (including the
                final agenda) should be published and available at least
                two weeks before the session starts.
             
             3. It is strongly suggested that the WG chair makes sure
                that an anonymous FTP directory be available for the
                upcoming session.  All relevant documents (including the
                final WG-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.
             
             4. While open discussion and contribution is essential to
                working group success, the chair is responsible for
                ensuring forward progress.  As appropriate it may be
                acceptable to have restricted participation (not
                attendance!) at IETF working group sessions for the
                purpose of achieving progress. The working group chair
                usually has the authority to refuse to grant the floor
                to any individual who is unprepared or otherwise
                covering inappropriate material.
             
             5. The detailed specification effort within a working group
                may be assigned to self-selecting sub-groups, called
                Design Teams.  They may hold closed sessions for
                conducting 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
        
        
        IESG                                                                7
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
                members and the DT must be responsive to the direction
                of the working group's "rough" consensus.
             
             6. Many working group participants hold that mailing list
                discussion is the best place to consider and resolve
                issues and make decisions, while others maintain that
                such work should be accomplished primarily at IETF
                meetings. 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
                wide base of interested persons than is attendance at
                IETF meetings, due to the time and expense required to
                attend.
             
             7. 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.
             
             8. Consensus can be determined by balloting, humming, or
                any other means the WG agrees on (by rough consensus, of
                course).  IETF consensus does not require that all
                members 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.)
             
             9. It is occasionally appropriate to re-visit 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 E-mail in the minutes of
                the next 'live' session, and to briefly summarise
                decision making history in the final documents the WG
                produces.
             
             10.     To facilitate making forward progress, a working
                group chair may wish to direct a discussion to reject
                the input from a member, based upon the following
                criteria:
                
                (old)      The input pertains to a topic that already
        
        
        IESG                                                                8
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
                            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;
                            or
                
                (not yet)  The input pertains to a topic that the
                            working group has not yet opened for
                            discussion.
        
        
        
        2.3. Birds Of A Feather (Bof)
        
        For an individual, or small group of individuals, it is often not
        clear if the issue(s) at hand merit the formation of a WG. To
        alleviate this problem 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.
        
        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 has to
        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.
        
        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;
             
             -  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:
             
             1. All BOFs wishing to meet during an IETF meeting 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.
        
        IESG                                                                9
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
             
             2. 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 IETF Secretariat for inclusion in the proceedings.
             
             3. A BOF may be held only once (ONE slot at one IETF
                Plenary meeting).
             
             4. Under unusual circumstances an Area Director can, at
                his/her 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.
             
             5. BOFs are not permitted to meet three times.
             
             6. Non-IETF groups wishing to participate in IETF meetings
                may hold a BOF for single-event discussion, or may
                pursue creation of normal IETF working groups for on-
                going interactions and discussions. The rules governing
                such BOFs are the same as for all other IETF BOFs and
                working groups.
             
             7. When necessary, IETF WGs will be given priority for
                meeting space over IETF BOFs.
        
        
        
        2.4. WG Formation
        
        
        Criteria for Formation
        
        When determining if creating a working group is appropriate, the
        Area Director 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?
             
             -  Do the working group's activities overlap with those of
                another working group? If so, it may still be
                appropriate to create another working group, but this
                question must be considered carefully by the Area
        
        IESG                                                               10
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
                Directors as subdividing efforts often dilutes the
                available technical expertise.
             
             -  Are there several people clearly interested in the
                working group's topic and willing to expend the effort
                to produce the desired result (e.g., a protocol
                specification)?  Working groups require considerable
                effort: a chair is needed to run sessions, an editor to
                maintain the working document(s), and contributors to
                write the text.  IETF experience suggests that these
                roles typically cannot all be handled by one person;
                four or five active members are typically required.  If
                the necessary staffing is lacking, the person interested
                in creating the working group might consider actually
                writing the specification alone and submitting it for
                review, rather than attempting to create a working
                group.
             
             -  Does a base of interested consumers appear to exist for
                the planned work?  Consumer interest can be measured by
                participation of end-users within the IETF process, as
                well as less direct indications.
        
        Considering the above criteria, the Area Director will decide
        whether to pursue the formation of the group through the
        chartering process.
        
        
        Charter
        
        The formation of a working group requires a charter which is
        negotiated between a prospective working group chair and the
        relevant Area Director and which:
             
             1) Lists relevant administrative aspects of the working
                group, such as identifying the WG Chair or co-Chairs,
                the WG secretary (who may also be the WG chair), and the
                addresses of the mailing list and any archive.
             
             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 goals and milestones together with
                time frames for their completion.
             
             3) Lists the milestones and dates for intermediate goals,
                and
        
        
        IESG                                                               11
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        When both the prospective chair and the Area Director are
        satisfied with the charter text, it becomes the basis for forming
        a working group. The charter document may be similarly
        renegotiated or modified at any time during the course of the
        working group's effort to reflect the changing goals of the
        group.
        
        Charters are reviewed and approved by the IESG. They may be re
        negotiated periodically to reflect the current status,
        organization or goals of the working group. Hence, a working
        group charter is a contract between the IETF and the working
        group which is committing to meeting explicit milestones and
        delivering concrete "products".
        
        Specifically, each charter consists of five sections:
        
        1.   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.
        
        2.   Working Group Chair(s):
             
             The working group may have one or two chair(s) to perform
             the administrative functions of the group. The chair(s)
             shall be reachable by Email.
        
        3.   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.
        
        4.   Working Group Description:
             
             In one to two paragraphs, the focus and intent of the group
             shall be set forth. 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 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.
             
             Recognizing the importance of security and network
             management in the Internet Architecture, this description of
        
        
        IESG                                                               12
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
             the work of the group must specifically address the impact
             of the work on these two issues.
        
        5.   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 such; e.g. 'Internet-
             draft finished' is fine, but 'discuss via E-mail' is not.
             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 IETF
             Secretariat
                  
                  ietfadm@cnri.reston.va.us
        
        6.   Mailing Lists:
             
             Most of the work of an IETF working group is conducted on
             Internet mailing lists. It is required that an IETF working
             group have a general discussion list. An individual needs to
             be designated as the list service postmaster, usually
             through a list-request alias mechanism. A message archive
             should be maintained in a public place which can be accessed
             via FTP. The address
                  
                  IETF-archive@cnri.reston.va.us
             
             shall be included on the mailing list. Retrieval from the
             archive via electronic mail requests also is recommended.
        
        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 access via FTP to
        the mail archives. 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. The
        list maintainer or archiver need not be the working group chair
        or secretary, but may be a member of the working group itself.
        
        An example of a WG charter is in appendix A.
        
        
        
        
        
        IESG                                                               13
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        Charter Review & Approval
        
        Once the Area Director has approved the Working Group charter,
        the charter is submitted to the Internet Engineering and Steering
        Group and Internet Architecture Board for review and approval.
        The IESG will primarily consider whether :
             
             -  There is sufficient expertise in the IETF to produce the
                desired results of the WG;
             
             -  There is a good indication that the intended user
                population wants this work;
             
             -  The risks and urgency of the work are specified, to
                determine the level of attention required, and
             
             -  The extent to which the work will affect an installed
                base of users is taken into account.
             
             -  The WG has overlap with WGs in other areas;
             
             -  Related work by other groups will be affected or will be
                sufficiently coordinated with the work of this group
        
        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 by the IESG Secretary
        to the IETF mailing list, by the IESG secretary.
        
        
        
        2.5. Working Group Sessions
        
        All working group actions shall be public, and wide participation
        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, and to direct
        future activities. It is common, but not required that a working
        group will meet at the trimester IETF plenary meetings.
        Additionally, interim sessions may be scheduled for telephone
        conference, video teleconference, or by actual face to face
        sessions.
        
        As noted in the earlier section on Working Group Policies and
        
        IESG                                                               14
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        Procedures, 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 consensus and
        ensuring consensus among a core of the working group members.
        
        Sessions must be publicized widely and well in advance and must
        take place at a convenient location.  The time and location of a
        session must be announced on the working group mailing list,
        through any other mechanisms that are appropriate,  and must
        include the IETF mailing list:
             
             ietf@cnri.reston.va.us
        
        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 the working group secretary
        or 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.
        
        If a WG needs a session at an IETF meeting, the chair must apply
        for one or more 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 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;
             
        
        IESG                                                               15
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
             -  The estimated number of people that will attend the WG
                session;
             
             -  Related wgs that must not be scheduled for the same time
                slot(s).
        
        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 wg-chairs
        for final approval.
        
        
        
        2.6. Termination Of A WG
        
        Working groups are typically chartered to accomplish a specific
        task. After that task is complete, the group will be disbanded.
        However, if the work of a WG results in a Proposed Standard, the
        WG will go dormant rather than disband (i.e., the WG will no
        longer conduct formal activities, but the mailing list and the
        membership 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.
        
        When the working group chairperson and the Area Director disagree
        about the steps required to refocus the group or the need to
        disband the group, the IESG will make a determination with input
        from the Area Director and the working group chair(s).
        
        
        
        
        
        
        
        
        
        
        IESG                                                               16
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        3.  MANAGEMENT
        
        
        
        3.1. WG Chair Duties
        
        The Working Group chair(s) have wide discretion in the conduct of
        business. The WG chair has to make sure that the WG operates in a
        reasonably efficient and effective way towards reaching the goals
        and results described in the WG charter. This very general
        description encompasses at the very least the following detailed
        tasks:
        
        -    Moderate the WG distribution list
             
             The chair should attempt to ensure that the discussions on
             this list are relevant and that they converge. 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 "session" with agenda and deliverables.
        
        -    Organize, prepare and chair face-to-face sessions
             
             The chair should plan and announce sessions well in advance.
             (See section on WG Sessions for exact procedures.)  The
             chair should make sure that relevant documents and the final
             WG-agenda are ready at least 2 weeks in advance of the
             session.  It is strongly suggested that the WG chair creates
             an anonymous FTP directory for the working group's
             documents. All relevant documents should be placed in this
             directory.
        
        -    Communicate results of session
             
             The chair must ensure that minutes of the session are taken
             and that an attendance list is circulated.  After screening
             the minutes the final version will be sent to the Area
             Director(s) and the IETF secretariat, in time for
             publication in the IETF proceedings. The WG chair should
             provide the Area Directors with a very short report (via E-
             mail) on the session directly after it takes place. These
             reports will be used for the Area Report as presented in the
             proceedings of each IETF meeting.
        
        -    Distribute the work
             
             Of course each WG will have members who may not be able to
             (or want to) do any work at all. Most of the time the bulk
        
        IESG                                                               17
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
             of the work is done by a few dedicated members. It is the
             task of the chair to motivate enough experts to allow for a
             fair distribution of the workload.
        
        -    Progress documents
             
             The chair will make sure that authors of WG documents
             incorporate changes as discussed by the WG. Once a document
             is approved by the WG the chair reports to the Area
             Director(s) and the IESG secretary. The chair indicates (per
             E-mail) which document has been approved, and asks the IESG
             to review it for publication (specify Experimental, Proposed
             STD, etc.). The Area Director will acknowledge receipt of
             the E-mail, and from then on action is the responsibility of
             the IESG. See the section on Review of Documents for
             possible further involvement of the chair in progressing
             documents.
        
        
        
        3.2. Area Director Duties
        
        The Area Directors are responsible for ensuring that working
        groups in their area produce coherent, coordinated and
        architecturally consistent output from the Working Groups in
        their area as a contribution to the overall results of the IETF.
        This very general description encompasses at the very least the
        detailed tasks related to the Working Groups:
        
        -    Coordination of WGs
             
             The Area director(s) coordinate the work done by the various
             WGs within (and sometimes even outside) the relevant Area.
             The Director(s) try 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(s) report to the IETF on progress in the
             Area.
        
        -    Reviewing
             
             The Area Directors may appoint independent reviewers prior
             to document approval. The Area Director(s) track the
        
        
        
        IESG                                                               18
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
             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 Directors track and manage the progress of the
             various WGs with the aid of a regular status report
             generated by the IESG secretary. The Area directors forward
             this regular status reports on documents and milestones made
             by the IESG Secretary to the WG chairs. This in turn helps
             the chairs to manage their WGs.
        
        -    Area Directorate
             
             The Area Director(s) chairs the Area Directorate. They are
             responsible for regular sessions of the directorate.
        
        
        
        3.3. Contention And Appeals Overview
        
        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 member 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 three levels:
        
         - Area
           
           This includes the Working Group review and Area Director
           review.  No appeal should come to the IESG before the Area
           Director has reviewed the point of contention.
        
         - IESG
           
           If the offended party is not happy with the Area-level
           review, then they may bring them to the IESG chair and the
           Area Director for Standards Management. The IESG chair has to
           be in this loop on this.  The IESG chair and the Standards
        
        
        IESG                                                               19
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
           Area Director will bring the issue before the IESG for
           discussion and take the resolution back to the parties.
        
         - IAB
           
           If the offended party is still not happy with the outcome at
           the IESG level, then they may take their concern to the IAB.
        
        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 members; continued success requires continued
        attention to working group process.
        
        
        
        4.  DOCUMENT PROCEDURES
        
        
        
        4.1. Internet Drafts
        
        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 status whatsoever. They may, eventually,
        turn into a standards-track document or they may sink from sight.
        
        
        
        
        
        IESG                                                               20
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        4.2. Request For Comments (RFC)
        
        The work of an IETF working group usually results in publication
        of one or more documents, published as a Request For Comments
        (RFCs) [4]. This series is the journal of 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 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 subseries of RFCs the reader is
        referred to [1,5,6,7].
        
        
        
        4.3. Submission Of Documents
        
        When a WG decides that a working document is ready for
        publication, the following must be done:
             
             -  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 (see RFC-1111 [4]).
             
             -  The WG chair sends email to the relevant Area
                Director(s), 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 Full -- STD) RFC.
        
        The Area Director(s) will acknowledge receipt of the E-mail. From
        then onwards the progressing of the document is the
        responsibility of the IESG.
        
        
        
        4.4. Review Of Documents
        
        In case the submission is intended as an Informational RFC only
        
        IESG                                                               21
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        no review is necessary. However if the WG or the RFC editor
        thinks that a review is appropriate, the AD may be asked to
        provide one. In case of submission as an Experimental RFC, the
        document will always be reviewed by the IESG. This review can
        either be done by the AD and other IESG members or the IESG may
        ask for an independent reviewer (i.e., 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 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 making a final decision on a standards-track document, the
        IESG will issue a "Last Call" to the IETF mailing list. 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,
        
        IESG                                                               22
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        to make sure that no important concerns have missed or
        misunderstood.  Last Call cannot serve as a more general, in-
        depth review.
        
        
        
        5.  SECURITY CONSIDERATIONS
        
        Security issues are not addressed in this memo.
        
        
        
        6.  REFERENCES
        
        [1]RFC1310bis, The Internet Standards Process
        
        [2]Charter Internet Society
        
        [3]New charter IETF
        
        [4]RFC 1111 Request for Comments on Request for Comments, J.
           Postel, August 1990.
        
        [5]RFC 1150 F.Y.I. on F.Y.I., G. Malkin and J. Reynolds, March
           1990
        
        [6]RFC 1311 Introduction to the Standards Notes, ed. J. Postel,
           March 1992.
        
        [7]RFC 1360 IAB Official Protocol Standards, ed. J. Postel,
           Sept. 1992.
        
        [8]RFC 1160, The Internet Activities Board, V.Cerf, may 1990
        
           (This should be OBE by [3] by the time this gets published)
        
        [9]Guidelines to Working Group Chair(s), S. Coya, IESG
           distribution only.
        
        
        
        7.  AUTHORS ADDRESS
        
        Erik Huizer
        SURFnet bv
        P.O. Box 19035                        Phone:        +31 30 310290
        3501 DA  Utrecht                        Fax:        +31 30 340903
        The Netherlands                       Email: 
        Erik.Huizer@SURFnet.nl
        
        IESG                                                               23
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        
        
        
        Dave Crocker
        Silicon Graphics, Inc.
        2011 N. Shoreline Blvd.                Phone:     +1 415 390 1804
        P.O. Box 7311                            Fax:     +1 415 962 8404
        Mountain View, CA 94039                Email:    dcrocker@sgi.com
        
        
        
        APPENDIX: Sample Working Group charter
        
        
        
        Integrated Directory Services (ids)
        
        Charter
        
        Chair(s):
                         Chris Weider  <clw@merit.edu>
                         Tim Howes  <tim@umich.edu>
        
        User Services Area Director(s)
        
                         Joyce Reynolds  <jkrey@isi.edu>
        
        Mailing lists:
                         General Discussion:ids@merit.edu
        
        To Subscribe:     ids-request@merit.edu
        
        Archive:         merit.edu:~/pub/ids-archive
        
        
        
        Description of Working Group:
        
        The Integrated Directory Services Working Group (IDS) is
        chartered to facilitate the integration and interoperability of
        current and future directory services into a unified directory
        service. This work will unite directory services based on a
        heterogeneous set of directory services protocols (X.500,
        WHOIS++, etc.). In addition to specifying technical requirements
        for the integration, the IDS Group will also contribute to the
        administrative and maintenance issues of directory service
        offerings by publishing guidelines on directory data integrity,
        maintenance, security, and privacy and legal issues for users and
        administrators of directories. IDS will also assume
        
        IESG                                                               24
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
        responsibility for the completion of the outstanding Directory
        Information Services Infrastructure (DISI) Internet-Drafts, which
        are all specific to the X.500 protocol, and for the maintenance
        of FYI 11, ``A catalog of available X.500 implementations''. IDS
        will need to liase with the groups working on development and
        deployment of the various directory service protocols.
        
        The IDS Working Group is a combined effort of the Applications
        Area and the User Services Area of the IETF.
        
        Goals and Milestones:
             
             Ongoing     Track emerging directory service protocols to
                       specify standards for interoperation with existing
                       protocols.
             
             Ongoing     Liase with groups working on deployment and
                       development of directory services to locate and
                       fix interoperability problems.
             
             Ongoing     Identify unfilled needs of directory service
                       offerers, administrators, and users.
             
             Mar 93      Submit to the IESG the DISI ``Advanced Usages of
                       X.500'' paper as an informational document.
             
             Mar 93      Submit to the IESG the DISI ``X.500 Pilot
                       Project Catalog'' paper as an informational
                       document.
             
             Mar 93      Submit to the IESG the 1993 revision of FYI 11,
                       ``A catalog of available X.500 implementations''
                       as an informational document.
             
             Mar 93      Submit as an Internet-Draft a ``Specifications
                       for interoperability between WHOIS++ and X.500''.
             
             Jul 93      Submit as an Internet-Draft a ``Guide to
                       administering a directory service'', which covers
                       data integrity, maintenance, privacy and legal
                       issues, and security.
             
             Jul 93      Submit as an Internet-Draft a ``Catalog of
                       available WHOIS++ implementations''.
             
             Nov 93      Submit to the IESG the ``Specifications for
                       interoperability between WHOIS++ and X.500'' as a
                       standards document.
             
        
        IESG                                                               25
        
INTERNET DRAFT           Working Group Guidelines          6/16/93
        
         
             Nov 93      Submit as an Internet-Draft a ``User's guide to
                       directory services on the Internet''.
             
             Mar 94      Submit to the IESG the ``Guide to administering
                       a directory service'' as an informational
                       document.
             
             Mar 94      Submit to the IESG the 1994 revision of FYI 11.
             
             Mar 94      Submit to the IESG the ``Catalog of available
                       WHOIS++ implementations'' as an informational
                       document.