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
AbstractThis 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.
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. 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
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. 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").
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. 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.
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). 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.
- 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).
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.
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.
R-035 will alert the Secretariat that the granting of permissions to some new people will be needed. 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). 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).
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).
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).
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
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.
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).
Section 7.4 of RFC 2418 [RFC2418]. A WG Chair who decides to conduct a WGLC on an I-D may use the "In WG Last Call" state to track the progress of the WGLC.
A WG Chair (or Delegate) SHALL be able configure the Datatracker to send a WGLC message to one or more mailing lists when he/she moves a WG draft into the "In WG Last Call" state and be able to select a different set of mailing lists for each I-D because some documents may need coordination with other WGs (R-082). The Datatracker also needs to be able to send an e-mail, after a specified period of time, to remind or 'nudge' a WG Chair to conclude a WGLC and to determine a next state for the I-D. The WG Chair (or Delegate) who moves an I-D into the "In WG Last Call" state SHALL be required to specify a length of time for the WGLC (R-083). The amount of time SHALL be able to be expressed as a "number of weeks", but it SHALL NOT be allowed to extend beyond the expiry date of the I-D (R-084). Other measures of time (e.g., "until a specific date in the future") MAY optionally be supported (R-085). The amount of time MUST be able to be changed after first being set (R-086). If an I-D is still in the "In WG Last Call" state when the amount of time specified in R-084 or R-085 runs out, the Datatracker SHALL send an e-mail to inform the WG Chairs and Delegates that the I-D is still in the "In WG Last Call" state, and to remind them they had planned to conclude the WGLC by now (R-087). Note that a WGLC may lead directly back into another WGLC for the same document. For example, an I-D that completed a WGLC as an "Informational" document may need another WGLC if a decision is taken to convert the I-D into a Standards Track document. The Datatracker MUST allow this to occur. (R-088)
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). 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).
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).
*** 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). [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. [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. 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.