diff options
Diffstat (limited to 'doc/rfc/rfc6175.txt')
| -rw-r--r-- | doc/rfc/rfc6175.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc6175.txt b/doc/rfc/rfc6175.txt new file mode 100644 index 0000000..1327322 --- /dev/null +++ b/doc/rfc/rfc6175.txt @@ -0,0 +1,1291 @@ + + + + + + +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] + |