summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6433.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6433.txt')
-rw-r--r--doc/rfc/rfc6433.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc6433.txt b/doc/rfc/rfc6433.txt
new file mode 100644
index 0000000..619740f
--- /dev/null
+++ b/doc/rfc/rfc6433.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Hoffman
+Request for Comments: 6433 VPN Consortium
+Updates: 6292 November 2011
+Category: Informational
+ISSN: 2070-1721
+
+
+ Requirements for a Working Group Milestones Tool
+
+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 Group charters. 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. This
+ document updates RFC 6292.
+
+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/rfc6433.
+
+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 6433 WG Milestones Tool Reqs November 2011
+
+
+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. A WG's
+ charter has several parts; one of those parts is the milestones.
+ Changing milestones currently requires Area Director (AD) approval,
+ but changing the charter text requires IESG approval.
+
+ Today, the tasks associated with creating and updating WG milestones
+ are performed manually by the Secretariat. Normally, WG chairs send
+ email to their AD requesting that milestones be created or updated.
+ They send mail to the their AD, or directly to the Secretariat, when
+ one or more milestone has been met. Apart from during WG creation,
+ these updates will be made through a separate tool after the
+ requirements in this document and in [RFC6292] are met.
+
+ 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 is intended to bring that discussion to a general
+ consensus for the requirements for the eventual tool.
+
+ Note that this document only discusses updating milestones that an
+ active WG is working against. As described in [RFC6292], when a WG
+ is rechartering, the new charter might also include new milestones.
+ The tool described here must not change the milestones that are
+ proposed for a WG recharter. That is, there must be two sets of
+ milestones kept by the Datatracker, one for the current WG charter
+ and one for a proposed recharter; the tool described here must only
+ affect the first of these two sets.
+
+ The IETF Administrative Oversight Committee (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 request for
+ proposals for the design and development of the tool. This document
+ was prepared at the request of the IAOC.
+
+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
+
+
+
+
+
+Hoffman Informational [Page 2]
+
+RFC 6433 WG Milestones Tool Reqs November 2011
+
+
+ the tool created by [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. (This is
+ the same model used in the Datatracker for other actions: it allows
+ one AD to carry the load for an AD who is temporarily unable to
+ perform such tasks.) 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 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. 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 change any milestone record
+ for that chair's WG. In each existing record, the chair needs to be
+ able to change 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.
+
+4. 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 milestone descriptions
+
+ o change milestone due dates
+
+
+
+
+
+
+Hoffman Informational [Page 3]
+
+RFC 6433 WG Milestones Tool Reqs November 2011
+
+
+ o change which Internet-Drafts are associated with a milestone
+
+ o assert that a milestone is no longer due
+
+ In addition to the above six actions, the tool must support
+ reordering of the list of milestones.
+
+ WG chairs can change milestone due dates, change which Internet-
+ Drafts are associated with a milestone, can assert that a milestone
+ is no longer due, for their WG, and reorder the list. When any of
+ these three actions are taken in 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 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 WG chair makes the proposed change, an email notification is
+ sent to the AD for the WG as well as to the WG's chairs.
+
+ When creating a milestone, it must be possible to set a due date. It
+ must also be to change the due date at any time.
+
+ When asserting that a milestone is no longer due, it must be possible
+ to provide an arbitrary short description phrase. Often this phrase
+ will be "Done", but other phrases such as "On hold" are also allowed.
+ When the Datatracker presents a milestone, the only information that
+ is expected to be associated with the provided phrase is that the
+ milestone is no longer due. The Datatracker will present the list of
+ milestones in the order given in the tool.
+
+ As noted in Section 2, any AD can take any of these six actions, as
+ well as reordering the list. After this tool is launched, the IETF
+ Secretariat will no longer need to post a change to the database
+ because the tool will do this without intervention by the
+ Secretariat; however, the Secretariat can take any of these six
+ actions as well.
+
+ When adding or editing a milestone, the AD or WG Chair must be able
+ to review and change the proposed change before committing the change
+ to the Datatracker. This will help prevent errors and reduce the
+ number of fixes that need to be made.
+
+ Once a day, the Datatracker will look for changes to the milestones
+ for a WG. If changes to milestones have been made in the past 24
+ hours, the Datatracker will send one message to the WG listing all
+ the changes from that period.
+
+
+
+Hoffman Informational [Page 4]
+
+RFC 6433 WG Milestones Tool Reqs November 2011
+
+
+ The Datatracker needs to have a method for ADs and the Secretariat to
+ see all the milestones that are pending approval. This list should
+ be sorted by the responsible AD.
+
+5. Mapping Milestones to Internet-Drafts
+
+ There is currently no mechanism to map WG milestones 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 WG chairs are CC'd on this
+ mail.
+
+ 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.
+
+
+
+
+Hoffman Informational [Page 5]
+
+RFC 6433 WG Milestones Tool Reqs November 2011
+
+
+ When a WG chair makes an Internet-Draft a WG work item, the
+ Datatracker will remind them that they may want to also add that
+ document to a milestone.
+
+7. Viewing Changes in Milestones
+
+ [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 [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 [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, or the list is reordered, the full set of
+ milestones is considered changed. A user should be able to easily
+ compare two 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 [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 [RFC6292], but it should be offered
+ to users in the same places as that feed is offered.
+
+ When a milestone is marked as no longer due, the Datatracker will
+ display the month and year that this change was made and will display
+ the status (such as "Done" or "On hold").
+
+8. Security Considerations
+
+ Creating a new tool for updating the milestones of WGs does not
+ affect the security of the Internet in any significant fashion.
+
+9. Acknowledgements
+
+ This document draws heavily on ideas from various WG chairs and ADs
+ on the wgchairs@ietf.org mailing list.
+
+
+
+
+
+Hoffman Informational [Page 6]
+
+RFC 6433 WG Milestones Tool Reqs November 2011
+
+
+10. References
+
+10.1. Normative References
+
+ [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.
+
+10.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 7]
+