idnits 2.17.1 draft-ietf-genarea-datatracker-iana-rfced-extns-03.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 2011) is 4697 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4844 (Obsoleted by RFC 8729) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5741 (Obsoleted by RFC 7841) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) S. Ginoza 3 Internet-Draft AMS 4 Intended Status: Informational M. Cotton 5 Expires: December 16, 2011 ICANN 6 A. Morris 7 AMS 8 June 16, 2011 10 Datatracker Extensions to 11 Include IANA and RFC Editor Processing Information 12 14 Abstract 16 This document captures the requirements for integrating IANA and RFC 17 Editor state information into the Datatracker to provide the 18 community with a unified tool to track the status of their document 19 as it progresses from Internet-Draft (I-D) version -00 to RFC. 20 Extending the Datatracker to hold document data from I-D version -00 21 to RFC allows for increased automation between the Datatracker, IANA, 22 and RFC Editor, thus reducing manual labor, processing errors, and 23 potential delay. Therefore, this document also describes the 24 requirements to make such automation possible. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 Copyright Notice 43 Copyright (c) 2011 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 respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 1. Introduction 70 The IETF Datatracker is a web-based system for managing information 71 about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison 72 statements, and several other important aspects of the document 73 process [IDTRACKER]. In this document, the term "IETF Datatracker" 74 is used as a generic name for the existing tool used to track state 75 changes as Internet-Drafts are processed. The word "IETF" in the 76 name "IETF Datatracker" is not meant to limit use of the tool to the 77 IETF document stream; this document expands use of the tool to the 78 other streams described in [RFC4844]. 80 The Datatracker is used to report on the status of I-Ds that have 81 been submitted to the IESG for evaluation and publication. The 82 Datatracker will be extended, according to the requirements defined 83 in [RFC6174] and [ALT-STREAMS], to include tracking information about 84 a document during its progression from version -00 to it being 85 requested for IESG evaluation. However, the Datatracker, ICANN 86 (performing the IANA function), and RFC Editor operate on separate 87 systems with varying degrees of visibility into the processing that 88 takes place once the stream managers have approved a document for 89 publication as an RFC. This document defines the requirements for 90 extending the Datatracker to include increased IANA and RFC Editor 91 state information, so that the Datatracker covers the lifetime of an 92 I-D from version -00 to RFC publication. 94 Additionally, this document lists the processes between the IANA, RFC 95 Editor, and Secretariat (via the Datatracker) that should be 96 automated for accuracy and timely processing. While this document 97 includes some details of the IANA, RFC Editor, and Secretariat 98 process, this document does not define any of the processes. The 99 processes are continually reviewed for process optimization and need 100 to remain flexible to adapt to new changes in policy and environment. 101 Processes are defined and set by each of the entities respectively. 103 NOTE: The IANA and RFC Editor are independent functions and they 104 retain ownership of their data, state names, and tracking 105 systems once a document enters their queues. This document 106 discusses how the data from the IANA and RFC Editor queues 107 can be better reflected in the Datatracker for ease of the 108 community. If there is any discrepancy, the IANA and RFC 109 Editor data are definitive (post approval for publication). 110 Prior to a document being approved for publication, the 111 Datatracker is definitive for tracking IANA status 112 information. The Datatracker should only allow for states 113 in which it is definitive to be administratively edited. 115 RFC Editor data is not editable via the Datatracker. The 116 only way for RFC Editor substates to be updated in the 117 Datatracker is to retrieve data from the definitive RFC 118 Editor database. 120 Post approval, IANA data is not editable via the 121 Datatracker. The only way for IANA substates to be updated 122 in the Datatracker is to retrieve data from the definitive 123 IANA database. 125 2. Integration of Data between the IANA and Datatracker 127 2.1. IANA Information To Be Added to the Datatracker 129 Currently, IANA reviews and touches documents at 4 different stages 130 in the process from I-D to RFC for IETF stream documents: IETF Last 131 Call, IESG Review, Document Approval (for publication), and RFC 132 Publication. Most of these state changes and issues are not captured 133 in the Datatracker. For the IRTF and INDEPENDENT streams, the IANA 134 review process begins when IESG Review is requested. For the IAB 135 stream, review would begin upon request for publication as an RFC. 137 This section specifies the requirements for including additional IANA 138 information in the Datatracker. 140 - IETF Last Call Comments 142 Currently, IANA reviews I-Ds that have been sent to IETF Last 143 Call, inputs comments in their data system, and then emails their 144 comments to authors, WG chairs, and then to the IESG. These 145 comments are also manually entered into the Datatracker for the 146 public record. However, it is difficult to determine whether the 147 IANA issues have been resolved. To help facilitate tracking of 148 IANA issues, a display is needed to show 5 new IANA substates, in 149 a similar fashion to how RFC Editor State is currently shown in 150 the Datatracker (see example of how IANA state information could 151 appear in the Datatracker for draft-example-00 below). 153 1) IANA Review Needed 155 This substate will allow the community, Secretariat, and IANA 156 to easily track which documents have or have not been reviewed 157 by IANA. If this substate is NOT set to IANA Not OK or IANA 158 OK, the substate should be set to "IANA review needed" by 159 default (this is the first substate for tracking IANA data). 160 For documents that originate from a non-IETF stream, the 161 default will be used. 163 2) IANA OK -- Actions Needed 165 This substate covers documents that require IANA actions and 166 the IANA considerations section indicates the details of the 167 actions correctly. 169 3) IANA OK -- No Actions Needed 171 This substate covers documents that require no IANA actions and 172 the IANA considerations section indicates this correctly. 174 NOTE: The substate will be set to "IANA OK -- Action Needed" or 175 "IANA OK -- No Actions Needed" (from "IANA Not OK") once any 176 outstanding issues have been resolved. The comments section will 177 be used to provide details in the History log about whether there 178 are no IANA actions, the text is OK, or the issues have been 179 resolved. 181 4) IANA Not OK 183 If IANA has issues with the text of the IANA Considerations 184 section of a document, the substate should be set to "IANA Not 185 OK" and the comment field should be populated with a 186 description of the issues and questions. In addition to any 187 questions IANA may have, IANA will also include in the comments 188 field whether expert review is required, if the doc is 189 dependent on another doc (e.g., doc B registers values in a 190 registry created by doc A, which hasn't been published yet), 191 and if there is a registry expert appointment required. 193 5) Version Changed -- Review Needed 195 This substate will allow the community, Secretariat, and IANA 196 to easily track which documents have been reviewed and 197 subsequently when a version of an Internet-Draft in Last Call 198 has changed, therefore requiring a second review of the 199 document by IANA to ensure that either the IANA Considerations 200 have not changed or that any changes made to the document 201 affecting IANA actions are clear. This substate applies to I- 202 Ds that are in any substate except "IANA Review Needed" and 203 "Version Changed". 205 When new versions are available, the Datatracker will 206 automatically set the IANA substate to "Version Changed -- 207 Review Needed". 209 Information providing the status of the IANA review (one of the 5 210 substates listed above) should be included as part of the evaluation 211 message (sent to the IESG) so that IANA can determine if and what 212 further action is required. 214 All comments will be recorded in the History log. However, to reduce 215 redundancy and manual effort, the Datatracker should provide the 216 ability to receive state information and related comments from the 217 IANA tracking system. There should be a notification that comments 218 have been entered in the IANA-maintained system, and entry of those 219 comments into the datatracker and distribution of those comments to 220 the authors should be automated. 222 - IESG Evaluation 224 As not all documents receive an IETF Last Call, this state is 225 sometimes the first time that IANA reviews a document. For a 226 document that wasn't IETF Last Called, IANA reviews the document, 227 enters comments in their own tracking system, distributes email to 228 authors and other interested parties (e.g., WG chairs, ISE), and 229 then enters those same comments into the Datatracker, where they 230 are recorded in the History log. In cases where a document was 231 IETF Last Called, IANA checks for and reviews version changes and 232 re-reviews documents to ensure that any identified IANA issues 233 have been resolved. 235 Comments will continue to be recorded in the History log. 236 However, to reduce redundancy and manual effort, the Datatracker 237 should provide the ability for IANA to enter substate information 238 and related comments into the IANA tracking system, and 239 distribution of those comments to the authors and entry into the 240 Datatracker should be automated. 242 Ideally, the authors will have responded to and resolved any IANA 243 issues prior to the document being slated for an IESG telechat. 244 However, if any document continues to have an "IANA Not OK", 245 "Version Changed - Review Needed", or "IANA Review needed" 246 substates and is slated for the IESG telechat, it should be called 247 out in the Agenda Package. For example, it could appear as 248 follows: 250 o draft-example-00 251 Title of Internet-Draft 252 Note: John Doe (jdoe@example.com) is the document shepherd. 253 Token: Jane Doe 254 IANA: IANA Not OK 256 This will ensure that IANA and the ADs are aware that there are 257 still IANA considerations issues to be addressed prior to 258 publication, or that initial or follow-up IANA Review is required 259 and not yet completed (in cases where the substate is listed as 260 "IANA review needed" or "Version Revision - Review Needed"). 262 - Document Approved for Publication 264 Once a document has been approved for publication, the document 265 enters the IANA queue and is tracked using IANA-defined states. 266 This state information is not currently available via the 267 Datatracker. In order for the community to view the IANA 268 processing states without being redirected to the IANA queue, the 269 Datatracker should be extended to include IANA state information 270 as defined by IANA. For example, IANA state information could 271 appear in the metadata portion of the document as follows: 273 Document type: Active Internet-Draft (FOO WG document) 274 Last updated: 2010-09-20 275 State: RFC Ed Queue 276 RFC Editor State: EDIT IANA 277 IANA State: In Progress 278 Intended status: Proposed Standard 280 IANA state-change information will link to the IANA queue, and 281 will be captured as a line item in the History log. IANA will 282 notify the Datatracker when changes are made in the IANA queue. 284 Once the IANA actions have been completed, the Datatracker History 285 log will be updated to include the actions completed by IANA (the 286 author-approved actions). This will include the same information 287 that is sent to the RFC Editor once the actions upon completion of 288 IANA actions. 290 The IANA State field may be any of the states defined by IANA. 291 The list of IANA state names in use at the time this document was 292 published is provided in Appendix A; however, IANA states are 293 defined by IANA and are subject to change. If there are any 294 discrepancies between the state names listed in this document and 295 those listed on the IANA queue page 296 (http://www.iana.org/about/performance/ietf-draft-status/), the 297 IANA queue is definitive. States may be added or removed by IANA; 298 IANA will work with the IAOC to update the Datatracker as 299 necessary. 301 - RFC Publication 303 References to I-Ds are updated to refer to the RFC once published, 304 and minor updates may be made to match the published RFC. This 305 data will be tracked in the Datatracker to show when the 306 references in the IANA registries were updated to include the 307 newly assigned RFC Number. 309 2.2. Future IANA Information To Be Available Via the Datatracker 311 The document "Definition of IETF Working Group Document States" 312 [RFC6174] includes the following: 314 4.3.1. Awaiting Expert Review/Resolution of Issues Raised 316 This tag means that someone (e.g. an author or editor of the WG 317 draft, or a WG Chair) has initiated an expert review of the 318 document and the review has not yet been completed and/or the 319 resolution of issues raised by the review has not yet been 320 completed. Examples of expert reviews include cross-area 321 reviews, MIB Doctor reviews, security expert reviews, and IANA 322 reviews. 324 WG drafts tagged with this annotation should retain the tag 325 until the review is complete and possibly until any issues 326 raised in the review are addressed. 328 IANA is in the process of documenting how an expert review is 329 conducted during the lifetime of an Internet-Draft. Once the process 330 has been defined, the Datatracker should be updated to indicate if a 331 document requires Expert Review [RFC5226] (either for the entire 332 document or a portion thereof), if the Expert Reviewer has issues 333 with what they are being requested to review, and if applicable 334 whether the Expert Reviewer has approved or rejected the requested 335 registration(s). There may be a need to complete expert reviews 336 again before publication of a document if there have been changes to 337 the text relevant to the review by the expert. In cases where a new 338 registry is being created in the document, an indicator of whether an 339 expert needs to be appointed by the IESG would also be useful. 341 2.3. Permissions to Change IANA State Information 343 IANA state changes should be automated, but IANA should have the 344 ability to log in to the Datatracker to manually update the system as 345 well. 347 Additionally, the IETF Secretariat should also have the ability to 348 change the IANA state if necessary. 350 It is expected that this feature would only be used to correct 351 issues; it is not intended to be part of regular operations. 353 3. Integration of Data between the RFC Editor and Datatracker 355 For quite some time, the RFC Editor was seen as a black box, where 356 documents were submitted for publication, went through some process, 357 and came out as RFCs. Over time, the community asked for a more 358 transparent process; thus, state information was made available on 359 the RFC Editor website. Currently, some of that state information is 360 available from the Datatracker. However, for additional transparency 361 about the RFC Editor process, the Datatracker should be extended to 362 hold supplementary RFC Editor state and process (e.g., MISSREF) 363 information. This section defines the requirements for RFC Editor 364 state information to be added to the Datatracker to provide more 365 transparency and allow for a unified end-to-end tracking system. 367 3.1. RFC Editor Information To Be Added to the Datatracker 369 Once a document has been approved for publication, the document 370 enters the RFC Editor queue and is tracked using RFC-Editor-defined 371 states. Some RFC Editor state information is currently available via 372 the Datatracker, but the information is not stored in the History 373 log. RFC-Editor-defined state information will continue to be shown 374 as is done currently. In addition, a line item will be entered into 375 the History log each time a document changes state. The RFC Editor 376 shall continue to provide a queue file to allow data extraction; in 377 addition, there will be a machine-readable notification to the 378 Datatracker when state changes are made. 380 RFC Editor state information should continue to appear in the 381 metadata portion of the document available using the Datatracker. 382 For example, an entry might look as follows (including the IANA State 383 information): 385 Document type: Active Internet-Draft (TLS WG document) 386 Last updated: 2010-09-20 387 State: RFC Ed Queue 388 RFC Editor State: EDIT IANA 389 IANA State: In Progress 390 Intended status: Proposed Standard 392 The RFC Editor State field may be any of the states defined by the 393 RFC Editor. The list of RFC Editor state names in use at the time 394 this document was published is provided in Appendix B, but RFC Editor 395 states are defined by the RFC Editor and are subject to change. If 396 there are any discrepancies between the state names listed in this 397 document and those listed on the RFC Editor queue page 398 (http://www.rfc-editor.org/queue.html), the RFC Editor queue is 399 definitive. States may be added or removed by the RFC Editor; the 400 RFC Editor will work with the IAOC to update the Datatracker as 401 necessary. 403 Although RFC Editor state information is already available in the 404 Datatracker, the Datatracker should be updated to include some 405 additional data that may help individuals understand the status of 406 their document. In particular, the Datatracker should be updated to 407 include the following data: 409 1) links to AUTH48 pages 411 AUTH48 pages provide information about which authors have approved 412 the document for publication, whether AD approval is required, and 413 sometimes a summary of issues that need to be resolved before the 414 document can move forward. 416 2) links to the cluster pages 418 Clusters are defined as documents with normative reference 419 dependencies, and documents that have been requested for 420 simultaneous publication. (For more information, see 421 http://www.rfc-editor.org/cluster_def.html.) The cluster pages 422 provide a view of the entire set of state information for 423 clustered documents. 425 Note: The RFC Editor has been working with the cluster data to 426 provide the community with accurate state information at the 427 appropriate level of detail. The RFC Editor database may require 428 significant updates before this data can be integrated with the 429 Datatracker. 431 3) RFC metadata upon publication 433 The RFC Editor will notify the Datatracker when a new RFC has been 434 published, and the Datatracker should have the ability to 435 automatically update the relevant fields with data related to the 436 published RFC. In particular, the RFC number will be recorded in 437 the Datatracker. However, note that all fields are subject to 438 change during editing and should be updated; for example, document 439 title and the list of authors are sometimes changed, and character 440 counts and page counts are always changed. 442 4) notation when documents are withdrawn from the RFC Editor queue 444 If a document is to be removed from the RFC Editor / IANA queues, 445 the responsible party (e.g., AD or Secretariat) should change the 446 state of the Document in the Datatracker to something other than 447 "RFC Ed Queue". The Datatracker should provide a text box to 448 allow the responsible party to record details about the state 449 change. The state change and the related details will be recorded 450 in the History tab. The state change in the Datatracker will 451 trigger an email message to the RFC Editor and IANA as 452 notification that the state of the doc has been set to "state" 453 (the newly assigned state) with the details provided in the text 454 box. The RFC Editor and IANA will update their queues 455 accordingly, and the document will disappear from their respective 456 queues. 458 4. Other Updates to the Datatracker 460 While the primary goal of this document is to update the Datatracker 461 to display the IANA and RFC Editor process state information, the 462 Datatracker could hold additional data for use by IANA and the RFC 463 Editor that would allow for increased automation, thus reducing the 464 potential for delays and processing errors. This section defines 465 requirements for updates to the Datatracker to eliminate some of the 466 administrative tasks currently performed by staff. 468 4.1. Datatracker to IANA 470 When a document is approved for publication, data will be provided in 471 a machine-readable format and will include (in addition to the usual 472 Document/Protocol Action emails) the data requested by the RFC Editor 473 in Section 4.2. 475 4.2. Datatracker to RFC Editor 477 When a document is approved for publication, data will be provided in 478 a machine readable format and will include the following (in addition 479 to the usual document/protocol action emails): 481 - I-D string 482 - Document Title 483 - Author List 484 - Author Email Addresses 485 - Author Organizations (if available) 486 - Expedited goal date (if applicable) 487 Note: this field needs to be editable for post-approval changes. 488 - Publication Status (as defined in [RFC2026]) 489 - Consensus (yes/no) 490 - Source (Working Group or Research Group name, Individual, 491 or alternate stream name) 492 Note: The RFC Editor database may require updates before Research 493 Group data can be received from the Datatracker. 494 - IESG Contact 495 - Document Shepherd 496 Note: this is the individual currently listed in the "Personnel" section of 497 a Document/Protocol action. 498 - IANA actions required 500 Most of these items are already stored in the Datatracker. However, 501 the following fields need to be added: 503 - Expedited goal date 504 - Consensus (yes/no) 505 - Document Shepherd 506 - IANA actions required 508 "Consensus" is as used in [RFC5741]; it determines the appropriate 509 Status of This Memo text to be applied to IETF and IRTF documents. 510 The Consensus field should be set by the responsible individuals and 511 it should be listed in the Agenda Package provided before an IESG 512 telechat so that the Area Directors can quickly review the status of 513 the documents under review and correct the field if Consensus was not 514 received. 516 Additionally, the Agenda Package provided before an IESG telechat 517 should show the expiration date of the IETF Last Call. This will be 518 helpful for the ADs and the Secretariat to track the IETF Last Call 519 timeline. 521 When a document has been added to the RFC Editor queue (i.e., shows 522 an RFC Editor state in the Datatracker), an automated note should be 523 sent to the Secretariat as acknowledgment that the announcement has 524 been received. 526 4.2.1. Notifications 528 The Datatracker should notify the RFC Editor and the Sponsoring AD 529 when a version of an I-D has been made available after the document 530 has been approved for publication. 532 Additionally, the Datatracker should notify the RFC Editor and IANA 533 when the state of an I-D has been moved to something than "RFC Ed 534 Queue" or "RFC Published" -- that is, when it should be removed from 535 the RFC Editor and IANA processing queues. See item 4) in Section 536 3.1 for more detail. 538 4.2.2. Datatracker Extensions for Alternate Streams 540 Once the Datatracker has been updated for the alternate streams 541 [ALT-STREAMS], the Datatracker should be updated so that the 542 following are automated: 544 - the Datatracker should not expire any I-Ds that are under review 545 for publication. 547 - the Datatracker should automatically notify the approving body 548 when an I-D that is under review has been updated (i.e., a new 549 version has been made available). 551 - the Datatracker should be updated to list I-Ds according to the 552 stream that requested publication in the Agenda Package. This 553 should help provide additional clarity during IESG reviews, as 554 there will be a clear indication of from which stream a document 555 originates. 557 4.2.2.1. Publication Requests 559 "Data Tracker States and Annotations for the IAB, IRTF, and 560 Independent Submission Streams" [ALT-STREAMS] lists the requirements 561 for extending the Datatracker to account for alternate stream states 562 and annotations. In particular, the document introduces the "Sent to 563 the RFC Editor" state, which means the document is complete and has 564 been sent to the RFC Editor for publication. 566 The Datatracker will provide a means for the alternate streams to 567 generate a uniform publication request. Using the Datatracker, the 568 stream managers should be able to generate a publication request that 569 contains the relevant information for any approved I-D. 570 Additionally, the Datatracker will provide the data (the same data 571 provided for any IETF publication request -- see Section 4.2) in a 572 machine-readable format. This data will be available to the IANA and 573 RFC Editor, so that data entry into the IANA and RFC Editor systems 574 can be automated. 576 This update will allow the IANA and RFC Editor to handle documents in 577 a similar manner, regardless of the document's stream. 579 4.3. Reporting Requirements 581 The Datatracker should have a "Show Discrepancies" feature. It 582 should show all records in the Datatracker that fit certain criteria 583 (that seem to be a discrepancy). In addition to showing data on 584 screen, it should send an email to defined interested parties at 585 regular intervals (e.g., weekly). This feature will only be 586 available to a subset of individuals (namely, IANA, RFC Editor, and 587 the Secretariat), to ensure that our queues are in sync. This will 588 be especially helpful as the Datatracker is extended (now and in the 589 future), to ensure that all parties are receiving the correct 590 messages/data. 592 An initial set of discrepancies should be defined, and additional 593 discrepancies could be defined over time. For example, the initial 594 set of discrepancies could include: 596 - Show drafts that have passed through the state "Approved 597 Announcement sent" but do not have an RFC Editor state. 599 - Show drafts that have IANA state "In Progress" but RFC Editor 600 State is not equal to "IANA" or does not contain "*A" (see 601 Appendix B). 603 - Show drafts that have IANA state "Waiting on RFC Editor" or "RFC- 604 Ed-Ack", but RFC Editor State is "IANA" or contains "*A" (See 605 Appendix B). 607 - Show drafts that have a state of something other than "RFC Ed 608 Queue" or "RFC Published" that are listed in the RFC Editor or 609 IANA queues. 611 5. IANA Considerations 613 This document does not request any IANA registrations. 615 6. Security Considerations 617 This document does not propose any new Internet mechanisms, and has 618 no security implications for the Internet. 620 Appendix A. Current IANA States and Definitions 622 The currently defined IANA states are listed below. 624 * No value (blank) - A new document has been received by IANA, but 625 no actions have been taken 626 * In Progress - IANA is currently processing the actions for this 627 document 628 * Waiting on Authors - IANA is waiting on the document's authors 629 to respond 630 * Waiting on ADs - IANA is waiting on the IETF Area Directors to 631 respond 632 * Waiting on WGC - IANA is waiting on the IETF Working Group 633 Chairs to respond 634 * Waiting on RFC Editor - IANA has notified the RFC Editor that 635 the actions have been completed 636 * RFC-Ed-Ack - Request completed. The RFC Editor has acknowledged 637 receipt of IANA's message that the actions have been completed 638 * On Hold - IANA has suspended work on the document 639 * No IC - Request completed. There were no IANA actions for this 640 document 642 IANA states are defined by IANA and are subject to change. If there 643 are any discrepancies between the state names listed in this document 644 and those listed on the IANA queue page 645 (http://www.iana.org/about/performance/ietf-draft-status/), the IANA 646 queue is definitive. 648 Appendix B. Current RFC Editor States and Definitions 650 The currently defined RFC Editor Queue states are listed below. 652 * AUTH = Awaiting Author Action 653 * AUTH48 = Awaiting final author approval 654 * EDIT = Approved by the stream manager (e.g., IESG, IAB, IRSG, 655 ISE), awaiting processing and publishing 656 * IANA = RFC-Editor/IANA Registration Coordination 657 * IESG = Holding for IESG Action 658 * ISR = Independent Submission Review by the ISE 659 * ISR-AUTH = Independent Submission awaiting author update, or in 660 * discussion between author and ISE 661 * REF = Holding for normative reference (followed by I-D string of 662 * referenced document) 663 * RFC-EDITOR = Awaiting final rfc-editor review before AUTH48 664 * TO = Time-out period during which the IESG reviews document for 665 * conflict/concurrence with other IETF working group work 666 (followed by date) 667 * MISSREF = Awaiting missing normative reference. 669 RFC Editor states are defined by the RFC Editor and are subject to 670 change. If there are any discrepancies between the state names 671 listed in this document and those listed on the RFC Editor queue page 672 (http://www.rfc-editor.org/queue2.html), the RFC Editor queue is 673 definitive. 675 Currently, there are also a couple of state annotations used in RFC 676 Editor state-change emails. These do not alter the Datatracker in 677 any way, but are listed here for completeness: 679 *A = indicates that IANA actions are required 680 *R = indicates potential REFerence holds 682 Normative References 684 [ALT-STREAMS] Hoffman, P., "Data Tracker States and Annotations for 685 the IAB, IRTF, and Independent Submission Streams", 686 draft-hoffman-alt-streams-tracker, September 2010. 688 [IDTRACKER] "The IETF Datatracker tool", Web Application: 689 https://datatracker.ietf.org/, September 15, 2010. 691 [RFC2026] Bradner, S., "The Internet Standards Process -- 692 Revision 3", BCP 9, RFC 2026, October 1996. 694 [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The 695 RFC Series and RFC Editor", RFC 4844, July 2007. 697 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 698 an IANA Considerations Section in RFCs", BCP 26, RFC 699 5226, May 2008. 701 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC 702 Streams, Headers, and Boilerplates", RFC 5741, December 703 2009. 705 [RFC6174] Juskevicius, E., "Definition of IETF Working Group 706 Document States", RFC 6174, March 2011. 708 Acknowledgments 710 The authors would like to thank the following individuals for their 711 input: 713 Amanda Baber 714 Glen Barney 715 Adrian Farrel 716 Alice Hagens 717 Paul Hoffman 718 Russ Housley 719 Ed Juskevicius 720 Henrik Levkowetz 721 Cindy Morgan 722 Ray Pelletier 723 Rober Sparks 724 Peter St. Andre 725 Amy Vezza 727 Authors' Addresses 729 Sandy Ginoza 730 Association Management Solutions 731 48377 Fremont Blvd., Suite 117 732 Fremont, CA 94538 733 United States 735 Phone: +1 (510) 492-4000 736 EMail: sginoza@amsl.com 737 URI: http://www.amsl.com/ 739 Michelle Cotton 740 Internet Corporation for Assigned Names and Numbers 741 4676 Admiralty Way, Suite 330 742 Marina del Rey, CA 90292 743 United States 745 Phone: +310-823-9358 746 EMail: michelle.cotton@icann.org 747 URI: http://www.iana.org/ 749 Alexa Morris 750 Association Management Solutions 751 48377 Fremont Blvd., Suite 117 752 Fremont, CA 94538 753 United States 755 Phone: +1 (510) 492-4000 756 EMail: amorris@amsl.com 757 URI: http://www.amsl.com/