Network Working Group                                    D. Crocker, Ed.
Internet-Draft                               Brandenburg InternetWorking
Obsoletes: 2418, 7221 (if approved)                        R. Droms, Ed.
Updates: 2026 (if approved)                                Cisco Systems
Intended status: Best Current Practice                 September 1, 2015
Expires: March 4, 2016


              IETF Working Group Guidelines and Procedures
                draft-crocker-rfc2418bis-wgguidelines-01

Abstract

   IETF activities are primarily organized into open-participation
   working groups (WGs).  This document describes the formation,
   requirements, structure, and operation of IETF working groups.  This
   includes the formal relationships and duties of participants.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 4, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Crocker & Droms           Expires March 4, 2016                 [Page 1]


Internet-Draft         WG Guidelines & Procedures         September 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology and References  . . . . . . . . . . . . . . .   4
     1.3.  OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Basic Structure and Requirements  . . . . . . . . . . . . . .   6
     2.1.  Working Group Charter . . . . . . . . . . . . . . . . . .   6
     2.2.  Deliverables  . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Mailing List  . . . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Area Directors  . . . . . . . . . . . . . . . . . . . . .   8
     2.5.  Chair(s)  . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.6.  Document Writer . . . . . . . . . . . . . . . . . . . . .   9
     2.7.  Participants  . . . . . . . . . . . . . . . . . . . . . .   9
     2.8.  Rough Consensus Decision Making . . . . . . . . . . . . .   9
   3.  Documents . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  Home Page . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.2.  Wiki  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.3.  Issue-tracking Tickets  . . . . . . . . . . . . . . . . .  11
     3.4.  Meeting Materials . . . . . . . . . . . . . . . . . . . .  11
     3.5.  Internet-Drafts (I-D) . . . . . . . . . . . . . . . . . .  12
     3.6.  Request For Comments (RFC)  . . . . . . . . . . . . . . .  12
   4.  Working Group Internal Operation  . . . . . . . . . . . . . .  12
     4.1.  Prime Directives  . . . . . . . . . . . . . . . . . . . .  12
     4.2.  General Organizing  . . . . . . . . . . . . . . . . . . .  13
     4.3.  Discussion and Progress . . . . . . . . . . . . . . . . .  15
     4.4.  IETF Open Decision-Making . . . . . . . . . . . . . . . .  16
     4.5.  Mailing List Primacy  . . . . . . . . . . . . . . . . . .  16
     4.6.  Discussion Venues . . . . . . . . . . . . . . . . . . . .  17
     4.7.  Session Planning  . . . . . . . . . . . . . . . . . . . .  20
     4.8.  Meeting Drafts and Documents  . . . . . . . . . . . . . .  21
     4.9.  Meeting Record Keeping  . . . . . . . . . . . . . . . . .  21
   5.  Document Development & Lifecycle  . . . . . . . . . . . . . .  21
     5.1.  Basic Sequence  . . . . . . . . . . . . . . . . . . . . .  22
     5.2.  Early Document Review . . . . . . . . . . . . . . . . . .  23
     5.3.  Document Coordination Between Working Groups  . . . . . .  23
     5.4.  Working Group Last-Call . . . . . . . . . . . . . . . . .  24
     5.5.  Final External Review of Documents  . . . . . . . . . . .  24
   6.  Staff Roles . . . . . . . . . . . . . . . . . . . . . . . . .  25
     6.1.  Development . . . . . . . . . . . . . . . . . . . . . . .  26
     6.2.  Advice  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     6.3.  Process . . . . . . . . . . . . . . . . . . . . . . . . .  26
   7.  WG External Administration  . . . . . . . . . . . . . . . . .  27
     7.1.  Working group Formation . . . . . . . . . . . . . . . . .  27
     7.2.  Charter Content . . . . . . . . . . . . . . . . . . . . .  32



Crocker & Droms           Expires March 4, 2016                 [Page 2]


Internet-Draft         WG Guidelines & Procedures         September 2015


     7.3.  Submission & Publication of Documents . . . . . . . . . .  33
     7.4.  Working Group Termination . . . . . . . . . . . . . . . .  34
     7.5.  Contention and appeals  . . . . . . . . . . . . . . . . .  35
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  35
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     9.1.  References - Normative  . . . . . . . . . . . . . . . . .  35
     9.2.  References - Informative  . . . . . . . . . . . . . . . .  36
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  38
   Appendix B.  Sample Working Group Charters  . . . . . . . . . . .  38
     B.1.  DPRIVE  . . . . . . . . . . . . . . . . . . . . . . . . .  38
     B.2.  iptel . . . . . . . . . . . . . . . . . . . . . . . . . .  40
     B.3.  rtg . . . . . . . . . . . . . . . . . . . . . . . . . . .  41
     B.4.  another one . . . . . . . . . . . . . . . . . . . . . . .  45
   Appendix C.  [PROTO-WIKI] Working Group Advice  . . . . . . . . .  45
     C.1.  If you have a formal WG role... . . . . . . . . . . . . .  45
     C.2.  Advice for Chairs . . . . . . . . . . . . . . . . . . . .  45
     C.3.  Meetings  . . . . . . . . . . . . . . . . . . . . . . . .  46
     C.4.  Ongoing WG operation  . . . . . . . . . . . . . . . . . .  47
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  48

1.  Introduction

   The IETF ([RFC3995],[About]) is an open community of network
   designers, operators, vendors, users, and researchers concerned with
   the development and operation of Internet technical specifications.
   Activities of the IETF are primarily performed by committees known as
   Working Groups [WG].  For administrative purposes, they are organized
   into topical [Areas].  Working groups are formally chartered,
   typically with a narrow focus and lifetime bounded by the completion
   of a specific set of tasks.

   This document describes the formation, requirements, structure, and
   operation of IETF working groups.  This includes the formal
   relationships and duties of participants.

   At base, working groups are driven by:

   o  Goals

   o  Rules

   o  Tasks

   o  Participants

   That is, a collection of participants, who fill various roles, work
   toward some common goal(s), according to IETF requirements.  This
   document is principally organized according to these distinctions.



Crocker & Droms           Expires March 4, 2016                 [Page 3]


Internet-Draft         WG Guidelines & Procedures         September 2015


1.1.  Background

   This version is organized as an aid to (new) working group
   participants both as an introduction and as a later reference.

   o  It describes existing IETF rules and practices and does not
      describe or suggest any changes.

   Specifically this version of the document:

   o  Replaces general IETF tutorial material that it had with pointers
      to independent versions

   o  Incorporates work from a number of targeted efforts over the years

   o  Reorganizes content to aid direct use by working group
      participants

   o  Distinguishes between formal IETF requirements and processes,
      versus common practices chosen by working groups, where the latter
      are primarily discussed in a non-normative external IETF Wiki
      (Appendix C) that can be continually revised by the community.

   A useful introduction to the IETF is The Tao of IETF: A Novice's
   Guide to the Internet Engineering Task Force [Tao].  Familiarity with
   The Internet Standards Process [RFC2026] is essential for a complete
   understanding of the philosophy, procedures and guidelines described
   in this document.

1.2.  Terminology and References

   When used in this document the key words "MUST", "MUST NOT",
   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" are normative and are to be
   interpreted as described in [RFC2119].

   NOTE:    Summary text about other documents is solely advisory.
      Unless explicitly stated otherwise, it MUST NOT be taken as pre-
      empting the content of those documents.

   Throughout the document, there are portions prefaced with a (Task)
   label.  These call out specific actions that are required, suggested,
   or permitted.  Besides being meant to draw the eye to action items
   that are distinct from surrounding discussion text, these provide an
   approximate list of tasks that might be assigned to various roles in
   the working group, as discussed in Section 6.





Crocker & Droms           Expires March 4, 2016                 [Page 4]


Internet-Draft         WG Guidelines & Procedures         September 2015


1.3.  OPEN ISSUES



      NOTE TO RFC EDITOR:   Remove this section before publication.

   This list is an invitation for information, pointers, corrections,
   and additional/different text.  In some cases, resolution will
   require discussion and some version of IETF consensus.

   Roles/Titles:    What are the formal WG roles/titles that are a)
      documented, b) can be written into a charter, and c) can be
      assigned via the Datatracker?  E.g., Consultant vs. Tech Adviser.
      What are the formal permissions for "Delegated authority"?  What
      are options and what are choices within options?

   Doc Publication:    In terms of process, what is formally required
      vs. typical vs. wg choice.  Eg, a) required - wg last call? --
      maybe not required, but advisable to avoid an appeal; b) Formal:
      publication as wg item, when pushing doc out of wg to iesg/rfc
      editor.

   WG Ops vs. Tasks:   Macro vs micro -- Overall wg management, eg,
      meetings and task sequencing; vs. managing a task, eg, doc
      revisions, issue tracking, writer/wg relationship.

   Familiarity:    Besides RFC 2026, what other IETF docs are "required"
      for the reader to have familiarity with?

   Charter negotiation:    WHO NEGOTIATES A CHARTER??? Distinguish
      required vs. flexible.  Emphasize open and accountable.

   Citations:    What other RFCs, IESG Statements, etc. need to be
      cited?

   Mailing List Hosting:    (Secretariat queried) Are IETF working group
      mailing lists now required to be hosted at the IETF?

   Milestones:   make sure example charter in Appendix A includes
      milestones

   Suspension:    Email -- " 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."
      Is it the AD that does this?  Who really does?

   Docs on Agenda:    "Any document which does not meet this publication
      deadline can only be discussed in a working group session with the



Crocker & Droms           Expires March 4, 2016                 [Page 5]


Internet-Draft         WG Guidelines & Procedures         September 2015


      specific approval of the working group chair(s)."  Current
      operation is that /all/ items on an agenda are explicitly approved
      by the chair/wg??? -- distinguish "IETF" deadline from "WG-
      specific" requirement(s)."

   Wiki?    What should be moved to the Wiki or added to it?

   Normative?  Review references for normative/non-normative placement
      listing in doc.

   Reporting?    Resolve various IETF website pages concerning
      submission and archive of notes, etc?

   Milestone Revision:    Revised milestones MUST be approved by the
      cognizant Area Director.  Is any other review or approval needed,
      such as from the IESG?

2.  Basic Structure and Requirements

   The IETF permits wide variation in the conduct of working group
   affairs.  Still, there is a core of required organization and
   required operation.  This section describes that core.

2.1.  Working Group Charter

   A working group is based on a formal a charter, which is a contract
   between a working group and the IETF to perform a set of tasks.  A
   charter:

   o  Lists relevant administrative information for the working group

   o  Specifies the direction or objectives of the working group and
      describes the approach that will be taken to achieve the goals

   o  Enumerates a set of milestones together with time frames for their
      completion

   Details concerning charters are provided in Section 7.2.

2.2.  Deliverables

   A working group's charter specifies deliverables to be achieved.
   (Section 7.2) These are usually documents to be published in the
   Request for Comments series [RFC-Editor].  The means of achieving
   those deliverables is only lightly constrained: whatever permits a
   working group to conduct a fair, open and accountable process, while
   achieving working group rough consensus, is permitted.  The challenge
   with this flexibility is formulating the details of internal working



Crocker & Droms           Expires March 4, 2016                 [Page 6]


Internet-Draft         WG Guidelines & Procedures         September 2015


   group structure and process in a manner that ensures timely
   achievement.

   In other words, the group needs to efficiently balance fair and open
   discussion, proper attention to legitimate concerns, and making
   forward progress.

2.3.  Mailing List

   A process that is truly open and inclusive makes participation as
   easy as possible, for the widest range of participants as possible.
   For the IETF, that means that the primary venue for working group
   activities MUST be the mailing list associated with the group.
   (Section 7.2) Further, the mailing list MUST be the only venue for
   formally assessing working group rough consensus.

      "Decisions" made at venues other than the working group mailing
      list MUST be treated as preliminary, and MUST be explicitly
      documented and confirmed through the mailing list.

   (Task)    It is important to ensure that the discussions on this list
      are relevant and that they converge to consensus agreements.

   (Task)    It can help to summarize a discussion periodically.

   (Task)    It also can help later review to ensure that outcomes are
      well and explicitly 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).

   Mailing lists related to IETF activities are usually hosted at the
   IETF, but generally MAY be hosted elsewhere.

   (Task)    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:

                        {ACRONYM}-archive@ietf.org






Crocker & Droms           Expires March 4, 2016                 [Page 7]


Internet-Draft         WG Guidelines & Procedures         September 2015


   (where {ACRONYM} is the abbreviated name for the working group) in
   the mailing list, so that a copy of all mailing list messages is
   recorded in the Secretariat's archive for the list.

   Multiple versions of list archives are available, as indicated in the
   "Archives" section of [MailList].  One form is located at:

   http://www.ietf.org/mail-archive/web/{ACRONYM}/current/maillist.html

   where {ACRONYM} is the abbreviated name for the working group.  For
   robustness, WGs SHOULD maintain an additional archive separate from
   that maintained by the Secretariat.

2.4.  Area Directors

   IETF Working Groups are administratively aggregated into "areas".
   Each working group has a designated ("cognizant") Area Director [AD]
   ([AD-Desc],[Areas]), to formally select chairs for the working group
   and to provide oversight.

2.5.  Chair(s)

   Working Group Chairs are formally responsible for ensuring that the
   working group makes forward progress through a fair and open process.
   They have wide discretion in the conduct of WG business.  However
   within the bounds of IETF formal requirement, Chairs are always
   accountable to the rough consensus (Section 2.8) of the working group
   participants, as well as to the Area Director who appointed them.
   Chairs ensure that a number of procedural, administrative and project
   management tasks are performed, either directly or by others assigned
   to the tasks.

   Chairs have the authority and the responsibility to make decisions,
   on behalf of the working group, regarding all matters of internal
   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 choices for assignment of tasks are highly dependent upon the
   nature of the working group topic, the nature of the work to be done,
   and the nature of working group participation.  When a topic is well-
   understood, the deliverables straightforward and the participants
   generally knowledgeable and compatible, a very streamlined working
   group organization can be quite reasonable.  As topic and/or
   participation get more challenging, working group operation typically
   needs to be more actively and formally managed, typically requiring




Crocker & Droms           Expires March 4, 2016                 [Page 8]


Internet-Draft         WG Guidelines & Procedures         September 2015


   administrative tasks to be spread among other participants and
   processes for discussion and decision-making more structured.

2.6.  Document Writer

   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 designates one or more people to serve as the Writer for a
   particular document.  The Document Writer 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 Writer
   positions are filled by different individuals to help ensure a clear
   distinction between process management and content generation.  This
   helps the resulting documents to accurately reflect the consensus of
   the working group.  However this separation is not a firm
   requirement.  Especially in a small, narrow, simple effort among a
   cohesive group, it might be convenient and efficient for the Chair
   and Writer roles to be combined.

   The Document Writer is variously called an "author" or an "editor".
   The IETF does not have consistent rules for distinguishing use of
   these terms.  However, see Section 3 of [RFC7221] for a suggested
   distinction between primary responsibility for creating concepts and
   content, versus responsibility for recording content developed by the
   working group itself.

2.7.  Participants

   The foundation of a working group is its participants.  Within the
   scope of the charter, working group participants represent the entire
   Internet, indicating what output is needed from the working group
   effort -- including who will use it and why -- and providing
   guidance, ideas, text, discussion, and assessment.  For all
   substantive choices, the 'rough consensus' of the participants
   determines the real work of the group.

   NOTE:    WG participants MUST conform to the requirements for
      disclosure of conflicts of interest in [RFC2028].

2.8.  Rough Consensus Decision Making

   The IETF does not have "members" and it's open processes can not make
   decisions by "voting".  Rather, a community sense of strongly-
   dominant agreement, in the absence of compelling objections, is used
   to make decisions.  This is called Rough Consensus [RFC7282].  Within
   working group processes, this is the required means for making



Crocker & Droms           Expires March 4, 2016                 [Page 9]


Internet-Draft         WG Guidelines & Procedures         September 2015


   working group decisions, but more importantly it is a model for
   considering issues.

   Expediency:    In the abstract, nearly all working group activities
      and decisions are subject to Rough Consensus.  In practice,
      working group chairs often make decisions based on the assumption
      of working group support.  This practice is essential for working
      group efficiency, but its risk is that the chair's choices will
      not actually be in sync with the working group's desires.
      Consequently, all participants carry the responsibility of voicing
      concerns they consider significant, even when no other participant
      has spoken up.

   Substantiveness:    A major challenge in considering Rough Consensus
      appears to be distinguishing between active and passive support.
      Active support is indicated by participants that are actively
      engaged in discussing the topic, whereas passive has, at most, pro
      forma expressions of support, without any obvious indication that
      the topic is both understand and important to the participant.
      The dangers of passive support are that it could mean the topic is
      not adequately understood and/or that the topic will not obtain
      community followup, such as deployment and use.

   Minorities:    The other major challenge, as discussed in [RFC7282],
      is that "minority" concerns are not adequately addressed.  In
      particular in the interest of moving the working group effort
      along, it is easy to marginalize such concerns because they are
      expressed by few participants.  What this risks is failure to
      attend to problems that are serious and will affect utility of the
      work later.  There is, of course, a competing pressure that
      'minority' voices could stall the working group.  So the core
      working group challenge with a minority concern is to adequately
      consider its nature and adequately consider its effect, while
      still making forward progress.

3.  Documents

3.1.  Home Page

   Each working group has an associated web page, listing working group
   documents and pointing to a variety of related other pages.  The
   working group home page is located at:

            http://datatracker.ietf.org/wg/{ACRONYM}/documents/

   where {ACRONYM} is the abbreviated name for the working group.





Crocker & Droms           Expires March 4, 2016                [Page 10]


Internet-Draft         WG Guidelines & Procedures         September 2015


3.2.  Wiki

   Working groups can have access to an editable wiki, if requested by a
   Chair, for use as the working group sees fit.  It is located at:

             http://trac.tools.ietf.org/wg/{ACRONYM}/trac/wiki

   where {ACRONYM} is the abbreviated name for the working group.

3.3.  Issue-tracking Tickets

   (Task)    As topics, issues and suggestions increase for a working
      group, it can be helpful to document them in an issue tracking
      system.

   One can be provided through the working group wiki, if requested by a
   Chair, at the tab for "View Tickets":

            http://trac.tools.ietf.org/wg/{ACRONYM}/trac/report

   where {ACRONYM} is the abbreviated name for the working group.

3.4.  Meeting Materials

   Any organized working group session (meeting) will have planning and
   reporting material, including:

   o  Agenda

   o  Presentations

   o  Notes

   o  Transcripts (e.g., jabber logs)

   (Task)    The planning and presentation material needs to be made
      available in advance of the session.

   (Task)    They and the reporting materials also need to be preserved
      for later reference.

   Details about IETF Meeting Materials are provided in [MeetMaterials],
   [MeetMaterialTool].

   NOTE:    The IETF web site has related information that appears to be
      out of date, such as [AgendaNotes].





Crocker & Droms           Expires March 4, 2016                [Page 11]


Internet-Draft         WG Guidelines & Procedures         September 2015


3.5.  Internet-Drafts (I-D)

   Working group efforts are typically driven by specific documents.
   Some are used to fuel working group discussion while others are the
   deliverable product under development.  Documents are processed as
   Internet Drafts [I-D], which are strictly working documents and have
   no official standards status whatsoever.  They might, eventually,
   turn into a standards-track document or they might sink from sight.

   Formal adoption of Internet Drafts in a working group is discussed in
   [RFC7221].  Also, there are naming conventions, to identify Internet
   Drafts that have been adopted by a working group, as described in
   Section 7 of [I-D-Guidelines].

3.6.  Request For Comments (RFC)

   The work of an IETF working group typically targets publication of
   one or more documents, as part of the Request For Comments (RFC)
   series.  ([RFC-IETF], [RFC-Editor], [RFC2026]) This series is the
   archival publication record for the Internet community.  There are
   multiple, independent streams that produce documents published as
   RFCs; the IETF stream is one of these.  A document can be written by
   an individual in a working group, by a group as a whole with a
   designated Writer, or by others not involved with the IETF.  The RFC
   Editor provides guidance for writing an RFC.  [RFC7322]

   NOTE: The RFC series is a publication mechanism only and publication
   does not determine the IETF status of a document.  RFCs are processed
   through a number of independent 'streams', of which those produced
   with IETF approval represent one.  The IETF 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.  [RFC1796]

4.  Working Group Internal Operation

4.1.  Prime Directives

   The IETF has basic requirements for open and fair participation and
   for thorough consideration of technical alternatives.  Within those
   constraints, working groups are nearly autonomous and each determines
   most of the details of its own operation with respect to
   organization, planning, session participation, discussion style,
   means of reaching closure, etc.

   o  The core rule for operation is that acceptance or agreement is
      achieved via working group "rough consensus".  (Section 2.8)



Crocker & Droms           Expires March 4, 2016                [Page 12]


Internet-Draft         WG Guidelines & Procedures         September 2015


   A number of procedural questions and issues will arise over time.
   The Working Group Chair(s) have ultimate responsibility for
   management of 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.  Some basic choices are listed
   in (Section 6).  These are discussed at length in the associated
   wiki.  (Appendix C)

   (Task)    Actual choices for the details of working group operation
      are determined by the working group participants and the Chair(s).

   For some working groups, this can be accomplished by having the Chair
   perform all management-related activities.  In other working groups
   -- particularly those with large or divisive participation -- it is
   helpful to allocate process and/or secretarial functions to other
   participants.  Process management pertains strictly to the style of
   working group interaction and not to its content.  It ensures
   fairness and detects redundancy.  The secretarial function
   encompasses document editing.  It is quite common for a working group
   to assign the task of specification Writer to one or two
   participants.  Sometimes, they also are part of the design team,
   described below.  (Section 6)

   Of course, each WG will have participants who might 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 and the necessary representation of Internet community
   requirements.

4.2.  General Organizing

   Working groups sometimes develop and operate organically, needing
   very little assertive management by the Chairs.  Such groups are
   nearly self-regulating and that is entirely acceptable, but it also
   is rare.  When a working group has to do simple tasks, and the
   working group is cohesive and knowledgeable, there is little need for
   much formality in working group management.  Most working groups are
   not so fortunate.  For them, active management might be required, to
   determine such things as the sequence of work, the design teams for
   doing core work, issue-tracking, the approach for resolving issues,
   and even discussion facilitation.





Crocker & Droms           Expires March 4, 2016                [Page 13]


Internet-Draft         WG Guidelines & Procedures         September 2015


4.2.1.  Characterizing the Effort

   (Task)    It can help to evaluate the work to be done and the
      participation in the working group that will do it:

      *  Consider the community knowledge of the problem space

      *  Consider the plausible solution space, in terms of complexity
         and clarity

      *  Consider the composition of the working group, in terms of
         size, shared knowledge, interaction style, and focus on
         achieving productive results

4.2.2.  Plan of Work

   Working groups typically produce more than one document.  While there
   might appear to be a natural sequence for developing them, consider
   that some foundational documents that logically need to be done first
   might also need to be revised later, as the working group gains more
   experience with its topic(s).

   (Task)    Given a sequence of documents, what are the subordinate
      steps that will achieve necessary milestones?  It can help to
      chart this explicitly in the working group Wiki.  (Section 3.2)

4.2.3.  Tasks vs. Roles

   A working group requires significant administrative and management
   work.  What is flexible is who performs the work.  The choices for
   assigning one or more tasks to a participant filling a particular
   role will depend upon the assessment of the Chair(s).  For example,
   as the scale or complexity or contentiousness of a working group
   increases, so does its risk of failure and its attendant need for
   more active and more formal management.

   This typically means stricter adherence to formal rules of working
   group process and assignment of various tasks to a wider set of
   participants in specific roles, so that each task receiver proper
   focus.  Roles that are required or, at least, useful are discussed
   later, in (Section 6).

4.2.4.  Venues

   Although the working group mailing list is intended to be the primary
   venue for discussion and MUST be the ultimate venue for assessing
   working group rough consensus, scheduled meetings can also be




Crocker & Droms           Expires March 4, 2016                [Page 14]


Internet-Draft         WG Guidelines & Procedures         September 2015


   important.  (Some successful efforts have taken place only on mailing
   lists, with no interactive meetings, but these are rare.)

   Meetings can be face-to-face, such as during the thrice-annual IETF
   Plenary Meeting, or "virtual" via teleconference or chat session.
   Face-to-face meetings can (and often do) include provisions for
   virtual participation to accommodate participants who cannot attend
   in person.  See: Section 4.6, Section 4.7, Section 4.6.4.

4.3.  Discussion and Progress

   The challenge to managing working group discussion 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.

   (Task)    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:

   (Task)    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:

   (Task)    Note important decisions/consensus reached by email in the
      notes of the next 'live' session, and to summarize briefly the
      decision-making history in the final documents the WG produces.

   (Task)    To facilitate making forward progress, a working group MAY
      decide to reject or defer the input from a participant, 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;




Crocker & Droms           Expires March 4, 2016                [Page 15]


Internet-Draft         WG Guidelines & Procedures         September 2015


         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.

4.4.  IETF Open Decision-Making

   The IETF values and demands open, inclusive decision-making by
   working groups.  A process that is truly open and inclusive makes
   participation as easy as possible, for the widest range of
   participants as possible.

      For the IETF, that means that the official venue for working group
      formal decision-making MUST be the mailing list associated with
      the group AND NOWHERE ELSE.

   Working groups make decisions through a "rough consensus" process
   (Section 2.8), which entails considerably more than merely
   determining that a majority are for or against a particular choice.
   IETF rough consensus does not require that all participants agree
   although this is, of course, preferred.  In general, the dominant
   view of the working group needs to prevail, absent compelling
   arguments against.  In particular note the role of "minority" views,
   as discussed in [RFC7282].

   It can be especially challenging to gauge the level of consensus on a
   mailing list.  There are two different cases where a working group
   might 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 might be generating much of the traffic.

   (Task)    Enough time MUST be given to the verification process for
      the mailing list readers to understand and consider any objections
      that might be raised on the list.  The normal two week last-call
      period SHOULD be sufficient for this.

4.5.  Mailing List Primacy

   Discussions relating to working group topics MAY happen anywhere,
   amongst any group of people, on a spontaneous or continuing basis and
   as a closed or open set.  Closed groups that persist with a
   continuing role in providing substantive input to the working group's
   content are called 'design teams'.  They can be self-forming or
   created by the Chair(s).

   The working group, itself, can provide a variety of open discussion
   venues, over the life of the working group, as discussed below.
   However discussions are conducted, "decisions" made at venues other



Crocker & Droms           Expires March 4, 2016                [Page 16]


Internet-Draft         WG Guidelines & Procedures         September 2015


   than the working group mailing list MUST be treated as preliminary,
   and MUST be explicitly documented and confirmed through the mailing
   list.

   An example method is to post a note summarizing:

   o  the discussion

   o  the proposed resolution

   o  the rationale for proposing its adoption

   This provides working group participants with enough foundational
   material to understand the proposal and comment on it or even support
   it.  It also creates a record on the official email archive.

   If discussion is held entirely over the mailing list, determination
   of the level of consensus might be harder to do, since most people
   subscribed to mailing lists do not actively participate in
   discussions.  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 they believe to be the
   consensus view and at the same time, request comments from the list
   about the stated conclusion.

4.6.  Discussion Venues

   Each working group will determine the balance of email versus
   interactive (face-to-face, online, ...) sessions that is appropriate
   for achieving its milestones.  Electronic mail permits the widest
   participation; interactive, real-time meetings often permit better
   focus and therefore can be more efficient for reaching a consensus
   among a core of the working group participants.  In determining the
   balance, the WG MUST ensure that its process does not serve to
   exclude contribution by email-only participants.

   (Task)    Remember that consensus reached during an interactive MUST
      be reviewed on the mailing list.

4.6.1.  Tradeoffs

   Each working group will determine the balance of email versus
   interactive (face-to-face, online, ...) sessions that is appropriate
   for achieving its milestones.  The choices are affected by various
   factors, including the working group's milestone schedule -- that is,
   degree of urgency -- complexity of the work, number of active
   discussants, and the schedule and support of those discussants.




Crocker & Droms           Expires March 4, 2016                [Page 17]


Internet-Draft         WG Guidelines & Procedures         September 2015


   However there tends to be a significant tradeoff between doing work
   at interactive sessions, versus working group inclusiveness.

   Interactive sessions demand that a participant's schedule permit
   availability during the sessions.  Even when held online, this can be
   a significant burden for some participants.  Even if their formal
   schedule is sufficiently flexible, the fact of different participant
   timezones tends to work to the disadvantage of some participants.

   If the meetings are face-to-face, the schedule and monetary demands
   are dramatically higher and, obviously, further restrict
   participation.

   A mailing list venue permits the widest and most-convenient
   participation, by allowing for time-shifted debate among participants
   in multiple time zones.  Its asynchrony also permits the most
   thoughtful presentation of views and the most thoughtful
   consideration of them.

   Interactive, real-time meetings often provide richer and higher speed
   communication with lower latency and therefore permit better focus.
   They therefore can be more efficient for reaching a consensus among a
   core of the working group participants, especially for narrow and
   contested choices.

   Any tools that permit real-time, or time-shifted, interaction and
   information exchange could be used, without affecting the basic
   principle that decisions are exposed and confirmed on the mailing
   list -- Facebook, Twitter, github, issue tracker, etc.  Note that
   these do not provide a formal, IETF archive of the activity, although
   their record can be useful to cite.

      The mode of interaction can (and probably ought) be different in
      different situations.  Regardless, the choice of operational style
      MUST be made through rough consensus of all working group mailing
      list participants.  In determining the balance, the working group
      MUST ensure that its process does not serve to exclude substantive
      contribution by email-only participants.

   A basic principle is that although face-to-face discussion, either
   during a plenary week or at an interim meeting, might sometimes be
   considered essential to make rapid progress or to resolve tricky
   issues, this MUST NOT be discriminatory against those unable to
   attend.  As far as technically and financially possible, facilities
   for passive and active remote participation SHOULD be provided.

   Similarly, "virtual" interim meetings in which all participants are
   remote MUST NOT be discriminatory against those unable to attend.



Crocker & Droms           Expires March 4, 2016                [Page 18]


Internet-Draft         WG Guidelines & Procedures         September 2015


      The choice of operational style MUST be made by the working group
      itself.

      Again: consensus reached during an interactive session is purely
      preliminary.  The proposed decision and its basis MUST be reviewed
      on the mailing list, and rough consensus developed and documented
      there.

4.6.2.  Mailing List Discussion Management

   It can be quite useful to conduct email exchanges in the same manner
   as an interactive session, with published schedule and agenda, as
   well as on-going summarization and consensus polling, even though
   message-posting and responding continues to be asynchronous amongst
   participants.

   WG chairs should guide WG email debate when necessary, for example by
   encouraging participants to stay on topic, remain polite, avoid
   repetition, etc.  It is helpful to encourage distinct threads with
   meaningful subject headers for distinct topics.

   As with face-to-face sessions occasionally a participant might engage
   in behavior on a mailing list which disrupts the WG's progress.

   (Task)    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.

   (Task)    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.

4.6.3.  IETF Plenary 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.



Crocker & Droms           Expires March 4, 2016                [Page 19]


Internet-Draft         WG Guidelines & Procedures         September 2015


   (Task)    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.

      (Task)    Requirements and procedures for obtaining a session slot
         at an IETF Meeting are specified in [MeetRequest].

   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.

   (Task)    The Working Group Chair has the authority to refuse to
      grant the floor to any individual who is unprepared, is 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.

4.6.4.  Interim Meetings

   In addition to mailing list discussion and meeting at the thrice-
   yearly IETF Meetings, a working group might decide that it should
   hold an additional, real-time "interim" meeting.  This might be
   through a real-time chat session, group telephone call, online
   teleconference, or physical, face-to-face meeting.

   Guidance for the conduct of such sessions is provided by [Interim],
   with useful tutorial material at [Interim-Train].  Also see:
   Section 4.7.

4.7.  Session Planning

   Administrative and process details for the conduct of structured
   meetings are referenced at [IETF-Meetings] and in [Interim]

   (Task)    Sessions MUST be planned, organized and announced well in
      advance.

   (Task)    For coordinated, structured WG interactions, a draft agenda
      SHOULD be published well in advance of the actual session.

   Details about Meeting Materials are provided in [MeetMaterials],
   [MeetMaterialTool].




Crocker & Droms           Expires March 4, 2016                [Page 20]


Internet-Draft         WG Guidelines & Procedures         September 2015


4.8.  Meeting Drafts and Documents

   NOTE:    The requirements here apply to all IETF working group
      meetings, independent of venue or mode.  That is, all official
      sessions during an IETF Week and all interims.

   (Task)    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, so that working group participants have
      adequate time to review all documents.

4.9.  Meeting Record Keeping

   NOTE:    The requirements here apply to all IETF working group
      meetings, independent of venue or mode.  That is, all official
      sessions during an IETF Week and all interims.

   The task(s) of creating records about meeting activity are discussed
   in [AgendaNotes], above.

   (Task)    An attendance list MUST be circulated

   (Task)    Notes of a session MUST be taken; they SHOULD include the
      agenda for the session, an account of the discussion including any
      decisions made, and a list of attendees

   (Task)    Immediately after a session, the WG Chair SHOULD provide
      the Area Director with a very short report (approximately one
      paragraph, via email) on the session.

5.  Document Development & Lifecycle

   Working groups produce documents and documents need Writers.

   (Task)    The Chair MUST make sure that Document Writers incorporate
      changes as agreed to by the WG.

   It is quite easy for active and productive writers to move into a
   dominant position, either making changes faster than the working
   group can absorb, or becoming adversarial with working group
   preferences.  An especially conducive environment for this problem
   combines original (pre-working group) authors with a more passive
   working group.  However a working group that does not fully and
   actively support a specification, the greater the risk that it will
   not achieve deployment and use.






Crocker & Droms           Expires March 4, 2016                [Page 21]


Internet-Draft         WG Guidelines & Procedures         September 2015


5.1.  Basic Sequence

   Working group development of a document proceeds through these steps:

   1.   An individual or a group has something for the WG to discuss and
        publishes a document on the topic as an individual I-D

   2.   WG adopts the document as a WG work item, per section 2 of
        [RFC7221]

   3.   WG develops the document, per [RFC7221]

   4.   When the WG is done with development, the chairs organize a WG
        last call to determine consensus for sending the I-D to the IESG
        for review and publication

   5.   Chairs assign a document shepherd who prepares the cover sheet
        and assumes responsibility for managing the review and
        publication process

   6.   The Working Group, through the chairs or the shepherd, make a
        recommendation to the to the Area Director that a standards
        action be approved regarding the document [RFC 2026]

   7.   Area Director reviews the document to determine if the standards
        action should proceed; this review may include an external
        review, per [RFC2026]

   8.   Area Director formally requests an IETF Last Call to determine
        IETF consensus about whether the I-D is ready for publication,
        per [RFC2026]

   9.   Once the IETF Last Call is complete, the AD, the document
        shepherd, the editors and the WG agree on any changes to the I-D
        based on the Last Call comments

   10.  The AD schedules the I-D for discussion during an IESG telechat

   11.  Prior to the telechat, IESG members post a ballot position on
        the I-D

   12.  After the telechat, the I-D may require additional revision; the
        IESG, the document shepherd, the editors and the WG agree on any
        changes to the I-D based on the IESG ballot positions and
        telechat discussion






Crocker & Droms           Expires March 4, 2016                [Page 22]


Internet-Draft         WG Guidelines & Procedures         September 2015


   13.  Once the I-D meets the IESG ballot requirements for publication,
        the IETF is notified of any associated standards action and the
        document is forwarded to the RFC Editor

5.2.  Early Document Review

   It is easier to make substantial changes to a specification during
   its early stages than it is later on.  Periodically, the IETF's
   various late-stage reviews uncover basic concerns with assumptions or
   approaches in a design.  When a working group is pursuing a solution
   that has unusual design choices or unusual operational
   characteristics, or has any other feature that might impede its
   success, or when the working group participants have less experience
   in producing specifications for Internet-scale use, it is advisable
   to recruit review and advice from a broad base of experts.

5.3.  Document Coordination Between Working Groups

   A document is adopted by one working group as a deliverable; they are
   therefore responsible for its development, review and publication.
   (Section 3.5) When initiated outside a working group environment, the
   writer(s) usually have a specific -- possibly new -- working group in
   mind as the development home.  However some documents address
   problems or contain technologies that span multiple Areas or working
   groups.  In such cases, the document is assigned to one of these,
   with other interested groups participating in the development
   process.  This joint participation can take many forms.  One example
   is a joint Working Group Last Call conducted by the host group but
   announced on the mailing lists for the other interested groups.

   As an example, documents that extend DHCP to carry configuration
   information for other protocols often span multiple working groups.
   Some of these documents define a simple DHCP option that follows one
   of the option formats in section 5 of [RFC7227].  Such options can be
   developed in the working group responsible for the protocol that will
   use the option, without significant participation of the dhc working
   group.  A joint last call between the two groups might be all that is
   required.  However some documents will define options that have a
   significantly new option format, or define a new DHCP message or
   otherwise make a fundamental change to the semantics of DHCP message
   exchanges.  These options or new messages will be developed in the
   dhc working group, with input from other interested groups, to ensure
   that there are no conflicts or other issues with the documents that
   would cause problems with the DHCP standards.







Crocker & Droms           Expires March 4, 2016                [Page 23]


Internet-Draft         WG Guidelines & Procedures         September 2015


5.4.  Working Group Last-Call

   When a WG decides that a document is ready for publication it is
   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
   an IESG Last-Call does in the broader IETF community.  ([RFC2026])

5.5.  Final External 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.  ([RFC2026]) 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:

   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 [RFC2026] for more
       details.)

   3.  Changes regarding content are suggested to the Writer(s)/WG.
       Suggestions from the IESG need to be clear and direct, so as to
       facilitate working group and Writer correction of the
       specification.  If the Writer(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,




Crocker & Droms           Expires March 4, 2016                [Page 24]


Internet-Draft         WG Guidelines & Procedures         September 2015


       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 [RFC2026].

6.  Staff Roles

   From initial chartering, through document development and
   publication, ending with working group termination, there are tasks
   that are formally required to be done, while others are merely --
   though often very -- helpful to do.  This document discusses the
   formal tasks and many of the other, useful tasks.

   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.

   Beyond a limited set of formal tasks, there are no rules about who
   MAY be assigned tasks internal to the working group.  This section
   discusses possible mappings between working group tasks and working
   group participants who might be assigned roles for performing those
   tasks.  However it is important to remember that such mappings are
   strictly at the discretion of the chairs, assuming working group
   agreement.

   [RFC2028] describes the roles of a number of individuals related to
   external aspects of working groups, as well including the working
   group chair and the document Writer.  These descriptions are expanded
   later in this section.







Crocker & Droms           Expires March 4, 2016                [Page 25]


Internet-Draft         WG Guidelines & Procedures         September 2015


6.1.  Development

   Document Writer:   This role is discussed in Section 2.6.

   Design Team:    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.
      Operationally, a design team typically is advisory to the Document
      Writer(s), specifically, or the working group discussion,
      generally.  Design teams can range from an informal chat between
      people in a hallway to a formal set of expert volunteers that the
      WG chair appoints to attack a controversial problem.  The output
      of a design team always MUST be subject to approval, rejection or
      modification by the WG as a whole.

   Participant:   Discuss issues.  Suggest ideas and text.  Review
      documents.  Actively pursue resolution of topics.

6.2.  Advice

   Adviser (WG Consultant):    At the discretion of the Area Director or
      Chair, an Adviser MAY be assigned to a working group.  Consultants
      have specific technical background appropriate to the WG and
      experience in Internet architecture and IETF process.  An
      adviser's role is strictly advisory rather than authoritative.
      However of course their concerns are likely to gain the attention
      of reviewers, the Area Director and the IESG.

6.3.  Process

   Area Director:    This role is discussed in Section 2.4.

   Working Group Chair:    This role is discussed in Section 2.5.

   WG Facilitator:    When meetings tend to become distracted or
      divisive, it often is helpful to assign the task of "process
      management" to one participant.  [Facilitate] 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.

   WG Secretary:    Taking notes, producing discussion summaries, and
      maintaining a list of working group action items are tasks often
      is performed by one or more designated participants.




Crocker & Droms           Expires March 4, 2016                [Page 26]


Internet-Draft         WG Guidelines & Procedures         September 2015


   Scribe:    A Scribe is tasked with note-taking during a meeting.
      This might be for real-time use during the session, such as
      providing quick summaries of on-going discussion via an instant-
      messaging channel, to assist remote participants.  Or it might be
      basic meeting notes; these are typically summarizations of
      discussions, rather than detailed 'minutes'.  [I-D-Jscribe]

7.  WG External Administration

7.1.  Working group Formation

   IETF working groups (WGs) are the primary means of developing IETF
   specifications and guidelines, many of which are intended to be
   standards or recommendations.  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.

   A working group is typically created by a community initiative, but
   can also be established at the initiative of an Area Director.
   Anyone interested in creating an IETF working group MUST obtain the
   advice and consent of IETF Area Director(s) and MUST proceed through
   the formal steps detailed in this section.

7.1.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:

   Issues:    Are the issues that the working group plans to address
      clear and relevant to the Internet community?

   Goals:    Are the goals specific and reasonably achievable, and
      achievable within a reasonable time frame?

   Risks/Urgency:    What are the risks and urgency of the work, to
      determine the level of effort required?

   WG Overlap:    Do the working group's activities overlap with those
      of another working group?  If so, it can still be appropriate to
      create the working group, but this question needs to be considered
      carefully by the Area Directors as subdividing efforts often
      dilutes the available technical expertise.

   Interest:    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,



Crocker & Droms           Expires March 4, 2016                [Page 27]


Internet-Draft         WG Guidelines & Procedures         September 2015


      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 needs to be broad enough that a working group
      would not be seen as merely the activity of a single vendor.

   Expertise:    Is there enough expertise within the IETF in the
      working group's topic, and are those people interested in
      contributing in the working group?

   Market:    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.

   IETF Relevance:    Does the IETF have a reasonable role to play in
      the determination of the technology?  There are many Internet-
      related technologies that might be interesting to IETF
      participants but in some cases the IETF might 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.

   IPR:    Are all known intellectual property rights relevant to the
      proposed working group's efforts issues understood?

   Real IETF Work:    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 might be limited?

   Existing Work:    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.

   SDO Overlap:    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) will use their
   best judgment to decide whether to pursue formation of the group
   through the chartering process.







Crocker & Droms           Expires March 4, 2016                [Page 28]


Internet-Draft         WG Guidelines & Procedures         September 2015


7.1.2.  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
   ([RFC5434]) as well as the early formation of an email list for
   preliminary discussion.  In addition, a BOF can 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, and their approval MUST be obtained before a
   BOF 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,

   o  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.

   o  The Area Director MAY require that there be a draft of the WG
      charter prior to holding a BOF.

   o  The Area Director MAY require that a BOF not be held until an
      Internet-Draft describing the proposed technology has been issued
      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 limited to a maximum of two meetings.  Note that all
   other things being equal, WGs will be given priority for meeting
   space over BOFs.  Also, occasionally BOFs might 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:



Crocker & Droms           Expires March 4, 2016                [Page 29]


Internet-Draft         WG Guidelines & Procedures         September 2015


   o  There was enough interest and focus in the subject to warrant the
      formation of a WG

   o  While there was a reasonable level of interest expressed in the
      BOF some other criteria for working group formation was not met,
      per Section 7.1.1

   o  The discussion came to a fruitful conclusion, with results to be
      written down and published, however there is no need to establish
      a WG

   o  There was not enough interest in the subject to warrant the
      formation of a WG

7.1.3.  Charter Development

   The formation of a working group requires a charter.  Development of
   a charter results from the efforts of interested parties and an Area
   Director.  The substance of IETF working group charters is specified
   in Section 7.2.  The development of the proposed charter is overseen
   by a shepherding Area Director and can be pursued in a number of
   ways.

   The method of developing a charter can vary greatly.  In many
   instances, the development of the charter is carried out on an open
   mailing list, allowing all interested IETF participants to contribute
   to the effort.  Among other possibilities, charter development might
   driven by a small group of active proponents.  All charter
   development models allow for interested participants to take
   ownership in the purpose and outcome of the working group.

   It is common, but not required, to hold an exploratory Birds of a
   Feather (BOF) meeting to gauge the level of support for a working
   group.([RFC5434],Section 7.1.2) Such a BOF can focus on formulating
   the problem to be solved, considering the key items in a proposed
   charter, discussing proposed solutions, or some combination of these
   items.

   When the prospective Chair(s), the Area Director and the IETF
   Secretariat are satisfied with the charter form and content, it
   becomes the foundation of the working group approval process and for
   the substantive conduct of the working group.

7.1.4.  Charter review & approval

   Proposed working groups often include technically competent
   participants who are not familiar with the history of Internet




Crocker & Droms           Expires March 4, 2016                [Page 30]


Internet-Draft         WG Guidelines & Procedures         September 2015


   architecture or IETF processes.  This can, unfortunately, lead to
   good working group consensus about a bad design.

   (Task)    To facilitate working group efforts, an Area Director MAY
      assign a Adviser from among the ranks of IETF participants.
      (Section 6)

   At the discretion of the Area Director, approval of a new WG MAY be
   withheld in the absence of sufficient Adviser resources.

   For review of a draft charter, the sponsoring Area Director might
   consult with their Area Directorate, or others, as deemed
   appropriate.  Once an Area Director supports a version of the working
   group charter, the approval sequence then is:

   1.  In parallel:

       *  The charter is submitted for review by the IAB

       *  It is also submitted for approval by the IESG.

   2.  After a review period of at least a week, in parallel:

       *  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.

       *  the proposed charter is also posted to the "new-work" mailing
          list.  This mailing list has been created to let qualified
          representatives from other standards organizations know about
          pending IETF working groups.

   3.  After another review period lasting at least a week the IESG MAY
       approve the charter as-is, or 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.

7.1.5.  Milestones Revision

   The milestone list is expected to be updated periodically.  Updated
   milestones are (re-)negotiated with the Area Director, as needed, and
   then are submitted to the IESG Secretariat:




Crocker & Droms           Expires March 4, 2016                [Page 31]


Internet-Draft         WG Guidelines & Procedures         September 2015


                          iesg-secretary@ietf.org

7.1.6.  Rechartering a Working Group

   Charters MAY be renegotiated periodically to reflect the current
   status, organization or goals of the working group.

   Rechartering a working group follows the same procedures that the
   initial chartering does Section 7.1.

7.2.  Charter Content

   Charter development and approval, rechartering, and milestone
   revision are discussed in Section 7.1.

   Examples working group charters are shown in Appendix B

   A charter consists of the following sections:

   Working group name:    A working group name ought to be reasonably
      descriptive or identifiable.  Additionally, the group needs to
      define an acronym (maximum 8 printable ASCII characters) to
      reference the group in the IETF directories, mailing lists, and
      general documents.

   Chair(s):    The working group can have one or more Chairs to perform
      the administrative functions of the group.  The email address(es)
      of the Chair(s) are included.  Generally, a working group is
      limited to two chairs.

   (Optional) Other Staff:  Optional positions, such as secretary and
      technical adviser.

   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.  The working group charter MUST include:

      *  The address to which a participant sends a subscription request
         and the procedures to follow when subscribing,

      *  The address to which a participant sends submissions and
         special procedures, if any, and



Crocker & Droms           Expires March 4, 2016                [Page 32]


Internet-Draft         WG Guidelines & Procedures         September 2015


      *  The location of the mailing list archive.

      For basic IETF requirements concerning mailing list configuration
      and use.  (Section 2.3)

   Description of working group:    The focus and intent of the group is
      set forth briefly.  By reading this section alone, an individual
      should be able to decide whether this group is relevant to their
      own work.

      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 MUST 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.

7.3.  Submission & Publication of Documents

   Once a WG has determined that rough consensus exists within the WG
   for the advancement of a document, the following MUST be done:






Crocker & Droms           Expires March 4, 2016                [Page 33]


Internet-Draft         WG Guidelines & Procedures         September 2015


   (Task)    The version of the relevant document exactly as agreed to
      by the WG MUST be in the Internet-Drafts directory, formatted
      according to Section 3.6

   (Task)    The WG Chair MUST initiate a publication request through
      the Datatracker entry for the document

   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
   Writer.

   The Chair and/or Document Editor will work with the RFC Editor to
   ensure document conformance with RFC publication requirements
   [RFC2223] 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.

7.4.  Working Group Termination

   Working groups are typically chartered to accomplish a specific task
   or tasks.  Upon completion of its goals and achievement of its
   objectives, the working group is usually terminated.  (A working
   group MAY also be terminated for other reasons, as discussed in
   Section 7.4.>

   If there is sufficient community interest the working group will
   formally become dormant rather than be disbanded -- the WG will no
   longer conduct formal activities -- so that the mailing list will
   remain available to review activities related to the working group's
   topic, including use and issues with documents it has produced.

   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:

   o  Recharter to refocus its tasks (See Section 7.1.6)

   o  Choose new Chair(s)




Crocker & Droms           Expires March 4, 2016                [Page 34]


Internet-Draft         WG Guidelines & Procedures         September 2015


   o  Disband

   If the working group disagrees with the Area Director's choice, it
   MAY appeal to the IESG.  Section 7.5

7.5.  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, resolution of
   such conflicts MUST be pursued through 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 [RFC2026].

8.  Security Considerations

9.  References

9.1.  References - Normative

   [AgendaNotes]
              "Formatting and Content of IETF Working Group Agendas and
              Minutes",
              <http://www.ietf.org/wg/agenda-minutes-procedures.html>.

   [IETF-Meetings]
              "IETF Meetings", <http://www.ietf.org/meeting/>.

   [Interim]  "Interim Meetings",
              <http://www.ietf.org/meeting/interim-meetings.html>.

   [MeetMaterials]
              "Meeting Materials",
              <http://www.ietf.org/wg/meeting-materials.html>.

   [MeetMaterialTool]
              "The IETF Meeting Materials Management Tool",
              <http://www.ietf.org/old/2009/instructions/
              meeting_materials_tool.html>.







Crocker & Droms           Expires March 4, 2016                [Page 35]


Internet-Draft         WG Guidelines & Procedures         September 2015


   [MeetRequest]
              "Requesting Meeting Sessions at IETF Meetings",
              <http://www.ietf.org/old/2009/instructions/
              MTG-SLOTS.html>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC3995]  Herriot, R. and T. Hastings, "Internet Printing Protocol
              (IPP): Event Notifications and Subscriptions", RFC 3995,
              March 2005.

9.2.  References - Informative

   [About]    "About the IETF", <http://www.ietf.org/about/>.

   [AD-Desc]  "Area Director Qualifications",
              <http://trac.tools.ietf.org/group/iesg/trac/wiki/
              AreasDescription>.

   [Areas]    "Areas", <https://www.ietf.org/iesg/area.html>.

   [ChairGuide]
              "WG Chairs' Guide,
              http://wiki.tools.ietf.org/group/wgchairs/",
              <http://wiki.tools.ietf.org/group/wgchairs/>.

   [Facilitate]
              "Facilitation", <http://en.wikipedia.org/wiki/
              Facilitation_%28business%29>.

   [I-D]      "Internet-Drafts (I-Ds)", <https://www.ietf.org/id-info/>.

   [I-D-Guidelines]
              Russ, R., "Guidelines to Authors of Internet-Drafts",
              December 2010, <https://www.ietf.org/id-info/
              guidelines.html>.

   [I-D-Jscribe]
              "The Jabber Scribe Role at IETF Meetings", I-D draft-
              saintandre-jabber-scribe.

   [Interim-Train]
              Atlas, A., Schliesser, B., and S. Turner, "Routing Area
              Chair Training: Interim Meetings", January 2015,
              <https://tools.ietf.org/area/rtg/trac/raw-
              attachment/wiki/WGChairTraining/rtgwg_train_4.pdf>.




Crocker & Droms           Expires March 4, 2016                [Page 36]


Internet-Draft         WG Guidelines & Procedures         September 2015


   [MailList]
              "Email Lists", <http://www.ietf.org/list/>.

   [RFC-Editor]
              "RFC Editor", <http://www.rfc-editor.org/>.

   [RFC-IETF]
              "Request for Comments (RFC)",
              <http://www.ietf.org/rfc.html>.

   [RFC1603]  Huizer, E. and D. Crocker, "IETF Working Group Guidelines
              and Procedures", RFC 1603, March 1994.

   [RFC1796]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
              Standards", RFC 1796, April 1995.

   [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
              the IETF Standards Process", BCP 11, RFC 2028, October
              1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
              RFC 2223, October 1997.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

   [RFC5434]  Narten, T., "Considerations for Having a Successful Birds-
              of-a-Feather (BOF) Session", RFC 5434, February 2009.

   [RFC7221]  Farrel, A. and D. Crocker, "Handling of Internet-Drafts by
              IETF Working Groups", RFC 7221, April 2014.

   [RFC7227]  Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
              S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
              BCP 187, RFC 7227, May 2014.

   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",
              RFC 7282, June 2014.

   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
              September 2014.







Crocker & Droms           Expires March 4, 2016                [Page 37]


Internet-Draft         WG Guidelines & Procedures         September 2015


   [Secretaries]
              Vigoureux, M. and D. King, "IETF Working Groups'
              Secretaries", I-D draft-secretaries-good-practices,
              November 2014.

   [Tao]      "The Tao of IETF: A Novice's Guide to the Internet
              Engineering Task Force", <http://www.ietf.org/tao.html>.

   [WG]       "Working Groups", <http://www.ietf.org/wg/>.

Appendix A.  Acknowledgements

   The original version of this document was developed by Erik Huizer
   and Dave Crocker.  ([RFC1603]) A revised version was edited by Scott
   Bradner and reviewed by the Poisson Working Group.  ([RFC2418]) The
   current version was prompted by [Secretaries] and the vigorous IETF
   discussion that ensued.  In their typical fashion, the IETF
   Secretariat staff were extremely helpful in clarifying current IETF
   administrative practices and rules.

   Development of the initial version of this document's revision
   benefited greatly from thoughtful and diligent comments by: Fred
   Baker, Brian Carpenter, Brian Haberman, Melinda Shore.

Appendix B.  Sample Working Group Charters

   NOTE:    Can we get a better example?  This example does not
      completely conform to wg charter requirements, especially for the
      first paragraph of the description. /d

B.1.  DPRIVE

DNS PRIVate Exchange (dprive)

Group Name:  DNS PRIVate Exchange
Acronym:  dprive
Area:  Internet Area (int)
Charter:   charter-ietf-dprive-01 (Approved)
Personnel
Chairs:   Tim Wicinski <tjw.ietf@gmail.com>
         Warren Kumari <warren@kumari.net>
Area Director:   Brian Haberman <brian@innovationslab.net>
Mailing List Address:  dns-privacy@ietf.org
To Subscribe:  https://www.ietf.org/mailman/listinfo/dns-privacy
Archive:  http://www.ietf.org/mail-archive/web/dns-privacy/
Jabber Chat Room Address:   xmpp:dprive@jabber.ietf.org
Logs:   http://jabber.ietf.org/logs/dprive/




Crocker & Droms           Expires March 4, 2016                [Page 38]


Internet-Draft         WG Guidelines & Procedures         September 2015


Charter for Working Group

The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
provide confidentiality to DNS transactions, to address concerns
surrounding pervasive monitoring (RFC 7258).

The set of DNS requests that an individual makes can provide an
attacker with a large amount of information about that individual.
DPRIVE aims to deprive the attacker of this information. (The IETF
defines pervasive monitoring as an attack [RFC7258])

The primary focus of this Working Group is to develop mechanisms that
provide confidentiality between DNS Clients and Iterative Resolvers,
but it may also later consider mechanisms that provide confidentiality
between Iterative Resolvers and Authoritative Servers, or provide
end-to-end confidentiality of DNS transactions. Some of the results of
this working group may be experimental. The Working Group will also
develop an evaluation document to provide methods for measuring the
performance against pervasive monitoring; and how well the goal is met.
The Working Group will also develop a document providing example
assessments for common use cases.

DPRIVE is chartered to work on mechanisms that add confidentiality to
the DNS. While it may be tempting to solve other DNS issues while
adding confidentiality, DPRIVE is not the working group to do this.
DPRIVE will not work on any integrity-only mechanisms.

Examples of the sorts of risks that DPRIVE will address can be found
in [draft-bortzmeyer-dnsop-dns-privacy], and include both passive
wiretapping and more active attacks, such as MITM attacks. DPRIVE will
address risks to end-users' privacy (for example, which websites an
end user is accessing).

Some of the main design goals (in no particular order) are:

- Provide confidentiality to DNS transactions (for the querier).

- Maintain backwards compatibility with legacy DNS implementations.

- Require minimal application-level changes.

- Require minimal additional configuration or effort from applications or users

Milestones
Dec 2014
WG LC on an problem statement document
draft-bortzmeyer-dnsop-dns-privacy
Mar 2015



Crocker & Droms           Expires March 4, 2016                [Page 39]


Internet-Draft         WG Guidelines & Procedures         September 2015


WG selects one or more primary protocol directions
Jul 2015
WG LC on primary protocol directions

B.2.  iptel

  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



Crocker & Droms           Expires March 4, 2016                [Page 40]


Internet-Draft         WG Guidelines & Procedures         September 2015


   of advanced personal mobility and call agent services.
   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

B.3.  rtg

Working Group Name:   Routing Over Low power and Lossy networks
Acronym:  roll
Area:  Routing Area (rtg)
Charter:   charter-ietf-roll-03 (Approved)
Personnel
Chairs:   Ines Robles <maria.ines.robles@ericsson.com>
         Michael Richardson <mcr+ietf@sandelman.ca>



Crocker & Droms           Expires March 4, 2016                [Page 41]


Internet-Draft         WG Guidelines & Procedures         September 2015


Area Director:   Adrian Farrel <adrian@olddog.co.uk>
Tech Advisor:   Rene Struik <rstruik.ext@gmail.com>
Delegates:   Robert Cragie <robert.cragie@gridmerge.com>
Yvonne-Anne Pignolet <yvonneanne.pignolet@gmail.com>
Mailing List Address:  roll@ietf.org
To Subscribe:  http://www.ietf.org/mailman/listinfo/roll
Archive:  http://www.ietf.org/mail-archive/web/roll/
Jabber Chat Room Address:   xmpp:roll@jabber.ietf.org
Logs:   http://jabber.ietf.org/logs/roll/

Charter for Working Group

Low power and Lossy networks (LLNs) are made up of many
embedded devices with limited power, memory, and processing
resources. They are interconnected by a variety of links, such as
IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low
power PLC (Powerline Communication) links. LLNs are transitioning
to an end-to-end IP-based solution to avoid the problem of
non-interoperable networks interconnected by protocol translation
gateways and proxies.

Generally speaking, LLNs have at least five distinguishing
characteristics:
- LLNs operate with a hard, very small bound on state.
- In most cases, LLN optimize for saving energy.
- Typical traffic patterns are not simply unicast flows (e.g. in some
  cases most if not all traffic can be point to multipoint)
- In most cases, LLNs will be employed over link layers with
  restricted frame-sizes, thus a routing protocol for LLNs should be
  specifically adapted for such link layers.
- LLN routing protocols have to be very careful when trading off
  efficiency for generality; many LLN nodes do not have resources to
  waste.

These specific properties cause LLNs to have specific routing
requirements.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have
been evaluated by the working group and have in their current form been
found to not satisfy all of these specific routing requirements.

The Working Group is focused on routing issues for LLN.

There is a wide scope of application areas for LLNs, including
industrial monitoring, building automation (HVAC, lighting, access
control,
fire), connected homes, healthcare, environmental monitoring, urban sensor
networks (e.g. Smart Grid), asset tracking. The Working Group focuses



Crocker & Droms           Expires March 4, 2016                [Page 42]


Internet-Draft         WG Guidelines & Procedures         September 2015


on routing solutions for a subset of these: industrial, connected
home, building and urban sensor networks for which routing requirements have
been specified. These application-specific routing requirement
documents will be used for protocol design.

The Working Group focuses only on IPv6 routing architectural framework
for these application scenarios. The Framework will take into
consideration various aspects including high reliability in the presence
of time
varying loss characteristics and connectivity while permitting low-power
operation with very modest memory and CPU pressure in networks
potentially comprising
a very large number (several thousands) of nodes.

The Working Group will pay particular attention to routing security
and manageability (e.g., self routing configuration) issues. It will
also need to consider the transport characteristic the routing protocol
messages will experience. Mechanisms that protect an LLN from congestion
collapse or
that establish some degree of fairness between concurrent
communication sessions are out of scope of the Working Group. It is
expected that
upper-layer applications utilizing LLNs define appropriate mechanisms.
The solution must include unicast and multicast considerations.

Work Items:

- Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for routing in
LLNs.

- Provide an architectural framework for routing and path selection at
Layer 3 (Routing for LLN Architecture) that addresses such issues as
whether LLN routing require a distributed and/or centralized path
computation models, whether additional hierarchy is necessary and how it
is
applied.

Manageability will be considered with each approach, along with
various trade-offs for maintaining low power operation, including the
presence of non-trivial loss and networks with a very large number of nodes.
should
- Produce a routing security framework for routing in LLNs.

- Protocol work: The Working Group will consider specific routing
requirements from the four application documents collectively, and
specify either
a new protocol or extend an existing routing protocol in cooperation



Crocker & Droms           Expires March 4, 2016                [Page 43]


Internet-Draft         WG Guidelines & Procedures         September 2015


with the
relevant Working Group.
If requirements from the four target application areas cannot be met
with a single protocol, the WG may choose to specify or extend more than
one
protocol (this will require a recharter of the WG).

- Documentation of applicability statement of ROLL routing protocols.

Milestones
Done
Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC.
Done
Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC.
Done
Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC.
Done
Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC.
Done
Submit Security Framework to the IESG to be considered as an Informational RFC
Done
Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard.
Done
Submit first draft of ROLL routing protocol specification as Proposed Standard.
Done
Submit the ROLL routing protocol specification to the IESG as Proposed Standard.
Done
Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC
Done
WG to adopt RPL applicability statement Home for Automation applications
draft-ietf-roll-applicability-home-building
Done
WG to adopt RPL applicability statement(s) for AMI networks
draft-ietf-roll-applicability-ami
Done
WG to adopt RPL applicability statement for Industrial applications
draft-ietf-roll-rpl-industrial-applicability
Done
WG to adopt reviewed template for applicability statements
draft-ietf-roll-applicability-template
Done
Resolve question of whether to keep this in roll or 6tisch
draft-ietf-roll-rpl-industrial-applicability
Done
submit REVISED thread-analysis document based upon security directorate review to IESG.
draft-ietf-roll-security-threats
Feb 2014
Submit first draft of RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC



Crocker & Droms           Expires March 4, 2016                [Page 44]


Internet-Draft         WG Guidelines & Procedures         September 2015


Done
Evaluate WG progress, recharter or close
Aug 2014
WG to joint-LC using flow-label for RPL with 6man
draft-thubert-6man-flow-label-for-rpl

B.4.  another one

Appendix C.  [PROTO-WIKI] Working Group Advice

   NOTE TO RFC EDITOR:    Prior to publication, this section is to be
      moved to an IETF wiki page, for on-going enhancement.

      ALSO: The document's reference to this section needs to be
      modified to refer to that wiki.

C.1.  If you have a formal WG role...

   Here is some basic advice to anyone performing working group
   administrative or management dutues -- that is, anyone assigned tasks
   by the AD or a chair:

   o  Re-read "The Tao of IETF: A Novice's Guide to the Internet
      Engineering Task Force" [Tao].  You've already read it at least
      once, right?

   o  Read [RFC7282].  No, really, I know you say you've read it; go
      read it again.  Be sure you know what "rough consensus" is, how it
      can be identified and how it is used in the IETF.  Pay particular
      attention to its extended discussion of the handling of 'minority'
      views.

C.2.  Advice for Chairs

   o  Become familiar with: [ChairGuide]

   o  Some WGs do work that requires interaction and cooperation with
      other standards bodies.  WG administrative staff should be aware
      of the possibility of such interactions, as formally described
      regarding IEEE in RFC 7241 and ITU-T in RFC 6756.  The IETF has
      established a formal liaison role for some of these interactions,
      as defined in RFC 4691.  RFC 4929 describes a specific (and
      historically interesting) example of interaction between the IETF
      and ITU-T.

   o  Handling Internet-Drafts as part of the activities of Working
      Groups is summarized in RFC 2418bis and described in detail in RFC




Crocker & Droms           Expires March 4, 2016                [Page 45]


Internet-Draft         WG Guidelines & Procedures         September 2015


      7241.  The states that a WG document can take are defined in RFC
      6174.

   o  The co-chairs are responsible for behavior of WG participants as
      part of the IETF.  RFC 7154 can help to identify and deal with
      unacceptable behavior.

   o  Intellectual property rights (IPR) management is crucial to the
      IETF and has been the source of serious legal issues in the past.
      Read RFC 6702 to understand the IETF disclosure rules and how to
      make sure your WG stays in compliance with those rules.  Also read
      RFC 6701 to learn how you can deal with IPR policy violations.

C.3.  Meetings

C.3.1.  WG meeting preparation

C.3.1.1.  Request meeting slot(s)

   A WG will typically meet once during an IETF meeting.  The chairs may
   choose to request two slots if the WG has a long agenda.  Requesting
   more than two slots requires approval of the Area Director.

   The request will include the expected length, number of participants
   and a list of other WGs with which time conflicts should be avoided.
   These specific requests should be considered carefully as they are
   important for successful scheduling.

C.3.1.2.  Create and post agenda

   Well before the meeting, the WG administration posts a request for
   proposed discussion items, presentations and other agenda items to
   the WG mailing list.

   The WG administration collects the requests for agenda items and adds
   other agenda items as required for WG operation and posts a draft
   agenda for WG review.  Once the final agenda is ready, the WG
   administration posts it through the IETF Meeting Materials manager
   web page.

C.3.1.3.  Post meeting materials

   Any documents to be discussed at the WG meeting must be posted two
   weeks before the meeting.  The IESG Secretariat enforces an I-D
   publication restriction during the two weeks before the IETF meeting.






Crocker & Droms           Expires March 4, 2016                [Page 46]


Internet-Draft         WG Guidelines & Procedures         September 2015


   Any presentations or other materials should be posted through to the
   IETF Meeting Materials at least a week before the IETF meeting to
   provide participants an opportunity to review those materials.

C.3.1.4.  Other meeting prep

   There are minute takers and jabber scribes at every WG meeting.  It
   can save time at the meeting to identify individuals to fill those
   roles prior to the meeting.

C.3.2.  WG meeting operation

      * Confirm meeting room logistics: AV equipment, presentation
      materials, etc.

      * Pass around attendance records ("blue sheets")

      * Bash the agenda

      * WG status update

      * Proceed through the agenda

      * Record significant consensus calls, process actions, technical
      decisions

C.3.3.  WG Meeting Followup

      * Deliver a one paragraph summary of the meeting, including
      significant consensus calls, process actions, technical decisions,
      for the Area Director before the end of the IETF meeting

      * Prepare notes, using notes, jabber log and audio recording of
      the meeting; once the notes are ready, post the notes to the IETF
      Meeting Materials

C.4.  Ongoing WG operation

C.4.1.  Managing Individual Documents

   Documents typically go through several revisions in the process of WG
   development and review.  The datatracker is used to manage and
   publish the state of an I-D as it progresses toward publication.  WG
   administration coordinates the editing of the document by the editors
   with the input from the WG.  The issues tracker is a useful tool for
   recording and managing specific issues with an I-D.





Crocker & Droms           Expires March 4, 2016                [Page 47]


Internet-Draft         WG Guidelines & Procedures         September 2015


   The document shepherd manages the processing and publication of the
   document after it has been submitted by the WG to the IESG for
   publication.  The issues tracker can be useful at this stage of the
   publication process as well.

C.4.2.  Charter Management

      * The WG administration reviews and periodically updates the WG
      milestones.

Authors' Addresses

   Dave Crocker (editor)
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086
   USA

   Phone: +1.408.246.8253
   Email: dcrocker@bbiw.net


   Ralph Droms (editor)
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA  01719

   Email: rdroms@cisco.com























Crocker & Droms           Expires March 4, 2016                [Page 48]