[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                             May 14, 2010
Expires: November 14, 2010


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


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on November 14, 2010.

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 November 14, 2010                [Page 1]

Internet-Draft      Working Group Document States              May 2010


Abstract

   This document specifies requirements for new functionality to be
   added to the Datatracker tool to make it possible for IETF working
   group chairs and/or their delegates to indicate and update the
   status of working group documents.  It also describes additional
   functions to enable IETF chairs and others to more easily follow the
   progression of working group documents from their earliest stages.

Table of Contents

   1. Introduction...................................................2
   2. Conventions used in this document..............................3
   3. General requirements...........................................3
   4. Privilege and Access Control requirements......................5
      4.1. For everyone..............................................5
      4.2. For IETF Working Group Chairs.............................5
      4.3. For Delegates of IETF WG Chairs...........................6
      4.4. For WG Document Shepherds.................................6
      4.5. For the IETF Secretariat..................................7
      4.6. For the Responsible Area Director.........................7
   5. Inputting and updating WG document status information..........7
   6. Special requirements for some document states and conditions...9
      6.1. Candidate WG Document.....................................9
      6.2. WG Document..............................................11
      6.3. In WG Last Call..........................................12
      6.4. WG Consensus: Waiting for Write-Up.......................12
      6.5. Submitted to IESG for Publication........................13
      6.6. Revised I-D Needed (annotation tag)......................13
   7. Status of WG Drafts not tracked by Chairs or Delegates........13
   8. WG document status change reporting requirements..............14
   9. WG document status reporting requirements.....................15
   10. Error handling requirements..................................15
   11. "Nice to have" features......................................15
      11.1. Querying the status of more than one I-D at a time......15
   12. Security Considerations......................................16
   13. IANA Considerations..........................................16
   14. References...................................................16
      14.1. Normative References....................................16
      14.2. Informative References..................................17
   15. Acknowledgments..............................................17

1. Introduction

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


Juskevicius           Expires November 14, 2010                [Page 2]

Internet-Draft      Working Group Document States              May 2010


   The Datatracker can be used to obtain a lot of information about the
   status and progression of Internet-Drafts after they have been sent
   to the IESG for review and publication.  A current limitation of the
   tool is that it has very little information about the status of IETF
   working group documents.  The Datatracker can only discern the basic
   validity of an I-D (e.g. "I-D Exists", "Expired", "Active") before
   the I-D is sent to the IESG.

   This document specifies requirements for new functionality to be
   added to the Datatracker to make it possible for IETF working group
   chairs and/or their delegates to input and update the status of
   working group documents.  It also describes additional requirements
   to enable chairs to manage working group documents from their
   earliest stages, and to allow document authors (and others) to more
   easily understand the status of all working group drafts.

2. Conventions used in this document

   The phrase "working group document" is to be interpreted as being
   synonymous with "working group I-D" and "working group draft".  The
   same is true for the plural case of each phrase.

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

   Several words are used to specify requirements in this document.
   These words are often capitalised.   The key words "MUST", "MUST
   NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in [RFC2119].

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

3. General requirements

   The IETF Datatracker SHALL be enhanced to make it possible for IETF
   working group chairs and/or their delegates to indicate the status
   and progression of working group documents. (R-001)

   Enhancements made to the Datatracker should not radically change the
   look or feel of the tool for document status entry, querying, or



Juskevicius           Expires November 14, 2010                [Page 3]

Internet-Draft      Working Group Document States              May 2010


   reporting. (R-002)  The goal is to add new functionality to the
   tool, not to redesign the tool.

   - the user-interface for inputting WG document status information
     SHOULD have a look and feel that is similar to the interface used
     by IETF Area Directors to describe the status of documents under
     formal review by the IESG. (R-003)

   - any new pages added to Datatracker to display the status of
     working group documents SHOULD have a look and feel that is
     similar to the pages currently used to report the status of
     documents under formal review by the IESG. (R-004)

   The status of IETF working group documents SHALL be described using
   the document stream, document states, WG document state machine,
   working group document annotation tags, and intended document
   maturity levels specified in [WGDRAFTS]. (R-005)

   Each IETF working group chair SHALL be able to use the new features
   added to the Datatracker for some, all, or none of the documents in
   his or her working group. (R-006)  The following two examples
   clarify this requirement:

  - the chair of a newly chartered working group may choose to use the
    Datatracker to report the status of every WG document to provide
    maximum transparency to the IETF community and to manage the
    progress of the I-Ds within the working group;

  - the chair of a working group that has nearly completed its charter
    or milestones may decide to do otherwise.

   The WG document states added to the Datatracker SHALL be implemented
   with a new state machine that MUST be separate from the existing
   IESG document status state machine. (R-007)  The state that a
   working group document is in, in each state machine, MUST be able to
   be independently updated by the respective primes for each state
   machine (viz. WG chairs and their delegates, and Area Directors).
   (R-008)

   All of the requirements specified in sections 3 to 10 inclusive of
   this document MUST be considered in the design of enhancements to
   the Datatracker. (R-009)

   Consideration SHOULD also be given to the implementation of some or
   all of the 'nice to have' features described in section 11. (R-010)




Juskevicius           Expires November 14, 2010                [Page 4]

Internet-Draft      Working Group Document States              May 2010


4. Privilege and Access Control requirements

4.1. For everyone

   Every member of the IETF community SHOULD be able to obtain
   information about the status of a working group document without
   being required to log-on to the Datatracker.  Everybody SHALL be
   allowed "read" access to working group document status information.
   (R-011)

   People who need to input, modify or update the status of a working
   group document will require "write" privileges; these people SHALL
   be required to log-on to the Datatracker using a personal user-id
   and password (e.g. an IETF tools password). (R-012)  Not everyone
   will be given "write" access.

4.2. For IETF Working Group Chairs

   When an IETF working group chair decides to input, modify or update
   the status information for a document in his or her working group,
   he or she SHALL be required to log-on to the Datatracker using a
   personal user-id and password (e.g. IETF tools password). (R-013)

   After successfully logging-on to the Datatracker, the WG chair:

  - SHALL be given full "read" and "write" privileges to input and to
    update information about the status of all documents associated
    with his or her working group; (R-014)

  - SHALL be able to designate one or more people to be granted full
    "read" and "write" privileges to assist with inputting and/or
    updating the status of documents in the chair's working group;
    (R-015)

  - SHALL be able to designate the IETF Secretariat as an additional
    delegate to be granted full "read" and "write" privileges to input
    or update information about the status of documents in the chair's
    working group; (R-016)

  - SHALL be able to review and make changes to the list of designated
    delegates for his or her working group; (R-017)  The identifier for
    each delegate SHOULD be the person's e-mail address; (R-018)

  - SHALL be able to assign a person to be a Document Shepherd for a
    working group document if this role will not be performed by the
    chair or a designated delegate. (R-019)  The identifier for the
    Document Shepherd SHOULD be the person's e-mail address. (R-020)


Juskevicius           Expires November 14, 2010                [Page 5]

Internet-Draft      Working Group Document States              May 2010


4.3. For Delegates of IETF WG Chairs

   After successfully logging-on to the Datatracker, the delegate of an
   IETF working group chair SHALL be granted the same privileges as the
   working group chair to input and/or update working group document
   status information. (R-021)

   Every person designated to be the delegate of an IETF working group
   chair WILL REQUIRE a personal user-id and password to log-on to the
   Datatracker. (R-022)

   The Datatracker SHOULD alert the chair and the newly designated
   delegate (e.g. via e-mail) if the person newly designated as a
   delegate of the chair does not have a personal user-id and password
   to log-on to the Datatracker. (R-023)  This will inform the chair
   that the delegate needs to take action to obtain a personal user-id
   and password, and it will inform the delegate that he/she needs to
   take action to obtain a personal user-id and password for the
   Datatracker.

   Before granting a personal user-id and password to a delegate who
   does not have one, the Datatracker SHOULD verify the person making
   the request has been designated to be a delegate by a working group
   chair. (R-024)

4.4. For WG Document Shepherds

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

   Every person designated to be a shepherd for a working group draft
   WILL REQUIRE a personal user-id and password to log-on to the
   Datatracker. (R-025)  A Document Shepherd who does not have a
   personal user-id and password will need to obtain one.  Before
   granting a personal user-id and password to a Shepherd, the
   Datatracker SHOULD verify the person making the request has been
   designated as a Document Shepherd by the chair of a working group.
   (R-026)

   A Document Shepherd SHALL be granted restricted "write" privileges
   to modify and update status information about a WG document when it
   is in the "WG Consensus: Waiting for Write-Up" state. (R-027)

   A Document Shepherd SHALL be allowed to upload and modify the PROTO
   write-up for a working group document in the "WG Consensus: Waiting
   for Write-Up" state in the Datatracker. (R-028)



Juskevicius           Expires November 14, 2010                [Page 6]

Internet-Draft      Working Group Document States              May 2010


   The Document Shepherd SHALL also be granted access to set and reset
   the document status annotation tag defined in Section 3.5.12 of
   [WGDRAFTS] called "Doc Shepherd Follow-Up Underway" for an I-D in
   the state called "WG Consensus: Waiting for Write-Up". (R-029)

  - The setting the "Doc Shepherd Follow-Up Underway" annotation tag
    shall indicate the Document Shepherd has started work on the write-
    up for the document; (R-030)

  - The absence or resetting of this annotation tag for a document in
    the "WG Consensus: Waiting for Write-up" state shall indicate the
    write-up has not yet been started, or has been put on-hold for some
    reason. (R-031)

4.5. For the IETF Secretariat

   The IETF Secretariat SHALL be granted the same access privileges as
   the working group chair has, to input and/or update working group
   document status information if the Secretariat has been designated
   as a delegate of the working group chair for this purpose. (R-032)

4.6. For the Responsible Area Director

   The Datatracker SHALL identify the Responsible Area Director for
   each IETF working group that uses the Datatracker to track WG
   documents, and grant full "read" and "write"  privileges to the Area
   Director for information about the status of documents in the
   working groups that he or she is responsible for. (R-033)

5. Inputting and updating WG document status information

   The state of an IETF working group document (which a chair has
   decided to track using the Datatracker) SHALL only be described
   using the working group document states and state names specified in
   Section 3.3 of [WGDRAFTS]. (R-034)  The creation of ad hoc WG
   document states and/or state names WILL NOT be an option. (R-035)

   The normal progression of an I-D through an IETF working group SHALL
   be assumed to follow the sequence of state changes illustrated in
   the state machine diagram in Section 3.4 of [WGDRAFTS]. (R-036)

   After a working group chair or delegate logs-on to the Datatracker
   to update the state of a working group document, he/she SHOULD be
   informed of the current state of the document, the amount of time
   that the document has been in its current state and the time
   remaining that the document may continue to remain in its current
   state (if that information is available) and the most likely next


Juskevicius           Expires November 14, 2010                [Page 7]

Internet-Draft      Working Group Document States              May 2010


   state (or states) that the document may transition into according to
   the working group document state machine. (R-037)  He/she SHALL then
   be presented with an ability to select a most likely next state for
   the I-D and to enter some text about the state change (into a
   comment log). (R-038)

   As a general principle, the Datatracker should always prompt the
   person making a change to the status of a WG document to input some
   text to explain the reason for the status change.

   A working group chair or delegate should not be constrained by the
   "most likely next state" for any working group document.  A working
   group chair or delegate SHOULD be able to change the state of a
   working group document from its current state to any other state.
   (R-039)

   To facilitate R-039, the Datatracker SHOULD display a pull-down menu
   of every other possible WG document state and then prompt the chair
   (or delegate) to select the next state for the document from the
   pull-down menu. (R-040)  If the next state for the document is
   selected from the pull-down menu, the Datatracker SHALL REQUIRE the
   chair or delegate to enter some text into a comment log (e.g. for
   its WG document status change history log file) to explain the
   reason for the state change to the community. (R-041)

   When a working group chair or delegate logs into the Datatracker to
   set or reset an annotation tag (used to describe a condition that
   may affect the state of a document), the Datatracker SHOULD display
   a summary of the last 'n' substate changes made to the document
   (i.e. the last 'n' annotation tag set/reset operations, where 'n' is
   selectable) and then guide the chair or delegate to select the one
   (or more) annotation tags to be set or reset. (R-042)

  - A pull-down menu listing every possible working group document
    annotation tag MAY be displayed to facilitate R-042. (R-043)

  - The summary of recent tag set/reset operations SHOULD include the
    date when each of the last 'n' tags were set or reset, and the
    e-mail address of the person who set or reset each tag, and a link
    to any text (e.g. in a history or comment log) that explains why
    each tag was set or reset. (R-044)

   The Datatracker SHOULD allow one or more annotation tags to be set
   or reset per log-on and the Datatracker SHOULD prompt a chair or
   delegate to consider inputting text into a comment log to explain
   why a tag is being set or reset. (R-045)



Juskevicius           Expires November 14, 2010                [Page 8]

Internet-Draft      Working Group Document States              May 2010


6. Special requirements for some document states and conditions

6.1. Candidate WG Document

   The "Candidate WG Document" state may be used to describe an
   Internet-Draft that is being considered for adoption by an IETF
   working group.  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 to be considered by a working group,
    if the chair has agreed with the request;

  - an I-D that the WG chair asked an author to write; or

  - an I-D listed as a 'candidate draft' in the WG charter.

   The Datatracker SHALL allow a working group chair or delegate to
   identify an I-D as a "Candidate WG Document" for her or his WG if
   the I-D is not expired and the document has not yet been adopted by
   any IETF working group. (R-046)  The Datatracker SHOULD NOT allow a
   document that is expired or that already been adopted by an IETF
   working group to be moved into the "Candidate WG Document" state.
   (R-047)

   It is not uncommon for an author to 'shop' a document to multiple
   working groups hoping to get the draft adopted somewhere.  The
   Datatracker SHALL allow a document to be in the "Candidate WG
   Document" state for more than one working group at a time if the
   conditions specified by R-046 and R-047 are met. (R-048)

   Requirements R-049 to R-061 inclusive are intended to minimize the
   time needed by working group chairs and/or their delegates to manage
   documents placed into the "Candidate WG Document" state.  The
   objectives are as follows:

  - a chair (or delegate) should be able to identify a document as a
    candidate for adoption in her or his working group if requirements
    R-046 to R-048 inclusive are met;

  - a chair (or delegate) should not have to update the status of a
    candidate document again unless he/she decides to adopt the
    document in his/her working group; and

  - a second (or third, or fourth) chair or delegate who may take an
    interest in the same candidate document should not create a problem


Juskevicius           Expires November 14, 2010                [Page 9]

Internet-Draft      Working Group Document States              May 2010


    or a coordination headache for any other working group chair or
    delegate.

  The code to be designed to track documents in the "Candidate WG
  Document" State should be designed to operate as follows:

  - the first chair (or delegate) to move an I-D into the candidate
    state shall specify the length of time the I-D may be in the
    candidate state;

  - the second (or third or fourth ...) chair or delegate to identify
    the same document as a candidate in his/her working group will be
    informed of the current status of the document, and will be given
    an opportunity to extend the period of time that the I-D may remain
    in the candidate state; and

  - the Datatracker will automatically change the state of the document
    to "Not Adopted by a WG" when the time runs out, unless someone
    logs-on to the Datatracker and moves the document into some other
    state first.

   Requirements R-049 to R-061 are detailed specifications for the
   implementation of this feature.

   The first chair (or delegate) to move an I-D into the "Candidate WG
   Document" state SHALL be REQUIRED to specify a length of time that
   the document may remain in this state. (R-049)  The length of time
   that an I-D may remain in the "Candidate WG Document" state SHOULD
   be specified as a number of weeks, or a specific date in the future,
   or a milestone such as "two weeks after the end of the next IETF
   meeting". (R-050)

   Before a different chair (or delegate) is allowed to identify the
   same document as a candidate for adoption in his or her (different)
   working group, the Datatracker SHALL indicate that the document is
   already in the candidate state for another IETF working group and
   display the name of the other working group and the amount of time
   remaining that the document may remain in the candidate state.
   (R-051)  If, after reviewing this information, the different chair
   (or delegate) decides to proceed, the Datatracker SHALL allow the
   document to be identified as a "Candidate WG Document" for that
   different working group, and the Datatracker SHALL ask the chair (or
   delegate) if the amount of time the document may remain in the
   candidate state is sufficient. (R-052)

  - If the time remaining is not sufficient, the different chair (or
    delegate) SHALL be required to specify a longer time which the


Juskevicius           Expires November 14, 2010               [Page 10]

Internet-Draft      Working Group Document States              May 2010


    Datatracker SHALL use to reprogram its timer. (R-053)  The time
    SHOULD NOT be allowed to exceed the date the document "Expires" (as
    specified the cover page of the I-D). (R-054)  After the new date
    is entered and confirmed, the Datatracker SHALL send an e-mail to
    the chairs and delegates of every other working group (in which the
    document is already a candidate) to inform them the document has
    become a candidate in another WG and that the time the I-D may
    remain as a candidate has been extended to a new date of (whatever
    the new date is). (R-055)

  - If the time remaining is sufficient, the different chair or
    delegate SHALL be allowed to identify the document as a candidate
    for her/his working group and the (already running) timer SHALL
    continue to count-down without interruption. (R-056)  In this case,
    the Datatracker SHALL send an e-mail to the chairs and delegates of
    every other working group (in which the document is already a
    candidate) to inform them the document has become a candidate in
    (yet) another WG and to confirm that the amount of time the I-D may
    remain as a candidate has not been changed. (R-057)

   One week before expiry of the timer, the Datatracker SHALL send a
   nudge via e-mail to every chair and delegate in which the I-D is a
   "Candidate WG Document". (R-058)  The e-mail will alert everyone
   that the document is still in the candidate state, and that the
   Datatracker will automatically move the I-D into the "Not adopted by
   a WG" state unless someone moves it to a different state before the
   timer expires. (R-059)

   If a "Candidate WG Document" is adopted in a working group before
   the timer expires (e.g. if the state of the document is changed to
   "WG Document" in a working group), the Datatracker SHALL cancel the
   timer and send an e-mail to the every chair and delegate who had an
   interest in the document to inform them that the I-D has been
   adopted by the (insert name of the WG here) WG. (R-060)

   If a document is not adopted by any working group when the time
   expires, it will still be in the "Candidate WG Document" state.  In
   this case, the Datatracker SHALL automatically move the document
   into the "Not Adopted by a WG" state and send an e-mail to the every
   chair and delegate who was interested in the document to announce
   the document was not adopted and that its state has been
   automatically changed. (R-061)

6.2. WG Document

   A "WG Document" is an I-D that has been adopted by an IETF working
   group and is being actively developed.  Under normal conditions, it


Juskevicius           Expires November 14, 2010               [Page 11]

Internet-Draft      Working Group Document States              May 2010


   should not be possible for an Internet-Draft to be a "WG Document"
   in more than one working group at a time.

   The Datatracker SHALL allow a working group chair or delegate to
   identify an I-D as a "WG Document" in her or his WG if the I-D is
   not expired and if the document not yet been adopted by any other
   IETF working group. (R-062)

   The chair (or delegate) who moves an I-D into the "WG Document"
   state for the first time SHALL be REQUIRED to indicate the "Intended
   Maturity Level" for the document, as defined in Section 3.6 of
   [WGDRAFTS]. (R-063)

   A WG document may be transferred from one working group to another
   by the Responsible Area Director.  The Datatracker SHALL allow the
   Responsible Area Director to transfer an I-D from being a "WG
   Document" in one WG to the same state in a different WG. (R-064)

6.3. In WG Last Call

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

   A document "In WG Last Call" SHOULD remain in this state until the
   chair (or delegate) moves the I-D to a different state. (R-065)

   The chair (or delegate) who moves an I-D into the "In WG Last Call"
   state SHALL be REQUIRED to specify a length of time that the
   document may remain in this state. (R-066)  The length of time
   SHOULD be specified as a number of weeks. (R-067)

   One week before expiry of the timer, the Datatracker SHOULD send a
   nudge via e-mail to the chair and his/her delegates to remind or
   'nudge' the chair to conclude the WGLC and to determine the next
   state for the document. (R-068)

6.4. WG Consensus: Waiting for Write-Up

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



Juskevicius           Expires November 14, 2010               [Page 12]

Internet-Draft      Working Group Document States              May 2010


   A document in this state SHOULD remain in this state until the chair
   (or delegate) moves the document to the next state. (R-069)  The
   Datatracker SHOULD be programmable to send an e-mail to the chair
   after a specified period of time to remind or 'nudge' the chair to
   look into the status of the proto write-up. (R-070)

6.5. 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 working
   group for revision.  Under normal conditions, an I-D that has
   reached this state will have finished it tenure as a working group
   document.

   The Datatracker SHOULD look for the presence of annotation tags when
   a WG document is moved into this state.  If there are any tags that
   have not been cleared or reset, the Datatracker SHOULD send an e-
   mail to the WG chair to suggest the chair (or delegate) log-on to
   the Datatracker to clear the extraneous tags. (R-071)

6.6. 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 working group for revision.

   A document that needs revision may be identified when the chair,
   delegate, or the Responsible Area Director logs-on to the
   Datatracker to append one of the "Issue Raised - Revision Needed"
   annotation tags to the status of the document.  The Datatracker
   SHALL REQUIRE the person who attaches one of these annotation tags
   to a document which had been in the "Submitted to IESG for
   Publication" state to change the state of the document to something
   else (e.g. Parked WG Draft, WG Document, Waiting for WG Chair Go-
   Ahead) and to indicate a period of time that the document may remain
   in the new state. (R-072)

   The Datatracker SHOULD be programmable to send an e-mail to the
   chair and delegate after a specified period of time to remind or
   'nudge' the chair and delegates to follow-up on the revisions to the
   document. (R-073)

7. Status of WG Drafts not tracked by Chairs or Delegates

   Requirement R-006 provides each IETF WG chair with the freedom to
   use the WG document states defined in [WGDRAFTS] to indicate the
   status and progression of documents in his or her working group.


Juskevicius           Expires November 14, 2010               [Page 13]

Internet-Draft      Working Group Document States              May 2010


   The same requirement also allows each IETF WG chair to decide to
   *not* log-on to the Datatracker to manually input or update the
   status of drafts in her/his working group.

   The Datatracker MUST allow for the possibility that some WG chairs
   will not manually input or update the status of some WG drafts.
   (R-074)

   To provide some visibility into the status of WG documents that are
   not manually tracked by a WG chair or delegate, the Datatracker
   SHOULD be programmed to automatically indicate the following:

  - The Datatracker SHOULD automatically indicate the state of I-D to
    be "WG Document" if the title of the I-D includes the name of the
    WG and the I-D is not expired and the I-D has not been manually
    moved into some other state by a WG Chair or delegate within one
    week of its submission to the I-D repository. (R-075)  The
    Datatracker SHALL generate and send an e-mail to the WG chair and
    his/her delegates immediately after the submission of any I-D that
    includes the WG name in its title if the I-D is not already in one
    of the WG document states defined in [WGSTATES}. (R-076)

  - The Datatracker SHALL indicate that the status of an I-D that is in
    the "WG Document" state is to "Expired" if the document is more
    than six months old, and "Active" otherwise. (R-077)

  - The Datatracker SHALL automatically change the state of an I-D in
    the "WG Document" state to be "Submitted to IESG for Publication"
    in the WG state machine if the WG chair or delegate has not
    manually moved the document into this state by the time the
    Responsible Area Director identifies the I-D as being in the
    "Publication Requested" state in the IESG state machine. (R-078)

8. WG document status change reporting requirements

   Anyone with "write" access to WG document status information SHOULD
   be able to obtain a summary display of "everything that has changed
   with respect to the WG documents I am responsible for, since my last
   log-on" or "during the last 'n' weeks", where 'n' may be specified
   by the person who logged-on. (R-079)

   The Datatracker SHOULD provide a convenient way for a WG chair to
   obtain a summary of all status changes made to WG documents on
   his/her behalf by a delegate, since the last log-in by the chair or
   in the last 'n' weeks, where 'n' may be specified by the chair.
   (R-080)



Juskevicius           Expires November 14, 2010               [Page 14]

Internet-Draft      Working Group Document States              May 2010


9. WG document status reporting requirements

   The Datatracker SHALL provide a WG chair with an ability to create a
   list of all the drafts that he/she needs to follow in a single-page
   view. (R-081)   The drafts to be followed may be all from the same
   working group, or they may be from different working groups, and
   they may include individual documents as well. (R-082)

   The Datatracker SHALL provide everyone with a convenient way to
   query the status of every document in an IETF working group and to
   see a display of the status of some or all of the documents in the
   working group. (R-083)

   The Datatracker SHALL also provide everyone with the ability to
   search for documents written by a specific author, or I-Ds in a
   specific WG document state, or having a specific 'intended maturity
   level', or having a specific annotation tag attached. (R-084)

10. Error handling requirements

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

   As a general rule, changes to the status of a working group document
   should be added to a history for each document that the Datatracker
   should maintain for every working group.  The creation of new or
   updated status information MUST NOT erase, overwrite or cause the
   deletion of any previously entered status information. (R-085)

   Errors in data entry by a chair or delegate SHOULD be corrected by
   updating any erroneous status information in the Datatracker until
   the status of the document is correctly recorded. (R-086)  For
   example, a document that was accidentally placed into the wrong
   state can be moved into the correct state by the chair (or
   delegate), and a comment msy be entered into the document's history
   log to explain what happened.

11. "Nice to have" features

11.1. Querying the status of more than one I-D at a time

   Many members of the IETF community do not have a log-on user-id or
   password for the Datatracker.  They would appreciate having an
   ability to have the Datatracker display the status of more than one
   working group document at a time, in response to a single query.
   For example, people who volunteer to serve on drafting groups may be



Juskevicius           Expires November 14, 2010               [Page 15]

Internet-Draft      Working Group Document States              May 2010


   interested in the status of several different drafts, in more than
   one working group.

   A "nice to have" feature would be to allow anyone to set up a
   drafting group document status page (on the Datatracker) to display
   the status of more than one document at a time.  Each such page
   could be identified by a large random string of characters in a URL,
   and the Datatracker could have a garbage collection function to
   delete pages that have not been accessed in a long period of time
   (e.g. 6 months).

   The basic idea of this feature is to allow anyone to go to a page on
   the Datatracker and say "I want to create a status display page for
   a set of I-Ds".  After appropriate Q&A and/or selection of the
   drafts to be tracked, the Datatracker could confirm that it has
   created the requested status display page by saying "OK.  Whenever
   you wish to see the status of this group of drafts, go to:

   https://datatracker.ietf.org/pagegroups/07539aec572dfce01e81564999

12. Security Considerations

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

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



14. References

14.1. Normative References

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

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

   [RFC4858]   Levkowetz, H., et al., "Document Shepherding from


Juskevicius           Expires November 14, 2010               [Page 16]

Internet-Draft      Working Group Document States              May 2010


               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.


14.2. Informative References

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

   [PROTO]     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.


15. Acknowledgments

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

   The author would also like to thank Henrik Levkowetz, Scott Bradner,
   Robert Sparks, Spencer Dawkins, Russ Housley, Paul Hoffman, Andy
   Malis, other WG chairs and the participants in the wgdtspec BOF at
   IETF 77 for their comments and suggestions for requirements to
   extend the Datatracker.

   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 November 14, 2010               [Page 17]


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