RFC 6175

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

📅 published March 2011, from ietf

Internet Engineering Task Force (IETF) 🎀

RFC 6175: Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors 💖

  • Author: E. Juskevicius (TrekAhead) ✨
  • Category: Informational 🌸
  • Date: March 2011 📅
  • ISSN: 2070-1721 🦋
  • Obsoletes / Updates: This title block doesn't list anything it obsoletes or updates, so there's nothing to chase down there 💅

Abstract ✨

Okay so this doc lays out the requirements for new features in the IETF Datatracker, so Working Group (WG) Chairs and their Delegates can put in and update the status of the Internet-Drafts (I-Ds) tied to their WGs 📝. Once these are built, Chairs can give everyone way more info about the status and progress of WG I-Ds than they can right now 🔥. It's giving transparency, bestie 🫶

Status of This Memo 🧾

This is not an Internet Standards Track spec. It's published just for info 🌈

It is a product of the IETF, and it represents IETF community consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check out Section 2 of RFC 5741 for the deets 💅

For the latest on this doc's status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc6175 🔗

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the publication date. Read them carefully, because they spell out your rights and restrictions for this doc 👀 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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

1. Introduction ✨

The IETF Datatracker is a web-based system for managing info about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison statements, and a bunch of other important parts of the IETF process [IDTRACKER] 🧚

Here's the thing: the Datatracker can track and report on the status of every I-D that's been submitted to the IESG for evaluation and publication 💅 But right now the tool has almost no ability to track I-Ds that haven't been submitted to the IESG. [RFC6174] 💀

Document authors and others have been asking for more visibility into the status and progression of IETF Working Group (WG) drafts 🙏

So this document specifies requirements to extend the Datatracker so it can track and report WG status for WG I-Ds 🌸 Once these are implemented, WG Chairs can give everyone more info about the WG status of the I-Ds tied to their WGs than is currently possible. Main character energy for the Chairs 👑

2. Conventions Used in This Document 📖

The terms "WG I-D", "WG document", and "WG draft" are used synonymously throughout this doc 🦋 Same goes for the plural form of each term 🫶

A "WG draft" is an I-D that has achieved consensus for adoption as a work item by a WG. That's different from an individual submission I-D, which hasn't (or hasn't yet) reached that consensus 🌈

The terms "WG document" and "WG draft" are not meant to cover any other doc that a IETF Working Group might review, discuss, or produce. WG meeting materials like Blue Sheets, agendas, jabber logs, scribe's notes, minutes, and presentation slides are not "WG documents" or "WG drafts" in the context of this doc 🙈

The phrase "WG status of an I-D" refers to the WG state an I-D is in, based on the definitions in Section 4.2 of [RFC6174]. It does not mean an I-D's availability status (like "Expired", "Active", or "Replaced by") as described in Section 3.1 of [RFC6174] 💅 It also doesn't mean any of the IESG states that IETF Area Directors (ADs) use to describe the I-Ds they might be evaluating. Note that this phrase covers all the states a WG I-D can be in, plus one more (viz. "Call for Adoption by WG Issued") ✨

The phrase "I-D associated with a WG" is meant 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 with a filename that contains the string 'draft-ietf-' followed by a WG acronym is almost always a WG draft, so it counts as an "I-D associated with a WG" for this doc 🎀

An I-D with a filename that includes the author's name and a WG acronym, but doesn't include the string '-ietf-', may be a candidate for adoption by a WG. If it is one, it also counts as an "I-D associated with a WG" for this doc 🌷

The requirements in this doc use English phrases that end 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 how these key words get used to make the intent of standards track docs as clear as possible. The same key words are used in this doc to make the meaning of its requirements as clear as possible 🧠💜

3. General Requirements 🌟

The enhancements to the Datatracker described in this doc MUST be built in a way that gives WG Chairs, and the people they designate as their Delegates, the option to input and update the WG status of some, all, or none of the I-Ds tied to their WGs. They can do this using the WG I-D states and I-D status annotation tags defined in [RFC6174] (R-001) 🎀 In other words, the implementation must not make WG Chairs change how they work. It just adds optional features. WG Chairs must have the flexibility to use the Datatracker enhancements to track the WG status of their I-Ds in whatever way is most appropriate for them 💖

To make sure at least some WG status info gets 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 in Section 7 of this document 🦋

Requirement R-001 SHALL NOT impair the Datatracker's ability 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 let users other than a Working Group's Chairs (e.g., the Chairs of a different IETF WG) update the WG status of a WG's docs through the regular Datatracker interface. The only exception is when one of the WG's Chairs has explicitly delegated those privileges to them (R-003) 🚫

The user interface the Datatracker provides to WG Chairs (and their Delegates) for entering the WG status of the I-Ds tied to their WGs SHOULD have a look and feel that's similar to the interface ADs currently use to identify the status of I-Ds under formal IESG evaluation (R-004) 💅

Any new pages built to display the status of WG I-Ds SHOULD be designed with a look and feel similar to the pages the Datatracker already provides for displaying the status of I-Ds under formal IESG evaluation (R-005) 🌸

New JavaScript user interface code and style sheets built to satisfy the requirements in this doc SHOULD reuse or share existing code where practical 🫶 That way, when a change to an I-D's IESG status gets entered into the Datatracker, its WG status tracking can benefit, and vice versa (R-006) 🔁

The Datatracker MUST date and timestamp every update to the WG status of an I-D that's associated with a WG, and it must be able to use that info when it displays the I-D's status change history (R-007) ⏰ The WG status change history for an I-D MUST also identify the person or entity that updated the WG status (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) 📜

Inputting or updating the WG status of an I-D SHALL NOT overwrite any previously archived status change history info for that I-D. Every update to the WG status of an I-D MUST be added to the I-D's status change history log (R-009) 🗂️ Nothing gets erased, periodt 💀

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

The Datatracker SHALL permit authorized users (e.g., WG Chairs and Delegates) to change the WG state of a draft independently of 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 peek at 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 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.
  • 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).

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.

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

okay so annotation tags are basically little sticky notes 🩷 you can put on an I-D to say what's going on with it (like why it's sitting in a certain state) or what needs to happen next to move it along. the tiny plot twist: they do NOT change the state of WG I-Ds. the state stays the same, the tag is just the tea 🍵

Section 4.3 of [RFC6174] is where the meaning and usage of the WG I-D status annotation tags for the Datatracker are spelled out, so that's your go-to for the details 📚

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). the Chairs and Delegates are literally the ones running the show for their WG, so they get the controls 👑

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). mix and match, bestie 🎀 that's the whole vibe

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). so they get a scrollable history 📜 from now going backwards, then the Datatracker nudges them to pick which tags to set or reset 💅

Note: Document Shepherds who are not WG Chairs may only set and reset the annotation tag called "Doc Shepherd Followup Underway" per Requirement R-037. so if you're a Doc Shepherd and not a Chair, that one tag is your lane 🦋 stay in it!!

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). so you can always see when a tag got slapped on and who did it 🕵️‍♀️ receipts, babe

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). multiple tags in one login? yes please 🙌 and it gently begs you to write a little reason for each one, which is honestly iconic of it 🥹

5.3. WG I-D Protocol Writeups 🧁

okay so the IESG currently requires a protocol writeup for every WG I-D before the I-D gets submitted to the IESG for evaluation. no writeup, no evaluation, no cap 🧢

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 vibe is "clear dashboard, no guessing" ✨

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). so you can see the latest date and who did it, which is so helpful for keeping receipts straight 📅

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). so once you've seen the status, you get the upload box and the tag toggle right there 🫶

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). before you bounce, it nudges you to flip that tag and leave a little note for context 💌 future-you will be so grateful 🥺

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). so the author gets an e-mail, the Chairs and Delegates get CC'd, and a Doc Shepherd who isn't the Chair or a Delegate gets a copy too, so everyone knows it actually landed 📬🎀

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. reminder, bestie: Chairs and Delegates have that power any time for any of their WG drafts ⏰👑

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). so if you're a Doc Shepherd and the I-D isn't in WG Consensus: Waiting for Writeup yet, the Datatracker gives you a little "hold up, it might be too early" 🙈 and points you to a Chair. 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. so the Chair can either flip the state so you can upload, or just upload it themselves 🧚

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. so Chairs get to peek at the exact same Doc Shepherd view, which is how they mentor new Doc Shepherds and check who's carrying how much 🫶🌸 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). and no logging out and back in just to peek, which is a major mood 💖

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. so this is the "we're thinking about it" stage 🤔 nothing's been decided yet

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 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] so it can be used when a Chair said yes to someone's request, when a Chair asked an author to write something for consideration, or when the WG's charter lists it as a candidate draft 📜

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. one WG at a time, periodt 💅 no sharing the spotlight

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). so the status is locked until the first of: the I-D expires, the Chair or Delegate moves it, or the WG decides not to adopt it 🔒 and if they pass on it, the Chairs and Delegates can cancel their interest 🙅‍♀️

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. so if it expires or isn't adopted, it flips to NULL and the history log gets updated, and an I-D that wasn't adopted can go back to having no stream-specific state at all 🫧

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). so if another WG is already holding the I-D, the move gets blocked, and you get told right away on the screen you're logged in to 🚫

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). so the Chair can set a time limit if they want to (totally optional), it can be set as a "number of weeks," and it can never go past the I-D's expiry date ⏳ other ways to set the time limit are allowed too, if they're added 🌸

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. basically it's a gentle "hey, you said you'd decide by now" ping 🔔 to the Chairs and Delegates

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. so this is the one where the WG said "yes, we're taking this one" 🥳

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. patience, bestie, the resubmission can take a minute 🐢

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. so using this state helps the Datatracker keep the "Replaces" and "Replaced by" info accurate, which is honestly the kind of organisation I live for 🗂️✨

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). so the move only works if the I-D isn't expired, withdrawn, replaced, or already adopted by another WG, and then everybody gets a confirmation email 💌

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). so no erasing the history, ever 🙅‍♀️ even when the I-D gets a new version-00 WG Document name that starts with draft-ietf- plus the WG acronym, the whole status history has to stay put 🦋🌈

6.3. WG Document ✨

Okay so the "WG Document" state is basically where an I-D gets adopted by an IETF WG and the group is actively cooking on it 🍳. It's the main character era of a draft 💅

WG Chairs and their Delegates SHALL be allowed to move an I-D that isn't tied to any other WG into the "WG Document" state in their WG, unless the I-D has expired, been withdrawn, or been 'replaced by' another I-D or RFC (R-069) 🎀

Or, if they want less clicking, WG Chairs can rely on the automation in Requirement R-070 to move a version-00 draft into "WG Document" for them 🦋

The Datatracker SHALL automatically place a brand new version-00 I-D into the "WG Document" state if a WG Chair approves its posting to the IETF document repository AND the filename 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's being 'replaced' (if there is one) by a new version-00 WG draft, right when the Chair approves the new posting (R-071) 🌸

The WG Chair (or Delegate) who approves or moves an I-D into "WG Document" for the very first time SHALL be encouraged to enter an "Intended Maturity Level" for it, as defined in Section 5 of [RFC6174], if the Datatracker can't figure this out automatically for some reason (R-072) 🧚 The Datatracker SHALL allow the "Intended Maturity Level" to be changed after it's first set, and the Datatracker SHALL allow a WG Chair or Delegate to enter it later if it couldn't be identified when the I-D first moved into "WG Document" (R-073) 💜

The Datatracker SHALL allow WG Chairs and their Delegates to move an I-D into "WG Document" from any other WG I-D state (for example, per Sections 3.2 and 4.1 of [RFC6174]) as long as the I-D hasn't expired, been withdrawn, or been 'replaced by' another I-D or RFC (R-074) 🦋

Under normal conditions, an I-D should not be possible to have in the "WG Document" state in more than one IETF WG at a time 👀 So the Datatracker SHALL NOT allow a WG Chair or Delegate to move an I-D into "WG Document" in their WG if the I-D is already in some WG I-D state in a different WG (R-075) 🚫💅

An I-D 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 do this transfer, and it SHALL encourage the AD to write some text in the I-D's status change history log to give 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) so everyone knows it moved (R-077) 💌

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 finished, or can't be progressed by the working group for some other reason 🥺

The Datatracker SHALL allow a Responsible AD to transfer a "Parked WG Document" that hasn't expired from one WG to a different WG, and it SHALL encourage the AD to add some text giving context for the transfer in the I-D's status change history log (R-078) 🌷

If an AD transfers an I-D, the Datatracker SHALL send an e-mail to the author of the I-D, to the WG Chairs and their Delegates, and to the Responsible ADs (of the WGs affected by the transfer) to let them know it's been moved to a different WG (R-079) 💖

6.5. Dead WG Document 💀

A "Dead WG Document" is an I-D that has been abandoned. BUT ngl, 'Dead' isn't always forever 🧟‍♀️ If consensus is reached later, a "Dead WG Document" can be resurrected! And a "Dead WG Document" that never gets resurrected will eventually expire 🕯️

The Datatracker SHALL allow a Responsible AD to transfer an I-D that hasn't expired from being "Dead WG Document" in one WG to a non-dead state in a different WG, and the Datatracker SHALL encourage the AD to add some text giving context for the transfer in the I-D's status change history log (R-080) 🌈

If an AD transfers an I-D under the conditions in 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 let them know it's been moved to a different WG (R-081) 📬

6.6. In WG Last Call 📣

An I-D in the "In WG Last Call" state is one that has a Working Group Last Call (WGLC) issued and in progress. Note that WG Last Calls are optional in the IETF WG process, per Section 7.4 of RFC 2418 [RFC2418] 🫶

A WG Chair who decides to run a WGLC on an I-D can use the "In WG Last Call" state to keep track of how it's going 📊

A WG Chair (or Delegate) SHALL be able to configure the Datatracker to send a WGLC message to one or more mailing lists when they move a WG draft into "In WG Last Call", and to pick a different set of mailing lists for each I-D, since some documents may need coordination with other WGs (R-082) 💜

The Datatracker also needs to be able to send an e-mail after a set amount of time to remind or 'nudge' the WG Chair to wrap up the WGLC and pick the next state for the I-D ⏰

The WG Chair (or Delegate) who moves an I-D into "In WG Last Call" SHALL be required to specify how long the WGLC will last (R-083). That time SHALL be able to be expressed as a "number of weeks", but it SHALL NOT be allowed to run past the I-D's expiry date (R-084). Other ways of measuring time (for example, "until a specific date in the future") MAY optionally be supported (R-085). The amount of time MUST be able to be changed after it's first set (R-086) 🦋

If an I-D is still in "In WG Last Call" when the time from R-084 or R-085 runs out, the Datatracker SHALL send an e-mail to the WG Chairs and Delegates to say the I-D is still in "In WG Last Call" and to remind them they planned to finish the WGLC by now (R-087) 🙈

Note that a WGLC may lead straight back into another WGLC for the same document 🔁 For example, an I-D that finished a WGLC as an "Informational" document may need another WGLC if the decision is made to convert it into a Standards Track document. The Datatracker MUST allow this to happen (R-088) 👑

6.7. WG Consensus: Waiting for Writeup 📝

A document in the "WG Consensus: Waiting for Writeup" state has pretty much finished its development within the WG and is almost ready to go to the IESG for publication 🎉 The last thing left to do is for the Document Shepherd to write up a protocol writeup. The IESG requires that this 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) 🔒

The Datatracker SHOULD be configurable to send an e-mail to a WG's Chairs and Delegates after a set amount of time to remind or 'nudge' them to check on the Document Shepherd's writeup for an I-D (R-090). This feature SHOULD look and feel similar to the way Requirements R-064 to R-067 inclusive are implemented (R-091) 🧚

6.8. Submitted to IESG for Publication 🚀

This state is for a WG document that has been submitted to the IESG for publication and hasn't been sent back to the WG for revision. An I-D in this state might be under IESG review, or it might be approved and sitting in the RFC Editor's queue, or it might already be published as an RFC. Other possibilities exist too 🌍 The document might also be "Dead" (in the IESG state machine) or in a "Do Not Publish" state 💀

The Datatracker SHOULD look for WG I-D status annotation tags when a WG draft moves into this state. If any tags haven't been cleared or reset, the Datatracker SHOULD encourage the WG Chairs (or Delegates) in real time to reset or clear any extra annotation tags (R-092) 🧹✨

6.9. Revised I-D Needed (Annotation Tag) 🔧

After an I-D is submitted to the IESG, it might get judged as needing revision before it can be published as an RFC 😬 An AD or the IESG as a whole can send a document back to a WG for revision 🔙

An I-D that needs revision may be flagged when the Responsible AD adds 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 (for example, 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 add one or more WG I-D status annotation tags to it (for example, 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 say how many weeks they expect a revised document will take (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 (for example, Parked WG Document, WG Document, or Waiting for WG Chair Go-Ahead) (R-094) 💅

If a revised version of the I-D isn't submitted to the WG before the time from R-093 runs out, the Datatracker SHALL send an e-mail to the WG's Chairs and Delegates to remind or 'nudge' them to follow up on the revisions (R-095) 📧

The Datatracker SHALL automatically reset or clear the "Revised I-D Needed" annotation tag on 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 cut down on the info that WG Chairs and Delegates have to type into the Datatracker, the tool must automatically make 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 📜

Okay bestie, this section is all about the paper trail 🧾 Everyone with 'write' access to WG I-D status information SHALL be able to pull up a summary of all the status changes made to the WG I-Ds that they are responsible for. It goes from the present time backwards and gets split into pages, and they can do this after successfully logging on to the Datatracker (R-098).

The Datatracker SHOULD give WG Chairs a convenient way to get a summary of all WG I-D status changes made on their behalf by their Delegates. It goes from the present time backwards and is split by pages too (R-099) 🫶

The Datatracker SHALL send an e-mail to the authors of an I-D, and to the Chairs and Delegates of the WG the I-D is associated with, whenever the WG status of the I-D gets updated 📨 That e-mail SHALL include details about the change, like 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. It also SHALL give the date of the change and say who (or which entity) caused it (R-100). Main character energy for transparency ✨

9. WG I-D Status Reporting Requirements 🔍

The Datatracker SHALL give everyone a convenient way to query the status of every document in an IETF WG, and to see the current status of some or all of the documents in the WG 👀 That includes the Document Shepherd protocol writeups for I-Ds that have been submitted to the IESG, plus the names of the Document Shepherds (R-101).

The Datatracker SHALL also let everyone search for the status of documents written by a specific author. They can search for I-Ds in a specific WG I-D state, or with a specific "Intended Maturity Level", or with a specific annotation tag attached (R-102) 🦋

The Datatracker's existing I-D status display pages SHOULD be updated to show at least the metadata and status info for an I-D that's associated with a WG. It should look like this 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, plus 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) 🎀

*** This field SHOULD display the name of the person (or the e-mail address of the person) designated as the Document Shepherd for the I-D. If a Document Shepherd hasn't been designated yet, it can be left blank (R-107) 🧚

**** This field SHALL display the current IESG status of the document, or the word "None" for documents that aren't being tracked by the IESG yet (R-108) 💅

10. Error Handling Requirements 🛠️

Errors with inputting or updating the status of a WG document are possible, so let's be real about that 🥲

Per Requirement R-009, creating new or updated status information cannot erase, overwrite, or cause the deletion of any previously entered document status change history information. The history is sacred 🔒

Errors in data entry by a WG Chair or Delegate should be corrected by a WG Chair or Delegate taking action to update any wrong status info in the Datatracker with the correct information, so the correct status of the I-D is displayed. For example, if a document was accidentally placed into the wrong state, a WG Chair (or Delegate) can move it into the correct state. They should also add a comment to the document's status change history log explaining what happened 📝 Honesty is iconic 🫶

11. Security Considerations 🚨

This document does not propose any new Internet mechanisms and has no security implications for the Internet. Phew 😮‍💨

However, this document has specific requirements to add features to the IETF Datatracker, so that a bigger number of users can input and/or update status information about I-Ds associated with IETF WGs. Enhancing the Datatracker may open the door to new denial-of-service (DoS) attacks, and/or to attempts by malicious users to corrupt the information in the WG document status database. This is the part that's giving danger 💀

This document does not propose any specific requirements to mitigate DoS attacks on the Datatracker. So keep that in mind 👀

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.

[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], which had lots of 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 while writing this document. A lot of their comments and suggestions were used by the author to revise and improve it 💜

The author also gives a huge shoutout 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 to 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 ✨

Author's Address

Ed Juskevicius
TrekAhead
PO Box 491, Carp, ON
CANADA

EMail: edj.etc@gmail.com
📦 where this page comes from