    Internet Engineering Task Force (IETF)                    E. Juskevicius
    Request for Comments: 6174                                     TrekAhead
    Category: Informational                                       March 2011
    ISSN: 2070-1721

                Definition of IETF Working Group Document States

    Abstract

       The IETF Datatracker tool needs to be enhanced to make it possible
       for Working Group (WG) Chairs to provide IETF participants with more
       information about the status and progression of WG documents than is
       currently possible.

       This document defines new states and status annotation tags that need
       to be added to the Datatracker to enable WG Chairs and their
       Delegates to track the status of Internet-Drafts (I-Ds) that are
       associated with their WGs.  This document also describes the meaning
       of all previously implemented I-D states and substate annotation tags
       currently used by IETF Area Directors to indicate the status of I-Ds
       that have been sent to the IESG for evaluation and publication.

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Not all documents
       approved by the IESG are a candidate for any level of Internet
       Standard; see Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc6174.

    Juskevicius                   Informational                     [Page 1]

    RFC 6174           IETF Working Group Document States         March 2011

    Copyright Notice

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

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (http://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.

    Table of Contents

       1. Introduction ....................................................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

    Juskevicius                   Informational                     [Page 2]

    RFC 6174           IETF Working Group Document States         March 2011

               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

    Juskevicius                   Informational                     [Page 3]

    RFC 6174           IETF Working Group Document States         March 2011

    1.  Introduction

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

       The Datatracker is currently able to 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 describes all of the
       document states and substate annotation tags used by IETF Area
       Directors (ADs) to indicate the status of I-Ds that have been sent to
       the IESG.

       In contrast, the Datatracker has almost no ability to indicate the
       status and progression of I-Ds before they are sent to the IESG.  The
       Datatracker can only track the availability status of I-Ds today
       (e.g., "Active", Expired", "Withdrawn", "Replaced by") and in some
       cases indicate which IETF Working Group (WG) an I-D is associated
       with (if any).

       Section 3 of this document contains a summary of the Datatracker's
       current ability to track and report on the status of I-Ds in the IETF
       document stream.  The IETF document stream is defined in Section
       5.1.1 of RFC 4844 [RFC4844].

       Section 4 of this document defines several new I-D states and I-D
       status annotation tags that need to be added to the Datatracker to
       enable status tracking and reporting for WG I-Ds.

    2.  Conventions Used in This Document

       A "working group I-D" (WG I-D) is an Internet-Draft that has achieved
       consensus for adoption as a work item by a WG (compared to an
       individual submission I-D that has not, or has not yet, achieved
       consensus).

       The terms "WG I-D", "WG document", and "WG draft" are used
       synonymously throughout this document.  The same is true for the
       plural case of each term.

       The terms "WG document" and "WG draft" are not intended to apply to
       any other document that may be reviewed, discussed, or produced by an
       IETF working group.  Working group meeting materials such as Blue
       Sheets, agendas, jabber logs, scribe's notes, minutes, and
       presentation slides are not to be considered "WG documents" or "WG
       drafts" in the context of this document.

    Juskevicius                   Informational                     [Page 4]

    RFC 6174           IETF Working Group Document States         March 2011

       The phrase "WG status of an I-D" is to be interpreted as referring to
       the state that an I-D is in, as defined in Section 4.2 of this
       document.  This phrase does not refer to an I-D's availability status
       (e.g., "Expired", "Active", "Replaced by") as described in Section
       3.1, or to any of the IESG states used by Area Directors to describe
       the status of I-Ds they may be evaluating.

    3.  I-D States Already Implemented by the Datatracker

       This section describes capabilities that are currently implemented in
       the Datatracker to track the status of I-Ds in the IETF document
       stream.

       The document availability states described in Section 3.1 are
       applicable to every I-D submitted to the IETF.

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

       The Datatracker currently has no I-D states or I-D status annotation
       tags to describe the WG status of any I-D.

    3.1.  I-D Availability States

       The Datatracker currently maintains availability status information
       for every I-D submitted to the IETF.  The I-D availability states are
       as follows:

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

       The first four I-D availability states are explained in the following
       subsections.  The other states are self-explanatory.

       Note that the Datatracker describes the status of some I-Ds with the
       phrase "I-D Exists".  "I-D Exists" is the state that is manufactured
       by the Datatracker to describe I-Ds for which it has no other status
       information.  For example, the tool currently uses "I-D Exists" to
       describe I-Ds that are not expired and that have not been sent to the
       IESG.

    Juskevicius                   Informational                     [Page 5]

    RFC 6174           IETF Working Group Document States         March 2011

    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.

       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.  One exception is that an I-D
       undergoing official evaluation by the IESG will not be expired before
       its status is resolved (e.g., the I-D is published as an RFC).  IESG
       states that do not relate to a formal request to publish a document
       (e.g., "AD is Watching") do not prevent 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 is applicable 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.  As a result, the "Active" I-D availability state
       cannot be used to determine 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 subsequently resubmitted to the I-D
       repository for some reason.

       Two common uses of "Replaced by" are as follows:

       -  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 having a filename
          that 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.

    Juskevicius                   Informational                     [Page 6]

    RFC 6174           IETF Working Group Document States         March 2011

       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 the following:

       -  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 maintains detailed information about the status and
       progression of I-Ds that have been sent to the IESG for evaluation
       and publication.

       All of the states used by Area Directors to indicate 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/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 the
       I-D other than to note that its publication has been requested.

    Juskevicius                   Informational                     [Page 7]

    RFC 6174           IETF Working Group Document States         March 2011

       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.
       This 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 that is 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 status 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 he/she may have with the document.  Issues that are
       blocking 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.  During the time that the I-D is being
       revised, the WG Chair may decide to transition the I-D 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").

    Juskevicius                   Informational                     [Page 8]

    RFC 6174           IETF Working Group Document States         March 2011

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

       The status-tracking states described in Section 3 are currently
       implemented in the Datatracker; however, their scope is not broad
       enough to provide 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 to make it possible for WG
       Chairs and/or their Delegates (e.g., WG Secretaries) to indicate 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 of the WG I-D states must be used by all WG Chairs to
       describe the status and progression of the I-Ds associated with their
       WGs.  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

       Figure 1 is a state machine diagram that illustrates all of the WG
       I-D states defined in Section 4.2 of this document.  The names of the
       WG I-D states are capitalized for clarity, and common state
       transitions are indicated via the solid, dashed, and dotted lines.

       The WG I-D state machine illustrated in Figure 1 is intended to be a
       new front-end to the IESG I-D state machine [IESGIDSM] that is
       currently implemented in Datatracker.

       Note that Figure 1 does not show every possible state transition.  WG
       Chairs may move an I-D from any WG state to any other WG state as
       appropriate to describe the WG status of the document.  The lack of
       an explicit path between two states does not mean that such a state
       transition is precluded.

       The first WG I-D state is "Call for Adoption by WG Issued" and its
       meaning and usage are defined in Section 4.2.1.

       One of several possible last states for a WG I-D is "Submitted to
       IESG for Publication".  This state is defined in Section 4.2.10.

    Juskevicius                   Informational                     [Page 9]

    RFC 6174           IETF Working Group Document States         March 2011

             "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

    Juskevicius                   Informational                    [Page 10]

    RFC 6174           IETF Working Group Document States         March 2011

       The Datatracker will be enhanced to automatically generate the
       following two state transitions for all WG drafts:

       -  A version-00 I-D that conforms to the 'draft-ietf-wgname-topic-00'
          file naming convention will be moved into the "WG Document" state
          automatically by the Datatracker when the WG Chair approves the
          posting of an I-D; and

       -  A WG draft that is 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".

       All other WG I-D state transitions will require the WG Chairs or
       their Delegates to log in to the Datatracker to manually input the
       appropriate WG state to describe the WG status of an I-D.

       Note that Figure 1 includes an arc from the "Submitted to IESG for
       Publication" state back to the "WG Document" state.  This is one
       example of what may happen after an AD or the IESG as a whole sends
       an I-D back to a WG for revision.  The WG chair may decide that the
       I-D needs further development and that it needs to return to the "WG
       Document" state for a while.

    4.2.  Working Group I-D States

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

       All of the states described herein need to be added to the front-end
       of IESG state machine [IESGIDSM] that has already been implemented in
       the IETF Datatracker.

       WG Chairs and their Delegates will be given the flexibility to use
       whichever of the WG I-D states they feel to be appropriate to
       describe the WG status of the I-Ds associated with their WG.

       It is not suggested or implied that Chairs must use all of the I-D
       states defined herein to describe the status and progression of all
       I-Ds associated with their WGs; Chairs may use all of the WG I-D
       states, or just some of the states.

       Note that an I-D that is not associated with a WG will be in a 'Null'
       state with respect to the WG state machine in Figure 1.

    Juskevicius                   Informational                    [Page 11]

    RFC 6174           IETF Working Group Document States         March 2011

    4.2.1.  Call for Adoption by WG Issued

       The "Call for Adoption by WG Issued" state should be used to indicate
       when an I-D is being considered for adoption by an IETF WG.  An I-D
       that is in this state is actively being considered for adoption and
       has not yet achieved consensus, preference, or selection in the WG.

       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 [WGDTSPEC], and/or an I-D that is listed as a
       'candidate draft' in the WG's charter.

       Under normal conditions, it should not be possible for an I-D to be
       in the "Call for Adoption by WG Issued" state in more than one
       working group at the same time.  This said, it is not uncommon for
       authors to "shop" their I-Ds to more than one WG at a time, with the
       hope of getting their documents adopted somewhere.

       After this state is implemented in the Datatracker, an I-D that is in
       the "Call for Adoption by WG Issued" state will not be able to be
       "shopped" to any other WG without the consent of the WG Chairs and
       the responsible ADs impacted by the shopping.

       Note that Figure 1 includes an arc leading from this state to outside
       of the WG state machine.  This illustrates that some I-Ds that are
       considered do not get adopted as WG drafts.  An I-D that is not
       adopted as a WG draft will transition out of the WG state machine and
       revert back to having no stream-specific state; however, the status
       change history log of the I-D will record that the I-D was previously
       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 will be able to clearly indicate when
       their WGs adopt individual submission I-Ds.  This will facilitate the
       Datatracker's ability to correctly capture "Replaces" information for
       WG drafts and correct "Replaced by" information for individual
       submission I-Ds that have been 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 information about the
       I-D, and because the filename of a WG I-D is supposed to be different
       from the filename of an individual submission I-D.

    Juskevicius                   Informational                    [Page 12]

    RFC 6174           IETF Working Group Document States         March 2011

       The filename of an individual submission I-D will typically be
       formatted as 'draft-author-wgname-topic-nn'.

       The filename of a WG document is supposed to be formatted as 'draft-
       ietf-wgname-topic-nn'.

       An individual 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.  If the
       "Adopted by a WG" state is not used, the Datatracker has no way to
       determine that an I-D has been adopted until a new version of the I-D
       is submitted to the WG by the author and until the I-D is approved
       for posting by a WG Chair.

    4.2.3.  Adopted for WG Info Only

       The "Adopted for WG Info Only" state describes a document that
       contains useful information for the WG that adopted it, but the
       document is not intended to be published as an RFC.  The WG will not
       actively develop the contents of the I-D or progress it for
       publication as an RFC.  The only purpose of the I-D is to provide
       information for internal use by the WG.

    4.2.4.  WG Document

       The "WG Document" state describes an I-D that has been adopted by an
       IETF WG and is being actively developed.

       A WG Chair may transition an I-D into the "WG Document" state at any
       time as long as the I-D is not being considered or developed in any
       other WG.

       Alternatively, WG Chairs may rely upon new functionality to be added
       to the Datatracker to automatically move version-00 drafts into the
       "WG Document" state as described in Section 4.1.

       Under normal conditions, it should not be possible for an I-D to be
       in the "WG Document" state in more than one WG at a time.  This said,
       I-Ds may 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,
       is waiting for another document to be written or for a review to be
       completed, or cannot be progressed by the working group for some
       other reason.

    Juskevicius                   Informational                    [Page 13]

    RFC 6174           IETF Working Group Document States         March 2011

       Some of the annotation tags described in Section 4.3 may be used in
       conjunction with this state to indicate why an I-D has been parked,
       and/or what may need to happen for the I-D to be un-parked.

       Parking a WG draft will not prevent it from expiring; however, this
       state can be used to indicate why the I-D has stopped progressing in
       the WG.

       A "Parked WG Document" that is not expired may 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.  Note that
       'Dead' is not always a final state for a WG I-D.  If consensus is
       subsequently achieved, a "Dead WG Document" may be resurrected.  A
       "Dead WG Document" that is not resurrected will eventually expire.

       Note that an I-D that is declared to be "Dead" in one WG and that is
       not expired may be transferred 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

       A document "In WG Last Call" is an I-D for which a WG Last Call
       (WGLC) has been issued and is in progress.

       Note that conducting a WGLC is an optional part of the IETF WG
       process, per Section 7.4 of RFC 2418 [RFC2418].

       If a WG Chair decides to conduct a WGLC on an I-D, the "In WG Last
       Call" state can be used to track the progress of the WGLC.  The Chair
       may configure the Datatracker to send a WGLC message to one or more
       mailing lists when the Chair moves the I-D into this state.  The WG
       Chair may also be able to select a different set of mailing lists for
       a different document undergoing a WGLC; some documents may deserve
       coordination with other WGs.

       A WG I-D in this state should remain "In WG Last Call" until the WG
       Chair moves it to another state.  The WG Chair may configure the
       Datatracker to send an e-mail after a specified period of time to
       remind or 'nudge' the Chair to conclude the WGLC and to determine the
       next state for the document.

    Juskevicius                   Informational                    [Page 14]

    RFC 6174           IETF Working Group Document States         March 2011

       It is possible for one WGLC to lead into another WGLC for the same
       document.  For example, an I-D that completed a WGLC as an
       "Informational" document may need another WGLC if a decision is taken
       to convert the I-D into a Standards Track document.

    4.2.8.  Waiting for WG Chair Go-Ahead

       A WG Chair may wish to place an I-D that receives a lot of comments
       during a WGLC into the "Waiting for WG Chair Go-Ahead" state.  This
       state describes an I-D that has undergone a WGLC; however, the Chair
       is not yet ready to call consensus on the document.

       If comments from the WGLC need to be responded to, or a revision to
       the I-D is needed, the Chair may place an I-D into this state until
       all of the WGLC comments are adequately 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
       essentially completed its development within the working group, and
       is nearly ready to be sent to the IESG for publication.  The last
       thing to be done is the preparation of a protocol writeup 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 is described in RFC 4858 [RFC4858]

       A WG Chair may call consensus on an I-D without a formal WGLC and
       transition an I-D that was in the "WG Document" state directly into
       this state.

       The name of this state includes the words "Waiting for Writeup"
       because a good document shepherd writeup takes time to prepare.

    4.2.10.  Submitted to IESG for Publication

       This state describes a WG document that has been submitted to the
       IESG for publication and that has not been sent back to the working
       group for revision.

       An I-D in this state may be under review by the IESG, it may have
       been approved and be in the RFC Editor's queue, or it may have been
       published as an RFC.  Other possibilities exist too.  The document
       may be "Dead" (in the IESG state machine) or in a "Do Not Publish"
       state.

    Juskevicius                   Informational                    [Page 15]

    RFC 6174           IETF Working Group Document States         March 2011

    4.3.  Working Group I-D Status Annotation Tags

       In addition to indicating which state a working group draft is in,
       the Datatracker will allow several substate conditions to be
       identified and tracked.  This section defines annotation tags that
       may be used to describe a condition that is affecting a WG I-D (e.g.,
       why a document is in the state it is in) or to indicate an action
       needed to progress the document.

       Annotation tags do not change the WG I-D state of WG drafts.

       Each of the annotation tags defined herein may be used to provide
       more information about the status of any WG draft in any state, if it
       makes sense to do so.  Each annotation tag may be used by itself, or
       in combination with other tags.

    4.3.1.  Awaiting Expert Review/Resolution of Issues Raised

       This tag means that someone (e.g., an author or editor of the WG
       draft, or a WG Chair) has initiated an expert review of the document
       and the review has not yet been completed and/or the resolution of
       issues raised by the review has not yet been completed.  Examples of
       expert reviews include cross-area reviews, MIB Doctor reviews,
       security expert reviews, and IANA reviews.

       WG drafts tagged with this annotation should retain 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 that someone (e.g., an author or editor of the WG
       draft, or a WG Chair) has initiated some other review of the document
       (e.g., sent it to another Standards Development Organization (SDO)
       for comments via a formal or informal liaison process), and the
       review has not yet been completed and/or the resolution of issues
       raised by the review has not yet been completed.

       WG drafts tagged with this annotation should retain 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 a decision has been made by someone (e.g., the
       document author, editor, or the WG Chair) to merge the I-D with one
       or more other I-Ds from the same (or another) working group.

    Juskevicius                   Informational                    [Page 16]

    RFC 6174           IETF Working Group Document States         March 2011

       If the result of the merge is a new I-D having a different title,
       then the old I-D may be declared as being a "Dead WG Document".  In
       such a case, the annotation tag should be changed from "Awaiting
       Merge with Other Document" to "Other - see Comment Log" and a
       description of the merge should be entered into the log for
       posterity.

       The Datatracker's regular 'Replaced by' information should also be
       set for the old I-Ds to make it easier to find the new merged
       document from the old documents.

       If the result of the merge operation is a revision to the old I-D,
       this annotation tag should be cleared when 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 that
       further work on the I-D cannot continue in an effective or efficient
       manner 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 that completion of the I-D is on-hold because the
       draft has a dependency on one or more other documents.  A typical
       example is where an I-D depends on another IETF document that has not
       yet progressed to a point where it may be referenced; the dependency
       may be on one or more 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 that completion of the I-D is on-hold because one or
       more other documents are dependent on it, and the WG Chair wants to
       submit all of the documents to the IESG (for publication)
       simultaneously.  This tag is the inverse of 4.3.5.

       This tag should be removed after the dependency is cleared.

    Juskevicius                   Informational                    [Page 17]

    RFC 6174           IETF Working Group Document States         March 2011

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

       This annotation may be used to flag an I-D that needs to be revised
       to address issues raised during a Working Group Last Call.  This
       annotation may also be used to indicate when the I-D is in the
       process of being revised.

       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 that the AD has sent the
       document back to the working group for revision.  This annotation may
       also be used to indicate when the I-D is in the process 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 that one or more IESG members had issues with
       the I-D during "IESG Evaluation" and the document has been sent back
       to the working group for revision.  This annotation may also be used
       to indicate that the revision to the I-D 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 may be used to indicate that the Document
       Shepherd for the WG document has begun working on the writeup
       required to submit the document (to the IESG) for publication.

       It is possible that too many I-Ds may arrive in a shepherd's queue in
       too short a time, and the shepherd cannot create satisfactory
       writeups for all of the documents simultaneously.

       When this annotation tag is set, it means the Document Shepherd has
       started work on the writeup for the I-D.  The absence or resetting of
       this annotation tag for an I-D in the "WG Consensus: Waiting for
       Writeup" state indicates the writeup has not yet been started, or has
       been put on-hold for some reason.

    Juskevicius                   Informational                    [Page 18]

    RFC 6174           IETF Working Group Document States         March 2011

    4.3.11.  Other - see Comment Log

       This annotation tag is a catch-all to indicate that someone (e.g., an
       author or editor of the document, the WG Chair, 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"
       associated with it (e.g., Informational, Proposed Standard,
       Experimental) before the I-D is submitted to the IESG for evaluation
       and publication.  This information is also often requested by IETF
       participants.

       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 to be enhanced to enable WG Chairs to input
       and/or change the intended maturity level of a WG draft before the
       I-D is sent to the IESG.

    6.  Security Considerations

       This document does not propose any new Internet mechanisms and 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.

    Juskevicius                   Informational                    [Page 19]

    RFC 6174           IETF Working Group Document States         March 2011

    7.2.  Informative References

       [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

       The author would like to thank Henrik Levkowetz and Allison Mankin
       for developing the original I-D [PROTO] that served as the starting
       point for this document, and Alfred Hoenes for his many comments and
       suggestions and for articulating 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 also wishes to thank the IETF WG Chairs, ADs and
       other people who contributed their insights and suggestions in real-
       time during the wgdtspec BOF at IETF 77, and 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.

    Juskevicius                   Informational                    [Page 20]

    RFC 6174           IETF Working Group Document States         March 2011

    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/publish the document,
       following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the
       request could be from a WG Chair, or from an individual.  Note: the
       Secretariat (iesg-secretary@ietf.org) is typically copied on these
       requests to ensure that the request makes it into the Datatracker.  A
       document in this state has not (yet) been reviewed by an Area
       Director nor has any official action been taken yet, other than to
       note that its publication has been requested.

    A.1.2.  AD Evaluation

       A specific AD (e.g., the "Area Advisor" for the WG) has begun their
       review of 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

       An AD sometimes asks for an external review by an outside party as
       part of evaluating 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,

    Juskevicius                   Informational                    [Page 21]

    RFC 6174           IETF Working Group Document States         March 2011

       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 requested that the Secretariat 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 IETF Last Call to complete.
       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 must 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

       As a result of the IETF Last Call, comments may need to be responded
       to and a revision of the I-D may be needed as well.  The AD is
       responsible for verifying that all Last Call comments have been
       adequately addressed and that the (possibly revised) document is
       ready for consideration by 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 in 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.  Unresolvable issues are
       documented as "DISCUSS" comments that can be forwarded to the
       authors/WG.  See the description of IESG substates in Section A.2 for
       additional details about the current state of the IESG discussion.

    Juskevicius                   Informational                    [Page 22]

    RFC 6174           IETF Working Group Document States         March 2011

    A.1.9.  IESG Evaluation - Defer

       During a telechat, one or more ADs requested an additional two weeks
       to review the document.  A defer is designed to be an exception
       mechanism, and 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 an official approval message.

    A.1.11.  Approved - announcement sent

       The IESG has approved the document for publication, and the
       Secretariat has sent out 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 its reasoning has not yet been
       produced.  DNPs apply primarily 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 is aware of the document and has chosen to place the document
       in a separate state in order to 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 the

    Juskevicius                   Informational                    [Page 23]

    RFC 6174           IETF Working Group Document States         March 2011

       document.  The AD has chosen to put the I-D into this state, to make
       it easier to keep track of (for his or her own reasons).

    A.1.17.  Dead

       The document is "Dead" and is no longer being tracked (e.g., it has
       been replaced by another document having a different name, it has
       been withdrawn, etc.)

    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 have
       not been written down yet. (It is common for discussions during a
       telechat to result in such situations.  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 indicating that the shepherding
       AD has the action to determine the appropriate next steps.  In
       particular, the appropriate steps (and the corresponding next state
       or substate) depend entirely on the nature of the issues that were
       raised and can only be decided with active involvement of 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 attempt to argue that the
          issue is not serious enough it to bring to the attention of the
          authors/WG.

    Juskevicius                   Informational                    [Page 24]

    RFC 6174           IETF Working Group Document States         March 2011

       -  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 to an issue clarifies the
          issue sufficiently.

       -  When a new revision appears, the shepherding AD will first look at
          the changes to determine whether they believe all outstanding
          issues have been raised satisfactorily, prior to asking the ADs
          who raised the original issues to verify the changes.

    A.2.3.  External Party

       The document is awaiting 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

    Juskevicius                   Informational                    [Page 25]