Network Working Group P. Hoffman Internet-Draft VPN Consortium Updates: May 28, 2011 raft-ietf-genarea-charter-tool (if approved) Intended status: Informational Expires: November 29, 2011 Requirements for a Working Group Milestones Tool draft-ietf-genarea-milestones-tool-01 Abstract 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 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 November 29, 2011. 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. 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 [CHARTER-TOOL]. 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 wgchairs@ietf.org 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]. 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 chairs. 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 changes. The database will record the date and person who initiates any addition of, or 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. Approval of Milestone Additions and Changes [[ The following proposal is based on early input to this draft, and may change significantly as the these requirements are discussed. ]] 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: o create new milestones o delete milestones o change milestone descriptions o change milestone due dates o change which Internet-Drafts are associated with a milestone o assert that a milestone is completed The default settings at the time that this feature is launched will be that all actions other than changing due dates and asserting completion require AD approval. These settings apply both to additions and changes made by WG chairs and by other ADs. 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 overdue. 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. 7. Viewing Changes in Milestones Section 5 of [CHARTER-TOOL] 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] 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], 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]. 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], 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 wgchairs@ietf.org mailing list. 11. References 11.1. Normative References [CHARTER-TOOL] 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. 11.2. Informative References [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005. Appendix A. Earlier Proposals During the early discussion of the requirements for this document in the IESG and among WG chair, there was not a common agreement about how milestones management should be handled. Some felt that WG chairs should be able to update their milestones without any AD intervention, as long as the responsible AD was informed after each change Some felt that ADs need to approve every change before the change is announced to the community Some felt that ADs might approve additions to the list of milestones and changing of a milestone's description, but not need to approve changing of milestone dates Some felt that ADs should be able to select which WGs could update their milestones without AD intervention while allowing others to do so freely, or for an AD to be able to set a limit on how many new milestones a WG could add before the AD had to intervene The requirements given in this document is that the default settings for the new tool should match the requirements faced by WG chairs currently. Some participants 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 Email: paul.hoffman@vpnc.org