diff options
Diffstat (limited to 'doc/rfc/rfc6359.txt')
| -rw-r--r-- | doc/rfc/rfc6359.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc6359.txt b/doc/rfc/rfc6359.txt new file mode 100644 index 0000000..380e180 --- /dev/null +++ b/doc/rfc/rfc6359.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Ginoza +Request for Comments: 6359 AMS +Category: Informational M. Cotton +ISSN: 2070-1721 ICANN + A. Morris + AMS + September 2011 + + + Datatracker Extensions to + Include IANA and RFC Editor Processing Information + +Abstract + + This document captures the requirements for integrating IANA and RFC + Editor state information into the Datatracker to provide the + community with a unified tool to track the status of their document + as it progresses from Internet-Draft (I-D) version -00 to RFC. + Extending the Datatracker to hold document data from I-D version -00 + to RFC allows for increased automation between the Datatracker, IANA, + and RFC Editor, thus reducing manual labor, processing errors, and + potential delay. Therefore, this document also describes the + requirements to make such automation possible. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6359. + + + + + + + + + + + + +Ginoza, et al. Informational [Page 1] + +RFC 6359 More Datatracker Updates September 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +1. Introduction + + The IETF Datatracker is a web-based system for managing information + about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison + statements, and several other important aspects of the document + process [IDTRACKER]. In this document, the term "IETF Datatracker" + is used as a generic name for the existing tool used to track state + changes as Internet-Drafts are processed. The word "IETF" in the + name "IETF Datatracker" is not meant to limit use of the tool to the + IETF document stream; this document expands use of the tool to the + other streams described in [RFC4844]. + + The Datatracker is used to report on the status of I-Ds that have + been submitted to the IESG for evaluation and publication. The + Datatracker will be extended, according to the requirements defined + in [RFC6174] and [RFC6322], to include tracking information about a + document during its progression from version -00 to it being + requested for IESG evaluation. However, the Datatracker, ICANN + (performing the IANA function), and RFC Editor operate on separate + systems with varying degrees of visibility into the processing that + takes place once the stream managers have approved a document for + + + +Ginoza, et al. Informational [Page 2] + +RFC 6359 More Datatracker Updates September 2011 + + + publication as an RFC. This document defines the requirements for + extending the Datatracker to include increased IANA and RFC Editor + state information, so that the Datatracker covers the lifetime of an + I-D from version -00 to RFC publication. + + Additionally, this document lists the processes between the IANA, RFC + Editor, and Secretariat (via the Datatracker) that should be + automated for accuracy and timely processing. While this document + includes some details of the IANA, RFC Editor, and Secretariat + process, this document does not define any of the processes. The + processes are continually reviewed for process optimization and need + to remain flexible to adapt to new changes in policy and environment. + Processes are defined and set by each of the entities respectively. + + The IANA and RFC Editor are functions independent of the IETF. When + an Internet-Draft enters the IANA queue, IANA retains ownership of + its own data, state names, and tracking systems. Similarly, when an + Internet-Draft enters the RFC Editor's queue, the RFC Editor retains + ownership of its own data, state names, and tracking systems. This + document discusses how the data from the IANA and RFC Editor queues + can be better reflected in the Datatracker to help inform the IETF + community what the state of a document is throughout its lifetime. + + Prior to when an Internet-Draft is approved for publication as an + RFC, the Datatracker is the definitive source for tracking IANA + status information, and the IANA data is editable (by IANA and the + Secretariat) in the Datatracker. After an Internet-Draft is approved + for publication as an RFC, the IANA tracking system becomes the + definitive source for tracking IANA status information, and the data + can no longer be edited in the Datatracker. At that point, the data + in the Datatracker is only a reflection of the data in the IANA + tracking system. If there is a discrepancy between the two after + this point, the data in the IANA tracking system is assumed to be + correct. + + The RFC Editor's tracking system is always the definitive source for + tracking the RFC Editor status of a document. RFC Editor data is not + editable via the Datatracker. The information in the Datatracker is + always a reflection of the information in the RFC Editor's tracking + system. + +2. Integration of Data between the IANA and Datatracker + +2.1. IANA Information to Be Added to the Datatracker + + Currently, IANA reviews and touches IETF stream documents at 4 + different stages in the process from I-D to RFC: IETF Last Call, IESG + Review, Document Approval (for publication), and RFC Publication. + + + +Ginoza, et al. Informational [Page 3] + +RFC 6359 More Datatracker Updates September 2011 + + + Most of these state changes and issues are not captured in the + Datatracker. For the IRTF (Internet Research Task Force) and + Independent streams, the IANA review process begins when IESG Review + is requested. For the IAB (Internet Architecture Board) stream, + review would begin upon request for publication as an RFC. + + This section specifies the requirements for including additional IANA + information in the Datatracker. + + - IETF Last Call Comments + + Currently, IANA reviews I-Ds that have been sent to IETF Last + Call, inputs comments in their data system, and then emails their + comments to authors, WG chairs, and then to the IESG. These + comments are also manually entered into the Datatracker for the + public record. However, it is difficult to determine whether the + IANA issues have been resolved. To help facilitate tracking of + IANA issues, a display is needed to show 5 new IANA substates, in + a similar fashion to how RFC Editor State is currently shown in + the Datatracker (see the example, later in this section, of how + IANA state information could appear in the Datatracker for + draft-example-00). + + 1) IANA Review Needed + + This substate will allow the community, Secretariat, and IANA + to easily track which documents have or have not been reviewed + by IANA. If this substate is NOT set to "IANA Not OK", "IANA + OK -- Actions Needed", or "IANA OK -- No Actions Needed", the + substate should be set to "IANA Review Needed" by default (this + is the first substate for tracking IANA data). For documents + that originate from a non-IETF stream, the default will be + used. + + 2) IANA OK -- Actions Needed + + This substate covers documents that require IANA actions, and + the IANA Considerations section indicates the details of the + actions correctly. + + 3) IANA OK -- No Actions Needed + + This substate covers documents that require no IANA actions, + and the IANA Considerations section indicates this correctly. + + + + + + + +Ginoza, et al. Informational [Page 4] + +RFC 6359 More Datatracker Updates September 2011 + + + Note: The substate will be set to "IANA OK -- Action Needed" or + "IANA OK -- No Actions Needed" (from "IANA Not OK") once any + outstanding issues have been resolved. The comments section will + be used to provide details in the History log about whether there + are no IANA actions, the text is OK, or the issues have been + resolved. + + 4) IANA Not OK + + If IANA has issues with the text of the IANA Considerations + section of a document, the substate should be set to "IANA Not + OK", and the comment field should be populated with a + description of the issues and questions. In addition to any + questions IANA may have, IANA will also include in the comments + field whether expert review is required, if the document is + dependent on another document (e.g., document B registers + values in a registry created by document A, which hasn't been + published yet), and if there is a registry expert appointment + required. + + 5) Version Changed -- Review Needed + + This substate will allow the community, Secretariat, and IANA + to easily track which documents have been reviewed and + subsequently when a version of an Internet-Draft in Last Call + has changed, therefore requiring a second review of the + document by IANA to ensure that either the IANA considerations + have not changed, or any changes made to the document affecting + IANA actions are clear. This substate applies to I-Ds that are + in any substate except "IANA Review Needed" and "Version + Changed -- Review Needed". + + When new versions are available, the Datatracker will + automatically set the IANA substate to "Version Changed -- + Review Needed". + + Information providing the status of the IANA review (one of the 5 + substates listed above) should be included as part of the evaluation + message (sent to the IESG) so that IANA can determine if, and what, + further action is required. + + All comments will be recorded in the History log. However, to reduce + redundancy and manual effort, the Datatracker should provide the + ability to receive state information and related comments from the + IANA tracking system. There should be a notification that comments + have been entered in the IANA-maintained system, and entry of those + comments into the Datatracker and distribution of those comments to + the authors should be automated. + + + +Ginoza, et al. Informational [Page 5] + +RFC 6359 More Datatracker Updates September 2011 + + + - IESG Evaluation + + As not all documents receive an IETF Last Call, this state is + sometimes the first time that IANA reviews a document. For a + document that wasn't IETF Last Called, IANA reviews the document, + enters comments in their own tracking system, distributes email to + authors and other interested parties (e.g., WG chairs, ISE + (Independent Submissions Editor)), and then enters those same + comments into the Datatracker, where they are recorded in the + History log. In cases where a document was IETF Last Called, IANA + checks for and reviews version changes and re-reviews documents to + ensure that any identified IANA issues have been resolved. + + Comments will continue to be recorded in the History log. + However, to reduce redundancy and manual effort, the Datatracker + should provide the ability for IANA to enter substate information + and related comments into the IANA tracking system, and + distribution of those comments to the authors and entry into the + Datatracker should be automated. + + Ideally, the authors will have responded to and resolved any IANA + issues prior to the document being slated for an IESG telechat. + However, if any document continues to have an "IANA Not OK", + "Version Changed -- Review Needed", or "IANA Review Needed" + substate and is slated for the IESG telechat, it should be called + out in the Agenda Package. For example, it could appear as + follows: + + o draft-example-00 + Title of Internet-Draft + Note: John Doe (jdoe@example.com) is the document shepherd. + Token: Jane Doe + IANA: IANA Not OK + + This will ensure that IANA and the Area Directors (ADs) are aware + that there are still IANA issues to be addressed prior to + publication, or that initial or follow-up IANA review is required + and not yet completed (in cases where the substate is listed as + "IANA Review Needed" or "Version Changed -- Review Needed"). + + + + + + + + + + + + +Ginoza, et al. Informational [Page 6] + +RFC 6359 More Datatracker Updates September 2011 + + + - Document Approved for Publication + + Once a document has been approved for publication, the document + enters the IANA queue and is tracked using IANA-defined states. + This state information is not currently available via the + Datatracker. In order for the community to view the IANA + processing states without being redirected to the IANA queue, the + Datatracker should be extended to include IANA state information + as defined by IANA. For example, IANA state information could + appear in the metadata portion of the document as follows: + + Document type: Active Internet-Draft (FOO WG document) + Last updated: 2010-09-20 + State: RFC Ed Queue + RFC Editor State: EDIT IANA + IANA State: In Progress + Intended status: Proposed Standard + + IANA state-change information will link to the IANA queue, and + will be captured as a line item in the History log. IANA will + notify the Datatracker when changes are made in the IANA queue. + + Once the IANA actions have been completed, the Datatracker History + log will be updated to include the actions completed by IANA + (i.e., the author-approved actions). This information will + include the same information that is sent to the RFC Editor upon + completion of IANA actions. + + The IANA State field may be any of the states defined by IANA. + The list of IANA state names in use at the time this document was + published is provided in Appendix A; however, IANA states are + defined by IANA and are subject to change. If there are any + discrepancies between the state names listed in this document and + those listed on the IANA queue page + (http://www.iana.org/about/performance/ietf-draft-status/), the + IANA queue is definitive. States may be added or removed by IANA; + IANA will work with the IETF Administrative Oversight Committee + (IAOC) to update the Datatracker as necessary. + + - RFC Publication + + References to the I-D are updated to refer to the RFC once it is + published, and minor updates may be made to match the published + RFC. This data will be tracked in the Datatracker to show when + the references in the IANA registries were updated to include the + newly assigned RFC number. + + + + + +Ginoza, et al. Informational [Page 7] + +RFC 6359 More Datatracker Updates September 2011 + + +2.2. Future IANA Information to Be Available via the Datatracker + + The document "Definition of IETF Working Group Document States" + [RFC6174] includes the following: + + 4.3.1. Awaiting Expert Review/Resolution of Issues Raised + + This tag means that someone (e.g., an author or editor of the + WG draft, or a WG Chair) has initiated an expert review of the + document and the review has not yet been completed and/or the + resolution of issues raised by the review has not yet been + completed. Examples of expert reviews include cross-area + reviews, MIB Doctor reviews, security expert reviews, and IANA + reviews. + + WG drafts tagged with this annotation should retain the tag + until the review is complete and possibly until any issues + raised in the review are addressed. + + IANA is in the process of documenting how an expert review is + conducted during the lifetime of an Internet-Draft. Once the process + has been defined, the Datatracker should be updated to indicate if a + document requires "Expert Review" [RFC5226] (either for the entire + document or a portion thereof); if the expert reviewer has issues + with what they are being requested to review; and, if applicable, + whether the expert reviewer has approved or rejected the requested + registration(s). There may be a need to complete expert reviews + again before publication of a document if there have been changes to + the text relevant to the review by the expert. In cases where a new + registry is being created in the document, an indicator of whether an + expert needs to be appointed by the IESG would also be useful. + +2.3. Permissions to Change IANA State Information + + IANA state changes should be automated, but IANA should have the + ability to log in to the Datatracker to manually update the system as + well. + + The IETF Secretariat should also have the ability to change the IANA + state if necessary. + + It is expected that this feature would only be used to correct + issues; it is not intended to be part of regular operations. + + + + + + + + +Ginoza, et al. Informational [Page 8] + +RFC 6359 More Datatracker Updates September 2011 + + +3. Integration of Data between the RFC Editor and Datatracker + + For quite some time, the RFC Editor was seen as a black box, where + documents were submitted for publication, went through some process, + and came out as RFCs. Over time, the community asked for a more + transparent process; thus, state information was made available on + the RFC Editor website. Currently, some of that state information is + available from the Datatracker. However, for additional transparency + about the RFC Editor process, the Datatracker should be extended to + hold supplementary RFC Editor state and process (e.g., MISSREF) + information. This section defines the requirements for RFC Editor + state information to be added to the Datatracker to provide more + transparency and allow for a unified end-to-end tracking system. + +3.1. RFC Editor Information to Be Added to the Datatracker + + Once a document has been approved for publication, the document + enters the RFC Editor queue and is tracked using RFC-Editor-defined + states. Some RFC Editor state information is currently available via + the Datatracker, but the information is not stored in the History + log. RFC-Editor-defined state information will continue to be shown + as is done currently. In addition, a line item will be entered into + the History log each time a document changes state. The RFC Editor + shall continue to provide a queue file to allow data extraction; in + addition, there will be a machine-readable notification to the + Datatracker when state changes are made. + + RFC Editor state information should continue to appear in the + metadata portion of the document available using the Datatracker. + For example, an entry might appear as follows (including the IANA + State information): + + Document type: Active Internet-Draft (TLS WG document) + Last updated: 2010-09-20 + State: RFC Ed Queue + RFC Editor State: EDIT IANA + IANA State: In Progress + Intended status: Proposed Standard + + The RFC Editor State field may be any of the states defined by the + RFC Editor. The list of RFC Editor state names in use at the time + this document was published is provided in Appendix B, but RFC Editor + states are defined by the RFC Editor and are subject to change. If + there are any discrepancies between the state names listed in this + + + + + + + +Ginoza, et al. Informational [Page 9] + +RFC 6359 More Datatracker Updates September 2011 + + + document and those listed on the RFC Editor queue page + (http://www.rfc-editor.org/queue2.html), the RFC Editor queue is + definitive. States may be added or removed by the RFC Editor; the + RFC Editor will work with the IAOC to update the Datatracker as + necessary. + + Although RFC Editor state information is already available in the + Datatracker, the Datatracker should be updated to include some + additional data that may help individuals understand the status of + their document. In particular, the Datatracker should be updated to + include the following data: + + 1) links to AUTH48 pages + + AUTH48 pages provide information about which authors have approved + the document for publication, whether AD approval is required, and + sometimes a summary of issues that need to be resolved before the + document can move forward. + + 2) links to the cluster pages + + Clusters are defined as documents with normative reference + dependencies, and documents that have been requested for + simultaneous publication. (For more information, see + http://www.rfc-editor.org/cluster_def.html.) The cluster pages + provide a view of the entire set of state information for + clustered documents. + + Note: The RFC Editor has been working with the cluster data to + provide the community with accurate state information at the + appropriate level of detail. The RFC Editor database may require + significant updates before this data can be integrated with the + Datatracker. + + 3) RFC metadata upon publication + + The RFC Editor will notify the Datatracker when a new RFC has been + published, and the Datatracker should have the ability to + automatically update the relevant fields with data related to the + published RFC. In particular, the RFC number will be recorded in + the Datatracker. However, note that all fields are subject to + change during editing and should be updated; for example, the + document title and the list of authors are sometimes changed, and + character counts and page counts are always changed. + + + + + + + +Ginoza, et al. Informational [Page 10] + +RFC 6359 More Datatracker Updates September 2011 + + + 4) notation when documents are withdrawn from the RFC Editor queue + + If a document is to be removed from the RFC Editor / IANA queues, + the responsible party (e.g., AD or Secretariat) should change the + state of the document in the Datatracker to something other than + "RFC Ed Queue". The Datatracker should provide a text box to + allow the responsible party to record details about the state + change. The state change and the related details will be recorded + in the History log. The state change in the Datatracker will + trigger an email message to the RFC Editor and IANA as + notification that the state of the document has been set to the + newly assigned state, with the details provided in the text box. + The RFC Editor and IANA will update their queues accordingly, and + the document will disappear from their respective queues. + +4. Other Updates to the Datatracker + + While the primary goal of this document is to update the Datatracker + to display the IANA and RFC Editor process state information, the + Datatracker could hold additional data for use by IANA and the RFC + Editor that would allow for increased automation, thus reducing the + potential for delays and processing errors. This section defines + requirements for updates to the Datatracker to eliminate some of the + administrative tasks currently performed by staff. + +4.1. Datatracker to IANA + + When a document is approved for publication, data will be provided in + a machine-readable format and will include (in addition to the usual + Document/Protocol Action emails) the data requested by the RFC Editor + in Section 4.2. + +4.2. Datatracker to RFC Editor + + When a document is approved for publication, data will be provided in + a machine-readable format and will include the following (in addition + to the usual Document/Protocol Action emails): + + - I-D String + + - Document Title + + - Author List + + - Author Email Addresses + + - Author Organizations (if available) + + + + +Ginoza, et al. Informational [Page 11] + +RFC 6359 More Datatracker Updates September 2011 + + + - Expedited Goal Date (if applicable) + + Note: This field needs to be editable for post-approval + changes. + + - Publication Status (as defined in [RFC2026]) + + - Consensus (yes/no) + + - Source (Working Group or Research Group name, Individual, + or alternate-stream name) + + Note: The RFC Editor database may require updates before + Research Group data can be received from the Datatracker. + + - IESG Contact + + - Document Shepherd <email> + + Note: This is the individual currently listed in the + "Personnel" section of a Document/Protocol Action. + + - IANA Actions Required + + Most of these items are already stored in the Datatracker. However, + the following fields need to be added: + + - Expedited Goal Date + + - Consensus (yes/no) + + - Document Shepherd <email> + + - IANA Actions Required + + "Consensus" is as used in [RFC5741]; it determines the appropriate + Status of This Memo text to be applied to IETF and IRTF documents. + The Consensus field should be set by the responsible individuals, and + it should be listed in the Agenda Package provided before an IESG + telechat so that the Area Directors can quickly review the status of + the documents under review and correct the field if Consensus was not + received. + + Additionally, the Agenda Package provided before an IESG telechat + should show the expiration date of the IETF Last Call. This will be + helpful for the ADs and the Secretariat to track the IETF Last Call + timeline. + + + + +Ginoza, et al. Informational [Page 12] + +RFC 6359 More Datatracker Updates September 2011 + + + When a document has been added to the RFC Editor queue (i.e., shows + an RFC Editor state in the Datatracker), an automated note should be + sent to the Secretariat as acknowledgment that the announcement has + been received. + +4.2.1. Notifications + + The Datatracker should notify the RFC Editor and the Sponsoring AD + when a version of an I-D has been made available after the document + has been approved for publication. + + Additionally, the Datatracker should notify the RFC Editor and IANA + when the state of an I-D has been moved to something other than "RFC + Ed Queue" or "RFC Published" -- that is, when it should be removed + from the RFC Editor and IANA processing queues. See item 4) in + Section 3.1 for more details. + +4.2.2. Datatracker Extensions for Alternate Streams + + Once the Datatracker has been updated for the alternate streams + [RFC6322], the Datatracker should be updated so that the following + are automated: + + - The Datatracker should not expire any I-Ds that are under review + for publication. + + - The Datatracker should automatically notify the approving body + when an I-D that is under review has been updated (i.e., a new + version has been made available). + + - The Datatracker should be updated so that the Agenda package lists + I-Ds according to the stream that requested publication. This + should help provide additional clarity during IESG Reviews, as + there will be a clear indication of from which stream a document + originates. + +4.2.2.1. Publication Requests + + RFC 6322 [RFC6322] lists the requirements for extending the + Datatracker to account for alternate-stream states and annotations. + In particular, the document introduces the "Sent to the RFC Editor" + state, which means the document is complete and has been sent to the + RFC Editor for publication. + + The Datatracker will provide a means for the alternate streams to + generate a uniform publication request. Using the Datatracker, the + stream managers should be able to generate a publication request that + contains the relevant information for any approved I-D. + + + +Ginoza, et al. Informational [Page 13] + +RFC 6359 More Datatracker Updates September 2011 + + + Additionally, the Datatracker will provide the data (the same data + provided for any IETF publication request -- see Section 4.2) in a + machine-readable format. This data will be available to the IANA and + RFC Editor, so that data entry into the IANA and RFC Editor systems + can be automated. + + This update will allow the IANA and RFC Editor to handle documents in + a similar manner, regardless of the document's stream. + +4.3. Reporting Requirements + + The Datatracker should have a "Show Discrepancies" feature. It + should show all records in the Datatracker that fit certain criteria + (that seem to be a discrepancy). In addition to showing data on + screen, it should send an email to defined interested parties at + regular intervals (e.g., weekly). This feature will only be + available to a subset of individuals (namely, IANA, RFC Editor, and + the Secretariat), to ensure that their queues are in sync. This will + be especially helpful as the Datatracker is extended (now and in the + future), to ensure that all parties are receiving the correct + messages/data. + + An initial set of discrepancies should be defined, and additional + discrepancies could be defined over time. For example, the initial + set of discrepancies could include the following: + + - Show drafts that have passed through the state "Approved + Announcement sent" but do not have an RFC Editor state. + + - Show drafts that have IANA state "In Progress", but RFC Editor + State is not equal to "IANA" or does not contain "*A" (see + Appendix B). + + - Show drafts that have IANA state "Waiting on RFC Editor" or + "RFC-Ed-Ack", but RFC Editor State is "IANA" or contains "*A" + (see Appendix B). + + - Show drafts that have a state of something other than "RFC Ed + Queue" or "RFC Published" that are listed in the RFC Editor or + IANA queues. + +5. Security Considerations + + This document does not propose any new Internet mechanisms, and has + no security implications for the Internet. + + + + + + +Ginoza, et al. Informational [Page 14] + +RFC 6359 More Datatracker Updates September 2011 + + +Appendix A. Current IANA States and Definitions + + The currently defined IANA states are listed below. + + * No value (blank) - A new document has been received by IANA, but + no actions have been taken + + * In Progress - IANA is currently processing the actions for this + document + + * Waiting on Authors - IANA is waiting on the document's authors + to respond + + * Waiting on ADs - IANA is waiting on the IETF Area Directors to + respond + + * Waiting on WGC - IANA is waiting on the IETF Working Group + Chairs to respond + + * Waiting on RFC Editor - IANA has notified the RFC Editor that + the actions have been completed + + * RFC-Ed-Ack - Request completed. The RFC Editor has acknowledged + receipt of IANA's message that the actions have been completed + + * On Hold - IANA has suspended work on the document + + * No IC - Request completed. There were no IANA actions for this + document + + IANA states are defined by IANA and are subject to change. If there + are any discrepancies between the state names listed in this document + and those listed on the IANA queue page + (http://www.iana.org/about/performance/ietf-draft-status/), the IANA + queue is definitive. + + + + + + + + + + + + + + + + +Ginoza, et al. Informational [Page 15] + +RFC 6359 More Datatracker Updates September 2011 + + +Appendix B. Current RFC Editor States and Definitions + + The currently defined RFC Editor Queue states are listed below. + + * AUTH = Awaiting Author Action + + * AUTH48 = Awaiting final author approval + + * EDIT = Approved by the stream manager (e.g., IESG, IAB, IRSG, + ISE), awaiting processing and publishing + + * IANA = RFC-Editor/IANA Registration Coordination + + * IESG = Holding for IESG Action + + * ISR = Independent Submission Review by the ISE + + * ISR-AUTH = Independent Submission awaiting author update, or in + discussion between author and ISE + + * REF = Holding for normative reference (followed by I-D string of + referenced document) + + * RFC-EDITOR = Awaiting final rfc-editor review before AUTH48 + + * TO = Time-out period during which the IESG reviews document for + conflict/concurrence with other IETF working group work + (followed by date) + + * MISSREF = Awaiting missing normative reference + + RFC Editor states are defined by the RFC Editor and are subject to + change. If there are any discrepancies between the state names + listed in this document and those listed on the RFC Editor queue page + (http://www.rfc-editor.org/queue2.html), the RFC Editor queue is + definitive. + + Currently, there are also a couple of state annotations used in RFC + Editor state-change emails. These do not alter the Datatracker in + any way, but are listed here for completeness: + + *A = indicates that IANA actions are required + *R = indicates potential REFerence holds + + + + + + + + +Ginoza, et al. Informational [Page 16] + +RFC 6359 More Datatracker Updates September 2011 + + +Normative References + + [IDTRACKER] "The IETF Datatracker tool", Web Application: + https://datatracker.ietf.org/, August 26, 2011. + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The + RFC Series and RFC Editor", RFC 4844, July 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, + Headers, and Boilerplates", RFC 5741, December 2009. + + [RFC6174] Juskevicius, E., "Definition of IETF Working Group + Document States", RFC 6174, March 2011. + + [RFC6322] Hoffman, P., "Datatracker States and Annotations for the + IAB, IRTF, and Independent Submission Streams", RFC 6322, + July 2011. + +Acknowledgments + + The authors would like to thank the following individuals for their + input: + + Amanda Baber + Glen Barney + Adrian Farrel + Alice Hagens + Paul Hoffman + Russ Housley + Ed Juskevicius + Henrik Levkowetz + Cindy Morgan + Ray Pelletier + Peter Saint-Andre + Robert Sparks + Amy Vezza + + + + + + + + +Ginoza, et al. Informational [Page 17] + +RFC 6359 More Datatracker Updates September 2011 + + +Authors' Addresses + + Sandy Ginoza + Association Management Solutions + 48377 Fremont Blvd., Suite 117 + Fremont, CA 94538 + United States + + Phone: +1 (510) 492-4000 + EMail: sginoza@amsl.com + URI: http://www.amsl.com/ + + + Michelle Cotton + Internet Corporation for Assigned Names and Numbers + 4676 Admiralty Way, Suite 330 + Marina del Rey, CA 90292 + United States + + Phone: +310-823-9358 + EMail: michelle.cotton@icann.org + URI: http://www.iana.org/ + + + Alexa Morris + Association Management Solutions + 48377 Fremont Blvd., Suite 117 + Fremont, CA 94538 + United States + + Phone: +1 (510) 492-4000 + EMail: amorris@amsl.com + URI: http://www.amsl.com/ + + + + + + + + + + + + + + + + + + +Ginoza, et al. Informational [Page 18] + |