RFC 6174

Definition of IETF Working Group Document States

📅 published March 2011, from ietf

RFC 6174: Definition of IETF Working Group Document States 🎀

RFC number: 6174 💖 Author: E. Juskevicius (TrekAhead) ✨ Category: Informational 🌸 Date: March 2011 📅 ISSN: 2070-1721 🔥 Obsoletes/Updates: The title block doesn't list anything this RFC obsoletes or updates 🧚

Okay bestie, this RFC is about giving Working Group (WG) documents a proper status glow-up in the IETF Datatracker 💅. Right now the tool is super good at tracking documents once they've reached the IESG, but it's basically clueless about what's happening before that point. This doc fixes that. 🦋

Abstract ✨

Okay so the IETF Datatracker tool needs an upgrade 💅. The goal is letting WG Chairs show IETF participants way more info about where their WG documents are at and how they're progressing 🔥.

This doc defines new states and status annotation tags for the Datatracker, so WG Chairs and their Delegates can track the status of the Internet-Drafts (I-Ds) tied to their WGs 🎀. It also explains what all the existing I-D states and substate annotation tags mean. Those are the ones Area Directors use to show where I-Ds are once they've been sent to the IESG for evaluation and publication 💖.

Status of This Memo 🌈

This document is not an Internet Standards Track specification 🙈. It's published for informational purposes only.

This document is a product of the Internet Engineering Task Force (IETF) 💜. It represents the consensus of the IETF community and got public review. The Internet Engineering Steering Group (IESG) approved it for publication ✨. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🧚.

For the latest status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc6174 🦋.

Copyright Notice 💅

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), which are in effect on the publication date 💖. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🔥.

Table of Contents 🧚

1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. I-D States Already Implemented by the Datatracker ...............5
   3.1. I-D Availability States ....................................5
        3.1.1. Expired .............................................6
        3.1.2. Active ..............................................6
        3.1.3. Replaces and Replaced By ............................6
   3.2. IESG Document States .......................................7
        3.2.1. Publication Requested ...............................7
        3.2.2. AD Evaluation .......................................8
        3.2.3. IESG Evaluation .....................................8
4. New States and Status Annotation Tags for WG I-Ds ...............9
   4.1. Working Group I-D State Diagram ............................9
   4.2. Working Group I-D States ..................................11
        4.2.1. Call for Adoption by WG Issued .....................12
        4.2.2. Adopted by a WG ....................................12
        4.2.3. Adopted for WG Info Only ...........................13
        4.2.4. WG Document ........................................13
        4.2.5. Parked WG Document .................................13
        4.2.6. Dead WG Document ...................................14
        4.2.7. In WG Last Call ....................................14
        4.2.8. Waiting for WG Chair Go-Ahead ......................15
        4.2.9. WG Consensus: Waiting for Writeup ..................15
        4.2.10. Submitted to IESG for Publication .................15
   4.3. Working Group I-D Status Annotation Tags ..................16
        4.3.1. Awaiting Expert Review/Resolution of Issues Raised .16
        4.3.2. Awaiting External Review/Resolution of
               Issues Raised ......................................16
        4.3.3. Awaiting Merge with Other Document .................16
        4.3.4. Author or Editor Needed ............................17
        4.3.5. Waiting for Referenced Document ....................17
        4.3.6. Waiting for Referencing Document ...................17
        4.3.7. Revised I-D Needed - Issue raised by WGLC ..........18
        4.3.8. Revised I-D Needed - Issue raised by AD ............18
        4.3.9. Revised I-D Needed - Issue raised by IESG ..........18
        4.3.10. Doc Shepherd Followup Underway ....................18
        4.3.11. Other - see Comment Log ...........................19
5. Intended Maturity Level of WG Drafts ...........................19
6. Security Considerations ........................................19
7. References .....................................................19
   7.1. Normative References ......................................19
   7.2. Informative References ....................................20
8. Acknowledgments ................................................20
Appendix A: "IESG Document" States ................................21
   A.1. Definition of "IESG Document" States ......................21
      A.1.1. Publication Requested ................................21
      A.1.2. AD Evaluation ........................................21
      A.1.3. Expert Review ........................................21
      A.1.4. Last Call Requested ..................................22
      A.1.5. In Last Call .........................................22
      A.1.6. Waiting for Writeup ..................................22
      A.1.7. Waiting for AD Go-Ahead ..............................22
      A.1.8. IESG Evaluation ......................................22
      A.1.9. IESG Evaluation - Defer ..............................23
      A.1.10. Approved - Announcement to be sent ..................23
      A.1.11. Approved - Announcement sent ........................23
      A.1.12. RFC Ed Queue ........................................23
      A.1.13. RFC Published .......................................23
      A.1.14. DNP - Waiting for AD note ...........................23
      A.1.15. DNP - Announcement to be sent .......................23
      A.1.16. AD is Watching ......................................23
      A.1.17. Dead ................................................24
   A.2. IESG Document Substates ...................................24
      A.2.1. Point Raised - writeup needed ........................24
      A.2.2. AD Followup ..........................................24
      A.2.3. External Party .......................................25
      A.2.4. Revised ID Needed ....................................25

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

Right now the Datatracker can track and report on the status of I-Ds that have been submitted to the IESG for evaluation and publication 🔥. Appendix A of this document covers all the document states and substate annotation tags that IETF Area Directors (ADs) use to show the status of I-Ds sent to the IESG ✨.

Here's the sad part though 🙈. The Datatracker has almost no ability to show the status and progression of I-Ds before they go to the IESG 💀. Today it can only track availability status (like "Active", Expired", "Withdrawn", "Replaced by") and sometimes shows which IETF Working Group (WG) an I-D belongs to, if any 🧚.

Section 3 of this document is a summary of what the Datatracker can currently track and report about I-D status in the IETF document stream 🦋. That stream is defined in Section 5.1.1 of RFC 4844 [RFC4844] 💜.

Section 4 is the glow-up 👑. It defines several new I-D states and I-D status annotation tags that need to be added to the Datatracker so it can track and report on WG I-Ds 🎀.

2. Conventions Used in This Document 🌈

A "working group I-D" (WG I-D) is an Internet-Draft that has reached 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 I-D", "WG document", and "WG draft" all mean the same thing throughout this document 💖. Same goes for the plural form of each term ✨.

"WG document" and "WG draft" are not meant to cover any other documents that an IETF working group might review, discuss, or produce 🔥. Stuff like Blue Sheets, agendas, jabber logs, scribe's notes, minutes, and presentation slides does not count as a "WG document" or "WG draft" here 🙅‍♀️.

"WG status of an I-D" refers to the state an I-D is in, as defined in Section 4.2 of this document 🧚. It does not mean an I-D's availability status (like "Expired", "Active", "Replaced by") from Section 3.1, and it's also not any of the IESG states that Area Directors use while they're evaluating I-Ds 🦋.

3. I-D States Already Implemented by the Datatracker 🎀

This section covers the capabilities the Datatracker already has for tracking I-D status in the IETF document stream 💜.

The document availability states in Section 3.1 apply to every I-D submitted to the IETF 🌸.

The IESG document states and substate annotation tags in Section 3.2 and Appendix A only apply to I-Ds that have been submitted to the IESG for evaluation and publication 🔥.

The Datatracker has no I-D states or I-D status annotation tags for the WG status of any I-D right now 💀.

3.1. I-D Availability States 💅

The Datatracker keeps availability status info for every I-D submitted to the IETF ✨. The I-D availability states are:

Expired
Active
Replaces
Replaced by
Withdrawn by Submitter
Withdrawn by IETF
RFC

The first four availability states get their own explanations in the subsections below 🧚. The rest are self-explanatory 💖.

Also, the Datatracker sometimes uses the phrase "I-D Exists" 🌈. That's a state the Datatracker makes up for I-Ds where it has no other status info 🙈. For example, the tool uses "I-D Exists" for I-Ds that aren't expired and haven't been sent to the IESG 🔥.

3.1.1. Expired ⏳

An "Expired" I-D is a document that is more than six months old and that has not been updated or replaced by a newer I-D or an RFC. 💀

Okay so every I-D has a normal lifespan of 185 days 🌸. An I-D will expire and be deleted from the I-D repository after six months unless it is updated or replaced by a newer version. The one exception is an I-D undergoing official evaluation by the IESG, which won't be expired before its status is resolved (e.g., the I-D is published as an RFC) 🙌. IESG states that don't relate to a formal request to publish a document (e.g., "AD is Watching") do not stop an I-D from expiring. [AUTHGUIDE]

3.1.2. Active 🦋

An "Active" I-D is a document that is less than six months old and has not been updated or replaced by a newer I-D or an RFC. ✨

The "Active" availability state applies to individual I-Ds and WG I-Ds. The Datatracker may also use "Active" to describe the status of I-Ds under formal evaluation by the IESG and I-Ds in the RFC Editor Queue. So, bestie, the "Active" I-D availability state cannot be used to tell if an I-D is actively being developed by a WG 🙈. [WGDTSPEC]

3.1.3. Replaces and Replaced By 🔁

The Datatracker uses "Replaces" and "Replaced by" to describe I-Ds that have been renamed and then resubmitted to the I-D repository for some reason 💅.

Two common uses of "Replaced by" look like this:

The filename of an individual I-D that is being considered for adoption by a WG typically includes the name of its author (e.g., draft-author-wgname-topic-nn). If the individual I-D is adopted by a WG, it will be "Replaced by" a newer draft whose filename includes the string ietf- (e.g., draft-ietf-wgname-topic-00). When the newer WG I-D is submitted to the I-D repository, it "Replaces" the older individual submission I-D. 🫶
The Datatracker also uses "Replaced by" to describe the final state of an I-D that has been published as an RFC. The I-D was "Replaced By" the RFC. 🎀

Note that getting correct "Replaces" and "Replaced by" data into the Datatracker currently requires an explicit request by a WG Chair 📝.

Without such a request, an individual submission I-D will co-exist with the newer WG I-D that replaces it until the individual submission I-D eventually expires 🫠.

The Datatracker's ability to track "Replaces" and "Replaced by" information may need to be extended in the future to handle more complex cases such as these:

Two or more I-Ds are merged into (i.e., "Replaced by") a single I-D. In such cases, the availability status of the (one) new I-D should indicate that the draft "Replaces" two or more older and previously separate I-Ds; and
One I-D is split or divided into two or more new I-Ds. In this case, the availability status should indicate that one (older) I-D was "Replaced by" two or more newer I-Ds. 🧩

3.2. IESG Document States 👑

In addition to tracking the availability status of every I-D, the Datatracker also keeps detailed info about the status and progression of I-Ds that have been sent to the IESG for evaluation and publication 📚.

All of the states that Area Directors use to show the status of I-Ds under evaluation by the IESG are defined in [IESGSTAT] and are reproduced for convenience in Appendix A 💖.

The following subsections describe some common interactions between three of the IESG I-D states and normal IETF WG processes. These interactions are relevant to several of the new WG I-D states defined in Section 4 🌈.

3.2.1. Publication Requested 📬

When a WG has determined that at least rough consensus exists within the WG to advance an I-D, progressing the document is then the responsibility of the IESG (unless the IESG returns the I-D to the WG for further development). [RFC2418]

The "Publication Requested" state describes an I-D for which a formal request has been sent to the IESG to advance or publish the I-D as an RFC, following the procedures specified in Section 7.5 of RFC 2418 [RFC2418]. This state does not mean that an Area Director has reviewed the I-D, or that any official action has been taken on it other than noting that its publication has been requested 🧐.

Many WG drafts enter the IESG state machine for the first time via the "Publication Requested" state. When an I-D advances through the IESG process, its IESG state will change to reflect its progress. That said, the WG status of the I-D should not change unless an AD or the IESG sends the I-D back to the WG for further development. The WG state of an I-D being progressed by the IESG is "Submitted to IESG for Publication", as defined in Section 4.2.10 🚀.

3.2.2. AD Evaluation 🔍

The "AD Evaluation" state describes an I-D that the responsible Area Director has begun to review. The purpose of the AD's review is to verify that the I-D is ready for advancement before an IETF Last Call is started or before the document is progressed to the IESG as a whole 🧠.

After evaluating an I-D, the responsible AD may decide that the document needs to be revised before it can be progressed further. The AD may send a working group I-D back to the WG that created it for revision 🔙.

When an AD sends an I-D back to a WG for revision, the Datatracker will report the IESG state and substate of the document as "AD Evaluation: Revised I-D Needed". If the required revisions are extensive, a WG Chair may decide to change the WG state of the I-D from "Submitted to IESG for Publication" to another WG state (e.g., "Waiting for WG Chair Go-Ahead" or "WG Document") for as long as it takes the revised I-D to be developed 🛠️. The IESG status of the I-D will continue to be "AD Evaluation: Revised I-D Needed" until the revised I-D becomes available ⏰.

3.2.3. IESG Evaluation 🕵️‍♀️

The "IESG Evaluation" state describes an I-D that is being formally evaluated by the entire IESG. Every AD is able to raise any content or process issues they may have with the document. Issues that block approval of the document are called "DISCUSS" comments. A "DISCUSS" with serious issues may cause a WG I-D to be returned to the WG for revision 😬.

If the IESG sends an I-D back to a WG for more development, the Datatracker will report the IESG state and substate of the I-D as "IESG Evaluation: Revised I-D Needed" until a revised version of the I-D becomes available. While the I-D is being revised, the WG Chair may decide to move it from the "Submitted to IESG for Publication" state into one of the earlier WG states (e.g., "Waiting for WG Chair Go-Ahead" or "WG Document") 🔄.

4. New States and Status Annotation Tags for WG I-Ds 🎀

The status-tracking states described in Section 3 are already implemented in the Datatracker. However, their scope isn't broad enough to give good visibility into the WG status of any I-D 👀.

This section describes new I-D states and I-D status annotation tags that need to be added to the Datatracker so WG Chairs and/or their Delegates (e.g., WG Secretaries) can show the status and progression of the I-Ds associated with their WGs 💜.

The WG I-D states defined in this section are a superset of the I-D states currently used across all IETF WGs. This is not to suggest or imply that all WG I-D states must be used by all WG Chairs to describe the status and progression of their I-Ds. Chairs may use all or just some of the document states illustrated in Figure 1 to describe the WG status of their I-Ds, as appropriate 🌟.

4.1. Working Group I-D State Diagram ✨

Okay bestie, Figure 1 is a state machine diagram that maps out every WG I-D state from Section 4.2 of this document 🗺️. The state names are capitalized so they pop, and the common transitions are drawn with solid, dashed, and dotted lines 💜.

The WG I-D state machine in Figure 1 is meant to be a brand-new front-end to the IESG I-D state machine [IESGIDSM] that already lives in Datatracker 🎀.

Heads up: Figure 1 does NOT show every possible transition 👀. WG Chairs can move an I-D from any WG state to any other WG state, whenever it makes sense for describing the WG status of the document 🦋. So if there's no arrow between two states, that doesn't mean the move is banned. 🙅‍♀️

The first WG I-D state is "Call for Adoption by WG Issued", and you can read all about what it means in Section 4.2.1 🌸.

One of the possible final states for a WG I-D is "Submitted to IESG for Publication" 🏁. That one gets its own explanation in Section 4.2.10 ✨.

     "I-D EXISTS": 'draft-author-wgname-topic-nn'  < - - .
                                 :                         .
 +---------------------------------------------------------------------+
 |  WG I-D State Machine             |                         .       |
 |                                   v                 (not adopted)   |
 |                                                            .        |
 |                   CALL FOR ADOPTION BY WG ISSUED  . . . . .         |
 |                     .             :                                 |
 |                    .              v                                 |
 |                   v                                                 |
 |             ADOPTED FOR     ADOPTED BY WG                           |
 |             WG INFO ONLY          .                                 |
 |                                   :                                 |
 |                                   :                                 |
 |    (individual I-D "Replaced by" 'draft-ietf-wgname-topic-00')      |
 |                                   :                                 |
 |                                   v                                 |
 |                                                                     |
 |       DEAD WG   <-------->   WG DOCUMENT  <-------->  PARKED WG     |
 |       DOCUMENT       ("Replaces" individual I-D)      DOCUMENT      |
 |                         .                                           |
 |                      .       ^          \                           |
 |                    .        /            \                          |
 |                   .        /              \                         |
 |                  .        v                \                        |
 |                 .                           \                       |
 |                .       IN WG    ---+         v                      |
 |                      LAST CALL     |                                |
 |               '          ^         +-->  WG CONSENSUS:              |
 |               ^          :                WAITING FOR               |
 |               '          v         +-->    WRITEUP                  |
 |               '                    |                                |
 |               ^      WAITING FOR   |          |                     |
 |               '       WG CHAIR  ---+          |                     |
 |                '      GO-AHEAD                v                     |
 |                 .                                                   |
 |                   .                    SUBMITTED TO IESG            |
 |          ("Revised ID Needed") - - < -  FOR PUBLICATION             |
 |                                                                     |
 |                                                                     |
 +---------------------------------------------------------------------+
                                  |
                                  v
                        IESG Document States
                          (see Appendix A)

      Figure 1:  WG I-D States and Common State Transitions

The Datatracker is getting an upgrade so it can automatically make the following two transitions for every WG draft 🤖💖:

A version-00 I-D that follows the 'draft-ietf-wgname-topic-00' file naming convention will get moved into the "WG Document" state automatically by the Datatracker, as soon as the WG Chair approves the posting of the I-D 🎉; and
A WG draft that gets moved into the IESG state called "Publication Requested" will automatically be moved by the Datatracker into the WG state called "Submitted to IESG for Publication" 🚀.

Every other WG I-D state transition needs the WG Chairs (or their Delegates) to log in to the Datatracker and manually enter the right WG state to describe the WG status of an I-D 💅.

Also, Figure 1 has an arrow going from "Submitted to IESG for Publication" back to "WG Document" 🔙. That's just one example of what can happen after an AD or the IESG as a whole sends an I-D back to a WG for revision 🫶. The WG Chair might decide the I-D still needs more work, and then it goes back to "WG Document" for a while 🌈.

4.2. Working Group I-D States 🦋

The WG I-D states in this section are a superset of the I-D states that are currently used across all IETF WGs 💜.

All of these states need to be added to the front-end of the IESG state machine [IESGIDSM] that's already implemented in the IETF Datatracker 🎀.

WG Chairs and their Delegates get to pick whichever WG I-D states feel right for describing the WG status of the I-Ds in their WG 💖. Main character energy 👑.

It's not suggested or implied that Chairs have to use every single I-D state in here to describe the status and progress of all their I-Ds 🙈. Chairs can use all of the WG I-D states, or just some of them, totally up to them ✨.

Also, an I-D that isn't associated with a WG will sit in a 'Null' state with respect to the WG state machine in Figure 1 🧚.

4.2.1. Call for Adoption by WG Issued 📣

The "Call for Adoption by WG Issued" state is for when an I-D is being considered for adoption by an IETF WG 🔍. An I-D in this state is actively being looked at for adoption, and it hasn't reached consensus, preference, or selection in the WG yet 🌸.

This state can describe an I-D that someone has asked a WG to consider for adoption, as long as the WG Chair has said yes to the request 💌. It can also be used for an I-D that a WG Chair asked an author to write specifically as a candidate WG item [WGDTSPEC] 🎀, and for an I-D that's listed as a 'candidate draft' in the WG's charter 📜.

Under normal conditions, an I-D should not be in the "Call for Adoption by WG Issued" state in more than one working group at the same time 🙅‍♀️. That said, it's really common for authors to "shop" their I-Ds to more than one WG at once, hoping one of them will adopt it 🛍️ (lowkey iconic, honestly 😭).

Once this state is implemented in the Datatracker, an I-D in the "Call for Adoption by WG Issued" state won't be able to be "shopped" to any other WG without the consent of the WG Chairs and the responsible ADs impacted by the shopping 🚫.

Figure 1 has an arc going from this state to outside of the WG state machine 🏃‍♀️. That shows some I-Ds that get considered never end up being adopted as WG drafts 💀. An I-D that isn't adopted as a WG draft will leave the WG state machine and go back to having no stream-specific state 🔄. The status change history log of that I-D will still record that it used to be in the "Call for Adoption by WG Issued" state 📖💜.

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

WG Chairs who use this state can clearly show when their WG adopts individual submission I-Ds 🎉. That makes it way easier for the Datatracker to correctly capture "Replaces" information for WG drafts, and to fix up "Replaced by" information for individual submission I-Ds that got replaced by WG drafts 🔁.

This state is needed because the Datatracker uses the filename of an I-D as a key to search its database for status info about that I-D 🔑. It's also needed because the filename of a WG I-D is supposed to be different from the filename of an individual submission I-D 🙃.

An individual submission I-D usually has a filename formatted as 'draft-author-wgname-topic-nn' 📝.

A WG document's filename is supposed to be formatted as 'draft-ietf-wgname-topic-nn' 🌟.

An individual I-D that gets adopted by a WG can take weeks or even months before the author resubmits it as a new (version-00) WG draft 🐢. If the "Adopted by a WG" state isn't used, the Datatracker has no way of knowing that an I-D has been adopted, not until a new version gets submitted to the WG by the author and a WG Chair approves it for posting 😤.

4.2.3. Adopted for WG Info Only 📚

The "Adopted for WG Info Only" state describes a document that holds useful information for the WG that adopted it 🧠. The catch is that the document isn't meant to be published as an RFC 🙅‍♀️. The WG won't actively develop its contents or push it toward publication as an RFC 💅. Its only purpose is to give information for the WG's own internal use 🫶.

4.2.4. WG Document 📄✨

The "WG Document" state describes an I-D that an IETF WG has adopted and is actively developing 🛠️.

A WG Chair can move an I-D into the "WG Document" state at any time, as long as the I-D isn't being considered or developed in any other WG 🙌.

Or, WG Chairs can rely on new Datatracker functionality that automatically moves version-00 drafts into the "WG Document" state, like we talked about in Section 4.1 🤖💕.

Under normal conditions, an I-D should not be in the "WG Document" state in more than one WG at a time 🚫. That said, I-Ds can be transferred from one WG to another, with the consent of the WG Chairs and the responsible ADs 🦋.

4.2.5. Parked WG Document 🅿️

A "Parked WG Document" is an I-D that has lost its author or editor 😢. It might be waiting for another document to be written, or for a review to be finished 🔎. It might also be stuck because the working group can't progress it for some other reason 🧱.

Some of the annotation tags from Section 4.3 can be used alongside this state to show why an I-D got parked, and/or what needs to happen for it to be un-parked 🏷️.

Parking a WG draft won't stop it from expiring 😬. This state is still useful, though, for showing why the I-D stopped progressing in the WG 💜.

A "Parked WG Document" that hasn't expired can be transferred from one WG to another, with the consent of the WG Chairs and the responsible ADs 🌈.

4.2.6. Dead WG Document 💀🌹

A "Dead WG Document" is an I-D that has been abandoned 🪦. But 'Dead' isn't always the final state for a WG I-D, bestie 🧚. If consensus gets reached later on, a "Dead WG Document" can be resurrected 🔥. A "Dead WG Document" that doesn't get resurrected will eventually expire 🍂.

An I-D that's declared "Dead" in one WG, and hasn't expired yet, can be moved to a non-dead state in another WG, with the consent of the WG Chairs and the responsible ADs 🔁💖.

4.2.7. In WG Last Call 📣

okay so a document is "In WG Last Call" when it's an I-D that has a WG Last Call (WGLC) issued and in progress 🫶

btw conducting a WGLC is optional in the IETF WG process, per Section 7.4 of RFC 2418 [RFC2418] 🤓

if a WG Chair decides to run a WGLC on an I-D, the "In WG Last Call" state is how you track it ✨ the Chair can set up the Datatracker to send a WGLC message to one or more mailing lists when they move the I-D into this state 📬 and the WG Chair can pick a different set of mailing lists for a different document in a WGLC, since some docs deserve coordination with other WGs 🧚

a WG I-D in this state should remain "In WG Last Call" until the WG Chair moves it somewhere else 💅 the Chair can also configure the Datatracker to send an e-mail after a set amount of time to gently 'nudge' them to wrap up the WGLC and decide the next state for the doc 🔥

it's possible for one WGLC to lead into another WGLC for the same document 🌈 for example, an I-D that finished a WGLC as an "Informational" document might need another WGLC if the group decides to turn it into a Standards Track document 💜

4.2.8. Waiting for WG Chair Go-Ahead 🙈

a WG Chair might want to put an I-D that gets a lot of comments during a WGLC into the "Waiting for WG Chair Go-Ahead" state 😭 this state means the I-D has been through a WGLC, but the Chair isn't ready to call consensus on it yet

if comments from the WGLC need answering, or the I-D needs a revision, the Chair can park it in this state until all of the WGLC comments are properly addressed and the (possibly revised) document is in the I-D repository 🎀

4.2.9. WG Consensus: Waiting for Writeup 🍓

a document in the "WG Consensus: Waiting for Writeup" state has basically finished its development inside the working group and is almost ready to go to the IESG for publication ✨ the last thing left is a protocol writeup prepared by a Document Shepherd 💖 the IESG requires that a document shepherd writeup be completed before publication of the I-D is requested 👑 the IETF document shepherding process and the role of a WG Document Shepherd are described in RFC 4858 [RFC4858]

a WG Chair can call consensus on an I-D without a formal WGLC and move an I-D that was in the "WG Document" state straight into this state 🦋

the name includes "Waiting for Writeup" because a good document shepherd writeup takes time to put together 🫠

4.2.10. 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 working group for revision 💅

an I-D in this state might be under review by the IESG 👀 it might have been approved and be sitting in the RFC Editor's queue, or it might already be published as an RFC 🎉 other possibilities exist too ✨ the document could be "Dead" (in the IESG state machine) or in a "Do Not Publish" state 💀

4.3. Working Group I-D Status Annotation Tags 🏷️

besides showing which state a working group draft is in, the Datatracker lets you identify and track several substate conditions 💜 this section defines annotation tags that can describe a condition affecting a WG I-D (like why a document is in the state it's in) or point to an action needed to move the document forward 🌸

annotation tags do not change the WG I-D state of WG drafts 🙌

each annotation tag defined here can give more info about the status of any WG draft in any state, when that makes sense 🧚 you can use a tag all by itself or stack it with other tags 🫶

4.3.1. Awaiting Expert Review/Resolution of Issues Raised 🔍

this tag means someone (like an author or editor of the WG draft, or a WG Chair) has started an expert review of the document, and either the review isn't finished yet or the issues it raised aren't resolved yet ⏳ examples of expert reviews include cross-area reviews, MIB Doctor reviews, security expert reviews, and IANA reviews 🛡️

WG drafts with this annotation should keep the tag until the review is complete and possibly until any issues raised in the review are addressed 💖

4.3.2. Awaiting External Review/Resolution of Issues Raised 🌍

this tag means someone (like an author or editor of the WG draft, or a WG Chair) has started some other review of the document 🤝 for example, they sent it to another Standards Development Organization (SDO) for comments through a formal or informal liaison process 📨 and the review isn't finished yet or the issues it raised aren't resolved yet ⏳

WG drafts with this annotation should keep the tag until the review is complete and possibly until any issues raised in the review are addressed 💜

4.3.3. Awaiting Merge with Other Document 🫂

this tag means someone (like the document author, editor, or the WG Chair) has decided to merge the I-D with one or more other I-Ds from the same (or another) working group 💫

if the merge produces a new I-D with a different title, the old I-D can be declared a "Dead WG Document" 🪦 in that case the annotation tag should change from "Awaiting Merge with Other Document" to "Other - see Comment Log", and a description of the merge should go into the log for posterity 📜

the Datatracker's regular 'Replaced by' information should also be set on the old I-Ds so people can easily find the new merged doc from the old ones 🔗

if the merge is a revision to the old I-D instead, this annotation tag should be cleared once the revised (merged) I-D is submitted to the WG ✨

4.3.4. Author or Editor Needed 😢

this tag means an I-D has lost a primary author or editor, and no further work can continue in an effective or efficient way until a new author or editor is found 🥺

this tag should be removed after a new primary author or editor is found 🥰

4.3.5. Waiting for Referenced Document ⏸️

this tag means the I-D is on hold because it depends on one or more other documents 🧩 a typical example is an I-D that depends on another IETF document that hasn't progressed far enough to be referenced yet 📚 the dependency could be on documents in other IETF Working Groups or on work in progress documents in other SDOs 🌐

this tag should be removed after the dependency is cleared 🎀

4.3.6. Waiting for Referencing Document 🤲

this tag means the I-D is on hold because one or more other documents depend on it, and the WG Chair wants to submit all of those documents to the IESG (for publication) at the same time 🎁 this tag is the inverse of 4.3.5. 🙃

this tag should be removed after the dependency is cleared 💅

4.3.7. Revised I-D Needed - Issue raised by WGLC ✍️

this annotation can flag an I-D that needs a revision to address issues raised during a Working Group Last Call 🚩 it can also show when the I-D is being revised right now 🛠️

this tag should be removed after a revised version of the I-D is submitted to the WG 🫶

4.3.8. Revised I-D Needed - Issue raised by AD 🧐

this annotation means the responsible AD raised one or more issues with the I-D during "AD Evaluation" and sent the document back to the working group for revision 🔙 it can also show when the I-D is in the middle of being revised 🌷

this tag should be removed after the revised version of the I-D is submitted to the WG 💖

4.3.9. Revised I-D Needed - Issue raised by IESG 🧾

this annotation means one or more IESG members had issues with the I-D during "IESG Evaluation", so the document went back to the working group for revision 😬 it can also show that the revision is in process 🔧

this tag should be removed after the revised version of the I-D is submitted to the WG 🎉

4.3.10. Doc Shepherd Followup Underway 🐑

this annotation tag can show that the Document Shepherd for the WG document has started working on the writeup needed to submit the document (to the IESG) for publication ✍️

it's possible for too many I-Ds to land in a shepherd's queue in too short a time, so the shepherd can't write satisfactory writeups for all of them at once 😵‍💫

when this tag is set, it means the Document Shepherd has started the writeup for the I-D 🏁 if the tag is absent or has been reset on an I-D in the "WG Consensus: Waiting for Writeup" state, that means the writeup hasn't been started yet or has been put on hold for some reason ⏸️

4.3.11. Other - see Comment Log 💬

this annotation tag is a catch-all for when someone (like an author or editor of the document, the WG Chair, or the Document Shepherd) has entered one or more comments about the current status of the I-D into the IETF Datatracker 📝

5. Intended Maturity Level of WG Drafts 🎓

the IESG requires a WG I-D to have an "intended maturity level" (like Informational, Proposed Standard, or Experimental) before the I-D is submitted to the IESG for evaluation and publication 📋 IETF participants ask about this a lot too 🙋‍♀️

I-D maturity levels were first defined in Sections 4 and 5 of RFC 2026 [RFC2026] 📖 the names of the maturity levels in use today are:

"Experimental" 🧪
"Informational" ℹ️
"Best Current Practice" 🏆
"Proposed Standard" 🌟
"Draft Standard" ✏️
"Standard" 👑
"Historic" 🏛️

the Datatracker may need an upgrade so WG Chairs can enter and/or change the intended maturity level of a WG draft before the I-D goes to the IESG 💖

6. Security Considerations 🔐

okay bestie, this one is short and sweet 🫶 this document doesn't propose any new Internet mechanisms, so it has no security implications for the Internet 🛡️✨

7. References 📚

7.1. Normative References 🔗

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 📘

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

[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. 📙

7.2. Informative References 📚

These are the extra-reading refs 💅, the ones that give you context without being part of the core spec:

[AUTHGUIDE] Housley, R., Ed. (for the IESG), "Guidelines to Authors of Internet-Drafts", December 7, 2010, http://www.ietf.org/ietf/1id-guidelines.txt.
[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.
[IESGSTAT] "Main I-D States", Web Application: https://datatracker.ietf.org/idtracker/help/state/, Version 3.12, February 2, 2011.
[PROTO] Levkowetz, H. and Mankin, A., "Requirements on I-D Tracker Extensions for Working Group Chairs", Work in Progress, February 2007.
[WGDTSPEC] Juskevicius, E., "Minutes of wgdtspec BOF", Proceedings of IETF 77, March 26, 2010, http://www.ietf.org/proceedings/10mar/minutes/wgdtspec.

8. Acknowledgments 🫶

Huge thank-you to Henrik Levkowetz and Allison Mankin 💖 for developing the original I-D [PROTO], which became the starting point for this doc. Also, a big shoutout to Alfred Hoenes for his many comments and suggestions 🙌 and for pointing out the need for the "Adopted by a WG" state 🦋.

The author would also like to thank Henrik Levkowetz, Russ Housley, Paul Hoffman, John Klensin, Pasi Eronen, Robert Sparks, Spencer Dawkins, Mary Barnes, Glenn Parsons, Marc Blanchet, Andy Malis, and Joel Halpern for their comments and feedback along the way 🌈.

Finally, the author wishes to thank the IETF WG Chairs, ADs, and other people who shared their insights and suggestions in real-time during the wgdtspec BOF at IETF 77 🎀. Thanks also to Lars Eggert, Tim Polk, Robert Sparks, Adrian Farrel, and Alexey Melnikov 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 🧚.

Appendix A. "IESG Document" States ✨

This Appendix describes the status information currently stored in the IETF Datatracker tool for every I-D submitted to the IESG for publication 📋. All of the terms and definitions in Sections A.1 and A.2 are copied from [IESGSTAT].

It must be noted 👀 that I-Ds sent to the IESG for publication (termed "IESG Documents" in this Appendix) do not stay with the IESG until the day they are published as RFCs. After evaluation, the IESG may declare that some I-Ds deserve a "Do Not Publish" label 🙅. Other I-Ds may become "Dead" 💀. Some I-Ds may get sent back to their originators (WGs or otherwise), and the rest may go into the RFC Editor queue 🍓.

Note that documents that are not tracked by the IESG (e.g., I-Ds for which no request has been made of the IESG) are in a null state with respect to the IESG state machine 🌸. The IESG state of an I-D that has no value assigned to the IESG state variable in the Datatracker's database is 'NULL'.

A.1. Definition of "IESG Document" States 🦋

A.1.1. Publication Requested

A formal request has been made to advance or publish the document, following the procedures in Section 7.5 of RFC 2418 [RFC2418] 📨. The request could come from a WG Chair or from an individual. Note: the Secretariat (iesg-secretary@ietf.org) is typically copied on these requests to make sure the request makes it into the Datatracker 💅. A document in this state has not (yet) been reviewed by an Area Director, and no official action has been taken yet, other than noting that its publication has been requested.

A.1.2. AD Evaluation

A specific AD (e.g., the "Area Advisor" for the WG) has started reviewing the document to verify that it is ready for advancement 🔍. The shepherding AD is responsible for doing any necessary review before starting an IETF Last Call or sending the document directly to the IESG as a whole.

A.1.3. Expert Review

Sometimes an AD asks an outside party for an external review as part of deciding whether a document is ready for advancement 🧐. MIBs, for example, are reviewed by "MIB doctors" 🩺. Other types of reviews may also be requested (e.g., security, operations impacts, etc.). Documents stay in this state until the review is complete and possibly until the issues raised in the review are addressed 🛠️.

Specific details on the nature of the review may be found in the "note" field associated with this state (i.e., within the Datatracker) 📝.

A.1.4. Last Call Requested

The AD has asked the Secretariat to start an IETF Last Call, but the actual Last Call message has not been sent yet 📣.

A.1.5. In Last Call

The document is currently waiting for the IETF Last Call to finish ⏳. Last Calls for WG documents typically last 2 weeks, and those for individual submissions last 4 weeks.

A.1.6. Waiting for Writeup

Before a standards-track or BCP document is formally considered by the entire IESG, the AD has to write up a protocol action ✍️. The protocol action is included in the approval message that the Secretariat sends out when the document is approved for publication as an RFC.

A.1.7. Waiting for AD Go-Ahead

After the IETF Last Call, comments may need responses, and the I-D may need a revision too 🔄. The AD is responsible for checking that all Last Call comments have been adequately addressed and that the (possibly revised) document is ready for the IESG as a whole 👀.

A.1.8. IESG Evaluation

The document is now (finally!) being formally reviewed by the entire IESG 🎉. Documents are discussed by email or during a bi-weekly IESG telechat 📞. In this phase, each AD reviews the document and airs any content or process issues they may have. Issues that can't be resolved get documented as "DISCUSS" comments that can be forwarded to the authors/WG 🗣️. See the description of IESG substates in Section A.2 for more details about the current state of the IESG discussion.

A.1.9. IESG Evaluation - Defer

During a telechat, one or more ADs asked for an extra two weeks to review the document ⏰. A defer is designed to be an exception mechanism, and it can only be invoked once, the first time the document comes up for discussion during a telechat 🙅‍♀️.

A.1.10. Approved - announcement to be sent

The IESG has approved the document for publication, but the Secretariat has not (yet) sent the official approval message ✅.

A.1.11. Approved - announcement sent

The IESG has approved the document for publication, and the Secretariat has sent the official approval message to the RFC Editor 🎊.

A.1.12. RFC Ed Queue

The document is in the RFC Editor Queue (as confirmed by http://www.rfc-editor.org/queue2.html) 📬.

A.1.13. RFC Published

The I-D has been published as an RFC 🏆.

A.1.14. DNP - waiting for AD note

Do Not Publish (DNP): The IESG recommends against publishing the document, but the writeup explaining why hasn't been produced yet 😬. DNPs apply mainly to individual submissions received through the RFC Editor. See the "note" field for more details on who has the action item.

A.1.15. DNP - announcement to be sent

The IESG recommends against publishing the document 🚫. The writeup explaining the IESG's reasoning has been produced, but the Secretariat has not yet sent out the official "Do Not Publish" recommendation message 📤.

A.1.16. AD is watching

An AD knows about the document and has chosen to put it in a separate state so they can monitor it (for whatever reason) 👁️. Documents in this state are not actively tracked by the IESG, in the sense that no formal request has been made to publish or advance them. The AD chose this state to make it easier to keep track of the document, for their own reasons 🧠.

A.1.17. Dead

The document is "Dead" and is no longer being tracked 💀. For example, it may have been replaced by another document with a different name, or it may have been withdrawn.

A.2. IESG Document Substates 🌈

Note that the annotation tags described in this section were defined circa 2002 🕰️. If these conditions were modelled today, they would most likely be modelled as annotation tags rather than as substates.

A.2.1. Point Raised - writeup needed

IESG discussions on the document have raised some issues that need to be brought to the attention of the authors/WG, but those issues haven't been written down yet 📝. (It's common for discussions during a telechat to end up like this. An AD may raise a possible issue during a telechat and only decide, as a result of that discussion, whether the issue is worth formally writing up and bringing to the attention of the authors/WG.)

A document stays in the "Point Raised - writeup needed" substate until ALL IESG blocking comments that have been raised have been documented 🚧.

A.2.2. AD Followup

"AD Followup" is a generic substate meaning the shepherding AD has to decide the next steps 🤔. The right steps (and the corresponding next state or substate) depend entirely on the nature of the issues raised, and they can only be decided with active involvement from the shepherding AD.

Examples include:

If another AD raises an issue, the shepherding AD may first iterate with the other AD to get a better understanding of the exact issue. Or, the shepherding AD may try to argue that the issue isn't serious enough to bring to the attention of the authors/WG 🙃.
If a documented issue is forwarded to a WG, some further iteration may be needed before it can be determined whether a new revision is needed or whether the WG response clarifies the issue sufficiently 🔁.
When a new revision appears, the shepherding AD will first look at the changes to decide whether they believe all outstanding issues have been raised satisfactorily, before asking the ADs who raised the original issues to verify the changes ✅.

A.2.3. External Party

The document is waiting for review or input from an external party (i.e., someone other than the shepherding AD, the authors, or the WG) 🤝. See the "note" field for more details on who has the action.

A.2.4. Revised ID Needed

An updated I-D is needed to address the issues that have been raised ✏️.

Author's Address 💌

Ed Juskevicius
TrekAhead
PO Box 491, Carp, ON
CANADA

EMail: edj.etc@gmail.com

📦 where this page comes from

ietf: rfc6174 2011-03
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms