GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6292

Internet Engineering Task Force (IETF) P. Hoffman Request for Comments: 6292 VPN Consortium Category: Informational June 2011 ISSN: 2070-1721

           Requirements for a Working Group Charter Tool

Abstract

 The IETF intends to provide a new tool to Area Directors for the
 creation, re-chartering, and closing of Working Groups.  The tool
 will also allow the IETF community to view the status of the
 chartering process.  This document describes the requirements for the
 proposed new tool, and it is intended as input to a later activity
 for the design and development of such a tool.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6292.

Copyright Notice

 Copyright (c) 2011 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
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Hoffman Informational [Page 1] RFC 6292 WG Charter Tool Reqs June 2011

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  WG Charter Process Overview  . . . . . . . . . . . . . . .  3
 2.  General Requirements . . . . . . . . . . . . . . . . . . . . .  3
   2.1.  WG Records . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2.  Comments . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.3.  Naming of Charter Text Proposals . . . . . . . . . . . . .  5
   2.4.  Wording of Announcements . . . . . . . . . . . . . . . . .  5
   2.5.  Access to the Tool . . . . . . . . . . . . . . . . . . . .  6
   2.6.  Initializing the Tool  . . . . . . . . . . . . . . . . . .  6
 3.  Creating and Rechartering WGs  . . . . . . . . . . . . . . . .  6
   3.1.  Chartering a New WG  . . . . . . . . . . . . . . . . . . .  6
   3.2.  Rechartering an Existing WG  . . . . . . . . . . . . . . .  8
   3.3.  Ballots for Charter Approval . . . . . . . . . . . . . . .  9
 4.  Requesting the Closing of a WG . . . . . . . . . . . . . . . .  9
 5.  Searching, Comparing, and Tracking Charters  . . . . . . . . .  9
   5.1.  Viewing and Searching the Charter Database . . . . . . . .  9
   5.2.  Seeing Differences between Versions of Pre-Approval
         Wordings . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.3.  Tracking Charters with an Atom Feed  . . . . . . . . . . . 10
 6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
 7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
 8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
   8.2.  Informative References . . . . . . . . . . . . . . . . . . 11

Hoffman Informational [Page 2] RFC 6292 WG Charter Tool Reqs June 2011

1. Introduction

 [RFC2418] describes the guidelines and procedures for formation and
 operation of IETF Working Groups (WGs).  Since the publication of RFC
 2418 in 1998, the IETF has started many dozen new WGs, and has shut
 down many dozen.  In that time, many WGs have had some (often dozens)
 changes to their charters.
 Today, virtually all of the tasks associated with creating,
 rechartering, and closing a WG are performed manually.  An Area
 Director (AD) requests one of these actions by manually sending a
 message to the Secretariat's ticket system.  A member of the
 Secretariat staff manually updates the internal Secretariat database
 and the IETF Datatracker, manually places the WG on the IESG
 teleconference agenda (when appropriate), and manually sends out all
 of the required messages and announcements.
 The IETF Administrative Oversight Committee (IAOC) would like to
 create a better tool for those tasks, and this document lists the
 requirements for such a tool.  When complete, this document may be
 used to issue an RFP for the design and development of the tool.
 This document was prepared at the request of the IAOC.

1.1. WG Charter Process Overview

 As described in [RFC2418], a key responsibility of the IESG is the
 creation, re-chartering, and closing of WGs.  Creation and
 rechartering of WGs is a multi-step process that involves internal
 review of a draft charter by the IESG and IAB, an external review of
 the draft charter by the IETF community and by other standards
 bodies, and (likely) approval of a final charter by the IESG.  The
 internal review by the IESG and IAB, and the external review by the
 IETF community, often result in revisions to the draft charter.
 Closing of a WG does not require review or approval by the IESG.
 Rather, a WG may be closed at the request of an AD, normally the Area
 Advisor for the WG.
 Note that the charter and recharter processes do not involve changing
 of WG milestones.  A tool that handles milestone updates will likely
 be created in the future.

2. General Requirements

 The tool described here holds records for new WGs that are being
 considered as well as for all WGs whose charter are under review.

Hoffman Informational [Page 3] RFC 6292 WG Charter Tool Reqs June 2011

2.1. WG Records

 A WG record contains the following fields:
 o  name of the WG
 o  the WG's acronym
 o  names of the WG chairs (if known)
 o  names of the WG secretary (if any)
 o  names of the WG technical advisors (if any)
 o  shepherding AD
 o  IETF area
 o  charter text
 o  mailing list address and archive location
 o  previous mailing list (if any)
 o  other web sites (such as wikis, trackers, and/or project sites, if
    any) including web sites existing prior to the WG formation
 o  earlier acronyms for the WG
 o  explanation for why the WG is being chartered or rechartered (if
    any)
 In addition, a WG record contains the state of the WG in the review
 process.  That state has one annotation: whether or not the state is
 for a proposed WG or for an existing WG undergoing rechartering.
 Some changes in state cause messages to be sent to the Secretariat so
 that the Secretariat can perform additional steps, such as sending
 out mail to various parties about the latest version of the charter
 text, deadlines for an upcoming decision, and so on.
 When a WG record is displayed, that display should also reflect
 whether the WG currently exists or has been closed; that data comes
 from a different part of the Datatracker database.
 Any AD can modify fields in an existing WG record.  Any AD can use
 the tool to change the review state of a WG record.  The normal order
 for steps is shown in this document, but an AD can set the state to
 any valid value at any time.

Hoffman Informational [Page 4] RFC 6292 WG Charter Tool Reqs June 2011

2.2. Comments

 During the reviews for WG creation and rechartering, ADs can comment
 on the reviews.  Any AD can add a comment to the record of a WG that
 is under review.  Each comment can be flagged as either "blocking"
 (meaning blocking forward movement until it is resolved) and "non-
 blocking" (meaning that it is only informative or editorial).

2.3. Naming of Charter Text Proposals

 Charter text proposals are to be kept for historical purposes.  They
 are kept in files with a specific naming pattern.  The pattern for
 charters before a WG is formed is:
 charter-ietf-wgacronym-nn[-mm]
 o  "wgacronym" is the acronym of the proposed WG.
 o  "nn" is a two-digit charter number assigned in sequence.  It
    starts at "00" for before the WG is first chartered; the first
    finished charter has a value of "01".
 o  "mm" is a two-digit proposal number assigned in sequence.  It
    starts at "00" for the first proposal for a particular version of
    charter.  It is omitted in the actual charter file.
 For instance, if the "example" WG is chartered and then rechartered
 twice, you might have the following sequence of files:
 charter-ietf-example-00-00.txt (first proposal)
 charter-ietf-example-00-01.txt (second proposal)
 charter-ietf-example-00-02.txt (third proposal)
 charter-ietf-example-01.txt (first charter)
 charter-ietf-example-01-00.txt (first recharter proposal)
 charter-ietf-example-01-01.txt (second recharter proposal)
 charter-ietf-example-01-02.txt (third recharter proposal)
 charter-ietf-example-02.txt (second charter)
 charter-ietf-example-02-00.txt (next recharter proposal)
 . . .
 charter-ietf-example-03.txt (third charter)

2.4. Wording of Announcements

 An AD can view and edit the standard "WG Review" and "WG Action"
 announcements before they are sent out during the WG creation,
 rechartering, and closing processes.  If the AD edits the message,
 the Secretariat is alerted to that fact when they receive the
 request.

Hoffman Informational [Page 5] RFC 6292 WG Charter Tool Reqs June 2011

2.5. Access to the Tool

 Area Directors and the IETF Secretariat currently have access to
 perform some actions in the Datatracker that other community members
 do not; this access control continues to be used in many of the
 extensions listed in this document.  Further, the IETF Secretariat
 can perform all actions that can be performed by any AD in this tool.

2.6. Initializing the Tool

 Records for all WGs that are being created, or are in the process of
 charter updates, will be added before the tool is first publicly
 deployed.
 The database should also be initialized with current and historical
 data, namely as much information as is currently known about existing
 and closed WGs that can be done in a mostly-automated fashion.

3. Creating and Rechartering WGs

3.1. Chartering a New WG

 Any AD can create a new WG record using a simple web form.  Creating
 a record should succeed as long as there is no other WG with the same
 name.  Names must be unique, so the tool will warn the AD if the
 acronym that is being proposed has been used in earlier WG charter
 proposals and suggest against its use for a new charter.  By default,
 the field in the form listing the shepherding AD will be prepopulated
 with the name of the AD who is filling in the form.  The AD can fill
 in all the fields for the proposed WG.  The names of the WG chairs
 can be left off during the initial chartering process.
 (Some Secretariat tools have trouble with acronyms of more than eight
 characters: they truncate the name.  This will probably be fixed in
 the future.  The new tool should have a configuration setting that is
 set to 8 initially, and it should be adjusted when the Secretariat
 tools are updated.  There may also be problems with names that have
 hyphens in them.  However, WGs that have more than eight characters
 in their names, and WGs with hyphens in their names, have existed for
 over a year.)
 Creating a new WG record causes the Datatracker state for this
 potential new WG to be "Informal IESG review".  When the record is
 created, the AD proposes a length of time (in weeks) for the internal
 review time; the default is one week.
 The review states in which a WG can exist during its initial
 chartering are:

Hoffman Informational [Page 6] RFC 6292 WG Charter Tool Reqs June 2011

 o  Informal IESG review -- This is the initial state, moved into by
    the tool when an AD creates a WG record.  When the WG record is
    moved to this state, a message is sent to the Secretariat.  The
    normal next state is "Internal review" if the idea is accepted, or
    "Not currently under review" if the idea is abandoned.  The tool
    should prompt the AD if they try to move to the next state in less
    than the minimum elapsed time set by the AD when creating the WG,
    but allow the move if the AD responds to the prompt.
 o  Internal review -- The IESG and IAB are reviewing the early draft
    of the charter; this is the initial IESG and IAB review.  When
    moved to this state, a note is sent to the Secretariat to place
    this on the next IESG telechat and to inform the IAB.  The usual
    next state is "External review" if the idea is adopted, or
    "Informal IESG review" if the IESG decides the idea needs more
    work, or "Not currently under review" if the idea is abandoned.
 o  External review -- The IETF community and possibly other standards
    development organizations (SDOs) are reviewing the proposed
    charter.  When moved to this state, a note is sent to the
    Secretariat to send out the external review announcement to the
    appropriate lists.  The external review announcement will be sent
    out to the normal IETF-related mailing lists.  The AD can specify
    whether or not to send the announcement to other SDOs (with the
    default being that it should be), and the AD can also specify
    additional recipients who should receive the announcement.  When
    moved to this state, a separate note is sent to the Secretariat to
    schedule discussion for the next IESG telechat.  The usual next
    state is "IESG review", although it might move to "Not currently
    under review" if the idea is abandoned during the external review.
 o  IESG review -- The IESG is reviewing the discussion from the
    external review of the proposed charter.  The usual next state is
    "WG exists", or "Not currently under review" if the idea is
    abandoned.
 o  WG exists -- The WG was approved by the IESG.  When moved to this
    state, a note is sent to the Secretariat to publish the charter
    and send the appropriate announcements.  The WG remains in this
    state until there is a request to update the charter.
 o  Not currently under review -- The proposed WG is not being
    considered at this time.  A proposed WG charter will remain in
    this state until an AD moves it to "Informa1 IESG review".
 All states above, except for "WG exists", are given the annotation
 "Initial chartering".

Hoffman Informational [Page 7] RFC 6292 WG Charter Tool Reqs June 2011

 The chartering process involves the proposed charter appearing on two
 IESG telechats.  The tool should allow an AD and/or the Secretariat
 to select the telechat date for the approval events.  When the
 telechat is selected, the state determines where it appears on that
 telechat's agenda.

3.2. Rechartering an Existing WG

 Any AD can request that a WG be rechartered using a simple web form.
 This form prompts with the current charter and allows all fields to
 be edited.  Asking for a recharter causes the Datatracker state for
 this WG to be "Informal IESG review".  When the recharter record is
 created, the AD proposes a length of time (in weeks) for the internal
 review time; the default is one week.
 The review states in which a WG can exist during rechartering are:
 o  WG exists; Informal IESG recharter review -- This is the initial
    state, moved into by the tool when an AD asks for a WG to be
    rechartered.  When the WG record is moved to this state, a message
    is sent to the Secretariat.  The normal next state is "WG exists;
    Internal review" if the idea is accepted, or "WG exists" if this
    attempt to recharter is abandoned.  The tool should prompt the AD
    if they try to move to the next state in less than the minimum
    elapsed time set by the AD when asking to recharter the WG.
 o  WG exists; Internal recharter review -- The IESG and IAB are
    reviewing the proposed new charter; this is the initial IESG and
    IAB review of the new charter.  When moved to this state, a note
    is sent to the Secretariat to place this on the next IESG telechat
    and to inform the IAB.  The usual next state is "WG exists;
    External review" if the idea is adopted, or "WG exists; Informal
    IESG review" if the IESG decides the idea needs more work, or "WG
    exists" if the current rechartering is abandoned or if the new
    charter is approved during internal review.
 o  WG exists; External recharter review -- The IETF community and
    possibly other SDOs are reviewing the proposed new charter.  When
    moved to this state, a note is sent to the Secretariat to send out
    the external review announcement to the appropriate lists.  The
    external review announcement will be sent to the normal IETF-
    related mailing lists.  The AD can specify whether or not to send
    the announcement to other SDOs (with the default being that it
    should be), and the AD can also specify additional recipients who
    should receive the announcement.  The usual next state is "WG
    exists; IESG review", although it might move to "WG exists" if the
    current rechartering is abandoned during the external review.

Hoffman Informational [Page 8] RFC 6292 WG Charter Tool Reqs June 2011

 o  WG exists; IESG recharter review -- The IESG is reviewing the
    discussion from the external review of the recharter.  When moved
    to this state, a note is sent to the Secretariat to schedule
    discussion for the next IESG telechat.  The usual next state is
    "WG exists".
 All states above are given the annotation "Rechartering".
 When rechartering existing WGs, the IESG decides whether or not the
 recharter needs an external review; many do not.
 The rechartering process involves the proposed charter appearing on
 one or two IESG telechats.  The tool should allow an AD and/or the
 Secretariat to select the telechat date for the approval events.
 When the telechat is selected, the state determines where it appears
 on that telechat's agenda.

3.3. Ballots for Charter Approval

 The current Datatracker has facilities for ballots on adoption of
 Internet-Drafts to become RFCs.  A separate facility needs to be
 created to allow balloting for initial chartering or rechartering
 during IESG review.  The balloting for charter and rechartering will
 allow ADs to express "yes", "no", and "abstain" positions, and will
 allow ADs to change their positions over time.
 As described in Section 2.2, comments can be added to the record for
 a WG.  It is expected that such comments will be added during the
 balloting process.

4. Requesting the Closing of a WG

 An AD can use the tool to request that the Secretariat close an
 existing WG.  The request action will prompt the AD to provide
 instructions regarding the disposition of each active Internet-Draft
 (such as to withdraw the draft, move it to another WG, convert it to
 an individual submission, and so on), wording for the closure
 announcement, and the status of the WG mailing list (will it remain
 open or should it be closed).

5. Searching, Comparing, and Tracking Charters

5.1. Viewing and Searching the Charter Database

 All members of the IETF community can view the public portions of the
 charter database.  This public view should have an explanation of the
 states given in this document.  They can also search for a WG record
 in the tool based on one or more of the following criteria:

Hoffman Informational [Page 9] RFC 6292 WG Charter Tool Reqs June 2011

 o  WG name (full or partial)
 o  WG acronym
 o  WG charter state
 o  Shepherding AD
 o  Area
 o  Text in any of the fields
 o  Earlier acronyms for the WG
 Further, all users can view all snapshots of earlier versions of a
 WG's charter.  Snapshots include the Area, AD, WG name, WG acronym,
 chairs, and charter text.

5.2. Seeing Differences between Versions of Pre-Approval Wordings

 It needs to be easy to compare differences between different versions
 of proposed charter language, up to and including the approved
 version.  Using the naming formats given in Section 2, this means
 that it must be easy to compare wgacronym-charter-ss (for the highest
 value of "ss") with wgacronym-recharter-ss-nn.  It must also be
 possible to compare any two versions of approved charters (that is,
 of two values for "ss" in wgacronym-charter-ss).  It also must be
 easy to compare two versions that have different acronyms in the case
 that the acronym changes during the chartering process.

5.3. Tracking Charters with an Atom Feed

 The tool needs to provide an Atom feed [RFC4287] for the changes in a
 charter.  The contents of the feed are the full WG record, plus an
 indication of what changed since the last entry in the feed.

6. Security Considerations

 Creating a new tool for tracking the charter of WGs does not affect
 the security of the Internet in any significant fashion.

7. Acknowledgements

 This document draws heavily on earlier work done on this topic by
 other writers, such as previous IESG and IAB members.  Various
 members of the IESG contributed many suggestions to this document.
 In particular David Harrington, Robert Sparks, and Russ Housley
 contributed a great deal of wording and many ideas.

Hoffman Informational [Page 10] RFC 6292 WG Charter Tool Reqs June 2011

8. References

8.1. Normative References

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

8.2. Informative References

 [RFC4287]  Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
            Syndication Format", RFC 4287, December 2005.

Author's Address

 Paul Hoffman
 VPN Consortium
 EMail: paul.hoffman@vpnc.org

Hoffman Informational [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6292.txt · Last modified: 2011/06/23 03:32 (external edit)