[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-proto-wgchair-tracker-ext) 00 01 02 03 04 05 06 07 08 09 10 RFC 6174

Proto                                                    E. Juskevicius
Internet Draft                                                TrekAhead
Intended status: Informational                          October 7, 2010
Expires: April 7, 2011


             Definition of IETF Working Group Document States
                 draft-ietf-proto-wgdocument-states-10.txt


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 Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 7, 2011.

Copyright Notice

   Copyright (c) 2010 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



Juskevicius             Expires April 7, 2011                  [Page 1]

Internet-Draft    IETF Working Group Document States       October 2010


   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................4
   3. I-D States already implemented by the Datatracker..............4
      3.1. I-D Availability States...................................5
         3.1.1. Expired..............................................5
         3.1.2. Active...............................................5
         3.1.3. Replaces & Replaced By...............................6
      3.2. IESG Document States......................................6
         3.2.1. Publication Requested................................7
         3.2.2. AD Evaluation........................................7
         3.2.3. IESG Evaluation......................................8
   4. New States and Status Annotation Tags for WG I-Ds..............8
      4.1. Working Group I-D State Diagram...........................8
      4.2. Working Group I-D States.................................10
         4.2.1. Call For Adoption By WG Issued......................11
         4.2.2. Adopted by a WG.....................................12
         4.2.3. Adopted for WG Info Only............................12
         4.2.4. WG Document.........................................12
         4.2.5. Parked WG Document..................................13
         4.2.6. Dead WG Document....................................13
         4.2.7. In WG Last Call.....................................13
         4.2.8. Waiting for WG Chair Go-Ahead.......................14
         4.2.9. WG Consensus: Waiting for Write-Up..................14
         4.2.10. Submitted to IESG for Publication..................15
      4.3. Working Group I-D Status Annotation Tags.................15
         4.3.1. Awaiting Expert Review/Resolution of Issues Raised..15
         4.3.2. Awaiting External Review/Resolution of Issues Raised15
         4.3.3. Awaiting Merge with Other Document..................16
         4.3.4. Author or Editor Needed.............................16
         4.3.5. Waiting for Referenced Document.....................16
         4.3.6. Waiting for Referencing Document....................17
         4.3.7. Revised I-D Needed - Issue raised by WGLC...........17
         4.3.8. Revised I-D Needed - Issue raised by AD.............17
         4.3.9. Revised I-D Needed - Issue raised by IESG...........17
         4.3.10. Doc Shepherd Follow-Up Underway....................17
         4.3.11. Other - see Comment Log............................18
   5. Intended Maturity Level of WG Drafts..........................18
   6. Security Considerations.......................................18
   7. IANA Considerations...........................................19
   8. References....................................................19
      8.1. Normative References.....................................19


Juskevicius             Expires April 7, 2011                  [Page 2]

Internet-Draft    IETF Working Group Document States       October 2010


      8.2. Informative References...................................19
   9. 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.............................22
         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...............................................23
      A.2. IESG Document Substates..................................24
         A.2.1. Point Raised - Write-up needed......................24
         A.2.2. AD Follow-up........................................24
         A.2.3. External Party......................................25
         A.2.4. Revised I-D Needed..................................25

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




Juskevicius             Expires April 7, 2011                  [Page 3]

Internet-Draft    IETF Working Group Document States       October 2010


   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" 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 as "WG documents" or
   "WG drafts" in the context of this document.

   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.


Juskevicius             Expires April 7, 2011                  [Page 4]

Internet-Draft    IETF Working Group Document States       October 2010


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:

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

  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



Juskevicius             Expires April 7, 2011                  [Page 5]

Internet-Draft    IETF Working Group Document States       October 2010


     state cannot be used to determine if an I-D is actively being
     developed by a WG. [WGDTSPEC]

  3.1.3. Replaces & 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 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 I-D will co-exist
      with the newer WG I-D that replaces it until the individual 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.


Juskevicius             Expires April 7, 2011                  [Page 6]

Internet-Draft    IETF Working Group Document States       October 2010


   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.

     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


Juskevicius             Expires April 7, 2011                  [Page 7]

Internet-Draft    IETF Working Group Document States       October 2010


     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 air
     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").

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 Figure 1 to describe the WG status of their I-Ds as
   appropriate for them.

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.


Juskevicius             Expires April 7, 2011                  [Page 8]

Internet-Draft    IETF Working Group Document States       October 2010


        "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         +-->    WRITE-UP                 |
|               '                    |                                |
|               ^      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             Expires April 7, 2011                  [Page 9]

Internet-Draft    IETF Working Group Document States       October 2010


   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 is 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.

   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 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 into 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.




Juskevicius             Expires April 7, 2011                 [Page 10]

Internet-Draft    IETF Working Group Document States       October 2010


   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.

  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.





Juskevicius             Expires April 7, 2011                 [Page 11]

Internet-Draft    IETF Working Group Document States       October 2010


  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 I-Ds.  This will facilitate the
     Datatracker's ability to correctly capture "Replaces" information
     for WG drafts and correct "Replaced by" information for individual
     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.

     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, however
     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.





Juskevicius             Expires April 7, 2011                 [Page 12]

Internet-Draft    IETF Working Group Document States       October 2010


     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.

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




Juskevicius             Expires April 7, 2011                 [Page 13]

Internet-Draft    IETF Working Group Document States       October 2010


     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.

     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 Write-Up

     A document in the "WG Consensus: Waiting for Write-Up" 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 write-up by
     a Document Shepherd.  The IESG requires that a document shepherd
     write-up 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 Write-Up"
     because a good document shepherd write-up takes time to prepare.


Juskevicius             Expires April 7, 2011                 [Page 14]

Internet-Draft    IETF Working Group Document States       October 2010


  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, or it may
     have been approved and be in the RFC Editor's queue, or it may
     have been published as an RFC.  Other possibilities exist too.
     The document may be "Dead" (in the IESG state machine) or in a
     "Do Not Publish" state.

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



Juskevicius             Expires April 7, 2011                 [Page 15]

Internet-Draft    IETF Working Group Document States       October 2010


     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.

     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.




Juskevicius             Expires April 7, 2011                 [Page 16]

Internet-Draft    IETF Working Group Document States       October 2010


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

     This tag should be removed after the dependency is cleared.

  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 Follow-Up Underway

     This annotation tag may be used to indicate that the Document
     Shepherd for the WG document has begun working on the write-up
     required to submit the document (to the IESG) for publication.





Juskevicius             Expires April 7, 2011                 [Page 17]

Internet-Draft    IETF Working Group Document States       October 2010


     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
     write-ups for all of the documents simultaneously.

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

  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.







Juskevicius             Expires April 7, 2011                 [Page 18]

Internet-Draft    IETF Working Group Document States       October 2010


7. IANA Considerations

   This document does not require any new number assignments from IANA,
   and does not define any new numbering spaces to be administered by
   IANA.

   RFC-Editor: Please remove this section before publication.

8. References

8.1. Normative References

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

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

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

8.2. Informative References

   [IDTRACKER] "The IETF Datatracker tool", Web Application:
               https://datatracker.ietf.org/, September 15, 2010.

   [AUTHGUIDE] Housley, R., Ed., for the IESG, "Guidelines to Authors
               of Internet-Drafts", May 4, 2010,
               http://www.ietf.org/ietf/1id-guidelines.txt.

   [WGDTSPEC]  Juskevicius, E., "Minutes of wgdtspec BOF", Proceedings
               of IETF 77, March 26, 2010,
               http://www.ietf.org/proceedings/10mar/minutes/wgdtspec

   [IESGSTAT]  "Main I-D States", Web Application:
               https://datatracker.ietf.org/idtracker/help/state/,
               September 15, 2010.

   [IESGIDSM]  "Diagram of Main I-D States", Web Application:
               https://datatracker.ietf.org/images/state_diagram.gif,
               September 15, 2010.

   [PROTO]     Levkowetz, H., and Mankin, A., "Requirements on I-D
               Tracker Extensions for Working Group Chairs",
               draft-ietf-proto-wgchair-tracker-ext-03.txt,
               February 8, 2007.





Juskevicius             Expires April 7, 2011                 [Page 19]

Internet-Draft    IETF Working Group Document States       October 2010


9. 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             Expires April 7, 2011                 [Page 20]

Internet-Draft    IETF Working Group Document States       October 2010


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 which 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,
   etc.)  Documents stay in this state until the review is complete and
   possibly until the issues raised in the review are addressed.


Juskevicius             Expires April 7, 2011                 [Page 21]

Internet-Draft    IETF Working Group Document States       October 2010


   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.

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.



Juskevicius             Expires April 7, 2011                 [Page 22]

Internet-Draft    IETF Working Group Document States       October 2010


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 write-up
   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
   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.)


Juskevicius             Expires April 7, 2011                 [Page 23]

Internet-Draft    IETF Working Group Document States       October 2010


A.2. IESG Document Substates

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

A.2.1. Point Raised - Write-up 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 Follow-up

   "AD Follow-up" 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.

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





Juskevicius             Expires April 7, 2011                 [Page 24]

Internet-Draft    IETF Working Group Document States       October 2010


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 I-D 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             Expires April 7, 2011                 [Page 25]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/