idnits 2.17.1 draft-ietf-proto-wgdocument-states-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2010) is 4922 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4858' is mentioned on line 673, but not defined ** Obsolete normative reference: RFC 4844 (Obsoleted by RFC 8729) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Proto E. Juskevicius 2 Internet Draft TrekAhead 3 Intended status: Informational October 7, 2010 4 Expires: April 7, 2011 6 Definition of IETF Working Group Document States 7 draft-ietf-proto-wgdocument-states-10.txt 9 Abstract 11 The IETF Datatracker tool needs to be enhanced to make it possible 12 for Working Group (WG) Chairs to provide IETF participants with more 13 information about the status and progression of WG documents than is 14 currently possible. 16 This document defines new states and status annotation tags that 17 need to be added to the Datatracker to enable WG Chairs and their 18 delegates to track the status of Internet-Drafts (I-Ds) that are 19 associated with their WGs. This document also describes the meaning 20 of all previously implemented I-D states and substate annotation 21 tags currently used by IETF Area Directors to indicate the status of 22 I-Ds that have been sent to the IESG for evaluation and publication. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with 27 the provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 7, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction...................................................3 59 2. Conventions used in this document..............................4 60 3. I-D States already implemented by the Datatracker..............4 61 3.1. I-D Availability States...................................5 62 3.1.1. Expired..............................................5 63 3.1.2. Active...............................................5 64 3.1.3. Replaces & Replaced By...............................6 65 3.2. IESG Document States......................................6 66 3.2.1. Publication Requested................................7 67 3.2.2. AD Evaluation........................................7 68 3.2.3. IESG Evaluation......................................8 69 4. New States and Status Annotation Tags for WG I-Ds..............8 70 4.1. Working Group I-D State Diagram...........................8 71 4.2. Working Group I-D States.................................10 72 4.2.1. Call For Adoption By WG Issued......................11 73 4.2.2. Adopted by a WG.....................................12 74 4.2.3. Adopted for WG Info Only............................12 75 4.2.4. WG Document.........................................12 76 4.2.5. Parked WG Document..................................13 77 4.2.6. Dead WG Document....................................13 78 4.2.7. In WG Last Call.....................................13 79 4.2.8. Waiting for WG Chair Go-Ahead.......................14 80 4.2.9. WG Consensus: Waiting for Write-Up..................14 81 4.2.10. Submitted to IESG for Publication..................15 82 4.3. Working Group I-D Status Annotation Tags.................15 83 4.3.1. Awaiting Expert Review/Resolution of Issues Raised..15 84 4.3.2. Awaiting External Review/Resolution of Issues Raised15 85 4.3.3. Awaiting Merge with Other Document..................16 86 4.3.4. Author or Editor Needed.............................16 87 4.3.5. Waiting for Referenced Document.....................16 88 4.3.6. Waiting for Referencing Document....................17 89 4.3.7. Revised I-D Needed - Issue raised by WGLC...........17 90 4.3.8. Revised I-D Needed - Issue raised by AD.............17 91 4.3.9. Revised I-D Needed - Issue raised by IESG...........17 92 4.3.10. Doc Shepherd Follow-Up Underway....................17 93 4.3.11. Other - see Comment Log............................18 94 5. Intended Maturity Level of WG Drafts..........................18 95 6. Security Considerations.......................................18 96 7. IANA Considerations...........................................19 97 8. References....................................................19 98 8.1. Normative References.....................................19 99 8.2. Informative References...................................19 100 9. Acknowledgments...............................................20 101 Appendix A: "IESG Document" States...............................21 102 A.1. Definition of "IESG Document" States.....................21 103 A.1.1. Publication Requested...............................21 104 A.1.2. AD Evaluation.......................................21 105 A.1.3. Expert Review.......................................21 106 A.1.4. Last Call Requested.................................22 107 A.1.5. In Last Call........................................22 108 A.1.6. Waiting for Writeup.................................22 109 A.1.7. Waiting for AD Go-Ahead.............................22 110 A.1.8. IESG Evaluation.....................................22 111 A.1.9. IESG Evaluation - Defer.............................22 112 A.1.10. Approved - Announcement to be sent.................23 113 A.1.11. Approved - Announcement sent.......................23 114 A.1.12. RFC Ed Queue.......................................23 115 A.1.13. RFC Published......................................23 116 A.1.14. DNP - Waiting for AD note..........................23 117 A.1.15. DNP - Announcement to be sent......................23 118 A.1.16. AD is Watching.....................................23 119 A.1.17. Dead...............................................23 120 A.2. IESG Document Substates..................................24 121 A.2.1. Point Raised - Write-up needed......................24 122 A.2.2. AD Follow-up........................................24 123 A.2.3. External Party......................................25 124 A.2.4. Revised I-D Needed..................................25 126 1. Introduction 128 The IETF Datatracker is a web-based system for managing information 129 about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison 130 statements and several other important aspects of the IETF process 131 [IDTRACKER]. 133 The Datatracker is currently able to track and report on the status 134 of I-Ds that have been submitted to the IESG for evaluation and 135 publication. Appendix A of this document describes all of the 136 document states and substate annotation tags used by IETF Area 137 Directors (ADs) to indicate the status of I-Ds that have been sent 138 to the IESG. 140 In contrast, the Datatracker has almost no ability to indicate the 141 status and progression of I-Ds before they are sent to the IESG. 142 The Datatracker can only track the availability status of I-Ds today 143 (e.g. "Active", Expired", "Withdrawn", "Replaced by") and in some 144 cases indicate which IETF Working Group (WG) an I-D is associated 145 with (if any). 147 Section 3 of this document contains a summary of the Datatracker's 148 current ability to track and report on the status of I-Ds in the 149 IETF document stream. The IETF document stream is defined in 150 Section 5.1.1 of RFC 4844 [RFC4844]. 152 Section 4 of this document defines several new I-D states and I-D 153 status annotation tags that need to be added to the Datatracker to 154 enable status tracking and reporting for WG I-Ds. 156 2. Conventions used in this document 158 A "working group I-D" is an Internet-Draft that has achieved 159 consensus for adoption as a work item by a WG (compared to an 160 individual submission I-D that has not, or has not yet, achieved 161 consensus). 163 The terms "WG I-D", "WG document", and "WG draft" are used 164 synonymously throughout this document. The same is true for the 165 plural case of each term. 167 The terms "WG document" and "WG draft" are not intended to apply to 168 any other document that may be reviewed, discussed, or produced by 169 an IETF working group. Working group meeting materials such as Blue 170 Sheets, agendas, jabber logs, scribe's notes, minutes, and 171 presentation slides are not to be considered as "WG documents" or 172 "WG drafts" in the context of this document. 174 The phrase "WG status of an I-D" is to be interpreted as referring 175 to the state that an I-D is in, as defined in Section 4.2 of this 176 document. This phrase does not refer to an I-D's availability 177 status (e.g. "Expired", "Active", "Replaced by") as described in 178 Section 3.1, or to any of the IESG states used by Area Directors to 179 describe the status of I-Ds they may be evaluating. 181 3. I-D States already implemented by the Datatracker 183 This section describes capabilities that are currently implemented 184 in the Datatracker to track the status of I-Ds in the IETF document 185 stream. 187 The document availability states described in Section 3.1 are 188 applicable to every I-D submitted to the IETF. 190 The IESG document states and substate annotation tags described in 191 Section 3.2 and Appendix A are only applicable to I-Ds that have 192 been submitted to the IESG for evaluation and publication. 194 The Datatracker currently has no I-D states or I-D status annotation 195 tags to describe the WG status of any I-D. 197 3.1. I-D Availability States 199 The Datatracker currently maintains availability status information 200 for every I-D submitted to the IETF. The I-D availability states 201 are: 203 - Expired 204 - Active 205 - Replaces 206 - Replaced by 207 - Withdrawn by Submitter 208 - Withdrawn by IETF 209 - RFC 211 The first four I-D availability States are explained in the 212 following subsections. The other states are self-explanatory. 214 Note that the Datatracker describes the status of some I-Ds with the 215 phrase "I-D Exists". "I-D Exists" is state that is manufactured by 216 the Datatracker to describe I-Ds for which it has no other status 217 information. For example, the tool currently uses "I-D Exists" to 218 describe I-Ds that are not expired and that have not been sent to 219 the IESG. 221 3.1.1. Expired 223 An "Expired" I-D is a document that is more than six months old 224 and that has not been updated or replaced by a newer I-D or an 225 RFC. 227 Every I-D has a normal lifespan of 185 days. An I-D will expire 228 and be deleted from the I-D repository after six months unless it 229 is updated or replaced by a newer version. One exception is that 230 an I-D undergoing official evaluation by the IESG will not be 231 expired before its status is resolved (e.g. the I-D is published 232 as an RFC). IESG states that do not relate to a formal request to 233 publish a document (e.g., "AD is Watching") do not prevent an I-D 234 from expiring. [AUTHGUIDE] 236 3.1.2. Active 238 An "Active" I-D is a document that is less than six months old and 239 has not been updated or replaced by a newer I-D or an RFC. 241 The "Active" availability state is applicable to individual I-Ds 242 and WG I-Ds. The Datatracker may also use "Active" to describe 243 the status of I-Ds under formal evaluation by the IESG and I-Ds in 244 the RFC Editor Queue. As a result, the "Active" I-D availability 245 state cannot be used to determine if an I-D is actively being 246 developed by a WG. [WGDTSPEC] 248 3.1.3. Replaces & Replaced By 250 The Datatracker uses "Replaces" and "Replaced by" to describe I-Ds 251 that have been renamed and subsequently resubmitted to the I-D 252 repository for some reason. 254 Two common uses of "Replaced by" are as follows: 256 - The filename of an individual I-D that is being considered for 257 adoption by a WG typically includes the name of its author 258 (e.g. 'draft-author-wgname-topic-nn'). If the individual I-D 259 is adopted by a WG it will be "Replaced by" a newer draft 260 having a filename that includes the string 'ietf-' (e.g. 261 'draft-ietf-wgname-topic-00'); when the newer WG I-D is 262 submitted to the I-D repository it "Replaces" the older 263 individual I-D. 265 - The Datatracker also uses "Replaced by" to describe the final 266 state of an I-D that has been published as an RFC; the I-D was 267 "Replaced By" the RFC. 269 Note that getting correct "Replaces" and "Replaced by" data into 270 the Datatracker currently requires an explicit request by a WG 271 Chair. Without such a request, an individual I-D will co-exist 272 with the newer WG I-D that replaces it until the individual I-D 273 eventually expires. 275 The Datatracker's ability to track "Replaces" and "Replaced by" 276 information may need to be extended in the future to handle more 277 complex cases such as the following: 279 - Two or more I-Ds are merged into (i.e. "Replaced by") a single 280 I-D; in such cases the availability status of the (one) new I-D 281 should indicate that the draft "Replaces" two or more older and 282 previously separate I-Ds; and 284 - One I-D is split or divided into two or more new I-Ds; in this 285 case the availability status should indicate that one (older) 286 I-D was "Replaced by" two or more newer I-Ds. 288 3.2. IESG Document States 290 In addition to tracking the availability status of every I-D, the 291 Datatracker also maintains detailed information about the status and 292 progression of I-Ds that have been sent to the IESG for evaluation 293 and publication. 295 All of the states used by Area Directors to indicate the status of 296 I-Ds under evaluation by the IESG are defined in [IESGSTAT] and are 297 reproduced for convenience in Appendix A. 299 The following subsections describe some common interactions between 300 three of the IESG I-D states and normal IETF WG processes. These 301 interactions are relevant to several of the new WG I-D states 302 defined in Section 4. 304 3.2.1. Publication Requested 306 When a WG has determined that at least rough consensus exists 307 within the WG to advance an I-D, progressing the document is then 308 the responsibility of the IESG (unless the IESG returns the I-D to 309 the WG for further development). [RFC2418] 311 The "Publication Requested" state describes an I-D for which a 312 formal request has been sent to the IESG to advance/publish the 313 I-D as an RFC, following the procedures specified in Section 7.5 314 of RFC 2418 [RFC2418]. This state does not mean that an Area 315 Director has reviewed the I-D or that any official action has been 316 taken on the I-D other than to note that its publication has been 317 requested. 319 Many WG drafts enter the IESG state machine for the first time via 320 the "Publication Requested" state. When an I-D advances through 321 the IESG process, its IESG state will change to reflect its 322 progress. This said, the WG status of the I-D should not change 323 unless an AD or the IESG sends the I-D back to the WG for further 324 development. The WG state of an I-D that is being progressed by 325 the IESG is "Submitted to IESG for Publication", as defined in 326 Section 4.2.10. 328 3.2.2. AD Evaluation 330 The "AD Evaluation" state describes an I-D that the responsible 331 Area Director has begun to review. The purpose of the AD's review 332 is to verify that the I-D is ready for advancement before an IETF 333 Last Call is started or before the document is progressed to the 334 IESG as a whole. 336 After evaluating an I-D, the responsible AD may decide that the 337 document needs to be revised before it can be progressed further. 338 The AD may send a working group I-D back to the WG that created it 339 for revision. 341 When an AD sends an I-D back to a WG for revision, the Datatracker 342 will report the IESG state and substate status of the document as 343 "AD Evaluation: Revised I-D Needed". If the required revisions 344 are extensive, a WG Chair may decide to change the WG state of the 345 I-D from "Submitted to IESG for Publication" to another WG state 346 (e.g. "Waiting for WG Chair Go-Ahead" or "WG Document") for as 347 long as it takes the revised I-D to be developed. The IESG status 348 of the I-D will continue to be "AD Evaluation: Revised I-D Needed" 349 until the revised I-D becomes available. 351 3.2.3. IESG Evaluation 353 The "IESG Evaluation" state describes an I-D that is being 354 formally evaluated by the entire IESG. Every AD is able to air 355 any content or process issues he/she may have with the document. 356 Issues that are blocking approval of the document are called 357 "DISCUSS" comments. A "DISCUSS" with serious issues may cause a 358 WG I-D to be returned to the WG for revision. 360 If the IESG sends an I-D back to a WG for more development, the 361 Datatracker will report the IESG state and substate of the I-D as 362 "IESG Evaluation: Revised I-D Needed" until a revised version of 363 the I-D becomes available. During the time that the I-D is being 364 revised, the WG Chair may decide to transition the I-D from the 365 "Submitted to IESG for Publication" state into one of the earlier 366 WG states (e.g. "Waiting for WG Chair Go-Ahead" or "WG Document"). 368 4. New States and Status Annotation Tags for WG I-Ds 370 The status tracking states described in Section 3 are currently 371 implemented in the Datatracker, however their scope is not broad 372 enough to provide good visibility into the WG status of any I-D. 374 This section describes new I-D states and I-D status annotation tags 375 that need to be added to the Datatracker to make it possible for WG 376 Chairs and/or their delegates (e.g. WG Secretaries) to indicate the 377 status and progression of the I-Ds associated with their WGs. 379 The WG I-D states defined in this section are a superset of the I-D 380 states currently used across all IETF WGs. This is not to suggest 381 or imply that all of the WG I-D states must be used by all WG Chairs 382 to describe the status and progression of the I-Ds associated with 383 their WGs. Chairs may use all or just some of the document states 384 illustrated Figure 1 to describe the WG status of their I-Ds as 385 appropriate for them. 387 4.1. Working Group I-D State Diagram 389 Figure 1 is a state machine diagram that illustrates all of the WG 390 I-D states defined in Section 4.2 of this document. The names of 391 the WG I-D states are capitalized for clarity, and common state 392 transitions are indicated via the solid, dashed, and dotted lines. 394 "I-D EXISTS": 'draft-author-wgname-topic-nn' < - - . 395 : . 396 +---------------------------------------------------------------------+ 397 | WG I-D State Machine | . | 398 | v (not adopted) | 399 | . | 400 | CALL FOR ADOPTION BY WG ISSUED . . . . . | 401 | . : | 402 | . v | 403 | v | 404 | ADOPTED FOR ADOPTED BY WG | 405 | WG INFO ONLY . | 406 | : | 407 | : | 408 | (individual I-D "Replaced by" 'draft-ietf-wgname-topic-00') | 409 | : | 410 | v | 411 | | 412 | DEAD WG <--------> WG DOCUMENT <--------> PARKED WG | 413 | DOCUMENT ("Replaces" individual I-D) DOCUMENT | 414 | . | 415 | . ^ \ | 416 | . / \ | 417 | . / \ | 418 | . v \ | 419 | . \ | 420 | . IN WG ---+ v | 421 | LAST CALL | | 422 | ' ^ +--> WG CONSENSUS: | 423 | ^ : WAITING FOR | 424 | ' v +--> WRITE-UP | 425 | ' | | 426 | ^ WAITING FOR | | | 427 | ' WG CHAIR ---+ | | 428 | ' GO-AHEAD v | 429 | . | 430 | . SUBMITTED TO IESG | 431 | ("Revised ID Needed") - - < - FOR PUBLICATION | 432 | | 433 | | 434 +---------------------------------------------------------------------+ 435 | 436 v 437 IESG Document States 438 (see Appendix A) 440 Figure 1: WG I-D States and Common State Transitions 442 The WG I-D state machine illustrated in Figure 1 is intended to be a 443 new front-end to the IESG I-D state machine [IESGIDSM] that is 444 currently implemented in Datatracker. 446 Note that Figure 1 does not show every possible state transition. 447 WG Chairs may move an I-D from any WG state to any other WG state as 448 appropriate to describe the WG status of the document. The lack of 449 an explicit path between two states does not mean that such a state 450 transition is precluded. 452 The first WG I-D state is "Call For Adoption By WG Issued" and its 453 meaning and usage is defined in Section 4.2.1. 455 One of several possible last states for a WG I-D is "Submitted to 456 IESG for Publication". This state is defined in Section 4.2.10. 458 The Datatracker will be enhanced to automatically generate the 459 following two state transitions for all WG drafts: 461 - A version-00 I-D that conforms to the 'draft-ietf-wgname-topic-00' 462 file naming convention will be moved into the "WG Document" state 463 automatically by the Datatracker when the WG Chair approves the 464 posting of I-D; and 466 - A WG draft that is moved into the IESG state called "Publication 467 Requested" will automatically be moved by the Datatracker into the 468 WG state called "Submitted to IESG for Publication". 470 All other WG I-D state transitions will require the WG chairs or 471 their delegates to log into the Datatracker to manually input the 472 appropriate WG state to describe the WG status of an I-D. 474 Note that Figure 1 includes an arc from the "Submitted to IESG for 475 Publication" state back to the "WG Document" state. This is one 476 example of what may happen after an AD or the IESG as a whole sends 477 an I-D back to a WG for revision. The WG chair may decide that the 478 I-D needs further development and that it needs to return to the 479 "WG Document" state for a while. 481 4.2. Working Group I-D States 483 The WG I-D states defined in this section are a superset of the I-D 484 states currently used across all IETF WGs. 486 All of the states described herein need to be added to the front-end 487 of IESG state machine [IESGIDSM] that has already been implemented 488 in the IETF Datatracker. 490 WG Chairs and their delegates will be given the flexibility to use 491 whichever of the WG I-D states they feel to be appropriate to 492 describe the WG status of the I-Ds associated with their WG. 494 It is not suggested or implied that Chairs must use all of the I-D 495 states defined herein to describe the status and progression of all 496 I-Ds associated with their WGs; Chairs may use all of the WG I-D 497 states, or just some of the states. 499 Note that an I-D that is not associated with a WG will be in a 500 'Null' state with respect to the WG state machine in Figure 1. 502 4.2.1. Call For Adoption By WG Issued 504 The "Call for Adoption by WG Issued" state should be used to 505 indicate when an I-D is being considered for adoption by an IETF 506 WG. An I-D that is in this state is actively being considered for 507 adoption, and has not yet achieved consensus, preference or 508 selection in the WG. 510 This state may be used to describe an I-D that someone has asked a 511 WG to consider for adoption, if the WG Chair has agreed with the 512 request. This state may also be used to identify an I-D that a WG 513 Chair asked an author to write specifically for consideration as a 514 candidate WG item [WGDTSPEC], and/or an I-D that is listed as a 515 'candidate draft' in the WG's charter. 517 Under normal conditions, it should not be possible for an I-D to 518 be in the "Call For Adoption by WG Issued" state in more than one 519 working group at the same time. This said, it is not uncommon for 520 authors to "shop" their I-Ds to more than one WG at a time, with 521 the hope of getting their documents adopted somewhere. 523 After this state is implemented in the Datatracker, an I-D that is 524 in the "Call for Adoption by WG Issued" state will not be able to 525 be "shopped" to any other WG without the consent of the WG Chairs 526 and the responsible ADs impacted by the shopping. 528 Note that Figure 1 includes an arc leading from this state to 529 outside of the WG state machine. This illustrates that some I-Ds 530 that are considered do not get adopted as WG drafts. An I-D that 531 is not adopted as a WG draft will transition out of the WG state 532 machine and revert back to having no stream-specific state; 533 however, the status change history log of the I-D will record that 534 the I-D was previously in the "Call for Adoption by WG Issued" 535 state. 537 4.2.2. Adopted by a WG 539 The "Adopted by a WG" state describes an individual submission I-D 540 that an IETF WG has agreed to adopt as one of its WG drafts. 542 WG Chairs who use this state will be able to clearly indicate when 543 their WGs adopt individual I-Ds. This will facilitate the 544 Datatracker's ability to correctly capture "Replaces" information 545 for WG drafts and correct "Replaced by" information for individual 546 I-Ds that have been replaced by WG drafts. 548 This state is needed because the Datatracker uses the filename of 549 an I-D as a key to search its database for status information 550 about the I-D, and because the filename of a WG I-D is supposed to 551 be different from the filename of an individual submission I-D. 553 The filename of an individual submission I-D will typically be 554 formatted as 'draft-author-wgname-topic-nn'. 556 The filename of a WG document is supposed to be formatted as 557 'draft-ietf-wgname-topic-nn'. 559 An individual I-D that is adopted by a WG may take weeks or months 560 to be resubmitted by the author as a new (version-00) WG draft. 561 If the "Adopted by a WG" state is not used, the Datatracker has no 562 way to determine that an I-D has been adopted until a new version 563 of the I-D is submitted to the WG by the author and until the I-D 564 is approved for posting by a WG Chair. 566 4.2.3. Adopted for WG Info Only 568 The "Adopted for WG Info Only" state describes a document that 569 contains useful information for the WG that adopted it, however 570 the document is not intended to be published as an RFC. The WG 571 will not actively develop the contents of the I-D or progress it 572 for publication as an RFC. The only purpose of the I-D is to 573 provide information for internal use by the WG. 575 4.2.4. WG Document 577 The "WG Document" state describes an I-D that has been adopted by 578 an IETF WG and is being actively developed. 580 A WG Chair may transition an I-D into the "WG Document" state at 581 any time as long as the I-D is not being considered or developed 582 in any other WG. 584 Alternatively, WG Chairs may rely upon new functionality to be 585 added to the Datatracker to automatically move version-00 drafts 586 into the "WG Document" state as described in Section 4.1. 588 Under normal conditions, it should not be possible for an I-D to 589 be in the "WG Document" state in more than one WG at a time. This 590 said, I-Ds may be transferred from one WG to another with the 591 consent of the WG Chairs and the responsible ADs. 593 4.2.5. Parked WG Document 595 A "Parked WG Document" is an I-D that has lost its author or 596 editor, is waiting for another document to be written or for a 597 review to be completed, or cannot be progressed by the working 598 group for some other reason. 600 Some of the annotation tags described in Section 4.3 may be used 601 in conjunction with this state to indicate why an I-D has been 602 parked, and/or what may need to happen for the I-D to be un- 603 parked. 605 Parking a WG draft will not prevent it from expiring, however this 606 state can be used to indicate why the I-D has stopped progressing 607 in the WG. 609 A "Parked WG Document" that is not expired may be transferred from 610 one WG to another with the consent of the WG Chairs and the 611 responsible ADs. 613 4.2.6. Dead WG Document 615 A "Dead WG Document" is an I-D that has been abandoned. Note that 616 'Dead' is not always a final state for a WG I-D. If consensus is 617 subsequently achieved, a "Dead WG Document" may be resurrected. A 618 "Dead WG Document" that is not resurrected will eventually expire. 620 Note that an I-D that is declared to be "Dead" in one WG and that 621 is not expired may be transferred to a non-dead state in another 622 WG with the consent of the WG Chairs and the responsible ADs. 624 4.2.7. In WG Last Call 626 A document "In WG Last Call" is an I-D for which a WG Last Call 627 (WGLC) has been issued, and is in progress. 629 Note that conducting a WGLC is an optional part of the IETF WG 630 process, per section 7.4 of RFC 2418 [RFC2418]. 632 If a WG Chair decides to conduct a WGLC on an I-D, the "In WG Last 633 Call" state can be used to track the progress of the WGLC. The 634 Chair may configure the Datatracker to send a WGLC message to one 635 or more mailing lists when the Chair moves the I-D into this 636 state. The WG Chair may also be able to select a different set of 637 mailing lists for a different document undergoing a WGLC; some 638 documents may deserve coordination with other WGs. 640 A WG I-D in this state should remain "In WG Last Call" until the 641 WG Chair moves it to another state. The WG Chair may configure 642 the Datatracker to send an e-mail after a specified period of time 643 to remind or 'nudge' the Chair to conclude the WGLC and to 644 determine the next state for the document. 646 It is possible for one WGLC to lead into another WGLC for the same 647 document. For example, an I-D that completed a WGLC as an 648 "Informational" document may need another WGLC if a decision is 649 taken to convert the I-D into a standards track document. 651 4.2.8. Waiting for WG Chair Go-Ahead 653 A WG Chair may wish to place an I-D that receives a lot of 654 comments during a WGLC into the "Waiting for WG Chair Go-Ahead" 655 state. This state describes an I-D that has undergone a WGLC; 656 however, the Chair is not yet ready to call consensus on the 657 document. 659 If comments from the WGLC need to be responded to, or a revision 660 to the I-D is needed, the Chair may place an I-D into this state 661 until all of the WGLC comments are adequately addressed and the 662 (possibly revised) document is in the I-D repository. 664 4.2.9. WG Consensus: Waiting for Write-Up 666 A document in the "WG Consensus: Waiting for Write-Up" state has 667 essentially completed its development within the working group, 668 and is nearly ready to be sent to the IESG for publication. The 669 last thing to be done is the preparation of a protocol write-up by 670 a Document Shepherd. The IESG requires that a document shepherd 671 write-up be completed before publication of the I-D is requested. 672 The IETF document shepherding process and the role of a WG 673 Document Shepherd is described in RFC 4858 [RFC4858] 675 A WG Chair may call consensus on an I-D without a formal WGLC, and 676 transition an I-D that was in the "WG Document" state directly 677 into this state. 679 The name of this state includes the words "Waiting for Write-Up" 680 because a good document shepherd write-up takes time to prepare. 682 4.2.10. Submitted to IESG for Publication 684 This state describes a WG document that has been submitted to the 685 IESG for publication and that has not been sent back to the 686 working group for revision. 688 An I-D in this state may be under review by the IESG, or it may 689 have been approved and be in the RFC Editor's queue, or it may 690 have been published as an RFC. Other possibilities exist too. 691 The document may be "Dead" (in the IESG state machine) or in a 692 "Do Not Publish" state. 694 4.3. Working Group I-D Status Annotation Tags 696 In addition to indicating which state a working group draft is in, 697 the Datatracker will allow several substate conditions to be 698 identified and tracked. This section defines annotation tags that 699 may be used to describe a condition that is affecting a WG I-D 700 (e.g., why a document is in the state it is in) or to indicate an 701 action needed to progress the document. 703 Annotation tags do not change the WG I-D state of WG drafts. 705 Each of the annotation tags defined herein may be used to provide 706 more information about the status of any WG draft in any state, if 707 it makes sense to do so. Each annotation tag may be used by itself, 708 or in combination with other tags. 710 4.3.1. Awaiting Expert Review/Resolution of Issues Raised 712 This tag means that someone (e.g. an author or editor of the WG 713 draft, or a WG Chair) has initiated an expert review of the 714 document and the review has not yet been completed and/or the 715 resolution of issues raised by the review has not yet been 716 completed. Examples of expert reviews include cross-area reviews, 717 MIB Doctor reviews, security expert reviews, and IANA reviews. 719 WG drafts tagged with this annotation should retain the tag until 720 the review is complete and possibly until any issues raised in the 721 review are addressed. 723 4.3.2. Awaiting External Review/Resolution of Issues Raised 725 This tag means that someone (e.g. an author or editor of the WG 726 draft, or a WG Chair) has initiated some other review of the 727 document (e.g. sent it to another Standards Development 728 Organization (SDO) for comments via a formal or informal liaison 729 process) and the review has not yet been completed and/or the 730 resolution of issues raised by the review has not yet been 731 completed. 733 WG drafts tagged with this annotation should retain the tag until 734 the review is complete and possibly until any issues raised in the 735 review are addressed. 737 4.3.3. Awaiting Merge with Other Document 739 This tag means a decision has been made by someone (e.g. the 740 document author, editor, or the WG Chair) to merge the I-D with 741 one or more other I-Ds from the same (or another) working group. 743 If the result of the merge is a new I-D having a different title, 744 then the old I-D may be declared as being a "Dead WG Document". 745 In such a case the annotation tag should be changed from "Awaiting 746 Merge with Other Document" to "Other - see Comment Log" and a 747 description of the merge should be entered into the log for 748 posterity. 750 The Datatracker's regular 'Replaced by' information should also be 751 set for the old I-Ds to make it easier to find the new merged 752 document from the old documents. 754 If the result of the merge operation is a revision to the old I-D, 755 this annotation tag should be cleared when the revised (merged) 756 I-D is submitted to the WG. 758 4.3.4. Author or Editor Needed 760 This tag means an I-D has lost a primary author or editor, and 761 that further work on the I-D cannot continue in an effective or 762 efficient manner until a new author or editor is found. 764 This tag should be removed after a new primary author or editor is 765 found. 767 4.3.5. Waiting for Referenced Document 769 This tag means that completion of the I-D is on-hold because the 770 draft has a dependency on one or more other documents. A typical 771 example is where an I-D depends on another IETF document that has 772 not yet progressed to a point where it may be referenced; the 773 dependency may be on one or more documents in other IETF working 774 groups or on work in progress documents in other SDOs. 776 This tag should be removed after the dependency is cleared. 778 4.3.6. Waiting for Referencing Document 780 This tag means that completion of the I-D is on-hold because one 781 or more other documents are dependent on it, and the WG Chair 782 wants to submit all of the documents to the IESG (for publication) 783 simultaneously. This tag is the inverse of 4.3.7. 785 This tag should be removed after the dependency is cleared. 787 4.3.7. Revised I-D Needed - Issue raised by WGLC 789 This annotation may be used to flag an I-D that needs to be 790 revised to address issues raised during a working group last call. 791 This annotation may also be used to indicate when the I-D is in 792 the process of being revised. 794 This tag should be removed after a revised version of the I-D is 795 submitted to the WG. 797 4.3.8. Revised I-D Needed - Issue raised by AD 799 This annotation means the responsible AD raised one or more issues 800 with the I-D during "AD Evaluation" and that the AD has sent the 801 document back to the working group for revision. This annotation 802 may also be used to indicate when the I-D is in the process of 803 being revised. 805 This tag should be removed after the revised version of the I-D is 806 submitted to the WG. 808 4.3.9. Revised I-D Needed - Issue raised by IESG 810 This annotation means that one or more IESG members had issues 811 with the I-D during "IESG Evaluation" and the document has been 812 sent back to the working group for revision. This annotation may 813 also be used to indicate that the revision to the I-D is in 814 process. 816 This tag should be removed after the revised version of the I-D is 817 submitted to the WG. 819 4.3.10. Doc Shepherd Follow-Up Underway 821 This annotation tag may be used to indicate that the Document 822 Shepherd for the WG document has begun working on the write-up 823 required to submit the document (to the IESG) for publication. 825 It is possible that too many I-Ds may arrive in a shepherd's queue 826 in too short a time, and the shepherd cannot create satisfactory 827 write-ups for all of the documents simultaneously. 829 When this annotation tag is set, it means the Document Shepherd 830 has started work on the write-up for the I-D. The absence or 831 resetting of this annotation tag for an I-D in the "WG Consensus: 832 Waiting for Write-up" state indicates the write-up has not yet 833 been started, or has been put on-hold for some reason. 835 4.3.11. Other - see Comment Log 837 This annotation tag is a catch-all to indicate that someone (e.g. 838 an author or editor of the document, the WG Chair, the Document 839 Shepherd) has entered one or more comments about the current 840 status of the I-D into the IETF Datatracker. 842 5. Intended Maturity Level of WG Drafts 844 The IESG requires a WG I-D to have an "intended maturity level" 845 associated with it (e.g. Informational, Proposed Standard, 846 Experimental) before the I-D is submitted to the IESG for evaluation 847 and publication. This information is also often requested by IETF 848 participants. 850 I-D maturity levels were first defined in sections 4 and 5 of RFC 851 2026 [RFC2026]. The names of the maturity levels in use today are: 853 * "Experimental" 854 * "Informational" 855 * "Best Current Practice" 856 * "Proposed Standard" 857 * "Draft Standard" 858 * "Standard" 859 * "Historic" 861 The Datatracker may need to be enhanced to enable WG Chairs to input 862 and/or change the intended maturity level of a WG draft before the 863 I-D is sent to the IESG. 865 6. Security Considerations 867 This document does not propose any new internet mechanisms, and has 868 no security implications for the internet. 870 7. IANA Considerations 872 This document does not require any new number assignments from IANA, 873 and does not define any new numbering spaces to be administered by 874 IANA. 876 RFC-Editor: Please remove this section before publication. 878 8. References 880 8.1. Normative References 882 [RFC4844] Daigle, L., Ed., "The RFC Series and RFC Editor", 883 RFC 4844, July 2007. 885 [RFC2418] Bradner, S., Ed., "IETF Working Group Guidelines and 886 Procedures", BCP 25, RFC 2418, September 1998. 888 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 889 3", BCP 9, RFC 2026, October 1996. 891 8.2. Informative References 893 [IDTRACKER] "The IETF Datatracker tool", Web Application: 894 https://datatracker.ietf.org/, September 15, 2010. 896 [AUTHGUIDE] Housley, R., Ed., for the IESG, "Guidelines to Authors 897 of Internet-Drafts", May 4, 2010, 898 http://www.ietf.org/ietf/1id-guidelines.txt. 900 [WGDTSPEC] Juskevicius, E., "Minutes of wgdtspec BOF", Proceedings 901 of IETF 77, March 26, 2010, 902 http://www.ietf.org/proceedings/10mar/minutes/wgdtspec 904 [IESGSTAT] "Main I-D States", Web Application: 905 https://datatracker.ietf.org/idtracker/help/state/, 906 September 15, 2010. 908 [IESGIDSM] "Diagram of Main I-D States", Web Application: 909 https://datatracker.ietf.org/images/state_diagram.gif, 910 September 15, 2010. 912 [PROTO] Levkowetz, H., and Mankin, A., "Requirements on I-D 913 Tracker Extensions for Working Group Chairs", 914 draft-ietf-proto-wgchair-tracker-ext-03.txt, 915 February 8, 2007. 917 9. Acknowledgments 919 The author would like to thank Henrik Levkowetz and Allison Mankin 920 for developing the original I-D [PROTO] that served as the starting 921 point for this document, and Alfred Hoenes for his many comments and 922 suggestions and for articulating the need for the "Adopted by a WG" 923 state. 925 The author would also like to thank Henrik Levkowetz, Russ Housley, 926 Paul Hoffman, John Klensin, Pasi Eronen, Robert Sparks, Spencer 927 Dawkins, Mary Barnes, Glenn Parsons, Marc Blanchet, Andy Malis and 928 Joel Halpern for their comments and feedback along the way. 930 Finally, the author also wishes to thank the IETF WG Chairs, ADs and 931 other people who contributed their insights and suggestions in real- 932 time during the wgdtspec BOF at IETF 77, and Lars Eggert, Tim Polk, 933 Robert Sparks, Adrian Farrel and Alexey Melnikov for their comments, 934 suggestions and DISCUSS points on the penultimate draft version of 935 this document. 937 This document was initially prepared using 2-Word-v2.0.template.dot. 939 Appendix A: "IESG Document" States 941 This Appendix describes the status information currently stored in 942 the IETF Datatracker tool for every I-D submitted to the IESG for 943 publication. All of the terms and definitions in Sections A.1 and 944 A.2 are copied from [IESGSTAT]. 946 It must be noted that I-Ds sent to the IESG for publication (termed 947 "IESG Documents" in this Appendix) do not stay with the IESG until 948 the day they are published as RFCs. After evaluation, the IESG may 949 declare that some I-Ds deserve a "Do Not Publish" label. Other I-Ds 950 may become "Dead". Some I-Ds may get sent back to their originators 951 (WGs or otherwise), and the rest may go into the RFC Editor queue. 953 Note that documents which are not tracked by the IESG (e.g. I-Ds for 954 which no request has been made of the IESG) are in a null state with 955 respect to the IESG state machine. The IESG state of an I-D that 956 has no value assigned to the IESG state variable in the 957 Datatracker's database is 'NULL'. 959 A.1. Definition of "IESG Document" States 961 A.1.1. Publication Requested 963 A formal request has been made to advance/publish the document, 964 following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the 965 request could be from a WG Chair, or from an individual. Note: the 966 Secretariat (iesg-secretary@ietf.org) is typically copied on these 967 requests to ensure that the request makes it into the Datatracker. 968 A document in this state has not (yet) been reviewed by an Area 969 Director nor has any official action been taken yet, other than to 970 note that its publication has been requested. 972 A.1.2. AD Evaluation 974 A specific AD (e.g. the "Area Advisor" for the WG) has begun their 975 review of the document to verify that it is ready for advancement. 976 The shepherding AD is responsible for doing any necessary review 977 before starting an IETF Last Call or sending the document directly 978 to the IESG as a whole. 980 A.1.3. Expert Review 982 An AD sometimes asks for an external review by an outside party as 983 part of evaluating whether a document is ready for advancement. 984 MIBs, for example, are reviewed by "MIB doctors". Other types of 985 reviews may also be requested (e.g., security, operations impacts, 986 etc.) Documents stay in this state until the review is complete and 987 possibly until the issues raised in the review are addressed. 989 Specific details on the nature of the review may be found in the 990 "note" field associated with this state (i.e. within the 991 Datatracker). 993 A.1.4. Last Call Requested 995 The AD has requested that the Secretariat start an IETF Last Call, 996 but the actual Last Call message has not been sent yet. 998 A.1.5. In Last Call 1000 The document is currently waiting for IETF Last Call to complete. 1001 Last Calls for WG documents typically last 2 weeks, and those for 1002 individual submissions last 4 weeks. 1004 A.1.6. Waiting for Writeup 1006 Before a standards-track or BCP document is formally considered by 1007 the entire IESG, the AD must write up a protocol action. The 1008 protocol action is included in the approval message that the 1009 Secretariat sends out when the document is approved for publication 1010 as an RFC. 1012 A.1.7. Waiting for AD Go-Ahead 1014 As a result of the IETF Last Call, comments may need to be responded 1015 to and a revision of the I-D may be needed as well. The AD is 1016 responsible for verifying that all Last Call comments have been 1017 adequately addressed and that the (possibly revised) document is 1018 ready for consideration by the IESG as a whole. 1020 A.1.8. IESG Evaluation 1022 The document is now (finally!) being formally reviewed by the entire 1023 IESG. Documents are discussed in email or during a bi-weekly IESG 1024 telechat. In this phase, each AD reviews the document and airs any 1025 content or process issues they may have. Unresolvable issues are 1026 documented as "DISCUSS" comments that can be forwarded to the 1027 authors/WG. See the description of IESG substates in Section A.2 1028 for additional details about the current state of the IESG 1029 discussion. 1031 A.1.9. IESG Evaluation - Defer 1033 During a telechat, one or more ADs requested an additional two weeks 1034 to review the document. A defer is designed to be an exception 1035 mechanism, and can only be invoked once, the first time the document 1036 comes up for discussion during a telechat. 1038 A.1.10. Approved - Announcement to be sent 1040 The IESG has approved the document for publication, but the 1041 Secretariat has not (yet) sent an official approval message. 1043 A.1.11. Approved - Announcement sent 1045 The IESG has approved the document for publication, and the 1046 Secretariat has sent out the official approval message to the RFC 1047 editor. 1049 A.1.12. RFC Ed Queue 1051 The document is in the RFC editor Queue (as confirmed by 1052 http://www.rfc-editor.org/queue2.html) 1054 A.1.13. RFC Published 1056 The I-D has been published as an RFC. 1058 A.1.14. DNP - Waiting for AD note 1060 Do Not Publish (DNP): The IESG recommends against publishing the 1061 document, but the writeup explaining its reasoning has not yet been 1062 produced. DNPs apply primarily to individual submissions received 1063 through the RFC Editor. See the "note" field for more details on 1064 who has the action item. 1066 A.1.15. DNP - Announcement to be sent 1068 The IESG recommends against publishing the document. The write-up 1069 explaining the IESG's reasoning has been produced, but the 1070 Secretariat has not yet sent out the official "Do Not Publish" 1071 recommendation message. 1073 A.1.16. AD is Watching 1075 An AD is aware of the document and has chosen to place the document 1076 in a separate state in order to monitor it (for whatever reason). 1077 Documents in this state are not actively tracked by the IESG in the 1078 sense that no formal request has been made to publish or advance the 1079 document. The AD has chosen to put the I-D into this state, to make 1080 it easier to keep track of (for his or her own reasons). 1082 A.1.17. Dead 1084 The document is "Dead" and is no longer being tracked (e.g. it has 1085 been replaced by another document having a different name, it has 1086 been withdrawn, etc.) 1088 A.2. IESG Document Substates 1090 Note that the annotation tags described in this section were defined 1091 circa 2002. If these conditioned were modelled today, they would 1092 most likely be modelled as annotation tags rather than as substates. 1094 A.2.1. Point Raised - Write-up needed 1096 IESG discussions on the document have raised some issues that need 1097 to be brought to the attention of the authors/WG, but those issues 1098 have not been written down yet. (It is common for discussions during 1099 a telechat to result in such situations. An AD may raise a possible 1100 issue during a telechat and only decide as a result of that 1101 discussion whether the issue is worth formally writing up and 1102 bringing to the attention of the authors/WG). 1104 A document stays in the "Point Raised - Writeup Needed" substate 1105 until *ALL* IESG blocking comments that have been raised have been 1106 documented. 1108 A.2.2. AD Follow-up 1110 "AD Follow-up" is a generic substate indicating that the shepherding 1111 AD has the action to determine the appropriate next steps. In 1112 particular, the appropriate steps (and the corresponding next state 1113 or substate) depend entirely on the nature of the issues that were 1114 raised and can only be decided with active involvement of the 1115 shepherding AD. 1117 Examples include: 1119 - If another AD raises an issue, the shepherding AD may first 1120 iterate with the other AD to get a better understanding of the 1121 exact issue. Or, the shepherding AD may attempt to argue that 1122 the issue is not serious enough it to bring to the attention of 1123 the authors/WG. 1125 - If a documented issue is forwarded to a WG, some further iteration 1126 may be needed before it can be determined whether a new revision 1127 is needed or whether the WG response to an issue clarifies the 1128 issue sufficiently. 1130 - When a new revision appears, the shepherding AD will first look 1131 at the changes to determine whether they believe all outstanding 1132 issues have been raised satisfactorily, prior to asking the ADs 1133 who raised the original issues to verify the changes. 1135 A.2.3. External Party 1137 The document is awaiting review or input from an external party 1138 (i.e. someone other than the shepherding AD, the authors, or the 1139 WG). See the "note" field for more details on who has the action. 1141 A.2.4. Revised I-D Needed 1143 An updated I-D is needed to address the issues that have been 1144 raised. 1146 Author's Address 1148 Ed Juskevicius 1149 TrekAhead 1150 PO Box 491, Carp, ON 1151 CANADA 1153 Email: edj.etc@gmail.com