doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc2418.txt b/doc/rfc/rfc2418.txt
new file mode 100644
index 0000000..9bdb2c5
--- /dev/null
+++ b/doc/rfc/rfc2418.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+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]
+