Proto E. Juskevicius
Internet Draft TrekAhead
Intended status: Informational May 21, 2010
Expires: November 21, 2010
Definition of IETF Working Group Document States
draft-ietf-proto-wgdocument-states-05.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 21, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
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.
Juskevicius Expires November 21, 2010 [Page 1]
Internet-Draft IETF Working Group Document States May 2010
Abstract
The IETF Datatracker tool will be enhanced to make it possible for
working group chairs to provide more transparency into the status
and progression of working group documents to authors and other
members of the IETF community.
This document defines the states that may be used to describe the
status of an Internet-Draft (I-D) that is associated with an IETF
working group (WG). The first state can be used to describe an I-D
that is being considered for adoption by a working group, and the
last state describes an I-D that has been submitted to the IESG.
Appendix A describes states currently used to indicate the status of
an I-D after it has been sent to the IESG for publication.
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.2. IESG Document States......................................5
3.2.1. Publication Requested................................5
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.............................6
3.3.1. Candidate WG Document................................7
3.3.2. WG Document..........................................7
3.3.3. Adopted For WG Info Only.............................8
3.3.4. Not Adopted by a WG..................................8
3.3.5. Parked WG Document...................................8
3.3.6. Dead WG Document.....................................9
3.3.7. In WG Last Call......................................9
3.3.8. Waiting for WG Chair Go-Ahead........................9
3.3.9. WG Consensus: Waiting for Write-Up..................10
3.3.10. Submitted to IESG for Publication..................10
3.4. Working Group Document State Diagram.....................10
3.5. WG Document Status Annotation Tags.......................12
3.5.1. Awaiting Cross-Area Review..........................12
3.5.2. Awaiting MIB Doctor Review..........................12
3.5.3. Awaiting Security Review............................13
3.5.4. Awaiting External Review............................13
3.5.5. Awaiting Merge with Other Document..................13
3.5.6. Author or Editor Needed.............................14
3.5.7. Waiting for Referenced Document.....................14
Juskevicius Expires November 21, 2010 [Page 2]
Internet-Draft IETF Working Group Document States May 2010
3.5.8. Waiting for Referencing Document....................14
3.5.9. Revised I-D Needed - Issue raised by WG Last Call...14
3.5.10. Revised I-D Needed - Issue raised by AD............14
3.5.11. Revised I-D Needed - Issue raised by IESG..........15
3.5.12. Doc Shepherd Follow-Up Underway....................15
3.5.13. Other - see Comment Log............................15
3.6. Intended Maturity Level of WG Documents..................15
4. Security Considerations.......................................16
5. IANA Considerations...........................................16
6. References....................................................16
6.1. Normative References.....................................16
6.2. Informative References...................................16
7. Acknowledgments...............................................17
Appendix A: "IESG Document" States...............................18
A.1. Definition of "IESG Document" States.....................18
A.1.1. NULL................................................18
A.1.2. Publication Requested...............................18
A.1.3. AD Evaluation.......................................18
A.1.4. Expert Review.......................................18
A.1.5. Last Call Requested.................................19
A.1.6. In Last Call........................................19
A.1.7. Waiting for Write-up................................19
A.1.8. Waiting for AD Go-Ahead.............................19
A.1.9. IESG Evaluation.....................................19
A.1.10. IESG Evaluation - Defer............................19
A.1.11. Approved - Announcement to be sent.................20
A.1.12. Approved - Announcement sent.......................20
A.1.13. RFC Ed Queue.......................................20
A.1.14. RFC Published......................................20
A.1.15. DNP - Waiting for AD note..........................20
A.1.16. DNP - Announcement to be sent......................20
A.1.17. AD is Watching.....................................20
A.1.18. Dead...............................................20
A.2. IESG Document Substates..................................21
A.2.1. Point Raised - Write-up needed......................21
A.2.2. AD Follow-up........................................21
A.2.3. External Party......................................22
A.2.4. Revised I-D Needed..................................22
1. Introduction
The IETF Datatracker is a web-based system for managing information
about Internet-Drafts, RFCs 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.
Juskevicius Expires November 21, 2010 [Page 3]
Internet-Draft IETF Working Group Document States May 2010
In contrast, the Datatracker currently has almost no information
about the status of a working group I-D before it is sent to 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 provide availability information,
but just an indication that an "I-D Exists"; this is synonymous with
an 'Active' I-D that has not been sent to the IESG.
This document defines new states to be added to the Datatracker to
make it possible for IETF working group chairs to indicate the
status and progression of the Internet-Drafts in their working
groups.
2. Conventions used in this document
The phrase "working group document" is to be interpreted as being
synonymous with "working group I-D" and "working group draft". 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 provides a summary of the status information that may
be obtained about an I-D by querying the Datatracker today, and it
defines several new states that need to be added to enable WG chairs
to describe the status of I-Ds in their working groups in more
detail.
3.1. Document Availability States
The Datatracker can be queried about the availability status of
every I-D submitted to the IETF. The availability states are
called:
- Expired
- Active
- Replaced
- Withdrawn by Submitter
- Withdrawn by IETF
- RFC
Juskevicius Expires November 21, 2010 [Page 4]
Internet-Draft IETF Working Group Document States May 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 version.
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 and that the
Datatracker has some additional status information about.
An "Active" document may be an Individual I-D or a WG I-D.
"Active" may also used to describe the status of an I-D under
formal evaluation by the IESG or an I-D that is in the RFC Editor
Queue, etc.
Note that "Active" is not a reliable indicator of whether an I-D
is being actively developed in an IETF working group [WGDTSPEC].
3.2. IESG Document States
The IESG uses more than a dozen different states to describe the
status and progression of I-Ds under evaluation by the IESG
[IESGSTAT]. The following sections describe three of the IESG
states which should be of interest to document 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
Internet-Draft 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.
Juskevicius Expires November 21, 2010 [Page 5]
Internet-Draft IETF Working Group Document States May 2010
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 Area Director 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 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 working group for revision.
"IESG Evaluation" describes a document that is being formally
evaluated by the entire IESG. Every Area Director is expected to
review the document and to air any issues he/she may have. Issues
that cannot be resolved are documented as "DISCUSS" comments that
can be forwarded to the document author and/or to the WG chair.
A "DISCUSS" with serious issues may cause the I-D to be returned
to the working group for revision.
3.2.4. Other IESG Document States
See Appendix A and [IESGSTAT].
3.3. Working Group Document States
This section describes new states to be added to the Datatracker to
make it possible for working group chairs and/or their delegates to
indicate the working group status of an I-D.
Working group chairs will have the option to use some, all or none
of these working group 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 visibility into why a WG document may be in the state it
is in and/or the action needed to progress the document into its
next state.
When an I-D is submitted to the IETF, the submission is logged in a
database that can be searched by the Datatracker. The Datatracker
examines the title of every submission to determine if the I-D is
associated with an IETF working group. An I-D that includes the
Juskevicius Expires November 21, 2010 [Page 6]
Internet-Draft IETF Working Group Document States May 2010
name of an IETF working group in its title is a WG document. An I-D
that does not include the name of a working group is not a WG
document; it may belong to one of the other document streams (e.g.
IAB, IRTF, Independent Submission) defined in RFC 4844 [RFC 4844].
In the case where a working group chair does not manually update the
status of a working group I-D, the Datatracker may be able to
provide some visibility into the WG status of the I-D using a subset
of the states defined in this section.
The Datatracker may be enhanced to automatically generate a few
state transitions for WG documents in cases where the chair does not
manually input the status of the I-Ds. For example, the Datatracker
could automatically place an I-D into the "WG Document" state
defined in Section 3.3.2 if the chair does not. Similarly, the
Datatracker could automatically move a "WG Document" into the
"Submitted to IESG for Publication" state in the WG document state
machine when the I-D enters the "Publication Requested" state in the
IESG state machine.
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 working group.
An I-D in this state has not (yet) achieved consensus, preference
or selection in a working group.
This state may be used by a WG chair to describe:
- an I-D that someone has asked to be considered by a working
group, if the chair has agreed with the request;
- an I-D that the working group chair asked an author to write;
- 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 have
a way to track this, the Datatracker will allow an I-D to be in
the "Candidate WG Document" state for more than one working group
at a time; the Datatracker will maintain a separate state machine
to track the status of I-Ds in every IETF working group.
3.3.2. WG Document
A "WG Document" is an I-D that has been adopted by an IETF working
group and is being actively developed.
Juskevicius Expires November 21, 2010 [Page 7]
Internet-Draft IETF Working Group Document States May 2010
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 regularly
requested by the community and is now required by the IESG for
every I-D that is sent 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
working group to another. The Datatracker will make it possible
to track when a "WG Document" is transferred from one IETF working
group to another.
3.3.3. Adopted For WG Info Only
The "Adopted For WG Info Only" state describes a document that
contains useful information for the working group; however the
document will not be published as an RFC. The working group will
not actively develop the contents of the I-D or progress it for
publication as an RFC. The purpose of the I-D is to provide
information for internal use by the working group.
3.3.4. 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 may be used to
describe an I-D that was considered for adoption by one or more
IETG 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 no
WG chair moves the I-D into some other state before the expiry of
a 'must be adopted by a specified date or else' timer. To
facilitate this, the Datatracker could send an e-mail 'nudge' to
the chair of every WG that identified the I-D as a candidate for
adoption. The nudge could warn that the Datatracker will
automatically move the I-D into the "Not Adopted by a WG" state in
a week's time unless some chair moves the document into a
different state first (e.g., "WG Document", "Adopted for WG Info
Only").
3.3.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
Juskevicius Expires November 21, 2010 [Page 8]
Internet-Draft IETF Working Group Document States May 2010
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.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 working group draft. If
consensus is subsequently achieved, a "Dead WG Document" may be
resurrected.
3.3.7. In WG Last Call
A document "In WG Last Call" is an I-D for which a Working Group
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, he/she may use
the "In WG Last Call" state to track the progress of the WGLC.
The chair may program the Datatracker to send a WGLC message to
one or more mailing lists when the chair moves the I-D into this
state.
A document in this state should remain "In WG Last Call" until the
WG chair moves it to another state. The WG chair may program 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.8. Waiting for WG Chair Go-Ahead
An IETF 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.
Juskevicius Expires November 21, 2010 [Page 9]
Internet-Draft IETF Working Group Document States May 2010
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 directory.
3.3.9. WG Consensus: Waiting for Write-Up
A document in the "WG Consensus: Waiting for Write-Up" state has
essentially completed its development within the working group,
and is nearly ready to be sent to the IESG for publication. The
last thing to be done is the preparation of a protocol write-up by
a document shepherd. The IESG requires that a document shepherd
write-up be completed before publication of the I-D is requested.
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.10. Submitted to IESG for Publication
This state describes a WG document that has been submitted to the
IESG for publication and that has not been sent back to the
working group for revision.
An I-D in this state may be under review by the IESG, or it may
have been approved and be in the RFC Editor's queue, or it may
have been published as an RFC. Other possibilities exist too.
The document may be "Dead" (in the IESG state machine) or in a
"Do Not Publish" state.
3.4. Working Group Document State Diagram
Figure 1 illustrates all of the WG documents states and many of the
state transitions that an I-D may experience during its 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.
A working group document may be moved from any WG document state to
any other WG document state by the 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.
Juskevicius Expires November 21, 2010 [Page 10]
Internet-Draft IETF Working Group Document States May 2010
+------------------------------------------------------------------+
| + - - - - - - - I-D Exists |
| | | |
| v v |
| |
| ADOPTED FOR <----- CANDIDATE WG -----> NOT ADOPTED |
| WG INFO ONLY DOCUMENT BY A WG |
| | |
| | |
| v |
| |
| PARKED WG <----------> WG <--------> DEAD WG |
| DOCUMENT . - > DOCUMENT DOCUMENT |
| . |
| . / \ |
| . / \ |
| . / \ |
| . v \ |
| . \ |
| . 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 working groups
Juskevicius Expires November 21, 2010 [Page 11]
Internet-Draft IETF Working Group Document States May 2010
The WG document states 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 Area Director or the IESG as a
whole sends an I-D back to a working group for revision. An I-D
that is deemed to need revision will have in one of the IESG states
(in the IESG state machine) and it may also return to being in one
of the states in the working group state machine for a while.
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
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.
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
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.
Juskevicius Expires November 21, 2010 [Page 12]
Internet-Draft IETF Working Group Document States May 2010
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
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.
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
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.
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 that 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 other) 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 Draft". 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 in 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)
Internet-Draft is submitted to the working group.
Juskevicius Expires November 21, 2010 [Page 13]
Internet-Draft IETF Working Group Document States May 2010
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
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 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 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 - Issue raised by WG Last Call
This annotation means the I-D 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.
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.
Juskevicius Expires November 21, 2010 [Page 14]
Internet-Draft IETF Working Group Document States May 2010
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.
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"
Juskevicius Expires November 21, 2010 [Page 15]
Internet-Draft IETF Working Group Document States May 2010
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.
RFC-Editor: Please remove this section before publication.
6. References
6.1. Normative References
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The
RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC2418] Bradner, S., Ed., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
6.2. Informative References
[IDTRACKER] "The IETF Datatracker tool", Web Application:
https://datatracker.ietf.org/, May 19, 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/,
May 19, 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.
Juskevicius Expires November 21, 2010 [Page 16]
Internet-Draft IETF Working Group Document States May 2010
7. Acknowledgments
The author would like to thank Henrik Levkowetz and Allison Mankin
for writing the original I-D [PROTO] used by the author as the
starting point for earlier versions of this document.
The author would also like to thank Henrik Levkowetz, Russ Housley,
Alfred Hoenes, John Klensin, Pasi Eronen, Robert Sparks, Spencer
Dawkins, Paul Hoffman, Mary Barnes, Glenn Parsons, Marc Blanchet,
and Andy Malis for their many comments and helpful suggestions to
improve this document.
Finally, the author would also like to thank the IETF WG chairs, ADs
and other participants in the wgdtspec BOF at IETF 77 for their
insights, discussions, comments and suggestions.
This document was initially prepared using 2-Word-v2.0.template.dot.
Juskevicius Expires November 21, 2010 [Page 17]
Internet-Draft IETF Working Group Document States May 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 November 21, 2010 [Page 18]
Internet-Draft IETF Working Group Document States May 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
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
mechanism, and can only be invoked once, the first time the document
comes up for discussion during a telechat.
Juskevicius Expires November 21, 2010 [Page 19]
Internet-Draft IETF Working Group Document States May 2010
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: 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).
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.).
Juskevicius Expires November 21, 2010 [Page 20]
Internet-Draft IETF Working Group Document States May 2010
A.2. IESG Document Substates
Note that the annotation tags described in this section were defined
circa 2002. If these conditioned were modelled today, they would
most likely be modelled as annotation tags rather than as
"substates".
A.2.1. Point Raised - Write-up needed
IESG discussions on the document have raised some issues that need
to be brought to the attention of the authors/WG, but those issues
have not been written down yet. (It is common for discussions during
a telechat to result in such situations. An AD may raise a possible
issue during a telechat and only decide as a result of that
discussion whether the issue is worth formally writing up and
bringing to the attention of the authors/WG).
A document stays in the "Point Raised - write-up needed" substate
until *ALL* IESG 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.
- when a new revision appears, the shepherding AD will first look
at the changes to determine whether they believe all outstanding
issues have been raised satisfactorily, prior to asking the ADs
who raised the original issues to verify the changes.
Juskevicius Expires November 21, 2010 [Page 21]
Internet-Draft IETF Working Group Document States May 2010
A.2.3. External Party
The document is awaiting review or input from an external party
(i.e, someone other than the shepherding AD, the authors, or the
WG). See the "note" field for more details on who has the action.
A.2.4. Revised I-D Needed
An updated I-D is needed to address the issues that have been
raised.
Author's Address
Ed Juskevicius
TrekAhead
PO Box 491, Carp, ON
CANADA
Email: edj.etc@gmail.com
Juskevicius Expires November 21, 2010 [Page 22]
