Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Updates:                                                   July 11, 2011
raft-ietf-genarea-charter-tool 6292 (if approved)                               August 1, 2011
Intended status: Informational
Expires: January 12, February 2, 2012

            Requirements for a Working Group Milestones Tool


   The IETF intends to provide a new tool to Working Group chairs and
   Area Directors for the creation and updating of milestones for
   Working Groups.  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 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

   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 January 12, February 2, 2012.

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

1.  Introduction

   [RFC2418] describes the guidelines and procedures for operation of
   IETF Working Groups (WGs).  Every WG has milestones that the WG is
   supposed to meet, such as the publication of a particular Internet-
   Draft or the beginning of discussion on a particular topic.  The WG's
   milestones are commonly listed with the WG's charter, although the
   milestones are not formally part of the charter.

   Today, the tasks associated with creating and updating WG milestones
   are performed manually.  Normally, WG chairs send email to their Area
   Director (AD) requesting that milestones be created or updated, or
   saying that one or more milestone has been met.  These messages
   sometimes come as part of charter creation or updating, but are often
   separate (such as if a current milestone is met but there is no
   reason to update the charter itself).  WG chairs sometimes send mail
   directly to the IETF Secretariat to make a change to the database of
   milestones, such as to change the dates for milestones or to say that
   they are completed.

   In early 2011, the IETF approved a set of requirements for a tool
   that helps ADs with the WG chartering and rechartering process
   [RFC6292].  During the IESG discussion of that document, it became
   clear that everyone wanted more automation to the milestones process.
   This document, and the discussion it will hopefully engender, is
   intended to bring that discussion to a general consensus among WG
   chairs and ADs for the requirements for the eventual tool.

   The IAOC would like to create a better tool for the tasks of WG
   milestone creation and updating, 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.  Discussion of These Requirements

   This document is being discussed on the mailing
   list.  See <> for more
   information. [[ This subsection is to be deleted before publication.

2.  Users of the Tool

   This tool can only be used by WG chairs and ADs, not by other members
   of the IETF community.  The tool will use the login and access
   control features that will already be in place from the outcome of
   the tool created by [CHARTER-TOOL]. [RFC6292].  It is important to note that some
   people are chairs for more than one WG, and everyone must be able to
   use the tool for all of the WGs that they chair.

   Any AD can add or update any milestone for any WG.  Normally, an AD
   would only add or update milestones in the WGs for which they are the
   responsible AD, but ADs are not bound by such a limitation.  WG
   chairs can only add or update milestones for WGs of which they are

   The IETF Secretariat needs to be able to perform the same tasks as
   the WG chairs and ADs in order to fix problems or to make emergency

   The database will record the date and person who initiates any
   addition of, or change to, a milestone.  The contents of the database
   will be visible to the IETF community so that anyone can see who made
   a particular change to a milestone.

3.  Updating, Adding, and Deleting Milestones

   A WG chair needs to see all of the milestones for that chair's WG in
   the tool.  The chair needs to be able to edit any milestone record
   for that chair's WG.  In each existing record, the chair needs to be
   able to edit the due date, the finished date, the associated
   Internet-Drafts, and the description of the milestone.  The chair
   also needs to be able to delete existing milestones.

   A WG chair needs to be able to add one or more milestone records to
   the database for their WG.  The chair needs to be able to specify the
   due date, zero or more associated Internet-Drafts, and the
   description of the record that he or she is adding.  A WG chair also
   needs to be able to delete one or more existing milestones.

4.  Automatic  Acceptance of Milestone Additions and Changes


   There are six actions associated with adding and changing milestones:

   o  create new milestones

   o  delete milestones

   o  change made by milestone descriptions
   o  change milestone due dates

   o  change which Internet-Drafts are associated with a WG chair will be automatically accepted by the
   tool.  If either chair of milestone

   o  assert that a milestone is completed

   WG wants to revert chairs can change milestone due dates, change which Internet-
   Drafts are associated with a change, such as if milestone, and can assert that a
   change was made
   milestone is completed, for their WG.  When any of these three
   actions are taken in error, those the Datatracker, an email notification is sent
   to the AD for the WG as well as to the WG's chairs; the changes are
   reflected immediately in the Datatracker without any need for
   approval from an AD.

   WG chairs can make also create new milestones, delete milestones, and
   change milestone descriptions; however, any of these action are not
   reflected in the Datatracker until the action is approved by an AD.
   When a subsequent
   change.  It WG chair makes the proposed change, an email notification is likely that such change-and-revert cycles will happen
   sent to the AD for the WG chairs get used as well as to the new tool. WG's chairs.

   As noted in Section 2, any AD can change take any milestone.  Thus, if of these six actions.

   When adding or editing a milestone, the AD or WG chair makes an erroneous Chair must be able
   to review and change the proposed change before committing the change
   to a milestone the Datatracker.  This will help prevent errors and does not fix reduce the error themselves,
   number of fixes that need to be made.

   When any AD may fix it for them.  In practice, it of these six actions is reflected in the Datatracker, an
   email notification is sent to the WG mailing list by the Datatracker.
   [[ NOTE: at the Quebec meeting, there was a discussion about this
   requirement.  There was a concern that the mailing lists would be better get
   cluttered if those who make errors fix a chair was making a bunch of changes at once.  Some WG
   chairs wanted to be able to suppress the errors themselves. message so that they could
   send a message themselves saying what was updated.  Other WG chairs
   wanted the messages to be batched, such as once a day.  Comments
   about this are solicited. ]]

   After this tool is launched, the IETF Secretariat will no longer need
   to post a change to the database: the tool will do this without
   intervention by the Secretariat.

5.  Mapping Milestones to Internet-Drafts

   There is currently no requirement how WG milestones map to Internet-
   Drafts.  While most milestones map one-to-one with Internet-Drafts,
   some milestones do not map to any Internet-Draft (such as those that
   say when a general discussion will begin or finish), and other
   milestones map to multiple Internet-Drafts (such as a milestone that
   covers a topic that has multiple related Internet-Drafts).  Some
   Internet-Drafts are part of more than one milestone.

   The new tool is required to make mappings between milestones and
   Internet-Drafts explicit, and those drafts must be listed in views of
   the milestone.  This change will require a change to the Datatracker
   database to make such an association.

   When an Internet-Draft that is mapped to a milestone changes its
   state to "Submitted to IESG for Publication" as described in
   [RFC6174], the tool will send a message to the WG chairs to remind
   them that they might want to update the milestone.  Note that this
   message will not apply to all Internet-Drafts that are mapped to a
   milestone, so it is up to the WG chairs to decide what to do when
   such a message is received.

6.  Reminders for WG Chairs and ADs

   Milestone changes that do not require AD approval are made
   immediately.  Requested changes that require AD approval are tracked
   by the tool.  If the AD has not approved or rejected the change
   within a week, email listing the request and the request date is sent
   to the WG chairs and AD.  That email is sent every week until the AD
   has approved or rejected the request.

   The tool will also send WG chairs reminders about pending milestones.
   A message is sent when a milestone is one month from being due, at
   the time a milestone is due, and every month in which a milestone is

   The tool will also send WG chairs reminders about Internet-Drafts
   that are mapped to milestones.  A message is sent when such a draft
   is one month from expiring, and at the time that a draft expires.  If
   a milestone is mapped to a draft that is expired, mail reminding the
   chairs of this will be sent weekly.

   When an Internet-Draft is added to a WG, the Datatracker will send a
   message to the WG chairs reminding them that they might want to add
   it to a milestone or create a new milestone for it.  Once a month,
   the Datatracker will send mail to the WG chairs if there are WG
   Internet-Drafts that are not in any WG milestones.

7.  Viewing Changes in Milestones

   Section 5 of [CHARTER-TOOL] [RFC6292] describes an extension to the Datatracker to
   allow the IETF community to view, search, and track changes to WG
   charters.  This document updates those requirements to allow the IETF
   community to view, search, and track changes to WG milestones.

   Section 5.1 of [CHARTER-TOOL] [RFC6292] is updated to allow searching for any text
   in a milestone's description, as well as for the name of any
   Internet-Draft name that is mapped to any milestone.

   A new capability will be added to the Datatracker that is similar to
   that described in Section 5.2 of [CHARTER-TOOL], [RFC6292], but instead of showing
   differences between charters, it shows differences between the full
   set of milestones.  Any time a milestone is added, deleted, or any of
   its fields changed, the full set of milestones is considered changed.
   Someone should be able to easily compare two full sets of milestones.
   They should also be able to see two more full sets of milestones with
   the differences highlighted.  The tool should show who made each
   change when changes are viewed.  These features should be found in
   the same place as the features described in Section 5.2 of [CHARTER-TOOL]. [RFC6292].

   The tool needs to provide an Atom feed [RFC4287] for the changes in
   the milestones for a WG.  The contents of the feed are the full WG
   record, plus an indication of what changed since the last entry in
   the feed and who made the change.  This feed is different than the
   feed described in Section 5.3 of [CHARTER-TOOL], [RFC6292], but it should be offered
   to users in the same places as that feed is offered.

8.  IANA Considerations

   None. [[ ...and thus this section can be removed before publication
   as an RFC... ]]

9.  Security Considerations

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

10.  Acknowledgements

   This document draws heavily on ideas from various WG chairs and ADs
   on the mailing list.

11.  References
11.1.  Normative References

              Hoffman, P., "Requirements for a Working Group Charter
              Tool", draft-ietf-genarea-charter-tool (work in progress),
              April 2011.

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

   [RFC6174]  Juskevicius, E., "Definition of IETF Working Group
              Document States", RFC 6174, March 2011.

   [RFC6292]  Hoffman, P., "Requirements for a Working Group Charter
              Tool", RFC 6292, June 2011.

11.2.  Informative References

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

Appendix A.  Earlier Proposals

   The first few drafts of this document had a different model for
   approval of milestone additions and changes.  Those drafts said "The
   responsible AD for a WG can specify whether any of the following
   actions can be made without the AD approval for milestones associated
   with the WG: create new milestones, delete milestones, change
   milestone descriptions, change milestone due dates, change which
   Internet-Drafts are associated with a milestone, assert that a
   milestone is completed."  In addition, the earlier drafts said that
   the default settings when the featured would have been launched would
   be that all actions other than changing due dates and asserting
   completion require AD approval.

   The current draft has quite a different mechanism described in
   Section 4.

   Also, some participants in the early discussion felt that the new
   tool should have a mode where milestones whose essence is that a
   particular draft is sent to the IESG is automatically marked as
   complete when the draft's state is that it has gone to IETF
   consideration.  However, there was a fair amount of disagrement about
   the need for such a mode and whether it would end up restricting
   actions that should remain flexible.

Author's Address

   Paul Hoffman
   VPN Consortium