    Internet Engineering Task Force (IETF)                    E. Juskevicius
    Request for Comments: 6175                                     TrekAhead
    Category: Informational                                       March 2011
    ISSN: 2070-1721

                     Requirements to Extend the Datatracker
                   for IETF Working Group Chairs and Authors

    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 document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Not all documents
       approved by the IESG are a candidate for any level of Internet
       Standard; see Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc6175.

    Juskevicius                   Informational                     [Page 1]

    RFC 6175               WG Datatracker Requirements            March 2011

    Copyright Notice

       Copyright (c) 2011 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (http://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.

    Table of Contents

       1. Introduction ....................................................3
       2. Conventions Used in This Document ...............................3
       3. General Requirements ............................................4
       4. Privilege and Access Control Requirements .......................6
          4.1. For Everyone ...............................................6
          4.2. For IETF Working Group Chairs ..............................6
          4.3. For Delegates of IETF WG Chairs ............................8
          4.4. For IETF WG Document Shepherds .............................8
          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 ..........10
          5.1. WG I-D States .............................................10
          5.2. WG I-D Status Annotation Tags .............................10
          5.3. WG I-D Protocol Writeups ..................................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 ...........................................14
          6.3. WG Document ...............................................14
          6.4. Parked WG Document ........................................16
          6.5. Dead WG Document ..........................................16
          6.6. In WG Last Call ...........................................16
          6.7. WG Consensus: Waiting for Writeup .........................17
          6.8. Submitted to IESG for Publication .........................18
          6.9. Revised I-D Needed (Annotation Tag) .......................18
       7. Automatic State Changes for I-Ds ...............................19
       8. WG I-D Status Change Reporting Requirements ....................19
       9. WG I-D Status Reporting Requirements ...........................20
       10. Error Handling Requirements ...................................21
       11. Security Considerations .......................................21
       12. References ....................................................21
       13. Acknowledgments ...............................................22

    Juskevicius                   Informational                     [Page 2]

    RFC 6175               WG Datatracker Requirements            March 2011

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

       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 with 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 "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 [RFC6174].  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 [RFC6174], 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 WG Issued").

    Juskevicius                   Informational                     [Page 3]

    RFC 6175               WG Datatracker Requirements            March 2011

       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.

       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 [RFC6174] (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.

    Juskevicius                   Informational                     [Page 4]

    RFC 6175               WG Datatracker Requirements            March 2011

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

       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
       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 provided by the Datatracker to display the status of I-Ds
       under formal evaluation by the IESG (R-005).

       New javascript user interface 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 the change (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).

    Juskevicius                   Informational                     [Page 5]

    RFC 6175               WG Datatracker Requirements            March 2011

       The Datatracker SHALL permit authorized users (e.g., WG Chairs,
       Delegates) 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 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 [RFC6174] to describe the
          current WG status of the I-Ds associated with their WGs (R-016).

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

       -  SHALL NOT be allowed to update or modify information that 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.

    Juskevicius                   Informational                     [Page 6]

    RFC 6175               WG Datatracker Requirements            March 2011

       -  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
          writeups 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).

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

    Juskevicius                   Informational                     [Page 7]

    RFC 6175               WG Datatracker Requirements            March 2011

    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 writeups 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
       notify 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].

       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 notify 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
       writeups 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 Followup Underway" as defined in Section
       4.3.10 of [RFC6174] for I-Ds in the "WG Consensus: Waiting for
       Writeup" state.

    Juskevicius                   Informational                     [Page 8]

    RFC 6175               WG Datatracker Requirements            March 2011

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

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

       The "Doc Shepherd Followup Underway" annotation tag should be set to
       indicate when the Document Shepherd has started work on a writeup for
       the document.  The absence or resetting of this annotation tag may
       indicate the protocol writeup 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 writeup for a WG I-D.

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

    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
       for which they are responsible (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 privileges they will
       obtain as a result of R-038 and R-039 for I-Ds associated with the
       WGs for which they are responsible (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 log in 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

    Juskevicius                   Informational                     [Page 9]

    RFC 6175               WG Datatracker Requirements            March 2011

       R-035 will alert the Secretariat that the granting of permissions to
       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
       [RFC6174].

       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 [RFC6174] to identify the
       'most likely next state' (or states) for an I-D that is associated
       with a WG (R-043).

       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 [RFC6174] 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 [RFC6174] for every I-D associated with their WGs (R-047).

    Juskevicius                   Informational                    [Page 10]

    RFC 6175               WG Datatracker Requirements            March 2011

       WG I-D status annotation tags SHALL be able to be used individually
       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 in to 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
       Followup 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 logon, and the Datatracker SHALL encourage the user to
       input some text to explain why each annotation tag is being set or
       reset (R-051).

    5.3.  WG I-D Protocol Writeups

       The IESG currently requires a protocol writeup 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 in to the
       Datatracker to input or upload a protocol writeup for an I-D, the
       Datatracker SHOULD make it easy for the user to understand the
       current status of the protocol writeup for every I-D for which he/she
       is responsible (R-052).  The Datatracker SHOULD indicate at least the
       date when the most recent protocol writeup 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 writeup for the I-Ds that he/she is responsible for, and to
       set or reset the "Doc Shepherd Followup Underway" annotation tag for
       I-Ds (R-054).  The Datatracker SHALL encourage the user to set or
       reset the "Document Shepherd Followup Underway" annotation tag before
       the end of each protocol writeup 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).

    Juskevicius                   Informational                    [Page 11]

    RFC 6175               WG Datatracker Requirements            March 2011

       Per Requirement R-100, the Datatracker will send an e-mail to the
       author of a WG draft (and carbon copy (CC) the WG Chairs and
       Delegates) when the protocol writeup 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) as notification
       that the protocol writeup 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 writeup 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 writeup for an I-D that is not
       in the WG state called "WG Consensus: Waiting for Writeup", the
       Datatracker SHOULD warn the Document Shepherd that it may be too
       early to input a writeup, 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
       Writeup" state to enable the Document Shepherd to upload his/her
       protocol writeup, or the WG Chair may upload the protocol writeup as
       specified in Requirement R-024.

       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 writeup 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 in to the Datatracker with their normal privileges SHALL be
       able to access the Document Shepherd user interface without having to
       logout and log back in to 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

    Juskevicius                   Informational                    [Page 12]

    RFC 6175               WG Datatracker Requirements            March 2011

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

       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 has not
       been withdrawn (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,
       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 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 in to) 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 is not required to, specify
       a length of time the I-D may remain in this state (R-064).  It SHALL
       be possible to specify the maximum length of time as a "number of
       weeks"; however, the maximum length 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

    Juskevicius                   Informational                    [Page 13]

    RFC 6175               WG Datatracker Requirements            March 2011

       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 submission 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 submission I-D.  This will
       facilitate the Datatracker's ability to correctly capture "Replaces"
       information for WG drafts and "Replaced by" information for the
       individual submissions 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 the Chairs
       and Delegates or the WG that adopted the I-D (per Requirement R-100).

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

    Juskevicius                   Informational                    [Page 14]

    RFC 6175               WG Datatracker Requirements            March 2011

       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
       [RFC6174] 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.,
       per Sections 3.2 and 4.1 of [RFC6174]) 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 AD 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 CC the Chairs, 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).

    Juskevicius                   Informational                    [Page 15]

    RFC 6175               WG Datatracker Requirements            March 2011

    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 to provide context for the
       transfer in the status change history log of the I-D (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 that 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 to provide context for the
       transfer in the status change history log of the I-D (R-080).

       If an AD transfers an I-D under the conditions specified by
       Requirement R-080, the Datatracker SHALL send an e-mail to the author
       of the I-D, the WG Chairs, the 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.

    Juskevicius                   Informational                    [Page 16]

    RFC 6175               WG Datatracker Requirements            March 2011

       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)

    6.7.  WG Consensus: Waiting for Writeup

       A document in the "WG Consensus: Waiting for Writeup" 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 writeup by the Document
       Shepherd.  The IESG requires that a protocol writeup be completed
       before publication of an I-D is requested.

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

    Juskevicius                   Informational                    [Page 17]

    RFC 6175               WG Datatracker Requirements            March 2011

       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 writeup
       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 as needing
       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 [RFC6174]), the WG's
       Chairs may decide to change the WG state of the I-D from "Submitted
       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 [RFC6174]).

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

    Juskevicius                   Informational                    [Page 18]

    RFC 6175               WG Datatracker Requirements            March 2011

       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
       followup on the revisions to the document (R-095).

       The Datatracker SHALL automatically reset or clear the "Revised I-D
       Needed" annotation tag attached to the WG status of an I-D when a
       revised version of that I-D is posted (R-096).

    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-097).

    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 that *they* are responsible for, from the present time
       backwards, split by pages, after successfully logging on to the
       Datatracker (R-098).

       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, split by pages
       (R-099).

       The Datatracker SHALL send an e-mail message to the authors of an I-D
       and to the Chairs and Delegates of the WG to which the I-D is
       associated 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-100).

    Juskevicius                   Informational                    [Page 19]

    RFC 6175               WG Datatracker Requirements            March 2011

    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 writeups for I-Ds that have
       been submitted to the IESG and the names of the Document Shepherds
       (R-101).

       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-102).

       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 example
       (R-103):

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

       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-11-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-104).

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

       **    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-106).

    Juskevicius                   Informational                    [Page 20]

    RFC 6175               WG Datatracker Requirements            March 2011

       ***   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-107).

       ****  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-108).

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

       However, this document 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.

    12.  References

    12.1.  Normative References

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

    Juskevicius                   Informational                    [Page 21]

    RFC 6175               WG Datatracker Requirements            March 2011

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

       [RFC4858]   Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin,
                   "Document Shepherding from Working Group Last Call to
                   Publication", RFC 4858, May 2007.

       [RFC6174]  Juskevicius, E., "Definition of IETF Working Group
                   Document States", RFC 6174, March 2011.

    12.2.  Informative References

       [IDTRACKER] "The IETF Datatracker tool", Web Application:
                   https://datatracker.ietf.org/, Version 3.12, February 2,
                   2011.

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

       [TRCKREQTS] Levkowetz, H. and Mankin, A., "Requirements on I-D
                   Tracker Extensions for Working Group Chairs", Work in
                   Progress, February 2007.

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

    Juskevicius                   Informational                    [Page 22]

    RFC 6175               WG Datatracker Requirements            March 2011

    Author's Address

       Ed Juskevicius
       TrekAhead
       PO Box 491, Carp, ON
       CANADA

       EMail: edj.etc@gmail.com

    Juskevicius                   Informational                    [Page 23]