Draft Ietf Proto Wgdocument States 02

Proto E.
Juskevicius
Internet Draft TrekAhead
Intended status: Informational March 2, 2010
Expires: September 2, 2010
Definition of Working Group Document States

draft-ietf-proto-wgdocument-states-02.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 September 2, 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 September 2, 2010 [Page 1]

Internet-Draft Working Group Document States March 2010
Abstract
This document contains definitions for the different states that
documents (viz. Internet-Drafts) may experience while associated
with an IETF working group. The first state occurs when an Internet
Draft (I-D) is submitted for consideration as a working group item.
The last state is either when the I-D is sent to the IESG for
publication, or declared as "dead".
The purpose of this Internet-Draft is to serve as a basis for the
definition of requirements to extend the IETF Datatracker tool so
that the community may monitor the status and progression of I-Ds
through IETF working groups.
For completeness, Appendix A has definitions for all of the I-D
states which are already coded into the Datatracker. These states
describe the progression and status of I-Ds after they have been
submitted to the IESG for publication.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. Definitions of Possible WG Document States.....................4
3.1. WG Document States........................................4
3.1.1. Candidate WG Document................................5
3.1.2. Active WG Document...................................5
3.1.3. Not a WG Document....................................5
3.1.4. Parked WG Document...................................5
3.1.5. In WG Last Call......................................5
3.1.6. WG Last Call Completed...............................5
3.1.7. Waiting for WG Document Shepherd Write-Up............6
3.1.8. Submitted to IESG for Publication....................6
3.1.9. Dead WG Document.....................................6
3.2. Straw Man WG Document State Diagram.......................6
3.3. WG Document Substates.....................................6
3.3.1. Awaiting Cross-Area Review...........................8
3.3.2. Awaiting MIB Doctor Review...........................8
3.3.3. Awaiting Security Review.............................8
3.3.4. Awaiting Other Review................................8
3.3.5. Awaiting Merge with Other Document...................9
3.3.6. Author or Editor Needed..............................9
3.3.7. Held due to Dependency on other Document.............9
3.3.8. Held due to IESG concerns on this Document...........9

3.3.9. Revised I-D Needed - based on WG consensus..........10

3.3.10. Revised I-D Needed - based on WG last call.........10
3.3.11. Doc Shepherd Follow-up.............................10
3.3.12. Other - see Comment Log............................10
3.4. Intended Maturity Level of WG Documents..................11
4. Security Considerations.......................................11
5. IANA Considerations...........................................11
6. References....................................................11
6.1. Normative References.....................................11
6.2. Informative References...................................12
7. Acknowledgments...............................................12
Appendix A: "IESG Document" States...............................13
A.1. Definition of "IESG Document" States.....................13
A.1.1. I-D Exists..........................................13
A.1.2. Publication Requested...............................13
A.1.3. AD Evaluation.......................................13
A.1.4. Expert Review.......................................13
A.1.5. Last Call Requested.................................14
A.1.6. In Last Call........................................14
A.1.7. Waiting for Writeup.................................14
A.1.8. Waiting for AD Go-Ahead.............................14
A.1.9. IESG Evaluation.....................................14
A.1.10. IESG Evaluation - Defer............................15
A.1.11. Approved-announcement to be sent...................15
A.1.12. Approved-announcement sent.........................15
A.1.13. RFC Ed Queue.......................................15
A.1.14. RFC Published......................................15
A.1.15. DNP-waiting for AD note............................15
A.1.16. DNP-announcement to be sent........................15
A.1.17. AD is Watching.....................................15
A.1.18. Dead...............................................16
A.2. "IESG Document" Substates................................16
A.2.1. Point Raised - writeup needed.......................16
A.2.2. AD Followup.........................................16
A.2.3. External Party......................................17
A.2.4. Revised I-D Needed..................................17
Author's Address................................................ 17
1. Introduction
The IETF Datatracker is a web-based system for managing information
about Internet-Drafts (I-Ds), RFCs and several other important
aspects of the IETF process [IDTRACKER]. A limitation of the
Datatracker is that its database contains very little information
about the status of Internet Drafts prior to the time they are

submitted to the IESG for publication. Only one non-IESG state is

currently defined and coded into the tool: "I-D Exists".
Section 3 of this I-D proposes definitions for an additional set of
document states, namely every state that a document written for
consideration by an IETF Working Group (WG) may experience during
its progression though a WG.
The purpose of defining WG document states is to enable community
discussion on them and consensus on a state diagram to illustrate
the state transitions preferred by most WGs to progress I-Ds.
A desired outcome of this initiative is to reach consensus on a set
of requirements to extend the Datatracker so that WG Chairs and
other members of the community could monitor the status of I-Ds as
they progress through IETF working groups.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Definitions of Possible WG Document States
The IETF Datatracker tool has minimal information about the status
of I-Ds at the WG level today. Prior to someone asking that an I-SD
be published, the only state tracked by the tool is "I-D Exists".
The Datatracker has no other status information about any WG
document.
In order for the Datatracker to be record WG document state, new WG
document states and substates need to be defined, agreed and then
coded into the front-end of the tool.
Section 3.1 defines the possible states that could apply to I-Ds
that have been submitted to an IETF working group. Section 3.2
illustrates the relationships between the states in diagram form.
Section 3.3 defines additional terms which may be useful to flag
various WG document substates. Section 3.4 lists the all of the
"intended maturity levels" which could be applied to a WG document.
3.1. WG Document States
This subsection defines all of the different states that MAY apply
to any I-D written as a contribution into an IETF working group.

3.1.1. Candidate WG Document

An I-D that is under consideration for becoming a working group
document as a "Candidate WG Document". A document being in this
state does not imply any consensus, and does not imply any
precedence or selection. The purpose of this state is simply to
indicate that someone has asked for an existing I-D to be
considered for acceptance as a working group document.
3.1.2. Active WG Document
An "Active WG Document" is an I-D that has been adopted by a
working group, and is being actively developed.
3.1.3. Not a WG Document
This document is not a WG Document. An I-D may be in this state
for a variety of reasons. Some examples are:
- the I-D was a "Candidate WG Document" but was rejected by the
WG; or
- the I-D is an IAB or IRTF document, an individual submission,
or an independent submission not intended to become a WG
document.
3.1.4. Parked WG Document
A "Parked WG Document" is an I-D which has lost its author or
editor, is waiting for another document to be written or for a
review to be completed, or cannot currently be progressed by the
working group for some other reason.
3.1.5. In WG Last Call
A document "In WG Last Call" is an I-D for which a WG last call
has been issued, and is in progress.
3.1.6. WG Last Call Completed
After a WG last call is completed, any comments received SHOULD be
evaluated before the I-D is progressed. During the evaluation
period, the I-D is in a "WG Last Call Completed" state. After the
evaluation, the document MAY return to being an "Active WG
Document" again (i.e. to be refined or rewritten) or be "Parked"
for a variety of reasons, or be progressed into "Waiting for
Document Shepherd Write-Up".

Many members of the community desire additional information when

the result of a WG Last Call is "Revised I-D Needed". See section
3.3 for "annotation tags" which may be used to provide such
additional information.
3.1.7. Waiting for WG Document Shepherd Write-Up
The working group last call has been completed and the document is
awaiting the document shepherd to submit his/her write-up.
3.1.8. Submitted to IESG for Publication
The document has been submitted to the IESG for publication (and
has not returned to the WG for further action). The document may
be under consideration 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; this state does not distinguish between different states that
may occur after the document has left the working group.
3.1.9. Dead WG Document
A "Dead WG Document" is an I-D that used to a WG document, but has
been abandoned. Note that this is not always a final state. If
consensus is subsequently achieved in the working group, a "Dead
WG Document" can be resurrected.
3.2. Straw Man WG Document State Diagram
Figure 1 illustrates all of the different states defined in section
3.1, and most of the state transitions that an I-D MAY experience
during its tenure as a WG Document.
State transitions which are rare (e.g. an I-D going from "Parked" to
"Dead") are not illustrated in the diagram, however the lack of an
explicit path between two states in the diagram does not mean that
such a transition is impossible.
3.3. WG Document Substates
In addition to identifying the state that every WG Document is in,
it would be informative for the Datatrack to record associated
substates or conditions which may affect each WG Document at
different time. The substates do not change the state of WG
documents, but they can be used, for example, to help the community
understand why a document is in the state it is in, and/or to
indicate the next action needed for the document.

+------------------------------------------------------------------+
| |
| I-D |
| Exists |
| | |
| | |
| v |
| |
| CANDIDATE WG |
| DOCUMENT |
| | |
| | |
| v |
| |
| DEAD WG <----------> ACTIVE WG <--------> PARKED WG |
| DOCUMENT . -> DOCUMENT DOCUMENT |
| . |
| . | ^ ^ |
| . | | | |
| . | + - < - - + | |
| . | | | |
| . v | ^ |
| | | |
| ' IN WG ^ | |
| LAST CALL | | |
| ^ | | |
| | | ^ |
| ' | ^ | |
| v | | |
| ^ | | |
| WG LAST CALL - - - + | |
| ' COMPLETED - - - - - - - - - + |
| |
| ^ | |
| +---------------------+ |
| ' | |
| . v |
| . |
| . SUBMITTED WAITING FOR |
| < - - (to IESG) <------ DOC SHEPHERD |
| FOR PUBLICATION WRITE-UP |
| |
+------------------------------------------------------------------+
Figure 1 - Diagram of I-D states relevant to IETG working groups

Each of the substates defined herein may be appropriate to indicate

the substate of a WG Document at different times.
3.3.1. Awaiting Cross-Area Review
This is a valid substate for "Active" and "Parked" WG Documents.
It 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 remain in this
substate until the review is complete and possibly until the
issues raised in the review are addressed.
3.3.2. Awaiting MIB Doctor Review
or the a WG Chair) has initiated a review of the document by a MIB
Doctor, and the review has not (yet) been completed.
3.3.3. Awaiting Security Review
or a WG Chair) has initiated a review of security considerations
in the document, and the review has not (yet) been completed.
3.3.4. Awaiting Other Review
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 [MPLSTPDP])
and the review has not (yet) been completed.


3.3.5. Awaiting Merge with Other Document
It means that a decision has been made by someone (e.g. the
document's authors, editors, or the WG Chairs) to have the I-D
merged with one or more other I-Ds from the same (or other) WG.
If the result of the "merge" operation is a brand new I-D having a
different title, then the old I-D may be declared as being "Dead".
In this case the substate annotation should be changed from
"Awaiting Merge with Other Document" to "Other - see Comment Log"
and a description of what happened should be entered in the log
for posterity.
If the result of the "merge" operation is a revision to the I-D,
then this substate should be cleared as soon as the the revised I-
D is submitted to the IETF by its authors or editors.
3.3.6. Author or Editor Needed
This substate is applicable to "Parked", "Dead" and (sometimes)
"Active" WG Documents. It means the I-D has lost a primary author
or editor, and that further work on the I-D can not continue in an
effective or efficient manner without a new author or editor being
found.
3.3.7. Held due to Dependency on other Document
This substate is most often associated with "Parked" WG Documents.
It means that work to complete the I-D is on-hold because of one
or more dependencies on other documents. A typical example is
where an I-D includes normative references to other IETF
documents, but all of other documents have not (yet) been
published as RFCs.
3.3.8. Held due to IESG concerns on this Document

This is a valid substate for "Active" and "Parked" WG Documents,
and I-Ds which are in the "WG Last Call Completed" state. This
annotation is an indicator that one or more IESG members have
expressed concerns about the document (e.g. during discussions
leading up to a WG Last Call, or during the WG Last Call), and

that the document MUST NOT be submitted to the IESG for

publication until the concerns are addressed.
Once in this substate, WG Documents SHOULD continue to be tagged
with this indicator until the IESG concerns are resolved, even if
the main state of the I-D changes (e.g. from "Active" to "Parked"
(or "Dead") or vice-versa).
3.3.9. Revised I-D Needed - based on WG consensus
This is a valid substate for "Active", "Parked", and "Dead" WG
Documents. This annotation means that rough consensus was
developed in the working group that the I-D needs to be revised if
it is to be progressed. This annotation can also indicate when an
I-D is already in the process of being revised. This substate
SHOULD be reset when the revised version of the I-D is submitted
to the WG.
3.3.10. Revised I-D Needed - based on WG last call
This is a valid substate for "WG Last Call Completed", "Active",
"Parked", and/or "Dead" WG Documents. This annotation means the
I-D was sent for WG Last Call and the consensus after the Last
Call is that the WG Document MUST be revised before it may
progress any further.
3.3.11. Doc Shepherd Follow-up

This substate annotation indicates when a shepherd for the WG
Document is actually working on the write-up required to submit
the document (to the IESG) for publication. It is often the case
that too many I-Ds can arrive in a Shepherd's queue in too short a
time, and the Shepherd can not create write-ups for all of them
simultaneously. This substate tag SHOULD be used to distinguish
between I-Ds waiting for write-up (i.e. I-Ds for which the write-
ups have not yet been started), and I-Ds for which the write-ups
are already underway.
3.3.12. 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, an AD) has
entered one or more comments about the current state of the I-D
into the IETF Datatracker.

3.4. Intended Maturity Level of WG Documents

In addition to the substate annotation tags defined in section 3.3,
the intended maturity level of every WG Document SHOULD also be
tracked. The definition of the maturity levels are as in sections 4
and 5 of RFC 2026 [RFC2026]. They are:
* "Experimental"
* "Informational"
* "Best Current Practice"
* "Proposed Standard"
* "Draft Standard"
* "Full Standard"
* "Historic"
4. Security Considerations
This document does not propose any new internet mechanisms, and has
no security implications for the internet.
5. IANA Considerations
This document does not require any new number assignments from IANA,
and does not define any new numbering spaces to be administered by
IANA.
RFC-Editor: Please remove this section before publication.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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/, March 1, 2010.
[IDSTATES] "Main I-D States", Web Application:

https://datatracker.ietf.org/idtracker/help/state/,
March 1, 2010.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 2008.
[MPLSTPDP] Farrel, A., et al, "IETF Multi-Protocol Label Switching
(MPLS) Transport Profile (MPLS-tp) Document Process",
draft-IETF-MPLS-tp-process-05.txt, Section 2.3,
January 24, 2010.
[PROTO] Levkowetz, H., and Mankin, A., "Requirements on I-D
Tracker Extensions for Working Group Chairs",
draft-ietf-proto-wgchair-tracker-ext-03,
February 8, 2007.
7. Acknowledgments
The author would like to thank Henrik Levkowetz and Allison Mankin
for writing the original I-Ds [PROTO] that provided copious amounts
of text and the basic structure of this document.
The author would also like to thank Henrik Levkowetz, Alfred Hoenes,
John Klensin, Pasi Eronen, Mary Barnes, Glenn Parsons, Spencer
Dawkins, Russ Housley, Marc Blanchet, Andy Malis and other WG chairs
for useful discussions, comments and suggestions.
This document was initially prepared using 2-Word-v2.0.template.dot.

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. The terms and definitions herein are as in [IDSTATES].
It must be noted that I-Ds sent to the IESG for publication (termed
"IESG Documents" in the Appendix) do not stay with the IESG until
they day they are published as RFCs. After evaluation, the IESG may
declare that some I-Ds deserve a "Do Not Publish" label, while
others should be "Dead". Some I-Ds get sent back to their
originators (WGs or otherwise), and the rest go into the RFC Editor
queue.
A.1. Definition of "IESG Document" States
A.1.1. I-D Exists
This is the initial (default) state for all Internet-Drafts. Such
documents are not tracked by the IESG as no request has been made of
the IESG to do anything with an I-D in this state.
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, from an individual through the RFC
Editor, etc. 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 (AD) nor has any official action been
taken on it yet (other than to note that its publication has been
requested).
A.1.3. AD Evaluation
A specific AD (e.g. the "Area Advisor" for the WG) 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 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 the "MIB doctors". Other types

of reviews may also be requested (e.g., security, operations

impacts, etc.). 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 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.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 in
the I-D directory and ready for consideration by the IESG as a
whole.
A.1.9. 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
issues she/he may have. Unresolvable issues are documented as
"discuss" comments that can be forwarded to the authors/WG. See the
description of 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 2 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.11. Approved-announcement to be sent
The IESG has approved the document for publication, but the
Secretariat has not yet sent out 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/queue.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 writeup explaining its reasoning has not yet been produced.
DNPs apply primarily to individual submissions received through the
RFC editor. 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 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.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 keep a closer eye on it (for

whatever reason). Documents in this state are still not being

actively tracked in the sense that no formal request has been made
to publish or advance the document. The sole difference between
this state and "I-D Exists" is that an AD has chosen to put it in a
separate 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.).
A.2. "IESG Document" 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" state until *ALL* IESG 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 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 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.
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

Draft Ietf Proto Wgdocument States 02

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Draft Ietf Proto Wgdocument States 02

Uploaded by

Copyright:

Available Formats

Proto E.

Definition of Working Group Document States

Status of this Memo

Juskevicius Expires September 2, 2010 [Page 1]

Juskevicius Expires September 2, 2010 [Page 2]

3.3.9. Revised I-D Needed - based on WG consensus..........10

Juskevicius Expires September 2, 2010 [Page 3]

submitted to the IESG for publication. Only one non-IESG state is

Juskevicius Expires September 2, 2010 [Page 4]

3.1.1. Candidate WG Document

Juskevicius Expires September 2, 2010 [Page 5]

Many members of the community desire additional information when

Juskevicius Expires September 2, 2010 [Page 6]

Juskevicius Expires September 2, 2010 [Page 7]

Each of the substates defined herein may be appropriate to indicate

Juskevicius Expires September 2, 2010 [Page 8]

Documents tagged with this annotation SHOULD remain in this

3.3.8. Held due to IESG concerns on this Document

Juskevicius Expires September 2, 2010 [Page 9]

that the document MUST NOT be submitted to the IESG for

3.3.11. Doc Shepherd Follow-up

3.3.12. Other - see Comment Log

Juskevicius Expires September 2, 2010 [Page 10]

3.4. Intended Maturity Level of WG Documents

Juskevicius Expires September 2, 2010 [Page 11]

6.2. Informative References

[IDSTATES] "Main I-D States", Web Application:

Juskevicius Expires September 2, 2010 [Page 12]

Appendix A: "IESG Document" States

Juskevicius Expires September 2, 2010 [Page 13]

of reviews may also be requested (e.g., security, operations

Juskevicius Expires September 2, 2010 [Page 14]

A.1.10. IESG Evaluation - Defer

Juskevicius Expires September 2, 2010 [Page 15]

whatever reason). Documents in this state are still not being

Juskevicius Expires September 2, 2010 [Page 16]

- when a new revision appears, the shepherding AD will first look at

Juskevicius Expires September 2, 2010 [Page 17]

You might also like