draft-ietf-genarea-milestones-tool-01.txt   draft-ietf-genarea-milestones-tool-02.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Updates: May 28, 2011 Updates: July 11, 2011
raft-ietf-genarea-charter-tool raft-ietf-genarea-charter-tool
(if approved) (if approved)
Intended status: Informational Intended status: Informational
Expires: November 29, 2011 Expires: January 12, 2012
Requirements for a Working Group Milestones Tool Requirements for a Working Group Milestones Tool
draft-ietf-genarea-milestones-tool-01 draft-ietf-genarea-milestones-tool-02
Abstract Abstract
The IETF intends to provide a new tool to Working Group chairs and The IETF intends to provide a new tool to Working Group chairs and
Area Directors for the creation and updating of milestones for Area Directors for the creation and updating of milestones for
Working Groups. This document describes the requirements for the Working Groups. This document describes the requirements for the
proposed new tool, and it is intended as input to a later activity proposed new tool, and it is intended as input to a later activity
for the design and development of such a tool. for the design and development of such a tool.
Status of this Memo Status of this Memo
skipping to change at line 36 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at line 114 skipping to change at page 3, line 25
would only add or update milestones in the WGs for which they are the 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 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 can only add or update milestones for WGs of which they are
chairs. chairs.
The IETF Secretariat needs to be able to perform the same tasks as 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 WG chairs and ADs in order to fix problems or to make emergency
changes. changes.
The database will record the date and person who initiates any The database will record the date and person who initiates any
addition of, or change to, a milestone. 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 3. Updating, Adding, and Deleting Milestones
A WG chair needs to see all of the milestones for that chair's WG in 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 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 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 able to edit the due date, the finished date, the associated
Internet-Drafts, and the description of the milestone. The chair Internet-Drafts, and the description of the milestone. The chair
also needs to be able to delete existing milestones. also needs to be able to delete existing milestones.
A WG chair needs to be able to add one or more milestone records to 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 the database for their WG. The chair needs to be able to specify the
due date, zero or more associated Internet-Drafts, and 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 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. needs to be able to delete one or more existing milestones.
4. Approval of Milestone Additions and Changes 4. Automatic Acceptance 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 Each change made by a WG chair will be automatically accepted by the
tool. If either chair of a WG wants to revert a change, such as if a
change was made in error, those WG chairs can make a subsequent
change. It is likely that such change-and-revert cycles will happen
as WG chairs get used to the new tool.
The default settings at the time that this feature is launched will As noted in Section 2, any AD can change any milestone. Thus, if a
be that all actions other than changing due dates and asserting WG chair makes an erroneous change to a milestone and does not fix
completion require AD approval. These settings apply both to the error themselves, any AD may fix it for them. In practice, it
additions and changes made by WG chairs and by other ADs. would be better if those who make errors fix the errors themselves.
After this tool is launched, the IETF Secretariat will no longer need 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 to post a change to the database: the tool will do this without
intervention by the Secretariat. intervention by the Secretariat.
5. Mapping Milestones to Internet-Drafts 5. Mapping Milestones to Internet-Drafts
There is currently no requirement how WG milestones map to Internet- There is currently no requirement how WG milestones map to Internet-
Drafts. While most milestones map one-to-one with Internet-Drafts, Drafts. While most milestones map one-to-one with Internet-Drafts,
some milestones do not map to any Internet-Draft (such as those that some milestones do not map to any Internet-Draft (such as those that
skipping to change at line 271 skipping to change at page 6, line 32
[RFC6174] Juskevicius, E., "Definition of IETF Working Group [RFC6174] Juskevicius, E., "Definition of IETF Working Group
Document States", RFC 6174, March 2011. Document States", RFC 6174, March 2011.
11.2. Informative References 11.2. Informative References
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, December 2005.
Appendix A. Earlier Proposals Appendix A. Earlier Proposals
During the early discussion of the requirements for this document in The first few drafts of this document had a different model for
the IESG and among WG chair, there was not a common agreement about approval of milestone additions and changes. Those drafts said "The
how milestones management should be handled. responsible AD for a WG can specify whether any of the following
actions can be made without the AD approval for milestones associated
Some felt that WG chairs should be able to update their milestones with the WG: create new milestones, delete milestones, change
without any AD intervention, as long as the responsible AD was milestone descriptions, change milestone due dates, change which
informed after each change Internet-Drafts are associated with a milestone, assert that a
milestone is completed." In addition, the earlier drafts said that
Some felt that ADs need to approve every change before the change the default settings when the featured would have been launched would
is announced to the community be that all actions other than changing due dates and asserting
completion require AD approval.
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 The current draft has quite a different mechanism described in
for the new tool should match the requirements faced by WG chairs Section 4.
currently.
Some participants felt that the new tool should have a mode where Also, some participants in the early discussion felt that the new
milestones whose essence is that a particular draft is sent to the tool should have a mode where milestones whose essence is that a
IESG is automatically marked as complete when the draft's state is particular draft is sent to the IESG is automatically marked as
that it has gone to IETF consideration. However, there was a fair complete when the draft's state is that it has gone to IETF
amount of disagrement about the need for such a mode and whether it consideration. However, there was a fair amount of disagrement about
would end up restricting actions that should remain flexible. the need for such a mode and whether it would end up restricting
actions that should remain flexible.
Author's Address Author's Address
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
 End of changes. 11 change blocks. 
56 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/