conflrevadrevAD ReviewTrueThe sponsoring AD is reviewing the document and preparing a proposed response2conflreviesgevalIESG EvaluationTrueThe IESG is considering the proposed conflict review response3conflrevdeferIESG Evaluation - DeferTrueThe evaluation of the proposed conflict review response has been deferred to the next telechat4conflrevappr-reqnopub-pendApproved Request to Not Publish - announcement to be sentTrueThe IESG has approved the conflict review response (a request to not publish), but the secretariat has not yet sent the response5conflrevappr-noprob-pendApproved No Problem - announcement to be sentTrueThe IESG has approved the conflict review response, but the secretariat has not yet sent the response6conflrevappr-reqnopub-sentApproved Request to Not Publish - announcement sentTrueThe secretariat has delivered the IESG's approved conflict review response (a request to not publish) to the requester7conflrevappr-noprob-sentApproved No Problem - announcement sentTrueThe secretariat has delivered the IESG's approved conflict review response to the requester8conflrevwithdrawWithdrawnTrueThe request for conflict review was withdrawn9conflrevdeadDeadTrueThe conflict review has been abandoned10draftactiveActiveTrue1draftexpiredExpiredTrue2draftrfcRFCTrue3draftreplReplacedTrue4draftauth-rmWithdrawn by SubmitterTrue5draftietf-rmWithdrawn by IETFTrue6draft-iesgpub-reqPublication RequestedTrueA formal request has been made to advance/publish the document, following the procedures in Section 7.5 of RFC 2418. The request could be from a WG chair, from an individual through the RFC Editor, etc. (The Secretariat (iesg-secretary@ietf.org) is copied on these requests to ensure that the request makes it into the ID tracker.) A document in this state has not (yet) been reviewed by an AD nor has any official action been taken on it yet (other than to note that its publication has been requested.10draft-iesgad-evalAD EvaluationTrueA specific AD (e.g., the Area Advisor for the WG) has begun reviewing 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.11draft-iesgreview-eExpert ReviewTrueAn 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 impact, etc.). Documents stay in this state until the review is complete and possibly until the issues raised in the review are addressed. See the "note" field for specific details on the nature of the review.12draft-iesglc-reqLast Call RequestedTrueThe AD has requested that the Secretariat start an IETF Last Call, but the the actual Last Call message has not been sent yet.15draft-iesglcIn Last CallTrueThe document is currently waiting for IETF Last Call to complete. Last Calls for WG documents typically last 2 weeks, those for individual submissions last 4 weeks.16draft-iesgwriteupwWaiting for WriteupTrueBefore 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.18draft-iesggoaheadwWaiting for AD Go-AheadTrueAs a result of the IETF Last Call, comments may need to be responded to and a revision of the ID 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 ID directory and ready for consideration by the IESG as a whole.19draft-iesgiesg-evaIESG EvaluationTrueThe 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 they may have. Unresolvable issues are documented as "discuss" comments that can be forwarded to the authors/WG. See the description of substates for additional details about the current state of the IESG discussion.20draft-iesgdeferIESG Evaluation - DeferTrueDuring 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.21draft-iesgapprovedApproved-announcement to be sentTrueThe IESG has approved the document for publication, but the Secretariat has not yet sent out on official approval message.27draft-iesgannApproved-announcement sentTrueThe IESG has approved the document for publication, and the Secretariat has sent out the official approval message to the RFC editor.30draft-iesgrfcqueueRFC Ed QueueTrueThe document is in the RFC editor Queue (as confirmed by http://www.rfc-editor.org/queue.html).31draft-iesgpubRFC PublishedTrueThe ID has been published as an RFC.32draft-iesgnopubadwDNP-waiting for AD noteTrueDo 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. See the "note" field for more details on who has the action item.33draft-iesgnopubanwDNP-announcement to be sentTrueThe IESG recommends against publishing the document, the writeup explaining its reasoning has been produced, but the Secretariat has not yet sent out the official "do not publish" recommendation message.34draft-iesgwatchingAD is watchingTrueAn 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 the AD's own reasons).42draft-iesgdeadDeadTrueDocument is "dead" and is no longer being tracked. (E.g., it has been replaced by another document with a different name, it has been withdrawn, etc.)99draft-rfceditorauthAUTHTrueAwaiting author action0draft-rfceditorauth48AUTH48TrueAwaiting final author approval0draft-rfceditoreditEDITTrueApproved by the stream manager (e.g., IESG, IAB, IRSG, ISE), awaiting processing and publishing0draft-rfceditoriana-crdIANATrueRFC-Editor/IANA Registration Coordination0draft-rfceditoriesgIESGTrueHolding for IESG action0draft-rfceditorisrISRTrueIndependent Submission Review by the ISE 0draft-rfceditorisr-authISR-AUTHTrueIndependent Submission awaiting author update, or in discussion between author and ISE0draft-rfceditorrefREFTrueHolding for normative reference0draft-rfceditorrfc-editRFC-EDITORTrueAwaiting final RFC Editor review before AUTH480draft-rfceditortimeoutTOTrueTime-out period during which the IESG reviews document for conflict/concurrence with other IETF working group work0draft-rfceditormissrefMISSREFTrueAwaiting missing normative reference0draft-stream-iabcandidatCandidate IAB DocumentTrueA document being considered for the IAB stream.1draft-stream-iabactiveActive IAB DocumentTrueThis document has been adopted by the IAB and is being actively developed.2draft-stream-iabparkedParked IAB DocumentTrueThis document has lost its author or editor, is waiting for another document to be written, or cannot currently be worked on by the IAB for some other reason. Annotations probably explain why this document is parked.3draft-stream-iabreview-iIAB ReviewTrueThis document is awaiting the IAB itself to come to internal consensus.4draft-stream-iabreview-cCommunity ReviewTrueThis document has completed internal consensus within the IAB and is now under community review.5draft-stream-iabapprovedApproved by IAB, To Be Sent to RFC EditorTrueThe consideration of this document is complete, but it has not yet been sent to the RFC Editor for publication (although that is going to happen soon).6draft-stream-iabdiff-orgSent to a Different Organization for PublicationTrueThe IAB does not expect to publish the document itself, but has passed it on to a different organization that might continue work on the document. The expectation is that the other organization will eventually publish the document.7draft-stream-iabrfc-editSent to the RFC EditorTrueThe IAB processing of this document is complete and it has been sent to the RFC Editor for publication. The document may be in the RFC Editor's queue, or it may have been published as an RFC; this state doesn't distinguish between different states occurring after the document has left the IAB.8draft-stream-iabpubPublished RFCTrueThe document has been published as an RFC.9draft-stream-iabdeadDead IAB DocumentTrueThis document was an active IAB document, but for some reason it is no longer being pursued for the IAB stream. It is possible that the document might be revived later, possibly in another stream.10draft-stream-ietfc-adoptCall For Adoption By WG IssuedTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.1" target="_blank">4.2.1. Call for Adoption by WG Issued</a>
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.1draft-stream-ietfadopt-wgAdopted by a WGTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.2" target="_blank">4.2.2. Adopted by a WG</a>
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. 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.2draft-stream-ietfinfoAdopted for WG Info OnlyTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.3" target="_blank">4.2.3. Adopted for WG Info Only</a>
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.3draft-stream-ietfwg-docWG DocumentTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.4" target="_blank">4.2.4. WG Document</a>
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.4draft-stream-ietfparkedParked WG DocumentTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.5" target="_blank">4.2.5. Parked WG Document</a>
A "Parked WG Document" is an I-D that has lost its author or editor, is waiting for another document to be written or for a review to be completed, or cannot be progressed by the working group for some other reason.
Some of the annotation tags described in Section 4.3 may be used in conjunction with this state to indicate why an I-D has been parked, and/or what may need to happen for the I-D to be un-parked.
Parking a WG draft will not prevent it from expiring; however, this state can be used to indicate why the I-D has stopped progressing in the WG.
A "Parked WG Document" that is not expired may be transferred from one WG to another with the consent of the WG Chairs and the responsible ADs.5draft-stream-ietfdeadDead WG DocumentTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.6" target="_blank">4.2.6. Dead WG Document</a>
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.6draft-stream-ietfwg-lcIn WG Last CallTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.7" target="_blank">4.2.7. In WG Last Call</a>
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.
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.7draft-stream-ietfchair-wWaiting for WG Chair Go-AheadTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.8" target="_blank">4.2.8. Waiting for WG Chair Go-Ahead</a>
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.8draft-stream-ietfwriteupwWG Consensus: Waiting for Write-UpTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.9" target="_blank">4.2.9. WG Consensus: Waiting for Writeup</a>
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.9draft-stream-ietfsub-pubSubmitted to IESG for PublicationTrue<a href="http://tools.ietf.org/html/rfc6174#section-4.2.10" target="_blank">4.2.10. Submitted to IESG for Publication</a>
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.10draft-stream-irtfcandidatCandidate RG DocumentTrueThis document is under consideration in an RG for becoming an IRTF document. A document in this state does not imply any RG consensus and does not imply any precedence or selection. It's simply a way to indicate that somebody has asked for a document to be considered for adoption by an RG.1draft-stream-irtfactiveActive RG DocumentTrueThis document has been adopted by the RG and is being actively developed.2draft-stream-irtfparkedParked RG DocumentTrueThis document has lost its author or editor, is waiting for another document to be written, or cannot currently be worked on by the RG for some other reason.3draft-stream-irtfrg-lcIn RG Last CallTrueThe document is in its final review in the RG.4draft-stream-irtfsheph-wWaiting for Document ShepherdTrueIRTF documents have document shepherds who help RG documents through the process after the RG has finished with the document.5draft-stream-irtfchair-wWaiting for IRTF ChairTrueThe IRTF Chair is meant to be performing some task such as sending a request for IESG Review.6draft-stream-irtfirsg-wAwaiting IRSG ReviewsTrueThe document shepherd has taken the document to the IRSG and solicited reviews from one or more IRSG members.7draft-stream-irtfirsgpollIn IRSG PollTrueThe IRSG is taking a poll on whether or not the document is ready to be published.8draft-stream-irtfiesg-revIn IESG ReviewTrueThe IRSG has asked the IESG to do a review of the document, as described in RFC5742.9draft-stream-irtfrfc-editSent to the RFC EditorTrueThe RG processing of this document is complete and it has been sent to the RFC Editor for publication. The document may be in the RFC Editor's queue, or it may have been published as an RFC; this state doesn't distinguish between different states occurring after the document has left the RG.10draft-stream-irtfpubPublished RFCTrueThe document has been published as an RFC.11draft-stream-irtfiesgholdDocument on Hold Based On IESG RequestTrueThe IESG has requested that the document be held pending further review, as specified in RFC 5742, and the IRTF has agreed to such a hold.12draft-stream-irtfdeadDead IRTF DocumentTrueThis document was an active IRTF document, but for some reason it is no longer being pursued for the IRTF stream. It is possible that the document might be revived later, possibly in another stream.13draft-stream-isereceiveSubmission ReceivedTrueThe draft has been sent to the ISE with a request for publication.1draft-stream-isefind-revFinding ReviewersTrue The ISE is finding initial reviewers for the document.2draft-stream-iseise-revIn ISE ReviewTrueThe ISE is actively working on the document.3draft-stream-iseneed-resResponse to Review NeededTrue One or more reviews have been sent to the author, and the ISE is awaiting response.4draft-stream-iseiesg-revIn IESG ReviewTrueThe ISE has asked the IESG to do a review of the document, as described in RFC5742.5draft-stream-iserfc-editSent to the RFC EditorTrueThe ISE processing of this document is complete and it has been sent to the RFC Editor for publication. The document may be in the RFC Editor's queue, or it may have been published as an RFC; this state doesn't distinguish between different states occurring after the document has left the ISE.6draft-stream-isepubPublished RFCTrueThe document has been published as an RFC.7draft-stream-isedeadNo Longer In Independent Submission StreamTrueThis document was actively considered in the Independent Submission stream, but the ISE chose not to publish it. It is possible that the document might be revived later. A document in this state may have a comment explaining the reasoning of the ISE (such as if the document was going to move to a different stream).8draft-stream-iseiesgholdDocument on Hold Based On IESG RequestTrueThe IESG has requested that the document be held pending further review, as specified in RFC 5742, and the ISE has agreed to such a hold.9minutesactiveActiveTrue1minutesdeletedDeletedTrue2slidesactiveActiveTrue1slidesdeletedDeletedTrue2conflrevconflrevApproveIs this the correct conflict review response?True0charterr-extrevReady for external reviewIs this charter ready for external review?True1draftapproveApproveTrue1charterr-wo-extReady w/o external reviewIs this charter ready for external review? Is this charter ready for approval without external review?True2charterapproveApproveDo we approve of this charter?True3