idnits 2.17.1 draft-ietf-genarea-datatracker-iana-rfced-extns-04.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 20, 2011) is 4695 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 20, 2011 ICANN 6 A. Morris 7 AMS 8 June 20, 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 The IANA and RFC Editor are functions independent of the IETF. When 104 an Internet-Draft enters the IANA queue, IANA retains ownership of 105 its own data, state names, and tracking systems. Similarly, when an 106 Internet-Draft enters the RFC Editor's queue, the RFC Editor retains 107 ownership of its own data, state names, and tracking systems. This 108 document discusses how the data from the IANA and RFC Editor queues 109 can be better reflected in the Datatracker to help inform the IETF 110 community what the state of a document is throughout its lifetime. 112 Prior to when an Internet-Draft is approved for publication as an 113 RFC, the Datatracker is the definitive source for tracking IANA 114 status information, and the IANA data is editable (by IANA and the 115 Secretariat) in the Datatracker. After an Internet-Draft is approved 116 for publication as an RFC, the IANA tracking system becomes the 117 definitive source for tracking IANA status information, and the data 118 can no longer be edited in the Datatracker. At that point, the data 119 in the Datatracker is only a reflection of the data in the IANA 120 tracking system. If there is a discrepancy at between the two after 121 this point, the data in the IANA tracking system is assumed to be 122 correct. 124 The RFC Editor's tracking system is always the definitive source for 125 tracking RFC Editor status of a document. RFC Editor data is not 126 editable via the Datatracker. The information in the Datatracker is 127 always a reflection of the information in the RFC Editor's tracking 128 system. 130 2. Integration of Data between the IANA and Datatracker 132 2.1. IANA Information To Be Added to the Datatracker 134 Currently, IANA reviews and touches documents at 4 different stages 135 in the process from I-D to RFC for IETF stream documents: IETF Last 136 Call, IESG Review, Document Approval (for publication), and RFC 137 Publication. Most of these state changes and issues are not captured 138 in the Datatracker. For the IRTF and INDEPENDENT streams, the IANA 139 review process begins when IESG Review is requested. For the IAB 140 stream, review would begin upon request for publication as an RFC. 142 This section specifies the requirements for including additional IANA 143 information in the Datatracker. 145 - IETF Last Call Comments 147 Currently, IANA reviews I-Ds that have been sent to IETF Last 148 Call, inputs comments in their data system, and then emails their 149 comments to authors, WG chairs, and then to the IESG. These 150 comments are also manually entered into the Datatracker for the 151 public record. However, it is difficult to determine whether the 152 IANA issues have been resolved. To help facilitate tracking of 153 IANA issues, a display is needed to show 5 new IANA substates, in 154 a similar fashion to how RFC Editor State is currently shown in 155 the Datatracker (see example of how IANA state information could 156 appear in the Datatracker for draft-example-00 below). 158 1) IANA Review Needed 160 This substate will allow the community, Secretariat, and IANA 161 to easily track which documents have or have not been reviewed 162 by IANA. If this substate is NOT set to IANA Not OK or IANA 163 OK, the substate should be set to "IANA review needed" by 164 default (this is the first substate for tracking IANA data). 165 For documents that originate from a non-IETF stream, the 166 default will be used. 168 2) IANA OK -- Actions Needed 170 This substate covers documents that require IANA actions and 171 the IANA considerations section indicates the details of the 172 actions correctly. 174 3) IANA OK -- No Actions Needed 176 This substate covers documents that require no IANA actions and 177 the IANA considerations section indicates this correctly. 179 NOTE: The substate will be set to "IANA OK -- Action Needed" or 180 "IANA OK -- No Actions Needed" (from "IANA Not OK") once any 181 outstanding issues have been resolved. The comments section will 182 be used to provide details in the History log about whether there 183 are no IANA actions, the text is OK, or the issues have been 184 resolved. 186 4) IANA Not OK 188 If IANA has issues with the text of the IANA Considerations 189 section of a document, the substate should be set to "IANA Not 190 OK" and the comment field should be populated with a 191 description of the issues and questions. In addition to any 192 questions IANA may have, IANA will also include in the comments 193 field whether expert review is required, if the doc is 194 dependent on another doc (e.g., doc B registers values in a 195 registry created by doc A, which hasn't been published yet), 196 and if there is a registry expert appointment required. 198 5) Version Changed -- Review Needed 200 This substate will allow the community, Secretariat, and IANA 201 to easily track which documents have been reviewed and 202 subsequently when a version of an Internet-Draft in Last Call 203 has changed, therefore requiring a second review of the 204 document by IANA to ensure that either the IANA Considerations 205 have not changed or that any changes made to the document 206 affecting IANA actions are clear. This substate applies to I- 207 Ds that are in any substate except "IANA Review Needed" and 208 "Version Changed". 210 When new versions are available, the Datatracker will 211 automatically set the IANA substate to "Version Changed -- 212 Review Needed". 214 Information providing the status of the IANA review (one of the 5 215 substates listed above) should be included as part of the evaluation 216 message (sent to the IESG) so that IANA can determine if and what 217 further action is required. 219 All comments will be recorded in the History log. However, to reduce 220 redundancy and manual effort, the Datatracker should provide the 221 ability to receive state information and related comments from the 222 IANA tracking system. There should be a notification that comments 223 have been entered in the IANA-maintained system, and entry of those 224 comments into the datatracker and distribution of those comments to 225 the authors should be automated. 227 - IESG Evaluation 229 As not all documents receive an IETF Last Call, this state is 230 sometimes the first time that IANA reviews a document. For a 231 document that wasn't IETF Last Called, IANA reviews the document, 232 enters comments in their own tracking system, distributes email to 233 authors and other interested parties (e.g., WG chairs, ISE), and 234 then enters those same comments into the Datatracker, where they 235 are recorded in the History log. In cases where a document was 236 IETF Last Called, IANA checks for and reviews version changes and 237 re-reviews documents to ensure that any identified IANA issues 238 have been resolved. 240 Comments will continue to be recorded in the History log. 241 However, to reduce redundancy and manual effort, the Datatracker 242 should provide the ability for IANA to enter substate information 243 and related comments into the IANA tracking system, and 244 distribution of those comments to the authors and entry into the 245 Datatracker should be automated. 247 Ideally, the authors will have responded to and resolved any IANA 248 issues prior to the document being slated for an IESG telechat. 249 However, if any document continues to have an "IANA Not OK", 250 "Version Changed - Review Needed", or "IANA Review needed" 251 substates and is slated for the IESG telechat, it should be called 252 out in the Agenda Package. For example, it could appear as 253 follows: 255 o draft-example-00 256 Title of Internet-Draft 257 Note: John Doe (jdoe@example.com) is the document shepherd. 258 Token: Jane Doe 259 IANA: IANA Not OK 261 This will ensure that IANA and the ADs are aware that there are 262 still IANA considerations issues to be addressed prior to 263 publication, or that initial or follow-up IANA Review is required 264 and not yet completed (in cases where the substate is listed as 265 "IANA review needed" or "Version Revision - Review Needed"). 267 - Document Approved for Publication 269 Once a document has been approved for publication, the document 270 enters the IANA queue and is tracked using IANA-defined states. 271 This state information is not currently available via the 272 Datatracker. In order for the community to view the IANA 273 processing states without being redirected to the IANA queue, the 274 Datatracker should be extended to include IANA state information 275 as defined by IANA. For example, IANA state information could 276 appear in the metadata portion of the document as follows: 278 Document type: Active Internet-Draft (FOO WG document) 279 Last updated: 2010-09-20 280 State: RFC Ed Queue 281 RFC Editor State: EDIT IANA 282 IANA State: In Progress 283 Intended status: Proposed Standard 285 IANA state-change information will link to the IANA queue, and 286 will be captured as a line item in the History log. IANA will 287 notify the Datatracker when changes are made in the IANA queue. 289 Once the IANA actions have been completed, the Datatracker History 290 log will be updated to include the actions completed by IANA (the 291 author-approved actions). This will include the same information 292 that is sent to the RFC Editor once the actions upon completion of 293 IANA actions. 295 The IANA State field may be any of the states defined by IANA. 296 The list of IANA state names in use at the time this document was 297 published is provided in Appendix A; however, IANA states are 298 defined by IANA and are subject to change. If there are any 299 discrepancies between the state names listed in this document and 300 those listed on the IANA queue page 301 (http://www.iana.org/about/performance/ietf-draft-status/), the 302 IANA queue is definitive. States may be added or removed by IANA; 303 IANA will work with the IAOC to update the Datatracker as 304 necessary. 306 - RFC Publication 308 References to I-Ds are updated to refer to the RFC once published, 309 and minor updates may be made to match the published RFC. This 310 data will be tracked in the Datatracker to show when the 311 references in the IANA registries were updated to include the 312 newly assigned RFC Number. 314 2.2. Future IANA Information To Be Available Via the Datatracker 316 The document "Definition of IETF Working Group Document States" 317 [RFC6174] includes the following: 319 4.3.1. Awaiting Expert Review/Resolution of Issues Raised 321 This tag means that someone (e.g. an author or editor of the WG 322 draft, or a WG Chair) has initiated an expert review of the 323 document and the review has not yet been completed and/or the 324 resolution of issues raised by the review has not yet been 325 completed. Examples of expert reviews include cross-area 326 reviews, MIB Doctor reviews, security expert reviews, and IANA 327 reviews. 329 WG drafts tagged with this annotation should retain the tag 330 until the review is complete and possibly until any issues 331 raised in the review are addressed. 333 IANA is in the process of documenting how an expert review is 334 conducted during the lifetime of an Internet-Draft. Once the process 335 has been defined, the Datatracker should be updated to indicate if a 336 document requires Expert Review [RFC5226] (either for the entire 337 document or a portion thereof), if the Expert Reviewer has issues 338 with what they are being requested to review, and if applicable 339 whether the Expert Reviewer has approved or rejected the requested 340 registration(s). There may be a need to complete expert reviews 341 again before publication of a document if there have been changes to 342 the text relevant to the review by the expert. In cases where a new 343 registry is being created in the document, an indicator of whether an 344 expert needs to be appointed by the IESG would also be useful. 346 2.3. Permissions to Change IANA State Information 348 IANA state changes should be automated, but IANA should have the 349 ability to log in to the Datatracker to manually update the system as 350 well. 352 Additionally, the IETF Secretariat should also have the ability to 353 change the IANA state if necessary. 355 It is expected that this feature would only be used to correct 356 issues; it is not intended to be part of regular operations. 358 3. Integration of Data between the RFC Editor and Datatracker 360 For quite some time, the RFC Editor was seen as a black box, where 361 documents were submitted for publication, went through some process, 362 and came out as RFCs. Over time, the community asked for a more 363 transparent process; thus, state information was made available on 364 the RFC Editor website. Currently, some of that state information is 365 available from the Datatracker. However, for additional transparency 366 about the RFC Editor process, the Datatracker should be extended to 367 hold supplementary RFC Editor state and process (e.g., MISSREF) 368 information. This section defines the requirements for RFC Editor 369 state information to be added to the Datatracker to provide more 370 transparency and allow for a unified end-to-end tracking system. 372 3.1. RFC Editor Information To Be Added to the Datatracker 374 Once a document has been approved for publication, the document 375 enters the RFC Editor queue and is tracked using RFC-Editor-defined 376 states. Some RFC Editor state information is currently available via 377 the Datatracker, but the information is not stored in the History 378 log. RFC-Editor-defined state information will continue to be shown 379 as is done currently. In addition, a line item will be entered into 380 the History log each time a document changes state. The RFC Editor 381 shall continue to provide a queue file to allow data extraction; in 382 addition, there will be a machine-readable notification to the 383 Datatracker when state changes are made. 385 RFC Editor state information should continue to appear in the 386 metadata portion of the document available using the Datatracker. 387 For example, an entry might look as follows (including the IANA State 388 information): 390 Document type: Active Internet-Draft (TLS WG document) 391 Last updated: 2010-09-20 392 State: RFC Ed Queue 393 RFC Editor State: EDIT IANA 394 IANA State: In Progress 395 Intended status: Proposed Standard 397 The RFC Editor State field may be any of the states defined by the 398 RFC Editor. The list of RFC Editor state names in use at the time 399 this document was published is provided in Appendix B, but RFC Editor 400 states are defined by the RFC Editor and are subject to change. If 401 there are any discrepancies between the state names listed in this 402 document and those listed on the RFC Editor queue page 403 (http://www.rfc-editor.org/queue.html), the RFC Editor queue is 404 definitive. States may be added or removed by the RFC Editor; the 405 RFC Editor will work with the IAOC to update the Datatracker as 406 necessary. 408 Although RFC Editor state information is already available in the 409 Datatracker, the Datatracker should be updated to include some 410 additional data that may help individuals understand the status of 411 their document. In particular, the Datatracker should be updated to 412 include the following data: 414 1) links to AUTH48 pages 416 AUTH48 pages provide information about which authors have approved 417 the document for publication, whether AD approval is required, and 418 sometimes a summary of issues that need to be resolved before the 419 document can move forward. 421 2) links to the cluster pages 423 Clusters are defined as documents with normative reference 424 dependencies, and documents that have been requested for 425 simultaneous publication. (For more information, see 426 http://www.rfc-editor.org/cluster_def.html.) The cluster pages 427 provide a view of the entire set of state information for 428 clustered documents. 430 Note: The RFC Editor has been working with the cluster data to 431 provide the community with accurate state information at the 432 appropriate level of detail. The RFC Editor database may require 433 significant updates before this data can be integrated with the 434 Datatracker. 436 3) RFC metadata upon publication 438 The RFC Editor will notify the Datatracker when a new RFC has been 439 published, and the Datatracker should have the ability to 440 automatically update the relevant fields with data related to the 441 published RFC. In particular, the RFC number will be recorded in 442 the Datatracker. However, note that all fields are subject to 443 change during editing and should be updated; for example, document 444 title and the list of authors are sometimes changed, and character 445 counts and page counts are always changed. 447 4) notation when documents are withdrawn from the RFC Editor queue 449 If a document is to be removed from the RFC Editor / IANA queues, 450 the responsible party (e.g., AD or Secretariat) should change the 451 state of the Document in the Datatracker to something other than 452 "RFC Ed Queue". The Datatracker should provide a text box to 453 allow the responsible party to record details about the state 454 change. The state change and the related details will be recorded 455 in the History tab. The state change in the Datatracker will 456 trigger an email message to the RFC Editor and IANA as 457 notification that the state of the doc has been set to "state" 458 (the newly assigned state) with the details provided in the text 459 box. The RFC Editor and IANA will update their queues 460 accordingly, and the document will disappear from their respective 461 queues. 463 4. Other Updates to the Datatracker 465 While the primary goal of this document is to update the Datatracker 466 to display the IANA and RFC Editor process state information, the 467 Datatracker could hold additional data for use by IANA and the RFC 468 Editor that would allow for increased automation, thus reducing the 469 potential for delays and processing errors. This section defines 470 requirements for updates to the Datatracker to eliminate some of the 471 administrative tasks currently performed by staff. 473 4.1. Datatracker to IANA 475 When a document is approved for publication, data will be provided in 476 a machine-readable format and will include (in addition to the usual 477 Document/Protocol Action emails) the data requested by the RFC Editor 478 in Section 4.2. 480 4.2. Datatracker to RFC Editor 482 When a document is approved for publication, data will be provided in 483 a machine readable format and will include the following (in addition 484 to the usual document/protocol action emails): 486 - I-D string 487 - Document Title 488 - Author List 489 - Author Email Addresses 490 - Author Organizations (if available) 491 - Expedited goal date (if applicable) 492 Note: this field needs to be editable for post-approval changes. 493 - Publication Status (as defined in [RFC2026]) 494 - Consensus (yes/no) 495 - Source (Working Group or Research Group name, Individual, 496 or alternate stream name) 497 Note: The RFC Editor database may require updates before Research 498 Group data can be received from the Datatracker. 499 - IESG Contact 500 - Document Shepherd 501 Note: this is the individual currently listed in the "Personnel" section of 502 a Document/Protocol action. 503 - IANA actions required 505 Most of these items are already stored in the Datatracker. However, 506 the following fields need to be added: 508 - Expedited goal date 509 - Consensus (yes/no) 510 - Document Shepherd 511 - IANA actions required 513 "Consensus" is as used in [RFC5741]; it determines the appropriate 514 Status of This Memo text to be applied to IETF and IRTF documents. 515 The Consensus field should be set by the responsible individuals and 516 it should be listed in the Agenda Package provided before an IESG 517 telechat so that the Area Directors can quickly review the status of 518 the documents under review and correct the field if Consensus was not 519 received. 521 Additionally, the Agenda Package provided before an IESG telechat 522 should show the expiration date of the IETF Last Call. This will be 523 helpful for the ADs and the Secretariat to track the IETF Last Call 524 timeline. 526 When a document has been added to the RFC Editor queue (i.e., shows 527 an RFC Editor state in the Datatracker), an automated note should be 528 sent to the Secretariat as acknowledgment that the announcement has 529 been received. 531 4.2.1. Notifications 533 The Datatracker should notify the RFC Editor and the Sponsoring AD 534 when a version of an I-D has been made available after the document 535 has been approved for publication. 537 Additionally, the Datatracker should notify the RFC Editor and IANA 538 when the state of an I-D has been moved to something than "RFC Ed 539 Queue" or "RFC Published" -- that is, when it should be removed from 540 the RFC Editor and IANA processing queues. See item 4) in Section 541 3.1 for more detail. 543 4.2.2. Datatracker Extensions for Alternate Streams 545 Once the Datatracker has been updated for the alternate streams 546 [ALT-STREAMS], the Datatracker should be updated so that the 547 following are automated: 549 - the Datatracker should not expire any I-Ds that are under review 550 for publication. 552 - the Datatracker should automatically notify the approving body 553 when an I-D that is under review has been updated (i.e., a new 554 version has been made available). 556 - the Datatracker should be updated to list I-Ds according to the 557 stream that requested publication in the Agenda Package. This 558 should help provide additional clarity during IESG reviews, as 559 there will be a clear indication of from which stream a document 560 originates. 562 4.2.2.1. Publication Requests 564 "Data Tracker States and Annotations for the IAB, IRTF, and 565 Independent Submission Streams" [ALT-STREAMS] lists the requirements 566 for extending the Datatracker to account for alternate stream states 567 and annotations. In particular, the document introduces the "Sent to 568 the RFC Editor" state, which means the document is complete and has 569 been sent to the RFC Editor for publication. 571 The Datatracker will provide a means for the alternate streams to 572 generate a uniform publication request. Using the Datatracker, the 573 stream managers should be able to generate a publication request that 574 contains the relevant information for any approved I-D. 575 Additionally, the Datatracker will provide the data (the same data 576 provided for any IETF publication request -- see Section 4.2) in a 577 machine-readable format. This data will be available to the IANA and 578 RFC Editor, so that data entry into the IANA and RFC Editor systems 579 can be automated. 581 This update will allow the IANA and RFC Editor to handle documents in 582 a similar manner, regardless of the document's stream. 584 4.3. Reporting Requirements 586 The Datatracker should have a "Show Discrepancies" feature. It 587 should show all records in the Datatracker that fit certain criteria 588 (that seem to be a discrepancy). In addition to showing data on 589 screen, it should send an email to defined interested parties at 590 regular intervals (e.g., weekly). This feature will only be 591 available to a subset of individuals (namely, IANA, RFC Editor, and 592 the Secretariat), to ensure that our queues are in sync. This will 593 be especially helpful as the Datatracker is extended (now and in the 594 future), to ensure that all parties are receiving the correct 595 messages/data. 597 An initial set of discrepancies should be defined, and additional 598 discrepancies could be defined over time. For example, the initial 599 set of discrepancies could include: 601 - Show drafts that have passed through the state "Approved 602 Announcement sent" but do not have an RFC Editor state. 604 - Show drafts that have IANA state "In Progress" but RFC Editor 605 State is not equal to "IANA" or does not contain "*A" (see 606 Appendix B). 608 - Show drafts that have IANA state "Waiting on RFC Editor" or "RFC- 609 Ed-Ack", but RFC Editor State is "IANA" or contains "*A" (See 610 Appendix B). 612 - Show drafts that have a state of something other than "RFC Ed 613 Queue" or "RFC Published" that are listed in the RFC Editor or 614 IANA queues. 616 5. IANA Considerations 618 This document does not request any IANA registrations. 620 6. Security Considerations 622 This document does not propose any new Internet mechanisms, and has 623 no security implications for the Internet. 625 Appendix A. Current IANA States and Definitions 627 The currently defined IANA states are listed below. 629 * No value (blank) - A new document has been received by IANA, but 630 no actions have been taken 631 * In Progress - IANA is currently processing the actions for this 632 document 633 * Waiting on Authors - IANA is waiting on the document's authors 634 to respond 635 * Waiting on ADs - IANA is waiting on the IETF Area Directors to 636 respond 637 * Waiting on WGC - IANA is waiting on the IETF Working Group 638 Chairs to respond 639 * Waiting on RFC Editor - IANA has notified the RFC Editor that 640 the actions have been completed 641 * RFC-Ed-Ack - Request completed. The RFC Editor has acknowledged 642 receipt of IANA's message that the actions have been completed 643 * On Hold - IANA has suspended work on the document 644 * No IC - Request completed. There were no IANA actions for this 645 document 647 IANA states are defined by IANA and are subject to change. If there 648 are any discrepancies between the state names listed in this document 649 and those listed on the IANA queue page 650 (http://www.iana.org/about/performance/ietf-draft-status/), the IANA 651 queue is definitive. 653 Appendix B. Current RFC Editor States and Definitions 655 The currently defined RFC Editor Queue states are listed below. 657 * AUTH = Awaiting Author Action 658 * AUTH48 = Awaiting final author approval 659 * EDIT = Approved by the stream manager (e.g., IESG, IAB, IRSG, 660 ISE), awaiting processing and publishing 661 * IANA = RFC-Editor/IANA Registration Coordination 662 * IESG = Holding for IESG Action 663 * ISR = Independent Submission Review by the ISE 664 * ISR-AUTH = Independent Submission awaiting author update, or in 665 * discussion between author and ISE 666 * REF = Holding for normative reference (followed by I-D string of 667 * referenced document) 668 * RFC-EDITOR = Awaiting final rfc-editor review before AUTH48 669 * TO = Time-out period during which the IESG reviews document for 670 * conflict/concurrence with other IETF working group work 671 (followed by date) 672 * MISSREF = Awaiting missing normative reference. 674 RFC Editor states are defined by the RFC Editor and are subject to 675 change. If there are any discrepancies between the state names 676 listed in this document and those listed on the RFC Editor queue page 677 (http://www.rfc-editor.org/queue2.html), the RFC Editor queue is 678 definitive. 680 Currently, there are also a couple of state annotations used in RFC 681 Editor state-change emails. These do not alter the Datatracker in 682 any way, but are listed here for completeness: 684 *A = indicates that IANA actions are required 685 *R = indicates potential REFerence holds 687 Normative References 689 [ALT-STREAMS] Hoffman, P., "Data Tracker States and Annotations for 690 the IAB, IRTF, and Independent Submission Streams", 691 draft-hoffman-alt-streams-tracker, September 2010. 693 [IDTRACKER] "The IETF Datatracker tool", Web Application: 694 https://datatracker.ietf.org/, September 15, 2010. 696 [RFC2026] Bradner, S., "The Internet Standards Process -- 697 Revision 3", BCP 9, RFC 2026, October 1996. 699 [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The 700 RFC Series and RFC Editor", RFC 4844, July 2007. 702 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 703 an IANA Considerations Section in RFCs", BCP 26, RFC 704 5226, May 2008. 706 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC 707 Streams, Headers, and Boilerplates", RFC 5741, December 708 2009. 710 [RFC6174] Juskevicius, E., "Definition of IETF Working Group 711 Document States", RFC 6174, March 2011. 713 Acknowledgments 715 The authors would like to thank the following individuals for their 716 input: 718 Amanda Baber 719 Glen Barney 720 Adrian Farrel 721 Alice Hagens 722 Paul Hoffman 723 Russ Housley 724 Ed Juskevicius 725 Henrik Levkowetz 726 Cindy Morgan 727 Ray Pelletier 728 Rober Sparks 729 Peter St. Andre 730 Amy Vezza 732 Authors' Addresses 734 Sandy Ginoza 735 Association Management Solutions 736 48377 Fremont Blvd., Suite 117 737 Fremont, CA 94538 738 United States 740 Phone: +1 (510) 492-4000 741 EMail: sginoza@amsl.com 742 URI: http://www.amsl.com/ 744 Michelle Cotton 745 Internet Corporation for Assigned Names and Numbers 746 4676 Admiralty Way, Suite 330 747 Marina del Rey, CA 90292 748 United States 750 Phone: +310-823-9358 751 EMail: michelle.cotton@icann.org 752 URI: http://www.iana.org/ 754 Alexa Morris 755 Association Management Solutions 756 48377 Fremont Blvd., Suite 117 757 Fremont, CA 94538 758 United States 760 Phone: +1 (510) 492-4000 761 EMail: amorris@amsl.com 762 URI: http://www.amsl.com/