idnits 2.17.1 draft-ietf-genarea-datatracker-iana-rfced-extns-00.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 : ---------------------------------------------------------------------------- ** 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 == Line 159 has weird spacing: '...ts have been ...' == 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 (February 25, 2011) is 4808 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5226' is mentioned on line 288, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC 5226' is defined on line 627, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5741 (Obsoleted by RFC 7841) Summary: 4 errors (**), 0 flaws (~~), 5 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: August 25, 2011 ICANN 6 A. Morris 7 AMS 8 February 25, 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]. 75 The Datatracker is used to report on the status of I-Ds that have 76 been submitted to the IESG for evaluation and publication. The 77 Datatracker will be extended, according to the requirements defined 78 in [WGDOCUMENT-STATES] and [ALT-STREAMS], to include tracking 79 information about a document during its progression from version -00 80 to it being requested for IESG evaluation. However, the Datatracker, 81 ICANN (peforming the IANA function), and RFC Editor operate on 82 separate systems with varying degrees of visibility into the 83 processing that takes place once the stream managers have approved a 84 document for publication. This document defines the requirements for 85 extending the Datatracker to include increased IANA and RFC Editor 86 state information, so that the Datatracker covers the lifetime of an 87 I-D from version -00 to RFC publication. 89 Additionally, this document lists the processes between the IANA, RFC 90 Editor, and Secretariat (via the Datatracker) that should be 91 automated for accuracy and timely processing. While this document 92 includes some details of the IANA, RFC Editor, and Secretariat 93 process, this document does not define any of the processes. The 94 processes are continually reviewed for process optimization and need 95 to remain flexible to adapt to new changes in policy and environment. 96 Processes are defined and set by each of the entities respectively. 98 2. Integration of Data between the IANA and Datatracker 100 2.1. IANA Information To Be Added to the Datatracker 102 Currently, IANA reviews and touches documents at 4 different stages 103 in the process from I-D to RFC: Last Call, IESG Review, Document 104 Approval (for publication), and RFC Publication. Most of these state 105 changes and issues are not captured in the Datatracker. This section 106 specifies the requirements for including additional IANA information 107 in the Datatracker. 109 - Last Call Comments 111 Currently, IANA reviews I-Ds that have been sent to IETF Last 112 Call, inputs comments in their data system, and then emails their 113 comments to authors, WG chairs, and then to the IESG. These 114 comments are also manually entered into the Datatracker for the 115 public record. However, it is difficult to determine whether the 116 IANA issues have been resolved. To help facilitate tracking of 117 IANA issues, 5 new substates will be added to the Datatracker: 119 1) IANA Review Needed 121 This flag will allow the community, Secretariat, and IANA to 122 easily track which documents have or have not been reviewed by 123 IANA. If this state is NOT set to 1) IANA Not OK or 2) IANA 124 OK, the state should be set to "IANA review needed" by default. 126 2) IANA OK -- Actions Needed 128 This substate covers documents that require IANA actions and 129 the IANA considerations section indicates the details of the 130 actions correctly. 132 3) IANA OK -- No Actions Needed 134 This substate covers document that require no IANA actions and 135 the IANA considerations section indicates this correctly. 137 NOTE: The substate will be set to "IANA OK -- Action Needed" or 138 "IANA OK -- No Actions Needed" (from "IANA Not OK") once any 139 outstanding issues have been resolved. The comments section will 140 be used to provide details in the History log about whether there 141 are no IANA actions, the text is OK, or the issues have been 142 resolved. 144 4) IANA Not OK 146 If IANA has issues with the text of the IANA Considerations 147 section of a document, the substate should be set to "IANA Not 148 OK" and the comment field should be populated with a 149 description of the issues and questions. In addition to any 150 questions IANA may have, IANA will also include in the comments 151 field whether expert review is required, if the doc is 152 dependent on another doc (e.g., doc B registers values in a 153 registry created by doc A, which hasn't been published yet), 154 and if there is a registry expert appointment required. 156 5) Version Changed -- Review Needed 158 This flag will allow the community, Secretariat, and IANA to 159 easily track which documents have been reviewed and 160 subsequently when a version of an Internet-Draft has changed, 161 therefore requiring a second review of the document by IANA to 162 ensure that either the IANA Considerations have not changed or 163 that any changes made to the document affecting IANA actions 164 are clear. This flag applies to I-Ds that have previously been 165 marked as "IANA OK -- Action Needed" or "IANA Not OK". 167 Information providing the status of the IANA review (one of the 4 168 substates listed above) should be included as part of the evaluation 169 message (sent to the IESG) so that IANA can determine if and what 170 further action is required. 172 All comments will be recorded in the History log. However, to reduce 173 redundancy and manual effort, the Datatracker should provide the 174 ability to receive state information and related comments from the 175 IANA tracking system. There should be a notification that comments 176 have been entered in the IANA-maintained system, and entry of those 177 comments into the datatracker and distribution of those comments to 178 the authors should be automated. 180 - IESG Review 182 As not all documents receive a Last Call, this substate is 183 sometimes the first time that IANA reviews a document. For a 184 document that wasn't Last Called, IANA reviews the document, 185 enters comments in their own tracking system, distributes email to 186 authors, WG chairs, and ADs (all interested parties), and then 187 enters those same comments into the Datatracker, where they are 188 recorded in the History log. In cases where a document was Last 189 Called, IANA checks for and reviews version changes and re-reviews 190 documents to ensure that any flagged IANA issues have been 191 resolved. 193 Comments will continue to be recorded in the History log. 194 However, to reduce redundancy and manual effort, the Datatracker 195 should provide the ability for IANA to enter state information and 196 related comments into the IANA tracking system, and distribution 197 of those comments to the authors and entry into the Datatracker 198 should be automated. 200 Ideally, the authors will have responded to and resolved any IANA 201 issues prior to the document being slated for an IESG telechat. 202 However, if any document continues to have an "IANA Not OK", 203 ""Version Changed - Review Needed", or "IANA Review needed" flag 204 and is slated for the IESG telechat, it should be called out in 205 the Agenda Package. For example, it could appear as follows: 207 o draft-example-00 208 Title of Internet-Draft 209 Note: John Doe (jdoe@example.com) is the document shepherd. 210 Token: Jane Doe 211 IANA: IANA Not OK 213 This will ensure that IANA and the ADs are aware that there are 214 still IANA considerations issues to be addressed prior to 215 publication, or that initial or follow-up IANA Review is required 216 and not yet completed (in cases where the state is listed as "IANA 217 review needed" or "Version Revision - Review Needed"). 219 - Document Approved for Publication 221 Once a document has been approved for publication, the document 222 enters the IANA queue and is tracked using IANA-defined states. 223 This state information is not currently available via the 224 Datatracker. In order for the community to view the IANA 225 processing states without being redirected to the IANA queue, the 226 Datatracker should be extended to include IANA state information 227 as defined by IANA. For example, IANA state information could 228 appear in the metadata portion of the document as follows: 230 Document type: Active Internet-Draft (FOO WG document) 231 Last updated: 2010-09-20 232 State: RFC Ed Queue 233 RFC Editor State: EDIT IANA 234 IANA State: In Progress 235 Intended status: Proposed Standard 237 IANA state-change information will link to the IANA queue, and 238 will be captured as a line item in the History log. IANA will 239 notify the Datatracker when changes are made in the IANA queue. 241 Once the IANA actions have been completed, the Datatracker History 242 log will be updated to include the actions completed by IANA (the 243 author-approved actions). This will include the same information 244 that is sent to the RFC Editor once the actions upon completion of 245 IANA actions. 247 The IANA State field may be any of the states defined by IANA. 248 The list of IANA state names in use at the time this document was 249 published is provided in Appendix A; however, IANA states are 250 defined by IANA and are subject to change. If there are any 251 discrepancies between the state names listed in this document and 252 those listed on the IANA queue page 253 (http://www.iana.org/about/performance/ietf-draft-status/), the 254 IANA queue is definitive. States may be added or removed by IANA; 255 IANA will work with the IAOC to update the Datatracker as 256 necessary. 258 - RFC Publication 260 References to I-Ds are updated to refer to the RFC once published, 261 and minor updates may be made to match the published RFC. This 262 data will be tracked in the Datatracker to show when the 263 references in the IANA registries were updated to include the 264 newly assigned RFC Number. 266 2.2. Future IANA Information To Be Available Via the Datatracker 268 The document "Definition of IETF Working Group Document States" 269 [WGDOCUMENT-STATES] includes the following: 271 4.3.1. Awaiting Expert Review/Resolution of Issues Raised 273 This tag means that someone (e.g. an author or editor of the WG 274 draft, or a WG Chair) has initiated an expert review of the 275 document and the review has not yet been completed and/or the 276 resolution of issues raised by the review has not yet been 277 completed. Examples of expert reviews include cross-area 278 reviews, MIB Doctor reviews, security expert reviews, and IANA 279 reviews. 281 WG drafts tagged with this annotation should retain the tag 282 until the review is complete and possibly until any issues 283 raised in the review are addressed. 285 IANA is in the process of documenting how an expert review is 286 conducted during the lifetime of an Internet-Draft. Once the process 287 has been defined, the Datatracker should be updated to indicate if a 288 document requires Expert Review [RFC5226] (either for the entire 289 document or a portion thereof), if the Expert Reviewer has issues 290 with what they are being requested to review, and if applicable 291 whether the Expert Reviewer has approved or rejected the requested 292 registration(s). There may be a need to complete expert reviews 293 again before publication of a document if there have been changes to 294 the text relevant to the review by the expert. In cases where a new 295 registry is being created in the document, an indicator of whether an 296 expert needs to be appointed by the IESG would also be useful. 298 2.3. Permissions to Change IANA State Information 300 IANA state changes should be automated, but IANA should have the 301 ability to log in to the Datatracker to manually update the system as 302 well. 304 Additionally, the IETF Secretariat should also have the ability to 305 change the IANA state if necessary. 307 3. Integration of Data between the RFC Editor and Datatracker 309 For quite some time, the RFC Editor was seen as a black box, where 310 documents were submitted for publication, went through some process, 311 and came out as RFCs. Over time, the community asked for a more 312 transparent process; thus, state information was made available on 313 the RFC Editor website. Currently, some of that state information is 314 available from the Datatracker. However, for additional transparency 315 about the RFC Editor process, the Datatracker should be extended to 316 hold supplementary RFC Editor state and process (e.g., MISSREF) 317 information. This section defines the requirements for RFC Editor 318 state information to be added to the Datatracker to provide more 319 transparency and allow for a unified end-to-end tracking system. 321 3.1. RFC Editor Information To Be Added to the Datatracker 323 Once a document has been approved for publication, the document 324 enters the RFC Editor queue and is tracked using RFC-Editor-defined 325 states. Some RFC Editor state information is currently available via 326 the Datatracker, but the information is not stored in the History 327 log. RFC-Editor-defined state information will continue to be shown 328 as is done currently. In addition, a line item will be entered into 329 the History log each time a document changes state. The RFC Editor 330 shall continue to provide a queue file to allow data extraction; in 331 addition, there will be a machine-readable notification to the 332 Datatracker when state changes are made. 334 RFC Editor state information should continue to appear in the 335 metadata portion of the document available using the Datatracker. 336 For example, an entry might look as follows (including the IANA State 337 information): 339 Document type: Active Internet-Draft (TLS WG document) 340 Last updated: 2010-09-20 341 State: RFC Ed Queue 342 RFC Editor State: EDIT IANA 343 IANA State: In Progress 344 Intended status: Proposed Standard 346 The RFC Editor State field may be any of the states defined by the 347 RFC Editor. The list of RFC Editor state names in use at the time 348 this document was published is provided in Appendix B, but RFC Editor 349 states are defined by the RFC Editor and are subject to change. If 350 there are any discrepancies between the state names listed in this 351 document and those listed on the RFC Editor queue page 352 (http://www.rfc-editor.org/queue.html), the RFC Editor queue is 353 definitive. States may be added or removed by the RFC Editor; the 354 RFC Editor will work with the IAOC to update the Datatracker as 355 necessary. 357 Although RFC Editor state information is already available in the 358 Datatracker, the Datatracker should be updated to include some 359 additional data that may help individuals understand the status of 360 their document. In particular, the Datatracker should be updated to 361 include the following data: 363 1) links to AUTH48 pages 365 AUTH48 pages provide information about which authors have approved 366 the document for publication, whether AD approval is required, and 367 sometimes a summary of issues that need to be resolved before the 368 document can move forward. 370 2) links to the cluster pages 372 Clusters are defined as documents with normative reference 373 dependencies, and documents that have been requested for 374 simultaneous publication. (For more information, see 375 http://www.rfc-editor.org/cluster_def.html.) The cluster pages 376 provide a view of the entire set of state information for 377 clustered documents. 379 Note: The RFC Editor has been working with the cluster data to 380 provide the community with accurate state information at the 381 appropriate level of detail. The RFC Editor database may require 382 significant updates before this data can be integrated with the 383 Datatracker. 385 3) RFC metadata upon publication 387 The RFC Editor will notify the Datatracker when a new RFC has been 388 published, and the Datatracker should have the ability to 389 automatically update the relevant fields with data related to the 390 published RFC. In particular, the RFC number will be recorded in 391 the Datatracker. However, note that all fields are subject to 392 change during editing and should be updated; for example, document 393 title and the list of authors are sometimes changed, and character 394 counts and page counts are always changed. 396 4. Other Updates to the Datatracker 398 While the primary goal of this document is to update the Datatracker 399 to display the IANA and RFC Editor process state information, the 400 Datatracker could hold additional data for use by IANA and the RFC 401 Editor that would allow for increased automation, thus reducing the 402 potential for delays and processing errors. This section defines 403 requirements for updates to the Datatracker to eliminate some of the 404 administrative tasks currently performed by staff. 406 4.1. Datatracker to IANA 408 When a document is approved for publication, data will be provided in 409 a machine-readable format and will include (in addition to the usual 410 Document/Protocol Action emails) the data requested by the RFC Editor 411 in Section 4.2. 413 4.2. Datatracker to RFC Editor 415 When a document is approved for publication, data will be provided in 416 a machine readable format and will include the following (in addition 417 to the usual document/protocol action emails): 419 - I-D string 420 - Document Title 421 - Author List 422 - Author Email Addresses 423 - Author Organizations (if available) 424 - Expedited goal date (if applicable) 425 Note: this field needs to be editable for post-approval changes. 426 - Publication Status (as defined in [RFC2026]) 427 - Consensus (yes/no) 428 - Source (Working Group or Research Group name, Individual, 429 or alternate stream name) 430 Note: The RFC Editor database may require updates before Research 431 Group data can be received from the Datatracker. 432 - IESG Contact 433 - Document Shepherd 434 Note: this is the individual currently listed in the "Personnel" section of 435 a Document/Protocol action. 436 - IANA actions required 438 Most of these items are already stored in the Datatracker. However, 439 the following fields/flags need to be added: 441 - Expedited goal date 442 - Consensus (yes/no) 443 - Document Shepherd 444 - IANA actions required 446 "Consensus" is as used in [RFC5741]; it determines the appropriate 447 Status of This Memo text to be applied to IETF and IRTF documents. 448 The Consensus field should be set by the responsible individuals and 449 it should be listed in the Agenda Package provided before an IESG 450 telechat so that the Area Directors can quickly review the status of 451 the documents under review and correct the field if Consensus was not 452 received. 454 Additionally, the Agenda Package provided before an IESG telechat 455 should show the expiration date of the Last Call. This will be 456 helpful for the ADs and the Secretariat to track the Last Call 457 timeline. 459 When a document has been added to the RFC Editor queue (i.e., shows 460 an RFC Editor state in the Datatracker), an automated note should be 461 sent to the Secretariat as acknowledgment that the announcement has 462 been received. 464 4.2.1. Notifications 466 The Datatracker should notify the RFC Editor and the Sponsoring AD 467 when a version of an I-D has been made available after the document 468 has been approved for publication. 470 4.2.2. Datatracker Extensions for Alternate Streams 472 Once the Datatracker has been updated for the alternate streams 473 [ALT-STREAMS], the Datatracker should be updated so that the 474 following are automated: 476 - the Datatracker should not expire any I-Ds that are under ISE 477 review. 479 - the Datatracker should automatically notify the ISE when an I-D 480 that is under ISE review has been updated (i.e., a new version has 481 been made available). 483 - the Datatracker should be updated to list I-Ds according to the 484 stream that requested publication in the Agenda Package. This 485 should help provide additional clarity during IESG reviews, as 486 there will be a clear indication of from which stream a document 487 originates. 489 4.2.2.1. Publication Requests 491 "Data Tracker States and Annotations for the IAB, IRTF, and 492 Independent Submission Streams" [ALT-STREAMS] lists the requirements 493 for extending the Datatracker to account for alternate stream states 494 and annotations. In particular, the document introduces the "Sent to 495 the RFC Editor" state, which means the document is complete and has 496 been sent to the RFC Editor for publication. 498 The Datatracker will provide a means for the alternate streams to 499 generate a uniform publication request. The stream managers should 500 be able to create an email message that contains the relevant 501 information for any approved I-D, and the Datatracker will provide 502 the data (same data provided for any IETF publication request -- see 503 Section 4.2) in a machine-readable format. This data will be 504 available to the IANA and RFC Editor, so that data entry into the 505 IANA and RFC Editor systems can be automated. 507 This update will allow the IANA and RFC Editor to handle documents in 508 a similar manner, regardless of the document's stream. 510 4.3. Reporting Requirements 512 The Datatracker should have a "Show Discrepancies" feature. It 513 should show all records in the Datatracker that fit certain criteria 514 (that seem to be a discrepancy). In addition to showing data on 515 screen, it should send an email to defined interested parties at 516 regular intervals (e.g., weekly). This feature will only be 517 available to a subset of individuals (namely, IANA, RFC Editor, and 518 the Secretariat), to ensure that our queues are in sync. This will 519 be especially helpful as the Datatracker is extended (now and in the 520 future), to ensure that all parties are receviing the correct 521 messages/data. 523 An initial set of discrepancies should be defined, and additional 524 discrepancies could be defined over time. For example, the initial 525 set of discrepancies could include: 527 - Show drafts that have passed through the state "Approved 528 Announcement sent" but do not have an RFC Editor state. 530 - Show drafts that have IANA state "In Progress" but RFC Editor 531 State is not equal to "IANA" or does not contain "*A" (see 532 Appendix B). 534 - Show drafts that have IANA state "Waiting on RFC Editor" or "RFC- 535 Ed-Ack", but RFC Editor State is "IANA" or contains "*A" (See 536 Appendix B). 538 5. IANA Considerations 540 This document does not request any IANA registrations. 542 6. Security Considerations 544 This document does not propose any new Internet mechanisms, and has 545 no security implications for the Internet. 547 Appendix A. Current IANA States and Definitions 549 The currently defined IANA states are listed below. 551 * No value (blank) - A new document has been received by IANA, but 552 no actions have been taken 553 * In Progress - IANA is currently processing the actions for this 554 document 555 * Waiting on Authors - IANA is waiting on the document's authors 556 to respond 557 * Waiting on ADs - IANA is waiting on the IETF Area Directors to 558 respond 559 * Waiting on WGC - IANA is waiting on the IETF Working Group 560 Chairs to respond 561 * Waiting on RFC Editor - IANA has notified the RFC Editor that 562 the actions have been completed 563 * RFC-Ed-Ack - Request completed. The RFC Editor has acknowledged 564 receipt of IANA's message that the actions have been completed 565 * On Hold - IANA has suspended work on the document 566 * No IC - Request completed. There were no IANA actions for this 567 document 569 IANA states are defined by IANA and are subject to change. If there 570 are any discrepancies between the state names listed in this document 571 and those listed on the IANA queue page 572 (http://www.iana.org/about/performance/ietf-draft-status/), the IANA 573 queue is definitive. 575 Appendix B. Current RFC Editor States and Definitions 577 The currently defined RFC Editor Queue states are listed below. 579 * AUTH = Awaiting Author Action 580 * AUTH48 = Awaiting final author approval 581 * EDIT = Approved by the stream manager (e.g., IESG, IAB, IRSG, 582 ISE), awaiting processing and publishing 583 * IANA = RFC-Editor/IANA Registration Coordination 584 * IESG = Holding for IESG Action 585 * ISR = Independent Submission Review by the ISE 586 * ISR-AUTH = Independent Submission awaiting author update, or in 587 * discussion between author and ISE 588 * REF = Holding for normative reference (followed by I-D string of 589 * referenced document) 590 * RFC-EDITOR = Awaiting final rfc-editor review before AUTH48 591 * TO = Time-out period during which the IESG reviews document for 592 * conflict/concurrence with other IETF working group work 593 (followed by date) 594 * MISSREF = Awaiting missing normative reference. 596 RFC Editor states are defined by the RFC Editor and are subject to 597 change. If there are any discrepancies between the state names 598 listed in this document and those listed on the RFC Editor queue page 599 (http://www.rfc-editor.org/queue2.html), the RFC Editor queue is 600 definitive. 602 Currently, there are also a couple of state annotations used in RFC 603 Editor state-change emails. These do not alter the Datatracker in 604 any way, but are listed here for completeness: 606 *A = indicates that IANA actions are required 607 *R = indicates potential REFerence holds 609 Normative References 611 [IDTRACKER] "The IETF Datatracker tool", Web Application: 612 https://datatracker.ietf.org/, September 15, 613 2010. 615 [WGDOCUMENT-STATES] Juskevicius, E., "Definition of IETF Working 616 Group Document States", draft-ietf-proto- 617 wgdocument-states, October 2010. 619 [ALT-STREAMS] Hoffman, P., "Data Tracker States and Annotations 620 for the IAB, IRTF, and Independent Submission 621 Streams", draft-hoffman-alt-streams-tracker, 622 September 2010. 624 [RFC2026] Bradner, S., "The Internet Standards Process -- 625 Revision 3", BCP 9, RFC 2026, October 1996. 627 [RFC 5226] Narten, T. and H. Alvestrand, "Guidelines for 628 Writing an IANA Considerations Section in RFCs", 629 BCP 26, RFC 5226, May 2008. 631 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC 632 Streams, Headers, and Boilerplates", RFC 5741, 633 December 2009. 635 Acknowledgments 637 The authors would like to thank the following indivduals for their 638 input: 640 Amanda Baber 641 Glen Barney 642 Alice Hagens 643 Paul Hoffman 644 Russ Housley 645 Ed Juskevicius 646 Henrik Levkowetz 647 Cindy Morgan 648 Ray Pelletier 649 Amy Vezza 651 Authors' Addresses 653 Sandy Ginoza 654 Association Management Solutions 655 48377 Fremont Blvd., Suite 117 656 Fremont, CA 94538 657 United States 659 Phone: +1 (510) 492-4000 660 EMail: sginoza@amsl.com 661 URI: http://www.amsl.com/ 663 Michelle Cotton 664 Internet Corporation for Assigned Names and Numbers 665 4676 Admiralty Way, Suite 330 666 Marina del Rey, CA 90292 667 United States 669 Phone: +310-823-9358 670 EMail: michelle.cotton@icann.org 671 URI: http://www.iana.org/ 673 Alexa Morris 674 Association Management Solutions 675 48377 Fremont Blvd., Suite 117 676 Fremont, CA 94538 677 United States 679 Phone: +1 (510) 492-4000 680 EMail: amorris@amsl.com 681 URI: http://www.amsl.com/