doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc6174.txt b/doc/rfc/rfc6174.txt
new file mode 100644
index 0000000..8ae652b
--- /dev/null
+++ b/doc/rfc/rfc6174.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    E. Juskevicius
+Request for Comments: 6174                                     TrekAhead
+Category: Informational                                       March 2011
+ISSN: 2070-1721
+
+
+            Definition of IETF Working Group Document States
+
+Abstract
+
+   The IETF Datatracker tool needs to be enhanced to make it possible
+   for Working Group (WG) Chairs to provide IETF participants with more
+   information about the status and progression of WG documents than is
+   currently possible.
+
+   This document defines new states and status annotation tags that need
+   to be added to the Datatracker to enable WG Chairs and their
+   Delegates to track the status of Internet-Drafts (I-Ds) that are
+   associated with their WGs.  This document also describes the meaning
+   of all previously implemented I-D states and substate annotation tags
+   currently used by IETF Area Directors to indicate the status of I-Ds
+   that have been sent to the IESG for evaluation and publication.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6174.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Juskevicius                   Informational                     [Page 1]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Conventions Used in This Document ...............................4
+   3. I-D States Already Implemented by the Datatracker ...............5
+      3.1. I-D Availability States ....................................5
+           3.1.1. Expired .............................................6
+           3.1.2. Active ..............................................6
+           3.1.3. Replaces and Replaced By ............................6
+      3.2. IESG Document States .......................................7
+           3.2.1. Publication Requested ...............................7
+           3.2.2. AD Evaluation .......................................8
+           3.2.3. IESG Evaluation .....................................8
+   4. New States and Status Annotation Tags for WG I-Ds ...............9
+      4.1. Working Group I-D State Diagram ............................9
+      4.2. Working Group I-D States ..................................11
+           4.2.1. Call for Adoption by WG Issued .....................12
+           4.2.2. Adopted by a WG ....................................12
+           4.2.3. Adopted for WG Info Only ...........................13
+           4.2.4. WG Document ........................................13
+           4.2.5. Parked WG Document .................................13
+           4.2.6. Dead WG Document ...................................14
+           4.2.7. In WG Last Call ....................................14
+           4.2.8. Waiting for WG Chair Go-Ahead ......................15
+           4.2.9. WG Consensus: Waiting for Writeup ..................15
+           4.2.10. Submitted to IESG for Publication .................15
+      4.3. Working Group I-D Status Annotation Tags ..................16
+           4.3.1. Awaiting Expert Review/Resolution of Issues Raised .16
+           4.3.2. Awaiting External Review/Resolution of
+                  Issues Raised ......................................16
+           4.3.3. Awaiting Merge with Other Document .................16
+           4.3.4. Author or Editor Needed ............................17
+           4.3.5. Waiting for Referenced Document ....................17
+
+
+
+Juskevicius                   Informational                     [Page 2]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+           4.3.6. Waiting for Referencing Document ...................17
+           4.3.7. Revised I-D Needed - Issue raised by WGLC ..........18
+           4.3.8. Revised I-D Needed - Issue raised by AD ............18
+           4.3.9. Revised I-D Needed - Issue raised by IESG ..........18
+           4.3.10. Doc Shepherd Followup Underway ....................18
+           4.3.11. Other - see Comment Log ...........................19
+   5. Intended Maturity Level of WG Drafts ...........................19
+   6. Security Considerations ........................................19
+   7. References .....................................................19
+      7.1. Normative References ......................................19
+      7.2. Informative References ....................................20
+   8. Acknowledgments ................................................20
+   Appendix A: "IESG Document" States ................................21
+      A.1. Definition of "IESG Document" States ......................21
+         A.1.1. Publication Requested ................................21
+         A.1.2. AD Evaluation ........................................21
+         A.1.3. Expert Review ........................................21
+         A.1.4. Last Call Requested ..................................22
+         A.1.5. In Last Call .........................................22
+         A.1.6. Waiting for Writeup ..................................22
+         A.1.7. Waiting for AD Go-Ahead ..............................22
+         A.1.8. IESG Evaluation ......................................22
+         A.1.9. IESG Evaluation - Defer ..............................23
+         A.1.10. Approved - Announcement to be sent ..................23
+         A.1.11. Approved - Announcement sent ........................23
+         A.1.12. RFC Ed Queue ........................................23
+         A.1.13. RFC Published .......................................23
+         A.1.14. DNP - Waiting for AD note ...........................23
+         A.1.15. DNP - Announcement to be sent .......................23
+         A.1.16. AD is Watching ......................................23
+         A.1.17. Dead ................................................24
+      A.2. IESG Document Substates ...................................24
+         A.2.1. Point Raised - writeup needed ........................24
+         A.2.2. AD Followup ..........................................24
+         A.2.3. External Party .......................................25
+         A.2.4. Revised ID Needed ....................................25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Juskevicius                   Informational                     [Page 3]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+1.  Introduction
+
+   The IETF Datatracker is a web-based system for managing information
+   about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison
+   statements, and several other important aspects of the IETF process
+   [IDTRACKER].
+
+   The Datatracker is currently able to track and report on the status
+   of I-Ds that have been submitted to the IESG for evaluation and
+   publication.  Appendix A of this document describes all of the
+   document states and substate annotation tags used by IETF Area
+   Directors (ADs) to indicate the status of I-Ds that have been sent to
+   the IESG.
+
+   In contrast, the Datatracker has almost no ability to indicate the
+   status and progression of I-Ds before they are sent to the IESG.  The
+   Datatracker can only track the availability status of I-Ds today
+   (e.g., "Active", Expired", "Withdrawn", "Replaced by") and in some
+   cases indicate which IETF Working Group (WG) an I-D is associated
+   with (if any).
+
+   Section 3 of this document contains a summary of the Datatracker's
+   current ability to track and report on the status of I-Ds in the IETF
+   document stream.  The IETF document stream is defined in Section
+   5.1.1 of RFC 4844 [RFC4844].
+
+   Section 4 of this document defines several new I-D states and I-D
+   status annotation tags that need to be added to the Datatracker to
+   enable status tracking and reporting for WG I-Ds.
+
+2.  Conventions Used in This Document
+
+   A "working group I-D" (WG I-D) is an Internet-Draft that has achieved
+   consensus for adoption as a work item by a WG (compared to an
+   individual submission I-D that has not, or has not yet, achieved
+   consensus).
+
+   The terms "WG I-D", "WG document", and "WG draft" are used
+   synonymously throughout this document.  The same is true for the
+   plural case of each term.
+
+   The terms "WG document" and "WG draft" are not intended to apply to
+   any other document that may be reviewed, discussed, or produced by an
+   IETF working group.  Working group meeting materials such as Blue
+   Sheets, agendas, jabber logs, scribe's notes, minutes, and
+   presentation slides are not to be considered "WG documents" or "WG
+   drafts" in the context of this document.
+
+
+
+
+Juskevicius                   Informational                     [Page 4]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   The phrase "WG status of an I-D" is to be interpreted as referring to
+   the state that an I-D is in, as defined in Section 4.2 of this
+   document.  This phrase does not refer to an I-D's availability status
+   (e.g., "Expired", "Active", "Replaced by") as described in Section
+   3.1, or to any of the IESG states used by Area Directors to describe
+   the status of I-Ds they may be evaluating.
+
+3.  I-D States Already Implemented by the Datatracker
+
+   This section describes capabilities that are currently implemented in
+   the Datatracker to track the status of I-Ds in the IETF document
+   stream.
+
+   The document availability states described in Section 3.1 are
+   applicable to every I-D submitted to the IETF.
+
+   The IESG document states and substate annotation tags described in
+   Section 3.2 and Appendix A are only applicable to I-Ds that have been
+   submitted to the IESG for evaluation and publication.
+
+   The Datatracker currently has no I-D states or I-D status annotation
+   tags to describe the WG status of any I-D.
+
+3.1.  I-D Availability States
+
+   The Datatracker currently maintains availability status information
+   for every I-D submitted to the IETF.  The I-D availability states are
+   as follows:
+
+      - Expired
+      - Active
+      - Replaces
+      - Replaced by
+      - Withdrawn by Submitter
+      - Withdrawn by IETF
+      - RFC
+
+   The first four I-D availability states are explained in the following
+   subsections.  The other states are self-explanatory.
+
+   Note that the Datatracker describes the status of some I-Ds with the
+   phrase "I-D Exists".  "I-D Exists" is the state that is manufactured
+   by the Datatracker to describe I-Ds for which it has no other status
+   information.  For example, the tool currently uses "I-D Exists" to
+   describe I-Ds that are not expired and that have not been sent to the
+   IESG.
+
+
+
+
+
+Juskevicius                   Informational                     [Page 5]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+3.1.1.  Expired
+
+   An "Expired" I-D is a document that is more than six months old and
+   that has not been updated or replaced by a newer I-D or an RFC.
+
+   Every I-D has a normal lifespan of 185 days.  An I-D will expire and
+   be deleted from the I-D repository after six months unless it is
+   updated or replaced by a newer version.  One exception is that an I-D
+   undergoing official evaluation by the IESG will not be expired before
+   its status is resolved (e.g., the I-D is published as an RFC).  IESG
+   states that do not relate to a formal request to publish a document
+   (e.g., "AD is Watching") do not prevent an I-D from expiring.
+   [AUTHGUIDE]
+
+3.1.2.  Active
+
+   An "Active" I-D is a document that is less than six months old and
+   has not been updated or replaced by a newer I-D or an RFC.
+
+   The "Active" availability state is applicable to individual I-Ds and
+   WG I-Ds.  The Datatracker may also use "Active" to describe the
+   status of I-Ds under formal evaluation by the IESG and I-Ds in the
+   RFC Editor Queue.  As a result, the "Active" I-D availability state
+   cannot be used to determine if an I-D is actively being developed by
+   a WG. [WGDTSPEC]
+
+3.1.3.  Replaces and Replaced By
+
+   The Datatracker uses "Replaces" and "Replaced by" to describe I-Ds
+   that have been renamed and subsequently resubmitted to the I-D
+   repository for some reason.
+
+   Two common uses of "Replaced by" are as follows:
+
+   -  The filename of an individual I-D that is being considered for
+      adoption by a WG typically includes the name of its author (e.g.,
+      'draft-author-wgname-topic-nn').  If the individual I-D is adopted
+      by a WG it will be "Replaced by" a newer draft having a filename
+      that includes the string 'ietf-' (e.g., 'draft-ietf-wgname-
+      topic-00'); when the newer WG I-D is submitted to the I-D
+      repository, it "Replaces" the older individual submission I-D.
+
+   -  The Datatracker also uses "Replaced by" to describe the final
+      state of an I-D that has been published as an RFC; the I-D was
+      "Replaced By" the RFC.
+
+   Note that getting correct "Replaces" and "Replaced by" data into the
+   Datatracker currently requires an explicit request by a WG Chair.
+
+
+
+Juskevicius                   Informational                     [Page 6]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   Without such a request, an individual submission I-D will co-exist
+   with the newer WG I-D that replaces it until the individual
+   submission I-D eventually expires.
+
+   The Datatracker's ability to track "Replaces" and "Replaced by"
+   information may need to be extended in the future to handle more
+   complex cases such as the following:
+
+   -  Two or more I-Ds are merged into (i.e., "Replaced by") a single
+      I-D; in such cases, the availability status of the (one) new I-D
+      should indicate that the draft "Replaces" two or more older and
+      previously separate I-Ds; and
+
+   -  One I-D is split or divided into two or more new I-Ds; in this
+      case the availability status should indicate that one (older) I-D
+      was "Replaced by" two or more newer I-Ds.
+
+3.2.  IESG Document States
+
+   In addition to tracking the availability status of every I-D, the
+   Datatracker also maintains detailed information about the status and
+   progression of I-Ds that have been sent to the IESG for evaluation
+   and publication.
+
+   All of the states used by Area Directors to indicate the status of
+   I-Ds under evaluation by the IESG are defined in [IESGSTAT] and are
+   reproduced for convenience in Appendix A.
+
+   The following subsections describe some common interactions between
+   three of the IESG I-D states and normal IETF WG processes.  These
+   interactions are relevant to several of the new WG I-D states defined
+   in Section 4.
+
+3.2.1.  Publication Requested
+
+   When a WG has determined that at least rough consensus exists within
+   the WG to advance an I-D, progressing the document is then the
+   responsibility of the IESG (unless the IESG returns the I-D to the WG
+   for further development). [RFC2418]
+
+   The "Publication Requested" state describes an I-D for which a formal
+   request has been sent to the IESG to advance/publish the I-D as an
+   RFC, following the procedures specified in Section 7.5 of RFC 2418
+   [RFC2418].  This state does not mean that an Area Director has
+   reviewed the I-D or that any official action has been taken on the
+   I-D other than to note that its publication has been requested.
+
+
+
+
+
+Juskevicius                   Informational                     [Page 7]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   Many WG drafts enter the IESG state machine for the first time via
+   the "Publication Requested" state.  When an I-D advances through the
+   IESG process, its IESG state will change to reflect its progress.
+   This said, the WG status of the I-D should not change unless an AD or
+   the IESG sends the I-D back to the WG for further development.  The
+   WG state of an I-D that is being progressed by the IESG is "Submitted
+   to IESG for Publication", as defined in Section 4.2.10.
+
+3.2.2.  AD Evaluation
+
+   The "AD Evaluation" state describes an I-D that the responsible Area
+   Director has begun to review.  The purpose of the AD's review is to
+   verify that the I-D is ready for advancement before an IETF Last Call
+   is started or before the document is progressed to the IESG as a
+   whole.
+
+   After evaluating an I-D, the responsible AD may decide that the
+   document needs to be revised before it can be progressed further.
+   The AD may send a working group I-D back to the WG that created it
+   for revision.
+
+   When an AD sends an I-D back to a WG for revision, the Datatracker
+   will report the IESG state and substate status of the document as "AD
+   Evaluation: Revised I-D Needed".  If the required revisions are
+   extensive, a WG Chair may decide to change the WG state of the I-D
+   from "Submitted to IESG for Publication" to another WG state (e.g.,
+   "Waiting for WG Chair Go-Ahead" or "WG Document") for as long as it
+   takes the revised I-D to be developed.  The IESG status of the I-D
+   will continue to be "AD Evaluation: Revised I-D Needed" until the
+   revised I-D becomes available.
+
+3.2.3.  IESG Evaluation
+
+   The "IESG Evaluation" state describes an I-D that is being formally
+   evaluated by the entire IESG.  Every AD is able to raise any content
+   or process issues he/she may have with the document.  Issues that are
+   blocking approval of the document are called "DISCUSS" comments.  A
+   "DISCUSS" with serious issues may cause a WG I-D to be returned to
+   the WG for revision.
+
+   If the IESG sends an I-D back to a WG for more development, the
+   Datatracker will report the IESG state and substate of the I-D as
+   "IESG Evaluation: Revised I-D Needed" until a revised version of the
+   I-D becomes available.  During the time that the I-D is being
+   revised, the WG Chair may decide to transition the I-D from the
+   "Submitted to IESG for Publication" state into one of the earlier WG
+   states (e.g., "Waiting for WG Chair Go-Ahead" or "WG Document").
+
+
+
+
+Juskevicius                   Informational                     [Page 8]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+4.  New States and Status Annotation Tags for WG I-Ds
+
+   The status-tracking states described in Section 3 are currently
+   implemented in the Datatracker; however, their scope is not broad
+   enough to provide good visibility into the WG status of any I-D.
+
+   This section describes new I-D states and I-D status annotation tags
+   that need to be added to the Datatracker to make it possible for WG
+   Chairs and/or their Delegates (e.g., WG Secretaries) to indicate the
+   status and progression of the I-Ds associated with their WGs.
+
+   The WG I-D states defined in this section are a superset of the I-D
+   states currently used across all IETF WGs.  This is not to suggest or
+   imply that all of the WG I-D states must be used by all WG Chairs to
+   describe the status and progression of the I-Ds associated with their
+   WGs.  Chairs may use all or just some of the document states
+   illustrated in Figure 1 to describe the WG status of their I-Ds as
+   appropriate.
+
+4.1.  Working Group I-D State Diagram
+
+   Figure 1 is a state machine diagram that illustrates all of the WG
+   I-D states defined in Section 4.2 of this document.  The names of the
+   WG I-D states are capitalized for clarity, and common state
+   transitions are indicated via the solid, dashed, and dotted lines.
+
+   The WG I-D state machine illustrated in Figure 1 is intended to be a
+   new front-end to the IESG I-D state machine [IESGIDSM] that is
+   currently implemented in Datatracker.
+
+   Note that Figure 1 does not show every possible state transition.  WG
+   Chairs may move an I-D from any WG state to any other WG state as
+   appropriate to describe the WG status of the document.  The lack of
+   an explicit path between two states does not mean that such a state
+   transition is precluded.
+
+   The first WG I-D state is "Call for Adoption by WG Issued" and its
+   meaning and usage are defined in Section 4.2.1.
+
+   One of several possible last states for a WG I-D is "Submitted to
+   IESG for Publication".  This state is defined in Section 4.2.10.
+
+
+
+
+
+
+
+
+
+
+Juskevicius                   Informational                     [Page 9]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+         "I-D EXISTS": 'draft-author-wgname-topic-nn'  < - - .
+                                     :                         .
+ +---------------------------------------------------------------------+
+ |  WG I-D State Machine             |                         .       |
+ |                                   v                 (not adopted)   |
+ |                                                            .        |
+ |                   CALL FOR ADOPTION BY WG ISSUED  . . . . .         |
+ |                     .             :                                 |
+ |                    .              v                                 |
+ |                   v                                                 |
+ |             ADOPTED FOR     ADOPTED BY WG                           |
+ |             WG INFO ONLY          .                                 |
+ |                                   :                                 |
+ |                                   :                                 |
+ |    (individual I-D "Replaced by" 'draft-ietf-wgname-topic-00')      |
+ |                                   :                                 |
+ |                                   v                                 |
+ |                                                                     |
+ |       DEAD WG   <-------->   WG DOCUMENT  <-------->  PARKED WG     |
+ |       DOCUMENT       ("Replaces" individual I-D)      DOCUMENT      |
+ |                         .                                           |
+ |                      .       ^          \                           |
+ |                    .        /            \                          |
+ |                   .        /              \                         |
+ |                  .        v                \                        |
+ |                 .                           \                       |
+ |                .       IN WG    ---+         v                      |
+ |                      LAST CALL     |                                |
+ |               '          ^         +-->  WG CONSENSUS:              |
+ |               ^          :                WAITING FOR               |
+ |               '          v         +-->    WRITEUP                  |
+ |               '                    |                                |
+ |               ^      WAITING FOR   |          |                     |
+ |               '       WG CHAIR  ---+          |                     |
+ |                '      GO-AHEAD                v                     |
+ |                 .                                                   |
+ |                   .                    SUBMITTED TO IESG            |
+ |          ("Revised ID Needed") - - < -  FOR PUBLICATION             |
+ |                                                                     |
+ |                                                                     |
+ +---------------------------------------------------------------------+
+                                    |
+                                    v
+                          IESG Document States
+                            (see Appendix A)
+
+        Figure 1:  WG I-D States and Common State Transitions
+
+
+
+
+Juskevicius                   Informational                    [Page 10]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   The Datatracker will be enhanced to automatically generate the
+   following two state transitions for all WG drafts:
+
+   -  A version-00 I-D that conforms to the 'draft-ietf-wgname-topic-00'
+      file naming convention will be moved into the "WG Document" state
+      automatically by the Datatracker when the WG Chair approves the
+      posting of an I-D; and
+
+   -  A WG draft that is moved into the IESG state called "Publication
+      Requested" will automatically be moved by the Datatracker into the
+      WG state called "Submitted to IESG for Publication".
+
+   All other WG I-D state transitions will require the WG Chairs or
+   their Delegates to log in to the Datatracker to manually input the
+   appropriate WG state to describe the WG status of an I-D.
+
+   Note that Figure 1 includes an arc from the "Submitted to IESG for
+   Publication" state back to the "WG Document" state.  This is one
+   example of what may happen after an AD or the IESG as a whole sends
+   an I-D back to a WG for revision.  The WG chair may decide that the
+   I-D needs further development and that it needs to return to the "WG
+   Document" state for a while.
+
+4.2.  Working Group I-D States
+
+   The WG I-D states defined in this section are a superset of the I-D
+   states currently used across all IETF WGs.
+
+   All of the states described herein need to be added to the front-end
+   of IESG state machine [IESGIDSM] that has already been implemented in
+   the IETF Datatracker.
+
+   WG Chairs and their Delegates will be given the flexibility to use
+   whichever of the WG I-D states they feel to be appropriate to
+   describe the WG status of the I-Ds associated with their WG.
+
+   It is not suggested or implied that Chairs must use all of the I-D
+   states defined herein to describe the status and progression of all
+   I-Ds associated with their WGs; Chairs may use all of the WG I-D
+   states, or just some of the states.
+
+   Note that an I-D that is not associated with a WG will be in a 'Null'
+   state with respect to the WG state machine in Figure 1.
+
+
+
+
+
+
+
+
+Juskevicius                   Informational                    [Page 11]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+4.2.1.  Call for Adoption by WG Issued
+
+   The "Call for Adoption by WG Issued" state should be used to indicate
+   when an I-D is being considered for adoption by an IETF WG.  An I-D
+   that is in this state is actively being considered for adoption and
+   has not yet achieved consensus, preference, or selection in the WG.
+
+   This state may be used to describe an I-D that someone has asked a WG
+   to consider for adoption, if the WG Chair has agreed with the
+   request.  This state may also be used to identify an I-D that a WG
+   Chair asked an author to write specifically for consideration as a
+   candidate WG item [WGDTSPEC], and/or an I-D that is listed as a
+   'candidate draft' in the WG's charter.
+
+   Under normal conditions, it should not be possible for an I-D to be
+   in the "Call for Adoption by WG Issued" state in more than one
+   working group at the same time.  This said, it is not uncommon for
+   authors to "shop" their I-Ds to more than one WG at a time, with the
+   hope of getting their documents adopted somewhere.
+
+   After this state is implemented in the Datatracker, an I-D that is in
+   the "Call for Adoption by WG Issued" state will not be able to be
+   "shopped" to any other WG without the consent of the WG Chairs and
+   the responsible ADs impacted by the shopping.
+
+   Note that Figure 1 includes an arc leading from this state to outside
+   of the WG state machine.  This illustrates that some I-Ds that are
+   considered do not get adopted as WG drafts.  An I-D that is not
+   adopted as a WG draft will transition out of the WG state machine and
+   revert back to having no stream-specific state; however, the status
+   change history log of the I-D will record that the I-D was previously
+   in the "Call for Adoption by WG Issued" state.
+
+4.2.2.  Adopted by a WG
+
+   The "Adopted by a WG" state describes an individual submission I-D
+   that an IETF WG has agreed to adopt as one of its WG drafts.
+
+   WG Chairs who use this state will be able to clearly indicate when
+   their WGs adopt individual submission I-Ds.  This will facilitate the
+   Datatracker's ability to correctly capture "Replaces" information for
+   WG drafts and correct "Replaced by" information for individual
+   submission I-Ds that have been replaced by WG drafts.
+
+   This state is needed because the Datatracker uses the filename of an
+   I-D as a key to search its database for status information about the
+   I-D, and because the filename of a WG I-D is supposed to be different
+   from the filename of an individual submission I-D.
+
+
+
+Juskevicius                   Informational                    [Page 12]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   The filename of an individual submission I-D will typically be
+   formatted as 'draft-author-wgname-topic-nn'.
+
+   The filename of a WG document is supposed to be formatted as 'draft-
+   ietf-wgname-topic-nn'.
+
+   An individual I-D that is adopted by a WG may take weeks or months to
+   be resubmitted by the author as a new (version-00) WG draft.  If the
+   "Adopted by a WG" state is not used, the Datatracker has no way to
+   determine that an I-D has been adopted until a new version of the I-D
+   is submitted to the WG by the author and until the I-D is approved
+   for posting by a WG Chair.
+
+4.2.3.  Adopted for WG Info Only
+
+   The "Adopted for WG Info Only" state describes a document that
+   contains useful information for the WG that adopted it, but the
+   document is not intended to be published as an RFC.  The WG will not
+   actively develop the contents of the I-D or progress it for
+   publication as an RFC.  The only purpose of the I-D is to provide
+   information for internal use by the WG.
+
+4.2.4.  WG Document
+
+   The "WG Document" state describes an I-D that has been adopted by an
+   IETF WG and is being actively developed.
+
+   A WG Chair may transition an I-D into the "WG Document" state at any
+   time as long as the I-D is not being considered or developed in any
+   other WG.
+
+   Alternatively, WG Chairs may rely upon new functionality to be added
+   to the Datatracker to automatically move version-00 drafts into the
+   "WG Document" state as described in Section 4.1.
+
+   Under normal conditions, it should not be possible for an I-D to be
+   in the "WG Document" state in more than one WG at a time.  This said,
+   I-Ds may be transferred from one WG to another with the consent of
+   the WG Chairs and the responsible ADs.
+
+4.2.5.  Parked WG Document
+
+   A "Parked WG Document" is an I-D that has lost its author or editor,
+   is waiting for another document to be written or for a review to be
+   completed, or cannot be progressed by the working group for some
+   other reason.
+
+
+
+
+
+Juskevicius                   Informational                    [Page 13]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   Some of the annotation tags described in Section 4.3 may be used in
+   conjunction with this state to indicate why an I-D has been parked,
+   and/or what may need to happen for the I-D to be un-parked.
+
+   Parking a WG draft will not prevent it from expiring; however, this
+   state can be used to indicate why the I-D has stopped progressing in
+   the WG.
+
+   A "Parked WG Document" that is not expired may be transferred from
+   one WG to another with the consent of the WG Chairs and the
+   responsible ADs.
+
+4.2.6.  Dead WG Document
+
+   A "Dead WG Document" is an I-D that has been abandoned.  Note that
+   'Dead' is not always a final state for a WG I-D.  If consensus is
+   subsequently achieved, a "Dead WG Document" may be resurrected.  A
+   "Dead WG Document" that is not resurrected will eventually expire.
+
+   Note that an I-D that is declared to be "Dead" in one WG and that is
+   not expired may be transferred to a non-dead state in another WG with
+   the consent of the WG Chairs and the responsible ADs.
+
+4.2.7.  In WG Last Call
+
+   A document "In WG Last Call" is an I-D for which a WG Last Call
+   (WGLC) has been issued and is in progress.
+
+   Note that conducting a WGLC is an optional part of the IETF WG
+   process, per Section 7.4 of RFC 2418 [RFC2418].
+
+   If a WG Chair decides to conduct a WGLC on an I-D, the "In WG Last
+   Call" state can be used to track the progress of the WGLC.  The Chair
+   may configure the Datatracker to send a WGLC message to one or more
+   mailing lists when the Chair moves the I-D into this state.  The WG
+   Chair may also be able to select a different set of mailing lists for
+   a different document undergoing a WGLC; some documents may deserve
+   coordination with other WGs.
+
+   A WG I-D in this state should remain "In WG Last Call" until the WG
+   Chair moves it to another state.  The WG Chair may configure the
+   Datatracker to send an e-mail after a specified period of time to
+   remind or 'nudge' the Chair to conclude the WGLC and to determine the
+   next state for the document.
+
+
+
+
+
+
+
+Juskevicius                   Informational                    [Page 14]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   It is possible for one WGLC to lead into another WGLC for the same
+   document.  For example, an I-D that completed a WGLC as an
+   "Informational" document may need another WGLC if a decision is taken
+   to convert the I-D into a Standards Track document.
+
+4.2.8.  Waiting for WG Chair Go-Ahead
+
+   A WG Chair may wish to place an I-D that receives a lot of comments
+   during a WGLC into the "Waiting for WG Chair Go-Ahead" state.  This
+   state describes an I-D that has undergone a WGLC; however, the Chair
+   is not yet ready to call consensus on the document.
+
+   If comments from the WGLC need to be responded to, or a revision to
+   the I-D is needed, the Chair may place an I-D into this state until
+   all of the WGLC comments are adequately addressed and the (possibly
+   revised) document is in the I-D repository.
+
+4.2.9.  WG Consensus: Waiting for Writeup
+
+   A document in the "WG Consensus: Waiting for Writeup" state has
+   essentially completed its development within the working group, and
+   is nearly ready to be sent to the IESG for publication.  The last
+   thing to be done is the preparation of a protocol writeup by a
+   Document Shepherd.  The IESG requires that a document shepherd
+   writeup be completed before publication of the I-D is requested.  The
+   IETF document shepherding process and the role of a WG Document
+   Shepherd is described in RFC 4858 [RFC4858]
+
+   A WG Chair may call consensus on an I-D without a formal WGLC and
+   transition an I-D that was in the "WG Document" state directly into
+   this state.
+
+   The name of this state includes the words "Waiting for Writeup"
+   because a good document shepherd writeup takes time to prepare.
+
+4.2.10.  Submitted to IESG for Publication
+
+   This state describes a WG document that has been submitted to the
+   IESG for publication and that has not been sent back to the working
+   group for revision.
+
+   An I-D in this state may be under review by the IESG, it may have
+   been approved and be in the RFC Editor's queue, or it may have been
+   published as an RFC.  Other possibilities exist too.  The document
+   may be "Dead" (in the IESG state machine) or in a "Do Not Publish"
+   state.
+
+
+
+
+
+Juskevicius                   Informational                    [Page 15]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+4.3.  Working Group I-D Status Annotation Tags
+
+   In addition to indicating which state a working group draft is in,
+   the Datatracker will allow several substate conditions to be
+   identified and tracked.  This section defines annotation tags that
+   may be used to describe a condition that is affecting a WG I-D (e.g.,
+   why a document is in the state it is in) or to indicate an action
+   needed to progress the document.
+
+   Annotation tags do not change the WG I-D state of WG drafts.
+
+   Each of the annotation tags defined herein may be used to provide
+   more information about the status of any WG draft in any state, if it
+   makes sense to do so.  Each annotation tag may be used by itself, or
+   in combination with other tags.
+
+4.3.1.  Awaiting Expert Review/Resolution of Issues Raised
+
+   This tag means that someone (e.g., an author or editor of the WG
+   draft, or a WG Chair) has initiated an expert review of the document
+   and the review has not yet been completed and/or the resolution of
+   issues raised by the review has not yet been completed.  Examples of
+   expert reviews include cross-area reviews, MIB Doctor reviews,
+   security expert reviews, and IANA reviews.
+
+   WG drafts tagged with this annotation should retain the tag until the
+   review is complete and possibly until any issues raised in the review
+   are addressed.
+
+4.3.2.  Awaiting External Review/Resolution of Issues Raised
+
+   This tag means that someone (e.g., an author or editor of the WG
+   draft, or a WG Chair) has initiated some other review of the document
+   (e.g., sent it to another Standards Development Organization (SDO)
+   for comments via a formal or informal liaison process), and the
+   review has not yet been completed and/or the resolution of issues
+   raised by the review has not yet been completed.
+
+   WG drafts tagged with this annotation should retain the tag until the
+   review is complete and possibly until any issues raised in the review
+   are addressed.
+
+4.3.3.  Awaiting Merge with Other Document
+
+   This tag means a decision has been made by someone (e.g., the
+   document author, editor, or the WG Chair) to merge the I-D with one
+   or more other I-Ds from the same (or another) working group.
+
+
+
+
+Juskevicius                   Informational                    [Page 16]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   If the result of the merge is a new I-D having a different title,
+   then the old I-D may be declared as being a "Dead WG Document".  In
+   such a case, the annotation tag should be changed from "Awaiting
+   Merge with Other Document" to "Other - see Comment Log" and a
+   description of the merge should be entered into the log for
+   posterity.
+
+   The Datatracker's regular 'Replaced by' information should also be
+   set for the old I-Ds to make it easier to find the new merged
+   document from the old documents.
+
+   If the result of the merge operation is a revision to the old I-D,
+   this annotation tag should be cleared when the revised (merged) I-D
+   is submitted to the WG.
+
+4.3.4.  Author or Editor Needed
+
+   This tag means an I-D has lost a primary author or editor, and that
+   further work on the I-D cannot continue in an effective or efficient
+   manner until a new author or editor is found.
+
+   This tag should be removed after a new primary author or editor is
+   found.
+
+4.3.5.  Waiting for Referenced Document
+
+   This tag means that completion of the I-D is on-hold because the
+   draft has a dependency on one or more other documents.  A typical
+   example is where an I-D depends on another IETF document that has not
+   yet progressed to a point where it may be referenced; the dependency
+   may be on one or more documents in other IETF Working Groups or on
+   work in progress documents in other SDOs.
+
+   This tag should be removed after the dependency is cleared.
+
+4.3.6.  Waiting for Referencing Document
+
+   This tag means that completion of the I-D is on-hold because one or
+   more other documents are dependent on it, and the WG Chair wants to
+   submit all of the documents to the IESG (for publication)
+   simultaneously.  This tag is the inverse of 4.3.5.
+
+   This tag should be removed after the dependency is cleared.
+
+
+
+
+
+
+
+
+Juskevicius                   Informational                    [Page 17]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+4.3.7.  Revised I-D Needed - Issue raised by WGLC
+
+   This annotation may be used to flag an I-D that needs to be revised
+   to address issues raised during a Working Group Last Call.  This
+   annotation may also be used to indicate when the I-D is in the
+   process of being revised.
+
+   This tag should be removed after a revised version of the I-D is
+   submitted to the WG.
+
+4.3.8.  Revised I-D Needed - Issue raised by AD
+
+   This annotation means the responsible AD raised one or more issues
+   with the I-D during "AD Evaluation" and that the AD has sent the
+   document back to the working group for revision.  This annotation may
+   also be used to indicate when the I-D is in the process of being
+   revised.
+
+   This tag should be removed after the revised version of the I-D is
+   submitted to the WG.
+
+4.3.9.  Revised I-D Needed - Issue raised by IESG
+
+   This annotation means that one or more IESG members had issues with
+   the I-D during "IESG Evaluation" and the document has been sent back
+   to the working group for revision.  This annotation may also be used
+   to indicate that the revision to the I-D is in process.
+
+   This tag should be removed after the revised version of the I-D is
+   submitted to the WG.
+
+4.3.10.  Doc Shepherd Followup Underway
+
+   This annotation tag may be used to indicate that the Document
+   Shepherd for the WG document has begun working on the writeup
+   required to submit the document (to the IESG) for publication.
+
+   It is possible that too many I-Ds may arrive in a shepherd's queue in
+   too short a time, and the shepherd cannot create satisfactory
+   writeups for all of the documents simultaneously.
+
+   When this annotation tag is set, it means the Document Shepherd has
+   started work on the writeup for the I-D.  The absence or resetting of
+   this annotation tag for an I-D in the "WG Consensus: Waiting for
+   Writeup" state indicates the writeup has not yet been started, or has
+   been put on-hold for some reason.
+
+
+
+
+
+Juskevicius                   Informational                    [Page 18]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+4.3.11.  Other - see Comment Log
+
+   This annotation tag is a catch-all to indicate that someone (e.g., an
+   author or editor of the document, the WG Chair, the Document
+   Shepherd) has entered one or more comments about the current status
+   of the I-D into the IETF Datatracker.
+
+5.  Intended Maturity Level of WG Drafts
+
+   The IESG requires a WG I-D to have an "intended maturity level"
+   associated with it (e.g., Informational, Proposed Standard,
+   Experimental) before the I-D is submitted to the IESG for evaluation
+   and publication.  This information is also often requested by IETF
+   participants.
+
+   I-D maturity levels were first defined in Sections 4 and 5 of RFC
+   2026 [RFC2026].  The names of the maturity levels in use today are:
+
+      *  "Experimental"
+      *  "Informational"
+      *  "Best Current Practice"
+      *  "Proposed Standard"
+      *  "Draft Standard"
+      *  "Standard"
+      *  "Historic"
+
+   The Datatracker may need to be enhanced to enable WG Chairs to input
+   and/or change the intended maturity level of a WG draft before the
+   I-D is sent to the IESG.
+
+6.  Security Considerations
+
+   This document does not propose any new Internet mechanisms and has no
+   security implications for the Internet.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
+               3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2418]   Bradner, S., "IETF Working Group Guidelines and
+               Procedures", BCP 25, RFC 2418, September 1998.
+
+   [RFC4844]   Daigle, L., Ed., and Internet Architecture Board, "The
+               RFC Series and RFC Editor", RFC 4844, July 2007.
+
+
+
+
+Juskevicius                   Informational                    [Page 19]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+7.2.  Informative References
+
+   [AUTHGUIDE] Housley, R., Ed. (for the IESG), "Guidelines to Authors
+               of Internet-Drafts", December 7, 2010,
+               http://www.ietf.org/ietf/1id-guidelines.txt.
+
+   [IDTRACKER] "The IETF Datatracker tool", Web Application:
+               https://datatracker.ietf.org/, Version 3.12, February 2,
+               2011.
+
+   [IESGIDSM]  "Diagram of Main I-D States", Web Application:
+               https://datatracker.ietf.org/images/state_diagram.gif,
+               October 21, 2002.
+
+   [IESGSTAT]  "Main I-D States", Web Application:
+               https://datatracker.ietf.org/idtracker/help/state/,
+               Version 3.12, February 2, 2011.
+
+   [PROTO]     Levkowetz, H. and Mankin, A., "Requirements on I-D
+               Tracker Extensions for Working Group Chairs", Work in
+               Progress, February 2007.
+
+   [WGDTSPEC]  Juskevicius, E., "Minutes of wgdtspec BOF", Proceedings
+               of IETF 77, March 26, 2010,
+               http://www.ietf.org/proceedings/10mar/minutes/wgdtspec
+
+8.  Acknowledgments
+
+   The author would like to thank Henrik Levkowetz and Allison Mankin
+   for developing the original I-D [PROTO] that served as the starting
+   point for this document, and Alfred Hoenes for his many comments and
+   suggestions and for articulating the need for the "Adopted by a WG"
+   state.
+
+   The author would also like to thank Henrik Levkowetz, Russ Housley,
+   Paul Hoffman, John Klensin, Pasi Eronen, Robert Sparks, Spencer
+   Dawkins, Mary Barnes, Glenn Parsons, Marc Blanchet, Andy Malis, and
+   Joel Halpern for their comments and feedback along the way.
+
+   Finally, the author also wishes to thank the IETF WG Chairs, ADs and
+   other people who contributed their insights and suggestions in real-
+   time during the wgdtspec BOF at IETF 77, and Lars Eggert, Tim Polk,
+   Robert Sparks, Adrian Farrel and Alexey Melnikov for their comments,
+   suggestions and DISCUSS points on the penultimate draft version of
+   this document.
+
+   This document was initially prepared using 2-Word-v2.0.template.dot.
+
+
+
+
+Juskevicius                   Informational                    [Page 20]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+Appendix A.  "IESG Document" States
+
+   This Appendix describes the status information currently stored in
+   the IETF Datatracker tool for every I-D submitted to the IESG for
+   publication.  All of the terms and definitions in Sections A.1 and
+   A.2 are copied from [IESGSTAT].
+
+   It must be noted that I-Ds sent to the IESG for publication (termed
+   "IESG Documents" in this Appendix) do not stay with the IESG until
+   the day they are published as RFCs.  After evaluation, the IESG may
+   declare that some I-Ds deserve a "Do Not Publish" label.  Other I-Ds
+   may become "Dead".  Some I-Ds may get sent back to their originators
+   (WGs or otherwise), and the rest may go into the RFC Editor queue.
+
+   Note that documents that are not tracked by the IESG (e.g., I-Ds for
+   which no request has been made of the IESG) are in a null state with
+   respect to the IESG state machine.  The IESG state of an I-D that has
+   no value assigned to the IESG state variable in the Datatracker's
+   database is 'NULL'.
+
+A.1.  Definition of "IESG Document" States
+
+A.1.1.  Publication Requested
+
+   A formal request has been made to advance/publish the document,
+   following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the
+   request could be from a WG Chair, or from an individual.  Note: the
+   Secretariat (iesg-secretary@ietf.org) is typically copied on these
+   requests to ensure that the request makes it into the Datatracker.  A
+   document in this state has not (yet) been reviewed by an Area
+   Director nor has any official action been taken yet, other than to
+   note that its publication has been requested.
+
+A.1.2.  AD Evaluation
+
+   A specific AD (e.g., the "Area Advisor" for the WG) has begun their
+   review of the document to verify that it is ready for advancement.
+   The shepherding AD is responsible for doing any necessary review
+   before starting an IETF Last Call or sending the document directly to
+   the IESG as a whole.
+
+A.1.3.  Expert Review
+
+   An AD sometimes asks for an external review by an outside party as
+   part of evaluating whether a document is ready for advancement.
+   MIBs, for example, are reviewed by "MIB doctors".  Other types of
+   reviews may also be requested (e.g., security, operations impacts,
+
+
+
+
+Juskevicius                   Informational                    [Page 21]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   etc.)  Documents stay in this state until the review is complete and
+   possibly until the issues raised in the review are addressed.
+
+   Specific details on the nature of the review may be found in the
+   "note" field associated with this state (i.e., within the
+   Datatracker).
+
+A.1.4.  Last Call Requested
+
+   The AD has requested that the Secretariat start an IETF Last Call,
+   but the actual Last Call message has not been sent yet.
+
+A.1.5.  In Last Call
+
+   The document is currently waiting for IETF Last Call to complete.
+   Last Calls for WG documents typically last 2 weeks, and those for
+   individual submissions last 4 weeks.
+
+A.1.6.  Waiting for Writeup
+
+   Before a standards-track or BCP document is formally considered by
+   the entire IESG, the AD must write up a protocol action.  The
+   protocol action is included in the approval message that the
+   Secretariat sends out when the document is approved for publication
+   as an RFC.
+
+A.1.7.  Waiting for AD Go-Ahead
+
+   As a result of the IETF Last Call, comments may need to be responded
+   to and a revision of the I-D may be needed as well.  The AD is
+   responsible for verifying that all Last Call comments have been
+   adequately addressed and that the (possibly revised) document is
+   ready for consideration by the IESG as a whole.
+
+A.1.8.  IESG Evaluation
+
+   The document is now (finally!) being formally reviewed by the entire
+   IESG.  Documents are discussed in email or during a bi-weekly IESG
+   telechat.  In this phase, each AD reviews the document and airs any
+   content or process issues they may have.  Unresolvable issues are
+   documented as "DISCUSS" comments that can be forwarded to the
+   authors/WG.  See the description of IESG substates in Section A.2 for
+   additional details about the current state of the IESG discussion.
+
+
+
+
+
+
+
+
+Juskevicius                   Informational                    [Page 22]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+A.1.9.  IESG Evaluation - Defer
+
+   During a telechat, one or more ADs requested an additional two weeks
+   to review the document.  A defer is designed to be an exception
+   mechanism, and can only be invoked once, the first time the document
+   comes up for discussion during a telechat.
+
+A.1.10.  Approved - announcement to be sent
+
+   The IESG has approved the document for publication, but the
+   Secretariat has not (yet) sent an official approval message.
+
+A.1.11.  Approved - announcement sent
+
+   The IESG has approved the document for publication, and the
+   Secretariat has sent out the official approval message to the RFC
+   editor.
+
+A.1.12.  RFC Ed Queue
+
+   The document is in the RFC editor Queue (as confirmed by
+   http://www.rfc-editor.org/queue2.html)
+
+A.1.13.  RFC Published
+
+   The I-D has been published as an RFC.
+
+A.1.14.  DNP - waiting for AD note
+
+   Do Not Publish (DNP): The IESG recommends against publishing the
+   document, but the writeup explaining its reasoning has not yet been
+   produced.  DNPs apply primarily to individual submissions received
+   through the RFC Editor.  See the "note" field for more details on who
+   has the action item.
+
+A.1.15.  DNP - announcement to be sent
+
+   The IESG recommends against publishing the document.  The writeup
+   explaining the IESG's reasoning has been produced, but the
+   Secretariat has not yet sent out the official "Do Not Publish"
+   recommendation message.
+
+A.1.16.  AD is watching
+
+   An AD is aware of the document and has chosen to place the document
+   in a separate state in order to monitor it (for whatever reason).
+   Documents in this state are not actively tracked by the IESG in the
+   sense that no formal request has been made to publish or advance the
+
+
+
+Juskevicius                   Informational                    [Page 23]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   document.  The AD has chosen to put the I-D into this state, to make
+   it easier to keep track of (for his or her own reasons).
+
+A.1.17.  Dead
+
+   The document is "Dead" and is no longer being tracked (e.g., it has
+   been replaced by another document having a different name, it has
+   been withdrawn, etc.)
+
+A.2.  IESG Document Substates
+
+   Note that the annotation tags described in this section were defined
+   circa 2002.  If these conditions were modelled today, they would most
+   likely be modelled as annotation tags rather than as substates.
+
+A.2.1.  Point Raised - writeup needed
+
+   IESG discussions on the document have raised some issues that need to
+   be brought to the attention of the authors/WG, but those issues have
+   not been written down yet. (It is common for discussions during a
+   telechat to result in such situations.  An AD may raise a possible
+   issue during a telechat and only decide as a result of that
+   discussion whether the issue is worth formally writing up and
+   bringing to the attention of the authors/WG).
+
+   A document stays in the "Point Raised - writeup needed" substate
+   until *ALL* IESG blocking comments that have been raised have been
+   documented.
+
+A.2.2.  AD Followup
+
+   "AD Followup" is a generic substate indicating that the shepherding
+   AD has the action to determine the appropriate next steps.  In
+   particular, the appropriate steps (and the corresponding next state
+   or substate) depend entirely on the nature of the issues that were
+   raised and can only be decided with active involvement of the
+   shepherding AD.
+
+   Examples include:
+
+   -  If another AD raises an issue, the shepherding AD may first
+      iterate with the other AD to get a better understanding of the
+      exact issue.  Or, the shepherding AD may attempt to argue that the
+      issue is not serious enough it to bring to the attention of the
+      authors/WG.
+
+
+
+
+
+
+Juskevicius                   Informational                    [Page 24]
+
+RFC 6174           IETF Working Group Document States         March 2011
+
+
+   -  If a documented issue is forwarded to a WG, some further iteration
+      may be needed before it can be determined whether a new revision
+      is needed or whether the WG response to an issue clarifies the
+      issue sufficiently.
+
+   -  When a new revision appears, the shepherding AD will first look at
+      the changes to determine whether they believe all outstanding
+      issues have been raised satisfactorily, prior to asking the ADs
+      who raised the original issues to verify the changes.
+
+A.2.3.  External Party
+
+   The document is awaiting review or input from an external party
+   (i.e., someone other than the shepherding AD, the authors, or the
+   WG).  See the "note" field for more details on who has the action.
+
+A.2.4.  Revised ID Needed
+
+   An updated I-D is needed to address the issues that have been raised.
+
+Author's Address
+
+   Ed Juskevicius
+   TrekAhead
+   PO Box 491, Carp, ON
+   CANADA
+
+   EMail: edj.etc@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Juskevicius                   Informational                    [Page 25]
+