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