[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                             June 1, 2010
Expires: December 1, 2010


     Requirements to Extend the Datatracker for WG Chairs and Authors
           draft-juskevicius-datatracker-wgdocstate-reqts-03.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 December 1, 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 December 1, 2010                [Page 1]

Internet-Draft       WG Datatracker Requirements              June 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 the status of
   working group documents.  The functions to be added will enable IETF
   Chairs and others to more easily follow the progression of working
   group documents from their earliest stages and increase the amount
   of information available to all IETF participants about the status
   of working group Internet-Drafts.

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.............................5
      4.3. For Delegates of IETF WG Chairs...........................6
      4.4. For WG Document Shepherds.................................7
      4.5. For the Responsible Area Director.........................8
   5. Inputting and updating WG document status information..........8
      5.1. WG Document States........................................8
      5.2. WG Document Status Annotation Tags........................8
   6. Special requirements for some WG I-D states and conditions.....9
      6.1. Candidate WG Document.....................................9
      6.2. WG Document..............................................12
      6.3. In WG Last Call..........................................12
      6.4. WG Consensus: Waiting for Write-Up.......................13
      6.5. Submitted to IESG for Publication........................13
      6.6. Revised I-D Needed (annotation tag)......................13
   7. WG Status of I-Ds that are not updated by Chairs or Delegates.14
   8. WG document status change reporting requirements..............14
   9. WG document status reporting requirements.....................15
   10. Error handling requirements..................................15
   11. Security Considerations......................................16
   12. IANA Considerations..........................................16
   13. References...................................................16
      13.1. Normative References....................................16
      13.2. Informative References..................................16
   14. 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 December 1, 2010                [Page 2]

Internet-Draft       WG Datatracker Requirements              June 2010


   The Datatracker can be used to obtain a lot of information about the
   status and progression of Internet-Drafts that have been sent to the
   IESG for review and publication.  In contrast, the Datatracker can
   only provide a little information about the status of any I-D that
   has not been sent to the IESG; the Datatracker can only report on
   the availability status of an I-D (e.g., Expired, Active, Replaced,
   Withdrawn, published as an RFC) and identify if an I-D has been
   adopted as an IETF working group (WG) document.

   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 provide detailed information about
   the working group status of I-Ds, and to manage working group I-Ds
   from their earliest stages.  The goal is to allow document authors
   (and others) to obtain more visibility into the status of I-Ds
   adopted by WGs and to increase the amount of information about the
   status of any I-D in any IETF WG for the benefit of all IETF
   participants.

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.

   This document specifies new functions and features to be added to
   the IETF Datatracker tool to make it possible for IETF WG Chairs
   and/or their delegates to indicate the status of WG documents.  When
   used in the context of the requirements in this document, the key
   words "MUST", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT" 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 implementation requirements
   for extending the Datatracker as clear as possible.

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






Juskevicius            Expires December 1, 2010                [Page 3]

Internet-Draft       WG Datatracker Requirements              June 2010


3. General requirements

   The Datatracker needs to be enhanced to make it possible for IETF WG
   Chairs and/or their delegates to provide all IETF participants with
   improved visibility into the status and progression of the Internet-
   Drafts in their working groups. (R-001)

   The Datatracker SHALL NOT permit users other than a working group's
   Chairs (such as for instance other Chairs, Area Directors, or IETF
   Secretariat staff) to change information about the status of a
   working group's documents through the regular Datatracker interface,
   unless the privileges to do so have been explicitly delegated to
   them by one of the working group's Chairs. (R-002)  (The fact that
   some IETF Secretariat staff have direct access to the Datatracker's
   database via administrative interfaces is a different matter; that
   is necessary in order to be able to correct problems that cannot be
   corrected otherwise).

   The enhancements made to the Datatracker SHOULD maintain the current
   look or feel of the tool as much as possible for document status
   entry, querying, and reporting. (R-003)  The goal is to add new
   functionality to the Datatracker, 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
   evaluation by the IESG. (R-004)

   All 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
   evaluation by the IESG. (R-005)

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

   The Datatracker SHALL provide IETF WG Chairs (and the people they
   designate to act as their delegates) with the flexibility to
   manually enter and/or update the WG status of all Internet-Drafts
   associated with their working groups, or just a subset of the I-Ds,
   or none of the I-Ds. (R-007)

   The following two examples clarify requirement R-007:

  - the Chairs (and/or their delegates) of a newly chartered working
    group may choose to manually update the status of every working



Juskevicius            Expires December 1, 2010                [Page 4]

Internet-Draft       WG Datatracker Requirements              June 2010


    group I-D to provide maximum transparency to the IETF community and
    to manage the progress of the I-Ds within the working group;

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

   If the Chairs of a WG decide *not* to manually enter or update the
   status of one or more of their working group documents, the
   Datatracker will be able to provide automatic transitions to a few
   WG document states based on information already available to it.
   For instance, an I-D can be automatically placed in the "WG
   Document" state when it is adopted as a WG document, and a
   transition into the WG state called "Submitted to IESG for
   Publication" can be generated when the I-D is moved into the IESG
   state called "Publication Requested".  The requirements for this
   feature are specified in Section 7.

   The WG document states added to the Datatracker MUST be implemented
   as a new state machine that is separate from the existing IESG
   document status state machine. (R-008)  The state that a working
   group I-D is in, in each state machine, MUST be able to be
   independently updated by the authorized users of each state machine.
   (R-009)

4. Privilege and Access Control requirements

4.1. For everyone

   Every IETF participant SHALL be able to obtain information about the
   status of a working group document without being required to log-on
   to the Datatracker. (R-010)  Everybody should to have 'read' access
   to working group document status information.

   People who need to input, modify or update the status of a working
   group document will need '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) in order to gain 'write'
   access. (R-011)

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) in order
   to gain 'write' access. (R-012)





Juskevicius            Expires December 1, 2010                [Page 5]

Internet-Draft       WG Datatracker Requirements              June 2010


   After successfully logging on to the Datatracker, IETF WG Chairs:

  - SHALL be given full 'read' and 'write' privileges to input and
    update information about the working group status of all I-Ds
    associated with the Chairs' working groups; (R-013)

  - SHALL be able to use all of the WG document states and status
    annotation tags defined in [WGDRAFTS] to describe the status of the
    I-Ds associated with their working groups; (R-014)

  - SHALL be given the option to select a subset of the WG document
    states defined in [WGDTAFTS] to be used to describe the status of
    I-Ds in their WGs; (R-015)

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

  - SHALL be able to designate one or more people to act as delegates
    to input and/or update the working group status of I-Ds associated
    with the Chair's working group; (R-017)

  - SHALL be able to identify if he/she would like the IETF Secretariat
    to act as a delegate for the working group (i.e., to input or
    update WG document status information on the Chair's behalf);
    (R-018)

  - SHALL be able to identify if he/she would like the Responsible Area
    Director to be able to update WG document status information in the
    Chair's WG; (R-019)

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

  - 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-022)  The identifier for the
    Document Shepherd SHOULD be the person's e-mail address. (R-023)

4.3. For Delegates of IETF WG Chairs

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





Juskevicius            Expires December 1, 2010                [Page 6]

Internet-Draft       WG Datatracker Requirements              June 2010


   Every person designated to be the delegate of an IETF working group
   Chair MUST have a personal user-id and password to log-on to the
   Datatracker. (R-025)

   The Datatracker SHOULD alert the WG's Chairs, the IETF Secretariat,
   and the newly designated delegate (e.g., via e-mail) if the person
   newly designated as a delegate of a Chair does not have a personal
   user-id and password to log-on to the Datatracker. (R-026)  This
   will inform the Chairs 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 (e.g., contact the IETF
   Secretariat) to obtain a personal user-id and password for the
   Datatracker.

   Before granting permissions to update WG document status settings to
   a person who does not have them, the IETF Secretariat should verify
   the person requesting the permissions is a WG Chair or has been
   delegated the authority to update the document states for the WG by
   one of the WG's Chairs.  In order to update the status of a WG's
   documents, a user will need to be granted the permissions to perform
   WG document status changes in general, and to be authorized by one
   of the WG's Chairs to update the status of the WG documents.

4.4. For WG Document Shepherds

   The requirements in this Section describe the access privileges to
   be granted to a WG Document Shepherd who is not a Chair of the WG or
   one of the Chair's delegates per Section 4.3.

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

   Every person designated to be a Document Shepherd for a working
   group draft MUST have a personal user-id and password to log-on to
   the Datatracker. (R-027)  A Document Shepherd who does not have a
   personal user-id and password will need to obtain one (e.g., by
   contacting the IETF Secretariat).

   A Document Shepherd SHALL have restricted 'write' privileges to
   modify and update WG status information for an I-D in the "WG
   Consensus: Waiting for Write-Up" state. (R-028)

   A Document Shepherd SHALL be allowed to upload and modify the
   protocol write-up for an I-D that is in the "WG Consensus: Waiting
   for Write-Up" state. (R-029)

   The Document Shepherd SHALL also be granted access to set and reset
   the document status annotation tag called "Doc Shepherd Follow-Up



Juskevicius            Expires December 1, 2010                [Page 7]

Internet-Draft       WG Datatracker Requirements              June 2010


   Underway" (as defined in Section 3.5.12 of [WGDRAFTS]) when an I-D
   is in the "WG Consensus: Waiting for Write-Up" state. (R-030)

   The setting of the "Doc Shepherd Follow-Up Underway" annotation tag
   will indicate the Document Shepherd has started work on the write-up
   for the document.  The absence or resetting of this annotation tag
   (for an I-D in the "WG Consensus: Waiting for Write-up" state) will
   indicate the write-up has not yet been started, or has been put on-
   hold for some reason.

4.5. For the Responsible Area Director

   The Datatracker SHALL allow an IETF Area Director to update the WG
   status information for the I-Ds in a WG that he/she is responsible
   for if the Chairs of the working group have indicated that they want
   the Area Director to have this ability in their WG. (R-031)

5. Inputting and updating WG document status information

5.1. WG Document States

   The state of an IETF working group document (which a Chair has
   decided to track using the Datatracker) may only be described using
   the working group document states and state names specified in
   Section 3.3 of [WGDRAFTS]. (R-032)  The creation of ad hoc WG
   document states and/or state names will not be an option. (R-033)

   When a working group Chair or delegate logs-on to the Datatracker to
   update the WG status of an I-D, 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, the time remaining that the document
   may continue to remain in its current state (if that information is
   available), and the most likely next state (or states) that the
   document may transition into according to the WG document state
   machine. (R-034)  The Datatracker SHALL use the WG document state
   machine illustrated in Section 3.4 of [WGDRAFT] to identify the
   'most likely next state (or states)'. (R-035)  The Datatracker shall
   then prompt the WG Chair or delegate to select the next state for
   the I-D and to enter some text about the state change (into a
   comment log). (R-036)

   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. (R-037)

5.2. WG Document Status Annotation Tags

   When a working group Chair or delegate logs into the Datatracker to
   set or reset an annotation tag (used to describe a condition that


Juskevicius            Expires December 1, 2010                [Page 8]

Internet-Draft       WG Datatracker Requirements              June 2010


   may affect the state of a document), the Datatracker SHOULD provide
   a summary display of all annotation tag set/reset operations to
   date, from the present time backwards, split by pages, and then
   guide the Chair or delegate to select the one (or more) annotation
   tags to be set or reset. (R-038)

   The summary of previous annotation tag set/reset operations SHOULD
   include the date when each of the annotation tags were set or reset,
   the e-mail address of the person who set or reset each tag, and any
   text (e.g., from the document history or comment log) that explains
   why each tag was set or reset. (R-039)

   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 input some text into a comment log to explain why the
   annotation tag is being set or reset. (R-040)

6. Special requirements for some WG I-D 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-041)  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.

   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 in R-041 are met. (R-042)




Juskevicius            Expires December 1, 2010                [Page 9]

Internet-Draft       WG Datatracker Requirements              June 2010


   Requirements R-043 to R-057 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-041 and R-042 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 takes an
    interest in the same candidate document should not create a problem
    or a coordination headache for any other WG Chair or delegate.

  The code to be written 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 maximum 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 time runs out, unless someone logs-on
    to the Datatracker and moves the document into some other state
    first.

   Requirements R-043 to R-057 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 I-D may remain in this state. (R-043)  The maximum length of
   time that an I-D may remain in the "Candidate WG Document" state
   SHOULD be specified as a number of weeks. (R-044)

   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 a candidate in another IETF working group and display the
   name of the other working group and the amount of time remaining


Juskevicius            Expires December 1, 2010               [Page 10]

Internet-Draft       WG Datatracker Requirements              June 2010


   that the document may remain in the candidate state. (R-045)  If,
   after reviewing this information, the different Chair (or delegate)
   decides to proceed, the Datatracker SHALL allow the Chair (or
   delegate) to identify the I-D as a "Candidate WG Document" for their
   working group, and to extend the number of weeks that the document
   may remain in the candidate state if more time is required. (R-046)

  - If the different Chair tries to extend the time beyond the expiry
    date of the I-D, the Datatracker SHALL adjust the time to coincide
    with the expiry date of the I-D and then inform the Chair. (R-047)
    The time that an I-D may remain in the "Candidate WG Document"
    state SHOULD NOT be allowed to exceed the date the document
    "Expires" (as specified the cover page of the I-D). (R-048)  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-049)

  - If the time remaining is not extended by the different Chair or
    delegate, the (already running) timer SHALL continue to count-down
    without interruption. (R-050)  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-051)

   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-052)  The e-mail will alert everyone the
   I-D is still in the candidate state, and inform everyone that the
   Datatracker will automatically move the I-D into the "Not adopted by
   a WG" state when time expires unless someone moves it to a different
   state first. (R-053)

   If a "Candidate WG Document" is adopted by 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-054)

   If a document is not adopted by any working group when time expires,
   the I-D 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 every WG Chair and
   delegate who was interested in the document to announce the document


Juskevicius            Expires December 1, 2010               [Page 11]

Internet-Draft       WG Datatracker Requirements              June 2010


   was not adopted and that its state has been changed automatically.
   (R-055)

   If a document is a "Candidate WG Document" in only one WG, the
   Datatracker shall allow the Chairs of that working group to change
   the state of the candidate I-D to "Not Adopted by a WG" at any time.
   (R-056)  The Datatracker SHALL NOT allow a document that is a
   candidate in more than one WG to be moved into the "Not Adopted by a
   WG state" before the timer specified in R-043 expires. (R-057)

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
   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 name of the I-D matches the conventional
   'draft-ietf-<wgname>-<subject>' naming. (R-058)

   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] if that information cannot be automatically determined by
   the Datatracker for some reason. (R-059)  The Datatracker SHALL
   allow the "Intended Maturity Level" to be changed after first being
   set. (R-060)

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

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-062)

   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 the document may
   remain in this state. (R-063)  The length of time SHOULD be


Juskevicius            Expires December 1, 2010               [Page 12]

Internet-Draft       WG Datatracker Requirements              June 2010


   specified as a number of weeks. (R-064)  The length of time in this
   state needs to be able to be changed after first being set. (R-065)

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

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 protocol write-up by the
   Document Shepherd.  The IESG requires that a protocol write-up be
   completed before publication of the I-D is requested.

   A document in this state SHOULD remain in this state until the Chair
   (or delegate) moves the document to a different state. (R-067)  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 Document Shepherd's write-up. (R-068)

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 any extraneous annotation tags. (R-069)

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 to indicate the number of weeks that it should take


Juskevicius            Expires December 1, 2010               [Page 13]

Internet-Draft       WG Datatracker Requirements              June 2010


   for the revised document to be produced (R-070).  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-071)

   The Datatracker should be programmed to send an e-mail to the WG's
   Chairs and delegates after the number of weeks specified in R-070 to
   remind or 'nudge' the Chairs and delegates to follow-up on the
   revisions to the document, unless the revised document is submitted
   before the time elapses. (R-072)

7. WG Status of I-Ds that are not updated by Chairs or Delegates

   Requirement R-007 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.
   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.

   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 that the state of an
    I-D is "WG Document" if the title of the I-D includes the name of
    the WG; (R-073)

  - The Datatracker SHALL indicate the availability status of an I-D in
    the "WG Document" state to be "Expired" if the document is more
    than six months old, and "Active" if the document is less than six
    months old (unless it has been withdrawn); (R-074)

  - The Datatracker SHALL automatically transition an I-D from the "WG
    Document" state into the "Submitted to IESG for Publication" state
    (in the WG state machine) if the WG Chair or delegate has not moved
    the document into this state by the time the I-D appears in the
    "Publication Requested" state in the IESG state machine. (R-075)

8. WG document status change reporting requirements

   Everyone with 'write' access to WG document status information
   SHOULD be able to obtain a summary display of all status changes
   made to the WG documents they are responsible for, from the present



Juskevicius            Expires December 1, 2010               [Page 14]

Internet-Draft       WG Datatracker Requirements              June 2010


   time backwards, split by pages, after successfully logging-on to the
   Datatracker. (R-076)

   The Datatracker SHOULD also provide a convenient way for WG Chairs
   to obtain a summary of all WG document status changes made on their
   behalf by their delegates, from the present time backwards, split by
   pages, after successfully logging-on to the Datatracker. (R-077)

   The Datatracker SHOULD send an e-mail message to the authors of an
   I-D whenever the WG status of the I-D is updated (e.g. automatically
   or by a WG Chair or delegate). (R-078)  The contents of the e-mail
   should provide details about the change in the 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 document status annotation tags).

9. WG document status reporting requirements

   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 current status of some or all of the documents
   in the working group, including the Document Shepherd protocol
   write-ups for I-Ds that have been submitted to the IESG. (R-079)

   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-080)

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 SHOULD NOT erase, overwrite or cause the
   deletion of any previously entered status information. (R-081)

   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 indicated.  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 may be entered into the document's history log to explain
   what happened.





Juskevicius            Expires December 1, 2010               [Page 15]

Internet-Draft       WG Datatracker Requirements              June 2010


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
   Internet-Drafts associated with IETF working groups.  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 working group document status database.

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

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

   [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-06,
               June 2010.

   [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/, May 31, 2010.


Juskevicius            Expires December 1, 2010               [Page 16]

Internet-Draft       WG Datatracker Requirements              June 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 for his ongoing
   support of this work, his dedication, and his many detailed comments
   and suggestions used by the author to refine and revise this
   document.

   The author also offers his gratitude to Russ Housley, Scott Bradner,
   Robert Sparks, Spencer Dawkins, Paul Hoffman, and the WG chairs and
   other IETF participants at the wgdtspec BOF at IETF 77 for their
   inputs, comments and suggestions.

   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 December 1, 2010               [Page 17]


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