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