Proto E. Juskevicius Internet Draft TrekAhead Intended status: Informational May 22, 2010 Expires: November 22, 2010 Requirements to Extend the Datatracker for WG Chairs and Authors draft-juskevicius-datatracker-wgdocstate-reqts-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 22, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Juskevicius Expires November 22, 2010 [Page 1] Internet-Draft WG Datatracker Requirements May 2010 Abstract This document specifies requirements for new functionality to be added to the Datatracker tool to make it possible for IETF working group Chairs and/or their delegates to indicate and update the status of working group documents. It also describes additional functions to enable IETF Chairs and others to more easily follow the progression of working group documents from their earliest stages. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. General requirements...........................................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.........................7 5. Inputting and updating WG document status information..........8 6. Special requirements for some WG I-D states and conditions.....9 6.1. Candidate WG Document.....................................9 6.2. WG Document..............................................11 6.3. In WG Last Call..........................................12 6.4. WG Consensus: Waiting for Write-Up.......................12 6.5. Submitted to IESG for Publication........................13 6.6. Revised I-D Needed (annotation tag)......................13 7. WG Status of I-Ds that are not updated by Chairs or Delegates.13 8. WG document status change reporting requirements..............14 9. WG document status reporting requirements.....................14 10. Error handling requirements..................................14 11. "Nice to have" features......................................15 11.1. Enhanced WG Document Status Querying for WG Chairs......15 11.2. Enhanced WG Document Status Querying for Everyone.......15 12. Security Considerations......................................16 13. IANA Considerations..........................................16 14. References...................................................16 14.1. Normative References....................................16 14.2. Informative References..................................17 15. Acknowledgments..............................................17 1. Introduction The IETF Datatracker is a web-based system for managing information about Internet-Drafts (I-Ds), RFCs and several other important aspects of the IETF process [IDTRACKER]. Juskevicius Expires November 22, 2010 [Page 2] Internet-Draft WG Datatracker Requirements May 2010 The Datatracker can be used to obtain a lot of information about the status and progression of Internet-Drafts after they have been sent to the IESG for review and publication. Conversely, the Datatracker can only provide minimal information about the status of I-Ds before they are sent to the IESG. The Datatracker can only report on the availability status of I-Ds (e.g., Expired, Active, Replaced, Withdrawn, published as an RFC), and associate an I-D with an IETF working group (WG) if the name of the WG is contained within the filename of the I-D. This document specifies requirements for new functionality to be added to the Datatracker to make it possible for IETF working group Chairs and/or their delegates to input and update the working group status of I-Ds. It also describes additional requirements to enable Chairs to manage working group documents from their earliest stages, and to allow document authors (and others) to obtain more visibility into the working group status of I-Ds. All of the requirements specified in sections 3 to 10 inclusive of this document are to be implemented in the first release of new functionality for the Datatracker. The features described in section 11 are additional capabilities that would be nice to have; however, their implementation is not essential in the first release. Implementation of the capabilities specified in section 11 may be deferred to a later release. 2. Conventions used in this document The phrase "working group document" is to be interpreted as being synonymous with "working group I-D" and "working group draft". The same is true for the plural case of each phrase. The phrase "working group document" is not intended to apply to any other document that may be reviewed, discussed, or produced by an IETF working group. Working group meeting materials such as Blue Sheets, agendas, jabber logs, scribe's notes, minutes, and presentation slides are not to be considered as "working group documents" in the context of this document. Several words are used to specify requirements in this document. These words are often capitalised. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The requirements specified in this document use English phrases ending with "(R-nnn)", where "nnn" is a unique requirement number. Juskevicius Expires November 22, 2010 [Page 3] Internet-Draft WG Datatracker Requirements May 2010 3. General requirements The IETF Datatracker needs to be enhanced to make it possible for IETF working group Chairs and/or their delegates to indicate the status and progression of working group documents. The enhancements SHOULD NOT radically change the look or feel of the Datatracker for document status entry, querying, or reporting. (R-001) The goal is to add new functionality to the tool, not to redesign the tool. The user-interface for inputting WG document status information SHOULD have a look and feel that is similar to the interface used by IETF Area Directors to describe the status of documents under formal evaluation by the IESG. (R-002) Any new pages added to Datatracker to display the status of working group documents SHOULD have a look and feel that is similar to the pages currently used to report the status of documents under formal evaluation by the IESG. (R-003) The status of IETF working group documents SHALL be described 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-004) The Datatracker SHALL provide IETF WG Chairs with the flexibility to manually enter and/or update the status of all I-Ds associated with their working groups, or just a subset of the I-Ds, or none of the I-Ds. (R-005) The following two examples clarify requirement R-005: - the Chairs of a newly chartered working group may choose to manually update the status of every working 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. The Datatracker SHALL provide IETF WG Chairs with the flexibility to choose from all of the predefined WG document states and status annotation tags to describe the status of working group I-Ds, or to identify a subset of the states to be used to indicate the WG status of I-Ds in their working groups. (R-006) If a Chair decides *not* to manually enter or update the status of one or more working group documents, the Datatracker will be able to provide automatic transitions to a few of the WG document states based on information already available to it. For instance, an I-D Juskevicius Expires November 22, 2010 [Page 4] Internet-Draft WG Datatracker Requirements May 2010 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 SHALL be implemented as a new state machine that must be separate from the existing IESG document status state machine. (R-007) The state that a working group document is in, in each state machine, MUST be able to be independently updated by the respective primes for each state machine (viz. WG chairs and their delegates, and Area Directors). (R-008) 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-009) 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-010) 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-011) After successfully logging on to the Datatracker, the WG Chair: - SHALL be given full 'read' and 'write' privileges to input and to update information about the working group status of all I-Ds associated with the Chair's working group; (R-012) - 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-013) Juskevicius Expires November 22, 2010 [Page 5] Internet-Draft WG Datatracker Requirements May 2010 - 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-014) - 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-015) - SHALL be able to review and make changes to the list of designated delegates for his or her working group; (R-016) The identifier for each delegate SHOULD be the person's e-mail address; (R-017) - 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-018) The identifier for the Document Shepherd SHOULD be the person's e-mail address. (R-019) 4.3. For Delegates of IETF WG Chairs 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 make changes to the state 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-020) (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). 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-021) 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-022) 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-023) 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. Juskevicius Expires November 22, 2010 [Page 6] Internet-Draft WG Datatracker Requirements May 2010 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 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-024) 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-025) 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-026) The Document Shepherd SHALL also be granted access to set and reset the document status annotation tag called "Doc Shepherd Follow-Up 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-027) 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-028) Juskevicius Expires November 22, 2010 [Page 7] Internet-Draft WG Datatracker Requirements May 2010 5. Inputting and updating WG document status information The state of an IETF working group document (which a Chair has decided to track using the Datatracker) SHALL only be described using the working group document states and state names specified in Section 3.3 of [WGDRAFTS]. (R-029) The creation of ad hoc WG document states and/or state names WILL NOT be an option. (R-030) The default WG state machine SHOULD follow the sequence of states illustrated in the WG document state machine diagram in Section 3.4 of [WGDRAFTS]. (R-031) After a working group Chair or delegate logs-on to the Datatracker, 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-032) The WG Chair SHALL then be allowed to select a next state for the I-D and to enter some text about the state change (into a comment log). (R-033) As a general principle, the Datatracker should always prompt the person making a change to the status of a WG document to input some text to explain the reason for the status change. A working group Chair or delegate should not be constrained by the "most likely next state" for any working group document. A working group Chair or delegate SHOULD be able to change the state of a working group document from its current WG document state to any other WG document state. (R-034) When a working group Chair or delegate logs into the Datatracker to set or reset an annotation tag (used to describe a condition that may affect the state of a document), the Datatracker SHOULD 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-035) 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-036) 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 Juskevicius Expires November 22, 2010 [Page 8] Internet-Draft WG Datatracker Requirements May 2010 delegate to consider inputting text into a comment log to explain why the annotation tag is being set or reset. (R-037) 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-038) 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 condition specified by R-038 is met. (R-039) Requirements R-040 to R-052 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-038 and R-039 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 Juskevicius Expires November 22, 2010 [Page 9] Internet-Draft WG Datatracker Requirements May 2010 - 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-040 to R-052 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-040) 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-041) 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 that the document may remain in the candidate state. (R-042) 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-043) - 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-044) 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-045) After Juskevicius Expires November 22, 2010 [Page 10] Internet-Draft WG Datatracker Requirements May 2010 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-046) - 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-047) 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-048) 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-049) 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-050) 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-051) 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 was not adopted and that its state has been changed automatically. (R-052) 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 Juskevicius Expires November 22, 2010 [Page 11] Internet-Draft WG Datatracker Requirements May 2010 not expired and if the name of the I-D matches the conventional 'draft-ietf--' naming. (R-053) 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-054) 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-055) 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-056) 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-057) The length of time SHOULD be specified as a number of weeks. (R-058) 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-059) 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-060) 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-061) Juskevicius Expires November 22, 2010 [Page 12] Internet-Draft WG Datatracker Requirements May 2010 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-062) 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 should be allowed for the revised document to be produced (R-063). 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-064) The Datatracker SHOULD be programmable to send an e-mail to the WG's Chairs and delegates after the number of weeks specified in R-063 to remind or 'nudge' the Chairs and delegates to follow-up on the revisions to the document. (R-065) 7. WG Status of I-Ds that are not updated by Chairs or Delegates Requirement R-006 provides each IETF WG Chair with the freedom to use the WG document states defined in [WGDRAFTS] to indicate the status and progression of documents in his or her working group. 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. Juskevicius Expires November 22, 2010 [Page 13] Internet-Draft WG Datatracker Requirements May 2010 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-066) - 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-067) - 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-068) 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 time backwards, split by pages, after successfully logging-on to the Datatracker. (R-069) 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-070) 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-071) 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-072) 10. Error handling requirements Errors with respect to inputting or updating the status of a WG document are possible. Juskevicius Expires November 22, 2010 [Page 14] Internet-Draft WG Datatracker Requirements May 2010 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-073) 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. 11. "Nice to have" features The functions specified in this section describe additional features that would be nice to have; however, their implementation is not essential in the first release of extensions to the Datatracker. The implementation of the feature specified herein may be deferred if needed to a later release. 11.1. Enhanced WG Document Status Querying for WG Chairs The Datatracker should provide each WG chair with the ability to create a list of all the drafts that he/she needs to follow in a single-page view. The drafts to be followed may all be from the same working group, or they may be from different working groups, and they may include individual documents as well. 11.2. Enhanced WG Document Status Querying for Everyone Some of members of the IETF community who do not have a log-on user- id or password would appreciate using the Datatracker to obtain the WG status of more than one I-D at a time. For example, people who volunteer to serve on drafting groups may be interested in the status of several different I-Ds which may be spread across more than one working group. A "nice to have" feature would be to provide everyone with a way to set up a 'drafting group document status page' (on the Datatracker) to display the WG status of more than one document at a time. Each such page could be identified by a random string of characters in a URL, and the Datatracker could have a garbage collection function to delete pages that have not been accessed in a long period of time (e.g., 6 months). The basic idea of this feature is to allow anyone to go to a page on the Datatracker and say "I want to create a status display page for Juskevicius Expires November 22, 2010 [Page 15] Internet-Draft WG Datatracker Requirements May 2010 a set of I-Ds". After appropriate Q&A and/or selection of the drafts to be tracked, the Datatracker could confirm that it has created the requested status display page by saying "OK. Whenever you wish to see the status of this group of drafts, go to: https://datatracker.ietf.org/pagegroups/07539aec572dfce01e816499 12. 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. 13. IANA Considerations This document does not require any new number assignments from IANA, and does not define any new numbering spaces to be administered by IANA. RFC-Editor: Please remove this section before publication. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels', RFC 2119, March 1997. [WGDRAFTS] Juskevicius, E., "Definition of WG Document States", work in process, draft-ietf-proto-wgdocument-states-05, May 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. Juskevicius Expires November 22, 2010 [Page 16] Internet-Draft WG Datatracker Requirements May 2010 14.2. Informative References [IDTRACKER] "The IETF Datatracker tool", Web Application: https://datatracker.ietf.org/, May 21, 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. 15. 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 November 22, 2010 [Page 17]