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