Proto                                                    E. Juskevicius
Internet Draft                                                TrekAhead
Intended status: Informational                            July 16, 2010
Expires: January 16, 2011


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


Abstract

   The IETF Datatracker tool will 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 several new states that may be used to
   describe the status of an Internet-Draft (I-D) that is associated
   with an IETF WG.  The first state can be used to describe an I-D
   that is being considered for adoption by a WG, and the last state
   describes an I-D that has been submitted to the IESG.  Appendix A
   describes the different states used by IETF Area Directors (ADs) to
   describe 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 January 16, 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



Juskevicius            Expires January 16, 2011                [Page 1]


Internet-Draft    IETF Working Group Document States          July 2010


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

Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................4
   3. Document States................................................4
      3.1. Document Availability States..............................4
         3.1.1. Expired..............................................5
         3.1.2. Active...............................................5
         3.1.3. Replaced.............................................5
      3.2. IESG Document States......................................5
         3.2.1. Publication Requested................................6
         3.2.2. AD Evaluation........................................6
         3.2.3. IESG Evaluation......................................6
         3.2.4. Other IESG Document States...........................6
      3.3. Working Group Document States.............................7
         3.3.1. Candidate WG Document................................7
         3.3.2. Adopted by a WG......................................7
         3.3.3. WG Document..........................................8
         3.3.4. Adopted for WG Info Only.............................8
         3.3.5. Not Adopted by a WG..................................9
         3.3.6. Parked WG Document...................................9
         3.3.7. Dead WG Document.....................................9
         3.3.8. In WG Last Call......................................9
         3.3.9. Waiting for WG Chair Go-Ahead.......................10
         3.3.10. WG Consensus: Waiting for Write-Up.................10
         3.3.11. Submitted to IESG for Publication..................10
      3.4. Working Group Document State Diagram.....................11
      3.5. WG Document Status Annotation Tags.......................13
         3.5.1. Awaiting Cross-Area Review / Resolution of Issues
         Raised.....................................................13
         3.5.2. Awaiting MIB Doctor Review / Resolution of Issues
         Raised.....................................................13
         3.5.3. Awaiting Security Review / Resolution of Issues Raised
         ...........................................................13
         3.5.4. Awaiting External Review / Resolution of Issues Raised
         ...........................................................14
         3.5.5. Awaiting Merge with Other Document..................14
         3.5.6. Author or Editor Needed.............................14
         3.5.7. Waiting for Referenced Document.....................14
         3.5.8. Waiting for Referencing Document....................15
         3.5.9. Revised I-D Needed..................................15
         3.5.10. Revised I-D Needed - Issue raised by AD............15


Juskevicius            Expires January 16, 2011                [Page 2]


Internet-Draft    IETF Working Group Document States          July 2010


         3.5.11. Revised I-D Needed - Issue raised by IESG..........15
         3.5.12. Doc Shepherd Follow-Up Underway....................16
         3.5.13. Other - see Comment Log............................16
      3.6. Intended Maturity Level of WG Documents..................16
   4. Security Considerations.......................................16
   5. IANA Considerations...........................................16
   6. References....................................................17
      6.1. Normative References.....................................17
      6.2. Informative References...................................17
   7. Acknowledgments...............................................17
   Appendix A: "IESG Document" States...............................19
      A.1. Definition of "IESG Document" States.....................19
         A.1.1. NULL................................................19
         A.1.2. Publication Requested...............................19
         A.1.3. AD Evaluation.......................................19
         A.1.4. Expert Review.......................................19
         A.1.5. Last Call Requested.................................20
         A.1.6. In Last Call........................................20
         A.1.7. Waiting for Write-up................................20
         A.1.8. Waiting for AD Go-Ahead.............................20
         A.1.9. IESG Evaluation.....................................20
         A.1.10. IESG Evaluation - Defer............................20
         A.1.11. Approved - Announcement to be sent.................21
         A.1.12. Approved - Announcement sent.......................21
         A.1.13. RFC Ed Queue.......................................21
         A.1.14. RFC Published......................................21
         A.1.15. DNP - Waiting for AD note..........................21
         A.1.16. DNP - Announcement to be sent......................21
         A.1.17. AD is Watching.....................................21
         A.1.18. Dead...............................................22
      A.2. IESG Document Substates..................................22
         A.2.1. Point Raised - Write-up needed......................22
         A.2.2. AD Follow-up........................................22
         A.2.3. External Party......................................23
         A.2.4. Revised I-D Needed..................................23

1. Introduction

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

   The Datatracker can provide a lot of information about the status
   and progression of an I-D after it has been submitted to the IESG
   for evaluation and publication.

   In contrast, the Datatracker currently has almost no information
   about the status of a working group (WG) I-D before it is sent to


Juskevicius            Expires January 16, 2011                [Page 3]


Internet-Draft    IETF Working Group Document States          July 2010


   the IESG.  The tool can only report on the availability of an I-D
   and the name of the WG that the I-D is associated with (if any).  In
   some cases, the Datatracker cannot even provide information about
   the availability of a document, but just indicate that an "I-D
   Exists".  "I-D Exists" is a state manufactured by the Datatracker to
   describe an I-D that has not been sent to the IESG for evaluation
   and that is not expired.

   This document defines new states to be added to the Datatracker to
   make it possible for WG Chairs to provide IETF participants with
   more visibility into the status and progression of WG documents.

2. Conventions used in this document

   The phrase "working group document" is to be interpreted as being
   synonymous with "working group I-D".  The same is true for the
   plural case of each phrase.

   The phrase "working group document" is 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 "working group
   documents" in the context of this document.

3. Document States

   This section describes the status information about every I-D that
   may be obtained by querying the Datatracker today, and it defines
   several new states that need to be added to allow WG Chairs and/or
   their delegates to identify the status of WG I-Ds in more detail.

3.1. Document Availability States

   The Datatracker can be queried for availability status of every I-D
   submitted to the IETF.  The availability states are:

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

   The first three availability states are described in the following
   subsections.





Juskevicius            Expires January 16, 2011                [Page 4]


Internet-Draft    IETF Working Group Document States          July 2010


  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.

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

     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" state cannot be
     used as a clear indication that an I-D is being actively developed
     by an IETF WG [WGDTSPEC].

  3.1.3. Replaced

     "Replaced" is a term used by the Datatracker to describe the final
     state of an I-D that was renamed and subsequently resubmitted to
     the I-D repository for some reason.

     Two common uses of "Replaced" are as follows:

      - The filename of an individual I-D that is being considered for
        adoption by an IETF WG will typically include the name of its
        author (e.g. 'draft-author-wgname-topic-nn').  If the I-D is
        adopted by a WG, its filename will change to 'draft-ietf-
        wgname-topic-00', and the Datatracker will describe the older
        individual I-D as having been "Replaced by" a newer WG I-D.

      - The Datatracker also uses "Replaced by" to describe the final
        state of an I-D that has been published as an RFC (i.e. the I-D
        was replaced by the RFC).

3.2. IESG Document States

   The Datatracker has more than a dozen different states to describe
   the status and progression of I-Ds under evaluation by the IESG



Juskevicius            Expires January 16, 2011                [Page 5]


Internet-Draft    IETF Working Group Document States          July 2010


   [IESGSTAT].  The following sections describe three IESG states that
   should be of interest to I-D authors and working group Chairs.

  3.2.1. Publication Requested

     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].  Most working group documents enter the
     IESG state machine at this point.

     An I-D in the "Publication Requested" state has not yet been
     reviewed by an Area Director (AD) and no official action has been
     taken on the I-D other than to note that its publication has been
     requested.

  3.2.2. AD Evaluation

     The "AD Evaluation" state is used to describe an I-D that the
     responsible Area Director has begun to review.  The purpose of the
     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 the document, the responsible AD may decide the
     I-D needs to be revised before it can progress further.  The AD
     may send a working group I-D back to the WG that created it for
     revision.

  3.2.3. IESG Evaluation

     "IESG Evaluation" is another state that may cause an I-D to be
     sent back to an IETF WG for revision.

     "IESG Evaluation" describes a document 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 the I-D to be
     returned to the WG for revision.

  3.2.4. Other IESG Document States

     See Appendix A and [IESGSTAT].







Juskevicius            Expires January 16, 2011                [Page 6]


Internet-Draft    IETF Working Group Document States          July 2010


3.3. Working Group Document States

   This section describes new states to be added to the Datatracker to
   make it possible for IETF WG Chairs and/or their delegates to
   indicate the status of I-Ds associated with their working groups.

   WG Chairs will have the option to use some, all or none of these WG
   document states to describe the status of some, all or none of the
   I-Ds associated with their WGs.

   The annotation tags defined in Section 3.5 may be used to provide
   additional information about why a WG document is in the state it is
   in and/or the action needed to progress the document into its next
   state.

  3.3.1. Candidate WG Document

     The "Candidate WG Document" state may be used to describe an I-D
     that is being considered for adoption by an IETF WG.  An I-D in
     this state has not yet achieved consensus, preference or selection
     in a WG.

     This state may be used by a WG Chair to describe:

       a) an I-D that someone has asked to be considered by a WG, if
          the WG Chair has agreed with the request;

       b) an I-D that the WG Chair asked an author to write;

       c) an I-D listed as a 'candidate draft' in the WG charter.

     Note that a document author may "shop" an I-D to multiple working
     groups hoping to get the I-D adopted somewhere.  In order to track
     this, the Datatracker will be enhanced to enable an I-D to be in
     the "Candidate WG Document" state in more than one WG at a time.

  3.3.2. Adopted by a WG

     The "Adopted by a WG" state should be used to identify an
     individual submission I-D that an IETF WG has agreed to adopt as
     one of its WG documents.

     The purpose of this state is to provide a clear indication of when
     an I-D is adopted by a WG, and to help the Datatracker identify
     correct "Replaced by" information for the history log of the
     individual I-D.

     This state is needed because the Datatracker uses the filename of
     an I-D as a key to locate status information about the I-D, and


Juskevicius            Expires January 16, 2011                [Page 7]


Internet-Draft    IETF Working Group Document States          July 2010


     because the filename of a WG document is supposed to be different
     from the filename of an individual 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 as a new version-00 WG document.  Without the
     "Adopted by a WG" state, the Datatracker has no way to identify
     that an I-D has been adopted until a new version-00 of the I-D is
     submitted to the WG and approved for posting by a WG Chair.

  3.3.3. WG Document

     A "WG Document" is an I-D that has been adopted by an IETF WG and
     is being actively developed.  The Datatracker will be extended to
     automatically place a new version-00 I-D into the "WG Document"
     state when a WG Chair approves the posting of an I-D that has a
     filename that includes the string 'draft-ietf-wgname-'

     A "WG Document" will be "Expired" or "Active" if its age is more
     or less than six months as described in Sections 3.1.1 and 3.1.2.

     Every "WG Document" should have an "intended maturity level" (e.g.
     Informational, Proposed Standard, Experimental) associated with it
     as described in Section 3.6.  This information is often requested
     by IETF participants and it is now required by the IESG for every
     I-D that is submitted to the IESG for publication.

     Under normal conditions, it should not be possible for an I-D to
     be in the "WG Document" state in more than one working group at a
     time.  That being said, documents may be transferred from one WG
     to another.  The Datatracker will make it easier to track an I-D
     that is transferred between IETF WGs.

  3.3.4. Adopted for WG Info Only

     The "Adopted for WG Info Only" state describes a document that
     contains useful information for the WG; however the document will
     not 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.





Juskevicius            Expires January 16, 2011                [Page 8]


Internet-Draft    IETF Working Group Document States          July 2010


  3.3.5. Not Adopted by a WG

     Some of the I-Ds considered for adoption by IETF working groups do
     not get adopted.  The "Not Adopted by a WG" state should be used
     to describe an I-D that was considered for adoption by one or more
     IETF working groups and was not adopted by any working group.

     The Datatracker may be programmed to automatically transition a
     "Candidate WG Document" into the "Not Adopted by a WG" state if
     the I-D is not adopted by any WG before the expiry of a 'must be
     adopted by a specified date' timer.  To facilitate this, the
     Datatracker may be configured to send an e-mail 'nudge' to the
     Chair of every WG that has identified the I-D as a candidate for
     adoption.  The nudge will warn that the Datatracker will
     automatically place the I-D in the "Not Adopted by a WG" state in
     a week's time unless a Chair moves the document into a different
     state first (e.g., "Adopted by a WG", "Adopted for WG Info Only").

  3.3.6. 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 3.5 may be used
     in conjunction with this state to indicate why the I-D has been
     parked, and/or what may need to happen for the I-D to be un-
     parked.

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

  3.3.8. 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
     working group 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


Juskevicius            Expires January 16, 2011                [Page 9]


Internet-Draft    IETF Working Group Document States          July 2010


     mailing lists for a different document undergoing a WGLC; some
     documents may deserve coordination with other WGs.

     A document 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 a 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.

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

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

     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.

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



Juskevicius            Expires January 16, 2011               [Page 10]


Internet-Draft    IETF Working Group Document States          July 2010


     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.

3.4. Working Group Document State Diagram

   Figure 1 illustrates all of the document states and many of the
   state transitions that an I-D may experience during its progression
   from being an individual draft to being adopted by a WG and replaced
   by a WG I-D, and its subsequent tenure as a WG document.

   The names of the WG document states are capitalized for clarity.

   Not every possible state transition is illustrated in the diagram.
   The absence of an explicit path between two states does not mean the
   state transition is precluded.  With very few exceptions, a working
   group document may be moved from any WG document state to any other
   WG document state by a WG Chair or his/her delegate.  If an unusual
   or uncommon state change is made, some text to explain the
   transition should be entered in a comment log in the Datatracker.

   The WG document states illustrated in Figure 1 will be implemented
   as a new state machine in the Datatracker.  WG Chairs and their
   delegates will be able to identify the status of documents they have
   adopted independently from how the status of the same documents may
   be described by the IESG (after they are submitted to the IESG for
   evaluation and publication).  Appendix A describes the states used
   by the IESG to indicate the status of I-Ds sent to them.

   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 can happen when an AD or the IESG as a whole sends
   an I-D back to an IETF WG for revision.  An I-D that is deemed to
   need revision will be in one of the IESG states (in the IESG state
   machine) and it may also return to being in a non-final WG state
   (such as "WG Document") for a while.

   If WG Chairs or their delegates decide not to manually update the WG
   status of an I-D, the Datatracker could be enhanced to automatically
   generate a few state transitions.  For example, an I-D may be moved
   into the "WG Document" state automatically when a WG Chair approves
   the posting of a new version-00 I-D that conforms to the 'draft-
   ietf-wgname-topic-00' file naming convention.  The Datatracker could
   also automatically transition an I-D into the "Submitted to IESG for
   Publication" state (in the WG document state machine) when the I-D
   is moved into the "Publication Requested" state in the IESG state
   machine.


Juskevicius            Expires January 16, 2011               [Page 11]


Internet-Draft    IETF Working Group Document States          July 2010


   +------------------------------------------------------------------+
   |            start for 'draft-author-wgname-topic-nn'              |
   |                               |                                  |
   |                               v                                  |
   |                                                                  |
   |        ADOPTED  <------  CANDIDATE WG  ----->  NOT ADOPTED       |
   |        BY A WG             DOCUMENT              BY A WG         |
   | (also "Replaced by ..")                                          |
   |           :                                                      |
   |           + - - - - - - - - - +                                  |
   |                               v                                  |
   |                                                                  |
   |             start for 'draft-ietf-wgname-topic-00'               |
   |                               |                                  |
   |                               v                                  |
   |                                                                  |
   |    ADOPTED FOR  <---------    WG      <--------> PARKED WG       |
   |    WG INFO ONLY     . - >  DOCUMENT   <--        DOCUMENT        |
   |                   .                      \                       |
   |                 .         /      \        \                      |
   |               .          /        \        \                     |
   |             .           /          \        ---> DEAD WG         |
   |            .           v            \            DOCUMENT        |
   |           .                          \                           |
   |          .         IN WG   --+        v                          |
   |                  LAST CALL   |                                   |
   |         ^            |       +->  WG CONSENSUS:                  |
   |         '            |             WAITING FOR                   |
   |         '            v       +-->   WRITE-UP                     |
   |         ^                    |         |                         |
   |         '       WAITING FOR  |         |                         |
   |         '        WG CHAIR  --+         |                         |
   |         ^        GO-AHEAD              v                         |
   |          .                                                       |
   |           .                        SUBMITTED                     |
   |    (revision needed) - < - - < - -  TO IESG                      |
   |                                 FOR PUBLICATION                  |
   |                                        :                         |
   |                                        :                         |
   |                           (IESG States as in Appendix A)         |
   |                                        :                         |
   |                                        :                         |
   |                                        v                         |
   +------------------------------------------------------------------+

       Figure 1 - Diagram of I-D states relevant to IETF WGs
                    (only common state transitions shown)




Juskevicius            Expires January 16, 2011               [Page 12]


Internet-Draft    IETF Working Group Document States          July 2010


3.5. WG Document Status Annotation Tags

   In addition to indicating which state a working group document 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 document
   (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 state of WG documents.

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

  3.5.1. Awaiting Cross-Area Review / Resolution of Issues Raised

     This tag means that someone (e.g. an author or editor of the
     document, or a WG Chair) has initiated a cross-area 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.

     Documents tagged with this annotation should retain the tag until
     the review is complete and possibly until any issues raised in the
     review are addressed.

  3.5.2. Awaiting MIB Doctor Review / Resolution of Issues Raised

     This tag means that someone (e.g. an author or editor of the
     document, or the WG Chair) has initiated a review of the document
     by a MIB Doctor and the review has not yet been completed and/or
     the resolution of issues raised by the review has not yet been
     completed.

     Documents tagged with this annotation should retain the tag until
     the review is complete and possibly until any issues raised in the
     review are addressed.

  3.5.3. Awaiting Security Review / Resolution of Issues Raised

     This tag means that someone (e.g. an author or editor of the
     document, or a WG Chair) has initiated a review of security
     considerations in 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.




Juskevicius            Expires January 16, 2011               [Page 13]


Internet-Draft    IETF Working Group Document States          July 2010


     Documents tagged with this annotation should retain the tag until
     the review is complete and possibly until the issues raised in the
     review are addressed.

  3.5.4. Awaiting External Review / Resolution of Issues Raised

     This tag means that someone (e.g. an author or editor of the
     document, 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.

     Documents tagged with this annotation should retain the tag until
     the review is complete and possibly until any issues raised in the
     review are addressed.

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

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

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


Juskevicius            Expires January 16, 2011               [Page 14]


Internet-Draft    IETF Working Group Document States          July 2010


     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.

  3.5.8. 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 Chair wants
     to submit all of these documents to the IESG (for publication)
     simultaneously.  This tag is the inverse of 3.5.7.

     This tag should be removed after the dependency is cleared.

  3.5.9. Revised I-D Needed

     This annotation means the I-D needs to be revised (e.g. 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.

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

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




Juskevicius            Expires January 16, 2011               [Page 15]


Internet-Draft    IETF Working Group Document States          July 2010


  3.5.12. Doc Shepherd Follow-Up Underway

     This annotation tag may be used to indicate that the shepherd for
     the WG document has begun working on the write-up 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
     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.

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

3.6. Intended Maturity Level of WG Documents

   In addition to the annotation tags defined in section 3.5, the
   intended maturity level of every WG document should also be tracked.
   Maturity levels are defined in sections 4 and 5 of RFC 2026
   [RFC2026].  They are:

     *  "Experimental"
     *  "Informational"
     *  "Best Current Practice"
     *  "Proposed Standard"
     *  "Draft Standard"
     *  "Standard"
     *  "Historic"

4. Security Considerations

   This document does not propose any new internet mechanisms, and has
   no security implications for the internet.

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



Juskevicius            Expires January 16, 2011               [Page 16]


Internet-Draft    IETF Working Group Document States          July 2010


   RFC-Editor: Please remove this section before publication.

6. References

6.1. Normative References

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

6.2. Informative References

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

   [AUTHGUIDE] Housley, R., Ed., for the IESG, "Guidelines to Authors
               of Internet-Drafts", February 9, 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/,
               June 8, 2010.

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

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





Juskevicius            Expires January 16, 2011               [Page 17]


Internet-Draft    IETF Working Group Document States          July 2010


   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.

   This document was initially prepared using 2-Word-v2.0.template.dot.














































Juskevicius            Expires January 16, 2011               [Page 18]


Internet-Draft    IETF Working Group Document States          July 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.  Most of the terms and definitions herein are as in
   [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.

A.1. Definition of "IESG Document" States

A.1.1. NULL

   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' or 'None'.

A.1.2. 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 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.3. AD Evaluation

   A specific Area Director (AD) for the working group has begun
   his/her 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.4. Expert Review

   An AD may ask for an expert review by an external 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.).


Juskevicius            Expires January 16, 2011               [Page 19]


Internet-Draft    IETF Working Group Document States          July 2010


   Documents remain in this state until the review is completed 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.5. 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.6. 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.7. Waiting for Write-up

   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.8. 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.9. IESG Evaluation

   The document is 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 she/he 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.10. 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



Juskevicius            Expires January 16, 2011               [Page 20]


Internet-Draft    IETF Working Group Document States          July 2010


   mechanism, and can only be invoked once, the first time the document
   comes up for discussion during a telechat.

A.1.11. 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.12. 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.13. RFC Ed Queue

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

A.1.14. RFC Published

   The I-D has been published as an RFC.

A.1.15. DNP - Waiting for AD note

   Do Not Publish (DNP): The IESG recommends against publishing the
   document, but the write-up explaining its reasoning has not yet been
   produced. DNPs apply primarily to individual submissions.  More
   information on who has the action item should be recorded in the
   "note" field associated with this state (i.e. within the
   Datatracker).

A.1.16. DNP - Announcement to be sent

   The IESG recommends against publishing the document.  A 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.17. 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).




Juskevicius            Expires January 16, 2011               [Page 21]


Internet-Draft    IETF Working Group Document States          July 2010


A.1.18. 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 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 - Write-up needed" substate
   until *ALL* IESG blocking comments that were 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.




Juskevicius            Expires January 16, 2011               [Page 22]


Internet-Draft    IETF Working Group Document States          July 2010


  - 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 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 January 16, 2011               [Page 23]