[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 6175

Proto                                                    E. Juskevicius
Internet Draft                                                TrekAhead
Intended status: Informational                         October 14, 2010
Expires: April 14, 2011


       Requirements to Extend the Datatracker for IETF WG Chairs and
                                  Authors
           draft-juskevicius-datatracker-wgdocstate-reqts-07.txt


Abstract

   This document specifies requirements for new functionality to be
   added to the IETF Datatracker tool to make it possible for Working
   Group (WG) Chairs and their Delegates to input and update the status
   of the Internet-Drafts (I-Ds) associated with their WGs.  After
   these requirements are implemented, WG Chairs will be able to use
   the Datatracker to provide everyone with more information about the
   status and progression of WG I-Ds than is currently possible.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 April 14, 2011.

Copyright Notice

   Copyright (c) 2010 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.


Juskevicius             Expires April 14, 2011                 [Page 1]

Internet-Draft       WG Datatracker Requirements           October 2010


Table of Contents

   1. Introduction...................................................2
   2. Conventions Used In This Document..............................3
   3. General Requirements...........................................4
   4. Privilege and Access Control Requirements......................5
      4.1. For Everyone..............................................5
      4.2. For IETF Working Group Chairs.............................6
      4.3. For Delegates of IETF WG Chairs...........................7
      4.4. For IETF WG Document Shepherds............................7
      4.5. For the Responsible Area Director.........................9
      4.6. Role of the IETF Secretariat in Granting Permissions......9
   5. Inputting and Updating WG Document Status Information..........9
      5.1. WG I-D States.............................................9
      5.2. WG I-D Status Annotation Tags............................10
      5.3. WG I-D Protocol Write-ups................................11
   6. Special Requirements for Some WG I-D States and Conditions....12
      6.1. Call For Adoption By WG Issued...........................12
      6.2. Adopted by a WG..........................................13
      6.3. WG Document..............................................14
      6.4. Parked WG Document.......................................15
      6.5. Dead WG Document.........................................15
      6.6. In WG Last Call..........................................16
      6.7. WG Consensus: Waiting for Write-Up.......................17
      6.8. Submitted to IESG for Publication........................17
      6.9. Revised I-D Needed (annotation tag)......................17
   7. Automatic State Changes for I-Ds..............................18
   8. WG I-D Status Change Reporting Requirements...................18
   9. WG I-D Status Reporting Requirements..........................19
   10. Error Handling Requirements..................................20
   11. Security Considerations......................................20
   12. IANA Considerations..........................................21
   13. References...................................................21
      13.1. Normative References....................................21
      13.2. Informative References..................................21
   14. Acknowledgments..............................................21


1. Introduction

   The IETF Datatracker is a web-based system for managing information
   about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison
   statements and several other important aspects of the IETF process.
   [IDTRACKER]

   The Datatracker can track and report on the status of every I-D that
   has been submitted to the IESG for evaluation and publication.  In
   contrast, the tool currently has almost no ability to track the
   status of I-Ds that have not been submitted to the IESG. [WGDRAFTS]


Juskevicius             Expires April 14, 2011                 [Page 2]

Internet-Draft       WG Datatracker Requirements           October 2010


   Document authors and others have asked for more visibility into the
   status and progression of IETF Working Group (WG) drafts.

   This document specifies requirements to extend the Datatracker to
   enable status tracking and reporting for WG I-Ds.  After these
   requirements are implemented, WG Chairs will be able to use the
   Datatracker to provide everyone more information about the WG status
   of the I-Ds associated with their WGs than is currently possible.

2. Conventions Used In This Document

   The terms "WG I-D", "WG document", and "WG draft" are used
   synonymously throughout this document.  The same is true for the
   plural case of each term.

   A "WG draft" is an I-D that has achieved consensus for adoption as a
   work item by a WG (compared to an individual submission I-D that has
   not, or has not yet, achieved consensus).

   The terms "WG document" and "WG draft" are not intended to apply to
   any other document that may be reviewed, discussed, or produced by
   an IETF Working Group.  WG meeting materials such as Blue Sheets,
   agendas, jabber logs, scribe's notes, minutes, and presentation
   slides are not to be considered as "WG documents" or "WG drafts" in
   the context of this document.

   The phrase "WG status of an I-D" refers to the WG state that an I-D
   is in per the definitions in Section 4.2 of [WGDRAFTS].  This phrase
   does not refer to an I-D's availability status (e.g. "Expired",
   "Active", "Replaced by") as described in Section 3.1 of [WGDRAFTS],
   or to any of the IESG states used by IETF Area Directors (ADs) to
   describe the status of I-Ds they may be evaluating.  Note that this
   phrase encompasses all of the states that a WG I-D may be in, plus
   one more (viz. "Call For Adoption By A WG Issued").

   The phrase "I-D associated with a WG" is intended to describe two
   types of Internet-Drafts:

  - I-Ds that have been accepted as WG drafts; and

  - I-Ds that are being considered under the guidance of a WG Chair for
    adoption by a WG.

   An I-D having a filename that contains the string 'draft-ietf-'
   followed by a WG acronym is almost always a WG draft and is to be
   interpreted as being an "I-D associated with a WG" for the purposes
   of this document.




Juskevicius             Expires April 14, 2011                 [Page 3]

Internet-Draft       WG Datatracker Requirements           October 2010


   An I-D having a filename that includes the author's name and a WG
   acronym but does not include the string '-ietf-' may be a candidate
   for adoption by a WG and, if so, is also to be interpreted as being
   an "I-D associated with a WG" for the purposes of this document.

   The requirements specified in this document use English phrases
   ending with "(R-nnn)", where "nnn" is a unique requirement number.

   When used in the context of the requirements in this document, the
   key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", and "MAY" are to be interpreted as described in
   RFC 2119 [RFC2119].  RFC 2119 defines the use of these key words
   to help make the intent of standards track documents as clear as
   possible.  The same key words are used in this document to make the
   meaning of the requirements specified herein as clear as possible.

3. General Requirements

   The enhancements to be made to the Datatracker described in this
   document MUST be implemented in a manner that provides WG Chairs and
   the people they designate to act as their Delegates with the option
   to input and update the WG status of some, all, or none of the I-Ds
   associated with their WGs using the WG I-D states and I-D status
   annotation tags defined in [WGDRAFTS]. (R-001)  In other words, the
   implementation must not require that WG Chairs change their way of
   working, but only provide optional features.  WG Chairs must have
   the flexibility to use the enhancements to the Datatracker to track
   the WG status of their I-Ds as is most appropriate for them.

   To ensure that at least some WG status information is tracked for
   every I-D associated with a WG, the Datatracker must be enhanced to
   generate a few automatic state transitions for every WG I-D.  The
   requirements for this feature are specified in Section 7 of this
   document.

   Requirement R-001 SHALL NOT impair the ability of the Datatracker to
   track and display the availability state of any I-D. (R-002)  I-D
   availability states (e.g. "Active", "Expired", "Replaces") are
   described in Section 3.1 of [WGDRAFTS].

   The Datatracker SHALL NOT permit users other than a Working Group's
   Chairs (e.g. the Chairs of a different IETF WG) to update the WG
   status of a WG's documents through the regular Datatracker
   interface, unless the privileges to do so have been explicitly
   delegated to them by one of the WG's Chairs. (R-003)

   The user-interface to be provided by the Datatracker to WG Chairs
   (and their Delegates) to input the WG status of the I-Ds associated
   with their WGs SHOULD have a look and feel that is similar to the


Juskevicius             Expires April 14, 2011                 [Page 4]

Internet-Draft       WG Datatracker Requirements           October 2010


   interface currently used by ADs to identify the status of I-Ds under
   formal evaluation by the IESG. (R-004)

   Any new pages created to display the status of WG I-Ds SHOULD be
   designed to have a look and feel that is similar to the pages
   currently used by the Datatracker to display the status of I-Ds
   under formal evaluation by the IESG. (R-005)

   New javascript UI code and style sheets implemented to satisfy the
   requirements in this document SHOULD reuse or share existing code
   where practical so that when a change to the IESG status of an I-D
   is entered into the Datatracker, the WG status tracking for that I-D
   can benefit, and vice versa. (R-006)

   The Datatracker MUST date and timestamp every update to the WG
   status of an I-D that is associated with a WG and be able to use
   that information when it displays the status change history for the
   I-D. (R-007)  The WG status change history for an I-D MUST also
   identify the person or entity that updated the WG status of the I-D
   (e.g. one of the WG's Chairs, a Delegate, an AD, the System, the
   IETF Secretariat) and describe what changed (e.g. "WG State changed
   from 'a' to 'b'", "WG Annotation Tag 'x' Set (or Reset)"). (R-008)

   The inputting or updating of the WG status of an I-D SHALL NOT
   overwrite any previously archived status change history information
   for the I-D; every update to the WG status of an I-D MUST be added
   to the status change history log for the I-D. (R-009)

   WG I-D status tracking MUST be implemented per-draft, not per-WG.
   (R-010)

   WG I-D status tracking SHOULD be implemented as a new front-end to
   the Datatracker's existing IESG state machine [IESGIDSM]. (R-011)

   The Datatracker SHALL permit authorized users (e.g. WG Chairs,
   Delagates) to change the WG state of a draft independently from the
   IESG state of the same I-D and vice versa. (R-012)

4. Privilege and Access Control Requirements

4.1. For Everyone

   Everyone needs to be able to view information about the WG status of
   an I-D without logging on to the Datatracker.  Everyone SHALL be
   given 'read' access to WG I-D status information. (R-013)

   People who need to input, modify or update the WG status of an I-D
   (e.g. WG Chairs and their Delegates) need 'write' privileges; these
   users SHALL be required to log-on to the Datatracker using a


Juskevicius             Expires April 14, 2011                 [Page 5]

Internet-Draft       WG Datatracker Requirements           October 2010


   personal user-id and password (e.g. an IETF tools password) in order
   to gain 'write' access. (R-014)

4.2. For IETF Working Group Chairs

   After successfully logging on to the Datatracker as specified in
   Requirement R-014, WG Chairs:

  - SHALL be given full 'read' and 'write' privileges to input and
    update the WG status information for all of the I-Ds associated
    with their WGs; (R-015)

  - SHALL be able to able to choose from all of the WG I-D states and
    WG I-D status annotation tags defined in [WGDRAFTS] to describe the
    current WG status of the I-Ds associated with their WGs; (R-016)

  - SHAALL NOT be allowed to create new WG I-D states or state names;
    (R-017)

  - SHALL NOT be allowed to update or modify information which is not
    related to the WG status of an I-D (e.g. IANA status, RFC-Editor
    status, IESG status); (R-018)

  - SHALL be able to designate a maximum of three people to act as
    their Delegates to input and update the WG status of the I-Ds
    associated with each of their WGs; (R-019)  A suitable way to
    specify a Delegate may be to use the individual's current e-mail
    address, but the delegation MUST be to the individual identified by
    the login credentials used by the Datatracker at any given time
    rather than to an e-mail address; (R-020)  Individuals must be able
    to update their e-mail addresses in the future without breaking the
    delegation specified in Requirement R-019;

  - SHALL be able to designate a maximum of three different people to
    act as their Delegates in a different WG if a WG Chair is also
    responsible for the different WG; (R-021)

  - SHALL be able to designate people who have other roles in the IETF
    process (e.g. are Chairs of different WGs, are ADs in a different
    Area) to be their Delegates; (R-022)

  - SHALL be able to review and change their Delegates; (R-023)

  - SHALL be able to input or upload Document Shepherd protocol write-
    ups for all of the I-Ds associated with their WGs; (R-024)

  - SHALL be able to designate themselves as the Document Shepherds for
    some or all of the I-Ds in their WGs; (R-025)



Juskevicius             Expires April 14, 2011                 [Page 6]

Internet-Draft       WG Datatracker Requirements           October 2010


  - SHALL be able to designate other people to be Document Shepherds
    for one or more of their WG I-Ds if this role will not be performed
    by the WG Chairs; (R-026)  A suitable way to designate people to be
    the Document Shepherds may be to use their e-mail addresses, but
    the delegation MUST be to the individuals identified by the login
    credentials used by the Datatracker at the time, rather than to the
    e-mail addresses; (R-027)  The Datatracker MUST be able to maintain
    an individual's designation as a Delegate per R-026 in the event
    that the person changes their e-mail address in the future; (R-028)

  - SHALL be warned in real-time (e.g. via the Datatracker's regular
    user-interface) if a person they try to designate as a Delegate or
    Document Shepherd does not have the necessary login credentials for
    the Datatracker; (R-029)  The Datatracker SHALL then allow the WG
    Chairs to confirm the original designee or to pick another. (R-030)

  - SHALL be able to review and change the people designated to be
    Document Shepherds for each of their WG I-Ds. (R-031)

  - SHOULD be able to access the same user-interfaces the Datatracker
    provides to their Delegates and Document Shepherds in order to
    mentor or coach them on how to input and update WG I-D status
    information in the Datatracker. (R-032).

4.3. For Delegates of IETF WG Chairs

   After successfully logging on to the Datatracker, the Delegates of
   WG Chairs (e.g. WG Secretaries) SHALL have the same privileges as
   their WG Chairs to input WG I-D status information and Document
   Shepherd protocol write-ups as specified in Requirements R-015 to
   R-018 inclusive, R-024 and R-025. (R-033)

   The Datatracker SHALL send an e-mail to the Chairs of the WG, the
   IETF Secretariat, and to a newly designated Delegate if the newly
   designated Delegate does not have a personal user-id and password to
   log-on to the Datatracker. (R-034)  The purpose of the e-mail is to
   confirm to the WG Chairs that the person they designated to be a
   Delegate needs to take action to obtain a personal user-id and
   password, and to inform the Delegate that he/she needs to take
   action (e.g. to contact the IETF Secretariat) to obtain their own
   user-id and password for the Datatracker.

4.4. For IETF WG Document Shepherds

   The IETF document shepherding process and the role of an IETF WG
   Document Shepherd is described in RFC 4858 [RFC4858].





Juskevicius             Expires April 14, 2011                 [Page 7]

Internet-Draft       WG Datatracker Requirements           October 2010


   The requirements in this Section describe the access privileges to
   be granted to a WG Document Shepherd who is not a WG Chair or a
   Delegate with the privileges specified in Section 4.3.

   Per Requirement R-014, each person designated to be a Document
   Shepherd for a WG draft needs to have their own personal user-id and
   password to log-on to the Datatracker.

   The Datatracker SHALL alert the WG Chairs, the IETF Secretariat, and
   the newly designated Document Shepherd (e.g. via e-mail) if a person
   newly designated as a Document Shepherd does not have a personal
   user-id and password to log-on to the Datatracker. (R-035)  The
   purpose of the e-mail is to confirm to the WG Chairs that the
   Document Shepherd needs to take action to obtain a personal user-id
   and password, and to inform the Document Shepherd that he/she needs
   to take action (e.g. to contact the IETF Secretariat) to obtain a
   personal user-id and password for the Datatracker.

   Document Shepherds need to be able to upload or input protocol
   write-ups into the Datatracker for the WG I-Ds assigned to them.
   They also need to be able to set and reset the WG I-D status
   annotation tag called "Doc Shepherd Follow-up Underway" as defined
   in Section 4.3.10 of [WGDRAFTS] for I-Ds in the "WG Consensus:
   Waiting for Write-Up" state.

   After successfully logging on to the Datatracker, Document Shepherds
   SHALL have restricted 'write' privileges to upload or input protocol
   write-ups for the WG I-Ds assigned to them when the I-Ds are in the
   "WG Consensus: Waiting for Write-Up" state. (R-036)

   Document Shepherds SHALL also have the ability to set and reset the
   WG I-D status annotation tag called "Doc Shepherd Follow-Up
   Underway" as defined in Section 4.3.10 of [WGDRAFTS]. (R-037)

   The "Doc Shepherd Follow-Up Underway" annotation tag should be set
   to indicate when the Document Shepherd has started work on a write-
   up for the document.  The absence or resetting of this annotation
   tag may indicate the protocol write-up has not yet been started, or
   has been put on-hold for some reason, or has been completed.  The
   log of set and reset operations performed on this annotation tag
   will provide insight into the status of the protocol write-up for a
   WG I-D.

   Section 5.3 describes how Document Shepherds may input or upload
   protocol write-ups to the Datatracker for the WG I-Ds assigned to
   them.





Juskevicius             Expires April 14, 2011                 [Page 8]

Internet-Draft       WG Datatracker Requirements           October 2010


4.5. For the Responsible Area Director

   After successfully logging on to the Datatracker, an AD SHALL have
   the same privileges as a WG Chair to input and update WG I-D status
   information, to designate Delegates and Document Shepherds. (R-038)
   An AD SHALL have the privileges specified in Requirement R-038 for
   every WG in his or her Area. (R-039)  ADs MUST also retain their
   existing privileges to input and update the IESG status of the I-Ds
   they are responsible for. (R-040)

   To minimize confusion, the Datatracker MUST make it easy for ADs to
   distinguish between their IESG-level privileges (to input or update
   the IESG status of an I-D) and the WG-level privilege they will
   obtain as a result of R-038 and R-039 for I-Ds associated with the
   WGs they are responsible for. (R-041)

4.6. Role of the IETF Secretariat in Granting Permissions

   The IETF Secretariat is involved in granting permissions to people
   who need to login to the Datatracker.

   Before granting permissions to update WG I-D status settings to a
   person who does not have them, the IETF Secretariat should verify
   that the person requesting the permissions is a WG Chair or an AD or
   has been delegated the authority to update WG I-D status information
   by one of the WG's Chairs or a Responsible AD.  The e-mails to be
   generated and sent by the Datatracker per Requirements R-034 and
   R-035 will alert the Secretariat that the granting of permissions of
   some new people will be needed.

5. Inputting and Updating WG Document Status Information

5.1. WG I-D States

   Requirements R-001, R-016 and R017 specify that the WG state of an
   I-D may only be described using the states defined in Section 4 of
   [WGDRAFTS].

   When a WG Chair or Delegate logs-on to the Datatracker to input or
   change the WG state of an I-D, the Datatracker SHOULD display the
   current state of the I-D, the length of time the document has been
   in its current state, the amount of time the I-D may continue to
   remain in its current state if this information is available (viz.
   per Requirements R-064 and R-083), and the most likely next WG state
   (or states) for the I-D. (R-042)  The Datatracker MAY use the WG I-D
   state machine illustrated in Section 4.1 of [WGDRAFTS] to identify
   the 'most likely next state' (or states) for an I-D that is
   associated with a WG. (R-043)



Juskevicius             Expires April 14, 2011                 [Page 9]

Internet-Draft       WG Datatracker Requirements           October 2010


   After displaying the information required by R-042, the Datatracker
   SHALL make it easy for the WG Chair or Delegate to select a next
   state for the I-D and to enter some text to explain the state change
   for the I-D's status change history. (R-044)  The Datatracker SHALL
   encourage the person who updates or changes the WG state of an I-D
   to provide some context for the status change by entering text to
   describe the change in the I-D's status change history log. (R-045)

   The Datatracker SHALL allow a WG Chair (or Delegate) to select the
   next state for an I-D from the 'most likely' next states described
   by Requirement R-043, or from any of the other WG I-D states (per
   Requirement R-016) if a different state change is required. (R-046)

5.2. WG I-D Status Annotation Tags

   WG I-D status annotation tags may be used to describe a condition
   that is affecting a document (e.g. why a WG I-D is in the state it
   is in) or to indicate an action needed to progress the document,
   however annotation tags do not change the state of WG I-Ds.

   Section 4.3 of [WGDRAFTS] defines the meaning and usage of the WG
   I-D status annotation tags to be added to the Datatracker.

   The Datatracker SHALL allow WG Chairs and their Delegates to set and
   reset each of the WG I-D status annotation tags defined in Section
   4.3 of [WGDRAFTS] for every I-D associated with their WGs. (R-047)

   WG I-D status annotation tags SHALL be able to be used one at a time
   or in combination with other annotation tags to describe the status
   of any I-D associated with a WG. (R-048)

   When a WG Chair, Delegate or Document Shepherd logs into the
   Datatracker to set or reset one or more WG I-D status annotation
   tags for the I-Ds they are responsible for, the Datatracker SHOULD
   display a summary of all annotation tag set/reset operations to date
   for those WG I-Ds, from the present time backwards, split by pages,
   and then guide the user to select one (or more) annotation tags to
   be set or reset. (R-049)  Note that Document Shepherds who are not
   WG Chairs may only set and reset the annotation tag called "Doc
   Shepherd Follow-up Underway" per Requirement R-037.

   The summary of annotation tag set/reset operations (required by
   R-049) SHALL also indicate when each annotation tag attached to the
   current state of each I-D was set or reset and the identity of the
   person or entity that set or reset each I-D status annotation tag.
   (R-050)

   The Datatracker SHALL allow more than one annotation tag to be set
   or reset per log-on, and the Datatracker SHALL encourage the user to


Juskevicius             Expires April 14, 2011                [Page 10]

Internet-Draft       WG Datatracker Requirements           October 2010


   input some text to explain why each annotation tag is being set or
   reset. (R-051)

5.3. WG I-D Protocol Write-ups

   The IESG currently requires a protocol write-up to be prepared for
   every WG I-D before the I-D is submitted to the IESG for evaluation.

   When a user (e.g. WG Chair, Document Shepherd) logs into the
   Datatracker to input or upload a protocol write-up for an I-D, the
   Datatracker SHOULD make it easy for the user to understand the
   current status of the protocol write-up for every I-D that he/she is
   responsible for. (R-052)  The Datatracker SHOULD indicate at least
   the date when the most recent protocol write-up was uploaded or
   inputted for each I-D and the identity of the person or entity that
   performed the upload or input operation. (R-053)

   After displaying the information required by R-053, the Datatracker
   SHALL provide the user with an interface to input or upload a
   protocol write-up for the I-Ds that he/she is responsible for, and
   to set or reset the "Doc Shepherd Follow-up Underway" annotation tag
   for I-Ds. (R-054)  The Datatracker SHALL encourage the user to set
   or reset the "Document Shepherd Follow-Up Underway" annotation tag
   before the end of each protocol write-up uploading or inputting
   session and to input some descriptive text (for context) to be
   stored in I-D's status change history log. (R-055)

   Per Requirement R-099, the Datatracker will send an e-mail to the
   author of a WG draft (and copy the WG Chairs and Delegates) when the
   protocol write-up for the I-D is loaded into the Datatracker.  A
   copy of the e-mail SHALL also be sent to the Document Shepherd if
   he/she is not the WG Chair (or Delegate) to confirm the protocol
   write-up for the I-D was successfully loaded into the Datatracker.
   (R-056)

   Recall that WG Chairs and their Delegates shall be able to input a
   protocol write-up for any of their WG drafts at any time per
   Requirements R-024 and R-033.

   If a Document Shepherd who is not a WG Chair or other Delegate
   attempts to upload or input a protocol write-up for an I-D that is
   not in the WG state called "WG Consensus: Waiting for Write-Up", the
   Datatracker SHOULD warn the Document Shepherd that it may be too
   early to input a write-up, and then direct the Document Shepherd to
   contact one of the WG's Chairs for guidance. (R-057)  The WG Chair
   may decide to move the I-D into the "WG Consensus: Waiting for
   Write-Up" state to enable the Document Shepherd to upload his/her
   protocol write-up, or the WG Chair may upload the protocol write-up
   as specified in Requirement R-024.


Juskevicius             Expires April 14, 2011                [Page 11]

Internet-Draft       WG Datatracker Requirements           October 2010


   Requirement R-032 specifies that WG Chairs should be able to access
   the Document Shepherd user-interface and call up a display of the
   same WG document protocol write-up status information that the
   Datatracker provides to each of a WG Chair's designated Document
   Shepherds.  This is to enable each WG Chair (or Delegate)_to be able
   to mentor new Document Shepherds and to review the workload assigned
   to each Document Shepherd.  WG Chairs (and their Delegates) who are
   logged into the Datatracker with their normal privileges SHALL be
   able to access the Document Shepherd user-interface without having
   to logout and log back into the Datatracker. (R-058)

6. Special Requirements for Some WG I-D States and Conditions

6.1. Call For Adoption By WG Issued

   The "Call For Adoption By WG Issued" state may be used to describe a
   draft that is being considered for adoption by an IETF WG.  An I-D
   in this state has not yet achieved consensus, preference or
   selection in a working group.

   This state may be used to describe an I-D that someone has asked a
   WG to consider for adoption if the WG Chair has agreed with the
   request.  This state may also be used to identify an I-D that a WG
   Chair asked an author to write specifically for consideration as a
   candidate WG item, and/or an I-D that is listed as a 'candidate
   draft' in the WG's charter. [WGDRAFTS]

   The Datatracker SHALL allow a WG Chair or Delegate to move an I-D
   into the "Call For Adoption By WG Issued" state in her or his WG if
   the I-D is not currently being considered for adoption in any other
   WG, is not yet adopted by any other WG, is not expired and if the I-
   D has not been withdrawn or 'replaced by' a different I-D; (R-059)
   an I-D can only be in the "Call For Adoption By WG Issued" state in
   one WG at a time.

   The Datatracker SHALL NOT change the WG status of an I-D that is in
   the "Call For Adoption By WG Issued" state until the I-D expires, or
   until the WG Chair (or Delegate) moves the I-D into a different
   state or until it is decided that the WG will not adopt the I-D,
   whichever comes first. (R-060)  In case a WG decides not to adopt an
   I-D that is in the "Call For Adoption By WG Issued" state, the
   Datatracker SHALL allow the WG Chairs (and Delegates) to cancel
   their interest in the I-D. (R-061)

   The Datatracker SHALL transition the state of an I-D that expires or
   is not adopted (per Requirement R-061) from the "Call For Adoption
   By A WG" state into a "NULL" state with respect to the WG state
   machine and then update the status change history log of the I-D



Juskevicius             Expires April 14, 2011                [Page 12]

Internet-Draft       WG Datatracker Requirements           October 2010


   accordingly. (R-062)  An I-D that is not adopted by a WG may revert
   back to having no stream-specific state in the Datatracker.

   If a different WG Chair (or Delegate) attempts to move an I-D into
   the "Call For Adoption By WG Issued" state in while the I-D is
   associated with another WG, the Datatracker will not allow the
   attempted state change to occur because of Requirement R-059. In
   this case, the Datatracker SHALL inform the WG Chair or Delegate in
   real-time (via the user-interface that he/she is logged into) that
   the I-D is currently associated with a different WG and that the
   state change they requested cannot be made at this time. (R-063)

   A WG Chair (or Delegate) who moves an I-D into the "Call For
   Adoption By WG Issued" state SHALL be able to, but not required to,
   specify a length of time the I-D may remain in this state. (R-064)
   The maximum length of time SHALL be able to be specified as a
   "number of weeks" however it MUST NOT be allowed to extend beyond
   the expiry date of the I-D. (R-065)  Other ways to specify this
   length of time MAY optionally be provided. (R-066)

   If an I-D is still in the "Call For Adoption By WG Issued" state
   when the length of time specified in R-064 runs out, the Datatracker
   SHALL send an e-mail to inform the WG Chairs and Delegates that the
   time has run out and that the I-D is still in "Call For Adoption By
   WG Issued" state. (R-067)  The purpose of this message is to remind
   the WG Chairs and Delegates that they had planned to make a decision
   on adopting the I-D by now.

6.2. Adopted by a WG

   The "Adopted by a WG" state describes an individual submission I-D
   that an IETF WG has agreed to adopt as one of its WG drafts.

   An individual I-D that is adopted by a WG may take weeks or months
   to be resubmitted by the author as a new (version-00) WG draft.

   WG Chairs who use this state will be able to clearly indicate when
   their WG has adopted an individual I-D.  This will facilitate the
   Datatracker's ability to correctly capture "Replaces" information
   for WG drafts and to capture correct "Replaced by" information for
   the individual I-Ds that are replaced by WG drafts.

   The Datatracker shall allow an individual submission I-D to be moved
   into the "Adopted by a WG" state if the I-D is not expired and it
   has not been withdrawn, been 'replaced by' another I-D, or been
   adopted by another IETF WG. (R-068)  When a WG Chair or Delegate
   moves an I-D into the "Adopted by a WG" state, the Datatracker SHALL
   confirm this state change via e-mail to the author of the I-D and to



Juskevicius             Expires April 14, 2011                [Page 13]

Internet-Draft       WG Datatracker Requirements           October 2010


   the Chairs and Delegates or the WG that adopted the I-D (per
   Requirement R-099).

   Requirement R-009 specifies that changes to the WG status of an I-D
   shall not overwrite any previously archived I-D status history
   information for the I-D.  All status change history information for
   an I-D needs to be preserved, including when an I-D is revised and
   subsequently approved for posting as a new version-00 "WG Document"
   having a different filename (viz. a filename that includes the
   string 'draft-ietf-' followed by a WG acronym).

6.3. WG Document

   The "WG Document" state describes an I-D that has been adopted by an
   IETF WG and is being actively developed.

   WG Chairs and their Delegates SHALL be allowed to move an I-D that
   is not associated with any other WG into the "WG Document" state in
   their WG unless the I-D has expired or been withdrawn or 'replaced
   by' another I-D or RFC. (R-069)

   Alternatively, WG Chairs may rely on the functionality specified in
   Requirement R-070 to automatically move a version-00 draft into the
   "WG Document" state.

   The Datatracker SHALL automatically place a new version-00 I-D into
   the "WG Document" state if a WG Chair approves the submission of the
   I-D for posting in the IETF document repository and if the filename
   of the I-D includes the string 'draft-ietf-wgname-'. (R-070)

   The Datatracker SHOULD encourage the WG Chair to input, confirm or
   correct the filename of the individual submission I-D that is being
   'replaced' (if any) by a new version-00 WG draft at the time that
   the WG Chair approves the posting of the new I-D. (R-071)

   The WG Chair (or Delegate) who approves or moves an I-D into the
   "WG Document" state for the first time SHALL be encouraged to input
   an "Intended Maturity Level" for the I-D as defined in Section 5 of
   [WGDRAFTS] if the Datatracker cannot automatically determine this
   information for some reason. (R-072)  The Datatracker SHALL allow
   the "Intended Maturity Level" to be changed after first being set,
   and the Datatracker SHALL allow a WG Chair or Delegate to enter this
   information at a later time if the "Intended Maturity Level" for an
   I-D could not be identified when the I-D was initially moved into
   the "WG Document" state. (R-073)

   The Datatracker SHALL allow WG Chairs and their Delegates to move an
   I-D into the "WG Document" state from any other WG I-D state (e.g.



Juskevicius             Expires April 14, 2011                [Page 14]

Internet-Draft       WG Datatracker Requirements           October 2010


   per Sections 3.2 and 4.1 of [WGDRAFTS]) if the I-D has not expired,
   been withdrawn or been 'replaced by' another I-D or RFC. (R-074)

   Under normal conditions, it should not be possible for an I-D to be
   in the "WG Document" state in more than one IETF WG at a time.  The
   Datatracker SHALL NOT allow a WG Chair or Delegate to move an I-D
   into the "WG Document" state in their WG if the I-D is already in
   some WG I-D state in a different WG. (R-075)

   An I-D that is in the "WG Document" state may be transferred from
   one WG to a different WG by a Responsible AD.  The Datatracker SHALL
   allow a Responsible Area Director to transfer an I-D from one WG to
   a different WG and it SHALL encourage the AD to input some text for
   the status change history log of the I-D to provide context for the
   transfer. (R-076)  If an AD transfers an I-D, the Datatracker SHALL
   send an e-mail to the author of the I-D and copy the Chairs and
   their Delegates and the Responsible ADs (for the WGs affected by the
   transfer) to inform them that the I-D has been transferred. (R-077)

6.4. Parked WG Document

   A "Parked WG Document" is an I-D that has lost its author or editor,
   is waiting for another document to be written or for a review to be
   completed, or cannot be progressed by the working group for some
   other reason.

   The Datatracker SHALL allow a Responsible AD to transfer a "Parked
   WG Document" that is not expired from one WG to a different WG and
   it SHALL encourage the AD to input some text for the status change
   history log of the I-D to provide context for the transfer. (R-078)

   If an AD transfers an I-D, the Datatracker SHALL send an e-mail to
   author of the I-D, to the WG Chairs and their Delegates, and to the
   Responsible ADs (of the WGs affected by the transfer of an I-D) to
   inform them the I-D has been transferred to a different WG. (R-079)

6.5. Dead WG Document

   A "Dead WG Document" is an I-D that has been abandoned.  Note that
   'Dead' is not always a final state for a WG I-D.  If consensus is
   subsequently achieved, a "Dead WG Document" may be resurrected,
   however a "Dead WG Document" that is not resurrected will eventually
   expire.

   The Datatracker SHALL allow a Responsible AD to transfer an I-D that
   is not expired from being in the "Dead WG Document" state in one WG
   to a non-dead state in different WG, and the Datatracker SHALL
   encourage the AD to input some text for the status change history
   log of the I-D to provide context for the transfer. (R-080)


Juskevicius             Expires April 14, 2011                [Page 15]

Internet-Draft       WG Datatracker Requirements           October 2010


   If an AD transfers an I-D under the conditions specified by
   Requirement R-080, the Datatracker SHALL send an e-mail to author of
   the I-D, the WG Chairs, Delegates and the Responsible ADs (for the
   WGs affected by the transfer) to inform them that the I-D has been
   transferred to a different WG. (R-081)

6.6. In WG Last Call

   A document that is in the "In WG Last Call" state is an I-D for
   which a Working Group Last Call (WGLC) has been issued, and is in
   progress.  Note that WG last calls are an optional part of the IETF
   WG process, per Section 7.4 of RFC 2418 [RFC2418].

   A WG Chair who decides to conduct a WGLC on an I-D may use the "In
   WG Last Call" state to track the progress of the WGLC.

   A WG Chair (or Delegate) SHALL be able configure the Datatracker to
   send a WGLC message to one or more mailing lists when he/she moves a
   WG draft into the "In WG Last Call" state and be able to select a
   different set of mailing lists for each I-D because some documents
   may need coordination with other WGs. (R-082)

   The Datatracker also needs to be able to send an e-mail after a
   specified period of time to remind or 'nudge' a WG Chair to conclude
   a WGLC and to determine a next state for the I-D.

   The WG Chair (or Delegate) who moves an I-D into the "In WG Last
   Call" state SHALL be required to specify a length of time for the
   WGLC. (R-083)  The amount of time SHALL be able to be expressed as a
   "number of weeks" but it SHALL NOT be allowed to extend beyond the
   expiry date of the I-D. (R-084)  Other measures of time (e.g. "until
   a specific date in the future") MAY optionally be supported. (R-085)
   The amount of time MUST be able to be changed after first being set.
   (R-086)

   If an I-D is still in the "In WG Last Call" state when the amount of
   time specified in R-084 or R-085 runs out, the Datatracker SHALL
   send an e-mail to inform the WG Chairs and Delegates that the I-D is
   still in the "In WG Last Call" state, and to remind them they had
   planned to conclude the WGLC by now. (R-087)

   Note that a WGLC may lead directly back into another WGLC for the
   same document.  For example, an I-D that completed a WGLC as an
   "Informational" document may need another WGLC if a decision is
   taken to convert the I-D into a standards track document.  The
   Datatracker MUST allow this to occur. (R-088)





Juskevicius             Expires April 14, 2011                [Page 16]

Internet-Draft       WG Datatracker Requirements           October 2010


6.7. WG Consensus: Waiting for Write-Up

   A document in the "WG Consensus: Waiting for Write-Up" state has
   essentially completed its development within the WG, and is nearly
   ready to be sent to the IESG for publication.  The last thing to be
   done is the preparation of a protocol write-up by the Document
   Shepherd.  The IESG requires that a protocol write-up be completed
   before publication of an I-D is requested.

   An I-D in the "WG Consensus: Waiting for Write-Up" state SHALL
   remain in this state until the WG Chair (or Delegate) moves the
   document to a different state. (R-089)

   The Datatracker SHOULD be configurable to send an e-mail to a WG's
   Chairs and Delegates after a specified period of time to remind or
   'nudge' them to check the status of the Document Shepherd's write-up
   for an I-D. (R-090)  This feature SHOULD look and feel similar to
   the way that Requirements R-064 to R-067 inclusive are implemented.
   (R-091)

6.8. Submitted to IESG for Publication

   This state describes a WG document that has been submitted to the
   IESG for publication and that has not been sent back to the WG for
   revision.  An I-D in this state may be under review by the IESG, or
   it may have been approved and be in the RFC Editor's queue, or it
   may have been published as an RFC.  Other possibilities exist too.
   The document may be "Dead" (in the IESG state machine) or in a "Do
   Not Publish" state.

   The Datatracker SHOULD look for the presence of WG I-D status
   annotation tags when a WG draft is moved into this state.  If there
   are any tags that have not been cleared or reset, the Datatracker
   SHOULD encourage the WG Chairs (or Delegates) in real-time to reset
   or clear any extraneous annotation tags. (R-092)

6.9. Revised I-D Needed (annotation tag)

   After an I-D is submitted to the IESG, it may be judged to need
   revision before it can be published as an RFC.  An AD or the IESG as
   a whole may return a document to a WG for revision.

   An I-D that needs revision may be identified when the Responsible AD
   appends the "Revised I-D Needed" annotation tag to the IESG state of
   the I-D.

   If an AD or the IESG as a whole sends an I-D back to a WG for
   revision (e.g. as described in Section 3.2 of [WGDRAFTS]), the WG's
   Chairs may decide to change the WG state of the I-D from "Submitted


Juskevicius             Expires April 14, 2011                [Page 17]

Internet-Draft       WG Datatracker Requirements           October 2010


   To IESG For Publication" to a different state and to append one or
   more WG I-D status annotation tags to the I-D (e.g. per Sections
   4.3.8 or 4.3.9 of [WGDRAFTS]).

   The Datatracker SHALL allow, but not require, the WG Chair or
   Delegate who attaches a "Revised I-D Needed" annotation tag to the
   WG status of an I-D to indicate the number of weeks they expect it
   will take for a revised document to be produced (R-093).  The
   Datatracker should also prompt the user to consider changing the WG
   state of the I-D from "Submitted to IESG for Publication" to
   something else (e.g. Parked WG Document, WG Document, Waiting for WG
   Chair Go-Ahead). (R-094)

   If a revised version of the I-D is not submitted to the WG before
   the time specified in R-093 elapses, the Datatracker SHALL send an
   e-mail to the WG's Chairs and Delegates to remind or 'nudge' them to
   follow-up on the revisions to the document. (R-095)

7. Automatic State Changes for I-Ds

   To reduce the amount of information that WG Chairs and Delegates
   need to input to the Datatracker, the tool must automatically
   generate the following WG state transitions:

  - The Datatracker will move a version-00 I-D into the "WG Document"
    state when a WG Chair approves the posting of an I-D that includes
    the string '-ietf-' in its filename (as specified in Requirement
    R-070; and

  - The Datatracker SHALL transition a draft into the WG state called
    "Submitted To IESG For Publication" at the same time that the I-D
    is moved into the "Publication Requested" state in the IESG state
    machine by an AD or the IETF Secretariat. (R-096)

8. WG I-D Status Change Reporting Requirements

   Everyone with 'write' access to WG I-D status information SHALL be
   able to obtain a summary display of all status changes made to the
   WG I-Ds they are responsible for, from the present time backwards,
   split by pages, after successfully logging-on to the Datatracker.
   (R-097)

   The Datatracker SHOULD provide a convenient way for WG Chairs to
   obtain a summary of all WG I-D status changes made on their behalf
   by their Delegates, from the present time backwards, and split by
   pages. (R-098)

   The Datatracker SHALL send an e-mail message to the authors of an
   I-D and to the Chairs and Delegates of the WG the I-D is associated


Juskevicius             Expires April 14, 2011                [Page 18]

Internet-Draft       WG Datatracker Requirements           October 2010


   with, whenever the WG status of the I-D is updated; the contents of
   the e-mail SHALL provide details about the change in the WG status
   of the document (e.g. the new state the I-D has been moved to and/or
   the names of any newly set or reset I-D status annotation tags), the
   date of the change in status, and an indication of who (or which
   entity) caused the change to the WG status of the I-D. (R-099)

9. WG I-D Status Reporting Requirements

   The Datatracker SHALL provide everyone with a convenient way to
   query the status of every document in an IETF WG and to see a
   display of the current status of some or all of the documents in the
   WG, including the Document Shepherd protocol write-ups for I-Ds that
   have been submitted to the IESG and the names of the Document
   Shepherds. (R-100)

   The Datatracker SHALL also provide everyone with the ability to
   search for the status of documents written by a specific author, or
   I-Ds in a specific WG I-D state or having a specific "Intended
   Maturity Level", or having a specific annotation tag attached.
   (R-101)

   The Datatracker's existing I-D status display pages SHOULD be
   modified to display at least the metadata and status information for
   an I-D that is associated with a WG as shown in the following sample
   page: (R-102)

     -----------------------------------------------------------------

     Document stream:          IETF
     I-D availability status:  Active / Expired / Withdrawn / RFC /
                               Replaces / Replaced by I-D or RFC (if
                               applicable)
     Last updated:             year-mm-dd (e.g. 2010-09-18)
     IETF WG status: *         Applicable WG state & name of WG or WGs
     Intended RFC status: **   Informational / Experimental / etc.
     Document shepherd: ***    Name of Document Shepherd (if assigned)
     IESG status:  ****        Name of applicable IESG state
     Responsible AD:           Name of the Responsible AD

     -----------------------------------------------------------------

    *    The "IETF WG status" SHALL display the current WG state of
          the I-D and the WG that the I-D is associated with, and any
          I-D status annotation tags that are currently set. (R-103)

    **   The "Intended RFC status" for I-Ds in the WG state called
          "Adopted for WG Info Only" SHOULD be displayed as "None".
          (R-104)


Juskevicius             Expires April 14, 2011                [Page 19]

Internet-Draft       WG Datatracker Requirements           October 2010


    **   The field called "Intended RFC status" SHOULD be renamed to
          "RFC status" when the Datatracker displays the status of a
          document that has been published as an RFC. (R-105)

    ***  This field SHOULD display the name of the person (or e-mail
          address of the person) designated as the Document Shepherd
          for the I-D, or be left blank if a Document Shepherd has
          not yet been designated. (R-106)

    ****  This field SHALL display the current IESG status of the
          document or the word "None" for documents that are not yet
          being tracked by the IESG. (R-107)



10. Error Handling Requirements

   Errors with respect to inputting or updating the status of a WG
   document are possible.

   Per Requirement R-009, the creation of new or updated status
   information cannot erase, overwrite or cause the deletion of any
   previously entered document status change history information.

   Errors in data entry by a WG Chair or Delegate should be corrected
   by a WG Chair or a Delegate taking action to update any erroneous
   status information in the Datatracker with correct information, so
   that the correct status of the I-D is displayed.  For example, a
   document that was accidentally placed into the wrong state can be
   moved into the correct state by the WG Chair (or Delegate), and a
   comment should be entered into the document's status change history
   log to explain what happened.

11. Security Considerations

   This document does not propose any new Internet mechanisms, and has
   no security implications for the Internet.

   This document does however contains specific requirements to add
   features to the IETF Datatracker to make it possible for a greater
   number of users to input and/or update status information about I-Ds
   associated with IETF WGs.  Enhancing the Datatracker may create an
   opening for new denial-of-service (DoS) attacks and/or attempts by
   malicious users to corrupt the information in the WG document status
   database.

   This document does not propose any specific requirements to mitigate
   DoS attacks on the Datatracker.



Juskevicius             Expires April 14, 2011                [Page 20]

Internet-Draft       WG Datatracker Requirements           October 2010


12. IANA Considerations

   This document does not require any new number assignments from IANA,
   and does not define any new numbering spaces to be administered by
   IANA.

   RFC-Editor: Please remove this section before publication.

13. References

13.1. Normative References

   [WGDRAFTS]  Juskevicius, E., "Definition of WG Document States",
               work in process, draft-ietf-proto-wgdocument-states-10,
               October 2010.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels', RFC 2119, March 1997.

   [RFC4858]   Levkowetz, H., et al., "Document Shepherding from
               Working Group Last Call to Publication", RFC 4858,
               May 2007.

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

13.2. Informative References

   [IDTRACKER] "The IETF Datatracker tool", Web Application:
               https://datatracker.ietf.org/, September 30, 2010.

   [IESGIDSM]  "Diagram of Main I-D States", Web Application:
               https://datatracker.ietf.org/images/state_diagram.gif,
               September 30, 2010.

   [TRCKREQTS] Levkowetz, H., and Mankin, A., "Requirements on I-D
               Tracker Extensions for Working Group Chairs",
               draft-ietf-proto-wgchair-tracker-ext-03,
               February 8, 2007.

14. Acknowledgments

   The author would like to thank Henrik Levkowetz and Allison Mankin
   for writing the original I-D [TRCKREQTS] that contained many good
   ideas and served as a foundation for this document.

   The author would also like to thank Henrik Levkowetz, Alfred Hoenes,
   Paul Hoffman and Subramanian (SM) Moonesamy for their ongoing
   support during the writing of this document.  Many of their comments


Juskevicius             Expires April 14, 2011                [Page 21]

Internet-Draft       WG Datatracker Requirements           October 2010


   and suggestions have been used by the author to revise and improve
   this document.

   The author also offers his gratitude to Russ Housley, Scott Bradner,
   Robert Sparks, Spencer Dawkins, and the WG Chairs and other IETF
   participants at the wgdtspec BOF at IETF 77 for their inputs,
   comments and suggestions, and Lars Eggert, Tim Polk, Robert Sparks,
   Ralph Droms, Adrian Farrel, Alexey Melnikov and Sean Turner for
   their comments, suggestions and DISCUSS points on the penultimate
   draft version of this document.

   This document was initially prepared using 2-Word-v2.0.template.dot.



   Author's Address

   Ed Juskevicius
   TrekAhead
   PO Box 491, Carp, ON
   CANADA

   Email: edj.etc@gmail.com




























Juskevicius             Expires April 14, 2011                [Page 22]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/