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
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
Datatracker扩展，包括IANA和RFC编辑器处理信息
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.
本文档捕获了将IANA和RFC编辑器状态信息集成到Datatracker中的要求，以便为社区提供一个统一的工具，在文档从Internet草稿（I-D）版本-00发展到RFC时跟踪其状态。扩展Datatracker以保存从I-D版本-00到RFC的文档数据，可以提高Datatracker、IANA和RFC编辑器之间的自动化程度，从而减少人工、处理错误和潜在延迟。因此，本文件还描述了实现此类自动化的要求。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6359.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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].
IETF数据跟踪器是一个基于网络的系统，用于管理有关互联网草稿（I-D）和RFC、知识产权披露、联络声明以及文件过程的其他几个重要方面的信息[IDTRACKER]。在本文件中，术语“IETF数据跟踪器”用作现有工具的通用名称，该工具用于在处理互联网草稿时跟踪状态变化。“IETF数据跟踪器”名称中的“IETF”一词并不意味着将工具的使用限制在IETF文档流中；本文档将该工具的使用扩展到[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
Datatracker用于报告已提交给IESG进行评估和发布的I-D的状态。数据跟踪器将根据[RFC6174]和[RFC6322]中定义的要求进行扩展，以包括从版本-00到IESG评估所需的文档的跟踪信息。但是，数据跟踪器、ICANN（执行IANA功能）和RFC编辑器在单独的系统上运行，在流管理器批准文件后，可以不同程度地了解处理过程
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.
以RFC形式发布。本文档定义了扩展Datatracker以包括增加的IANA和RFC编辑器状态信息的要求，以便Datatracker涵盖从版本-00到RFC发布的I-D的生命周期。
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.
此外，本文件还列出了IANA、RFC编辑器和秘书处（通过数据跟踪器）之间的流程，这些流程应实现自动化，以确保准确性和及时处理。虽然本文件包含IANA、RFC编辑器和秘书处流程的一些细节，但本文件并未定义任何流程。不断审查流程以优化流程，并需要保持灵活性以适应政策和环境的新变化。流程由每个实体分别定义和设置。
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.
IANA和RFC编辑器是独立于IETF的功能。当互联网草稿进入IANA队列时，IANA保留其自身数据、州名称和跟踪系统的所有权。类似地，当Internet草稿进入RFC编辑器队列时，RFC编辑器保留其自己的数据、状态名称和跟踪系统的所有权。本文档讨论了IANA和RFC编辑器队列中的数据如何更好地反映在Datatracker中，以帮助IETF社区了解文档在整个生命周期中的状态。
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.
在互联网草案被批准作为RFC发布之前，Datatracker是跟踪IANA状态信息的最终来源，IANA数据在Datatracker中是可编辑的（由IANA和秘书处）。在互联网草案被批准作为RFC发布后，IANA跟踪系统成为跟踪IANA状态信息的最终来源，并且数据不能再在Datatracker中编辑。此时，Datatracker中的数据只是IANA跟踪系统中数据的反映。如果在这一点之后两者之间存在差异，则假定IANA跟踪系统中的数据是正确的。
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.
RFC编辑器的跟踪系统始终是跟踪文档RFC编辑器状态的最终来源。RFC编辑器数据不能通过Datatracker进行编辑。Datatracker中的信息始终是RFC编辑器跟踪系统中信息的反映。
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.
目前，IANA在从I-D到RFC的过程中的4个不同阶段审查和接触IETF流文件：IETF最后一次调用、IESG审查、文件批准（用于发布）和RFC发布。
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.
大多数这些状态更改和问题都不会在Datatracker中捕获。对于IRTF（互联网研究任务组）和独立流，IANA审查过程在请求IESG审查时开始。对于IAB（互联网体系结构委员会）流，审查将在要求作为RFC发布时开始。
This section specifies the requirements for including additional IANA information in the Datatracker.
本节规定了在Datatracker中包含其他IANA信息的要求。
- IETF Last Call Comments
- IETF最后通话评论
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).
目前，IANA审查上一次发送给IETF的I-D，在其数据系统中输入评论，然后通过电子邮件将其评论发送给作者、工作组主席，然后发送给IESG。这些注释也会手动输入到Datatracker中以供公共记录。然而，很难确定IANA问题是否已得到解决。为了帮助跟踪IANA问题，需要显示5个新的IANA子状态，显示方式与数据跟踪器中当前显示RFC编辑器状态的方式类似（请参见本节后面关于IANA状态信息如何显示在draft-example-00数据跟踪器中的示例）。
1) IANA Review Needed
1) 需要IANA审查
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.
此子状态将允许社区、秘书处和IANA轻松跟踪哪些文件已经或没有经过IANA审查。如果此子状态未设置为“IANA NOT OK”、“IANA OK—需要操作”或“IANA OK—无需操作”，则默认情况下，该子状态应设置为“IANA Review Required”（这是跟踪IANA数据的第一个子状态）。对于源自非IETF流的文档，将使用默认值。
2) IANA OK -- Actions Needed
2) IANA好的--需要采取行动
This substate covers documents that require IANA actions, and the IANA Considerations section indicates the details of the actions correctly.
此子状态包含需要IANA操作的文档，IANA注意事项部分正确指示操作的详细信息。
3) IANA OK -- No Actions Needed
3) 伊安娜：好的，不需要采取任何行动
This substate covers documents that require no IANA actions, and the IANA Considerations section indicates this correctly.
此子状态包含不需要IANA操作的文档，IANA注意事项部分正确指出了这一点。
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.
注意：一旦任何未决问题得到解决，子状态将设置为“IANA OK——需要采取的行动”或“IANA OK——不需要采取的行动”（来自“IANA Not OK”）。注释部分将用于在历史日志中提供有关是否没有IANA操作、文本是否正常或问题是否已解决的详细信息。
4) IANA Not OK
4) 伊安娜不好
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.
如果IANA对文档的IANA注意事项部分的文本有问题，则子状态应设置为“IANA Not OK”，并且注释字段应填充问题和问题的说明。除了IANA可能提出的任何问题外，IANA还将在评论字段中包括是否需要专家审查，如果文件依赖于另一个文件（例如，文件B在文件a创建的注册表中注册了值，该注册表尚未发布），以及是否需要注册专家任命。
5) Version Changed -- Review Needed
5) 版本已更改--需要检查
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".
该子状态将使社区、秘书处和IANA能够轻松跟踪哪些文件已经过审查，以及最后一次通话中互联网草案的版本何时发生变化，因此需要IANA对该文件进行第二次审查，以确保IANA的考虑因素没有改变，或者对影响IANA行动的文件所做的任何更改都是明确的。此子状态适用于除“需要IANA审查”和“版本更改--需要审查”之外的任何子状态中的I-D。
When new versions are available, the Datatracker will automatically set the IANA substate to "Version Changed -- Review Needed".
当新版本可用时，Datatracker将自动将IANA子状态设置为“版本已更改--需要查看”。
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.
提供IANA审查状态的信息（上面列出的5个子状态之一）应作为评估信息的一部分（发送给IESG），以便IANA能够确定是否需要采取进一步行动，以及需要采取什么行动。
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.
所有评论都将记录在历史日志中。然而，为了减少冗余和手动操作，Datatracker应该能够从IANA跟踪系统接收状态信息和相关评论。应通知IANA维护的系统中已经输入了评论，并且应自动将这些评论输入数据跟踪器，并将这些评论分发给作者。
- IESG Evaluation
- IESG评估
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.
由于并非所有文档都会收到IETF最后一次调用，因此这种状态有时是IANA第一次审查文档。对于上次未调用IETF的文件，IANA审查该文件，在其自己的跟踪系统中输入评论，向作者和其他相关方（如工作组主席、ISE（独立提交编辑器））发送电子邮件，然后将这些评论输入数据跟踪器，记录在历史日志中。在文件最后一次被IETF调用的情况下，IANA检查和审查版本更改，并重新审查文件，以确保任何已确定的IANA问题已得到解决。
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.
注释将继续记录在历史日志中。然而，为了减少冗余和手动操作，Datatracker应提供IANA将子状态信息和相关注释输入IANA跟踪系统的能力，并应自动将这些注释分发给作者和输入Datatracker。
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:
理想情况下，作者应在将文件提交IESG telechat之前回应并解决任何IANA问题。但是，如果任何文件仍然有“IANA不正常”、“版本更改——需要审查”或“IANA审查需要”子状态，并且计划用于IESG Telecohat，则应在议程包中列出。例如，它可以显示如下：
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
o 草稿-example-00互联网草稿标题注释：John Doe(jdoe@example.com)是文件管理员。令牌：Jane Doe IANA:IANA不好
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").
这将确保IANA和区域总监（ADs）知道在发布之前仍有IANA问题需要解决，或者需要进行初始或后续IANA审查，但尚未完成（如果子状态被列为“需要IANA审查”或“版本更改-需要审查”）。
- 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:
批准发布文档后，文档将进入IANA队列，并使用IANA定义的状态进行跟踪。此状态信息当前无法通过Datatracker获得。为了让社区在不重定向到IANA队列的情况下查看IANA处理状态，应扩展Datatracker以包括IANA定义的IANA状态信息。例如，IANA状态信息可能出现在文档的元数据部分，如下所示：
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
文件类型：现行互联网草案（FOO WG文件）最后更新日期：2010-09-20状态：RFC Ed队列RFC编辑器状态：编辑IANA IANA状态：进行中预期状态：拟定标准
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.
IANA状态更改信息将链接到IANA队列，并将作为行项目记录在历史日志中。当IANA队列中发生更改时，IANA将通知Datatracker。
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.
IANA操作完成后，Datatracker历史日志将更新，以包括IANA完成的操作（即作者批准的操作）。该信息将包括完成IANA操作后发送给RFC编辑器的相同信息。
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.
IANA状态字段可以是IANA定义的任何状态。本文件发布时使用的IANA州名称清单见附录A；但是，IANA州由IANA定义，可能会发生变化。如果本文件中列出的州名称与IANA队列页面中列出的州名称之间存在任何差异(http://www.iana.org/about/performance/ietf-draft-status/)，IANA队列是确定的。IANA可以添加或删除状态；IANA将与IETF管理监督委员会（IAOC）合作，根据需要更新数据跟踪器。
- RFC Publication
- RFC出版物
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.
一旦发布，对I-D的引用将更新为对RFC的引用，并且可能会进行较小的更新以匹配发布的RFC。该数据将在Datatracker中跟踪，以显示IANA注册中的参考何时更新，以包括新分配的RFC编号。
The document "Definition of IETF Working Group Document States" [RFC6174] includes the following:
“IETF工作组文件定义”文件[RFC6174]包括以下内容：
4.3.1. Awaiting Expert Review/Resolution of Issues Raised
4.3.1. 等待专家审查/解决提出的问题
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.
此标签表示有人（例如，工作组草案的作者或编辑，或工作组主席）已开始对文件进行专家评审，且评审尚未完成和/或评审提出的问题的解决尚未完成。专家评审的示例包括跨领域评审、MIB医生评审、安全专家评审和IANA评审。
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.
IANA正在记录互联网草案有效期内如何进行专家评审。一旦定义了流程，应更新数据跟踪器，以表明文件是否需要“专家审查”[RFC5226]（整个文件或其中的一部分）；如果专家评审员对他们被要求评审的内容有疑问；以及，如果适用，专家评审员是否批准或拒绝了所要求的注册。如果与专家审查相关的文本发生了变化，则可能需要在文件发布之前再次完成专家审查。在文件中建立新登记处的情况下，一项关于专家是否需要由IESG任命的指标也很有用。
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.
IANA状态更改应该是自动化的，但IANA应该能够登录到Datatracker以手动更新系统。
The IETF Secretariat should also have the ability to change the IANA state if necessary.
如有必要，IETF秘书处还应有能力更改IANA状态。
It is expected that this feature would only be used to correct issues; it is not intended to be part of regular operations.
预计此功能仅用于纠正问题；它不打算成为常规操作的一部分。
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.
在相当长的一段时间里，RFC编辑器被视为一个黑匣子，文档被提交以供发布，经过一些过程，最终成为RFC。随着时间的推移，社区要求一个更透明的过程；因此，在RFC编辑网站上提供了州信息。目前，一些状态信息可从Datatracker获得。但是，为了增加RFC编辑器过程的透明度，应扩展Datatracker以保存补充的RFC编辑器状态和过程（例如，MISSREF）信息。本节定义了将RFC编辑器状态信息添加到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编辑器队列，并使用RFC编辑器定义的状态进行跟踪。某些RFC编辑器状态信息当前可通过Datatracker获得，但该信息未存储在历史日志中。RFC编辑器定义的状态信息将继续显示，与当前一样。此外，每次文档更改状态时，都会在历史记录日志中输入一个行项目。RFC编辑器应继续提供队列文件，以允许数据提取；此外，当状态发生更改时，将向Datatracker发出机器可读的通知。
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):
RFC编辑器状态信息应继续显示在使用Datatracker提供的文档的元数据部分中。例如，条目可能如下所示（包括IANA状态信息）：
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
文件类型：现行互联网草案（TLS WG文件）最后更新日期：2010-09-20状态：RFC Ed队列RFC编辑器状态：编辑IANA IANA状态：进行中预期状态：拟定标准
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
RFC编辑器状态字段可以是RFC编辑器定义的任何状态。本文件发布时使用的RFC编辑器状态名称列表见附录B，但RFC编辑器状态由RFC编辑器定义，可能会发生更改。如果本文件中列出的州名称之间存在任何差异
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.
文档和RFC编辑器队列页面上列出的文档(http://www.rfc-editor.org/queue2.html)，RFC编辑器队列是确定的。RFC编辑器可以添加或删除状态；RFC编辑器将与IAOC合作，根据需要更新Datatracker。
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:
尽管数据跟踪器中已有RFC编辑器状态信息，但应更新数据跟踪器，以包含一些附加数据，帮助个人了解其文档的状态。特别是，应更新Datatracker，以包括以下数据：
1) links to AUTH48 pages
1) 指向AUTH48页的链接
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.
AUTH48页提供了关于哪些作者批准了该文档的发布，是否需要广告批准的信息，有时还提供了在文档可以继续之前需要解决的问题的摘要。
2) links to the cluster pages
2) 指向群集页面的链接
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.
集群定义为具有规范性引用依赖关系的文档，以及要求同时发布的文档。（有关更多信息，请参阅http://www.rfc-editor.org/cluster_def.html.)集群页面提供集群文档的整个状态信息集的视图。
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.
注意：RFC编辑器一直在处理集群数据，以适当的详细程度向社区提供准确的状态信息。RFC编辑器数据库可能需要进行重大更新，然后才能将此数据与Datatracker集成。
3) RFC metadata upon publication
3) 发布时的RFC元数据
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.
当发布新的RFC时，RFC编辑器将通知Datatracker，Datatracker应该能够使用与发布的RFC相关的数据自动更新相关字段。特别是，RFC编号将记录在Datatracker中。但是，请注意，在编辑过程中，所有字段都可能发生更改，因此应进行更新；例如，文档标题和作者列表有时会更改，字符数和页数始终会更改。
4) notation when documents are withdrawn from the RFC Editor queue
4) 从RFC编辑器队列中撤回文档时的注释
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.
如果要从RFC编辑器/IANA队列中删除文档，则责任方（如AD或秘书处）应将Datatracker中文档的状态更改为“RFC Ed队列”以外的状态。Datatracker应提供一个文本框，允许责任方记录有关状态更改的详细信息。状态更改和相关详细信息将记录在历史日志中。Datatracker中的状态更改将触发发送给RFC编辑器和IANA的电子邮件，通知文档状态已设置为新分配的状态，详细信息在文本框中提供。RFC编辑器和IANA将相应地更新其队列，文档将从各自的队列中消失。
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.
虽然本文档的主要目标是更新Datatracker以显示IANA和RFC编辑器的处理状态信息，但Datatracker可以保存额外的数据供IANA和RFC编辑器使用，从而提高自动化程度，从而减少延迟和处理错误的可能性。本节定义了更新Datatracker的要求，以消除员工当前执行的一些管理任务。
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.
当批准发布文件时，将以机器可读的格式提供数据，并将包括（除通常的文件/协议行动电子邮件外）RFC编辑器在第4.2节中要求的数据。
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
- I-D字符串
- Document Title
- 文件标题
- Author List
- 作者名单
- Author Email Addresses
- 作者电子邮件地址
- Author Organizations (if available)
- 作者组织（如有）
- Expedited Goal Date (if applicable)
- 加速目标日期（如适用）
Note: This field needs to be editable for post-approval changes.
注意：对于审批后的更改，此字段需要可编辑。
- Publication Status (as defined in [RFC2026])
- 发布状态（定义见[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.
注：在从Datatracker接收研究组数据之前，RFC编辑器数据库可能需要更新。
- IESG Contact
- IESG联系人
- Document Shepherd <email>
- 文档管理器<电子邮件>
Note: This is the individual currently listed in the "Personnel" section of a Document/Protocol Action.
注：这是目前在文件/协议行动的“人员”部分列出的个人。
- IANA Actions Required
- IANA需要采取的行动
Most of these items are already stored in the Datatracker. However, the following fields need to be added:
这些项目中的大多数已经存储在Datatracker中。但是，需要添加以下字段：
- Expedited Goal Date
- 加速目标日期
- Consensus (yes/no)
- 共识（是/否）
- Document Shepherd <email>
- 文档管理器<电子邮件>
- IANA Actions Required
- IANA需要采取的行动
"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.
[RFC5741]中使用了“共识”；它确定了本备忘录文本适用于IETF和IRTF文件的适当状态。共识字段应由负责人设置，并应列在IESG telechat前提供的议程包中，以便区域主管能够快速审查所审查文件的状态，并在未收到共识时纠正该字段。
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.
此外，IESG telechat前提供的议程包应显示IETF最后一次呼叫的截止日期。这将有助于ADs和秘书处跟踪IETF最后一次呼叫时间线。
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.
将文件添加到RFC编辑器队列（即，在Datatracker中显示RFC编辑器状态）时，应向秘书处发送一份自动通知，以确认已收到公告。
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.
批准发布文件后，当I-D版本可用时，Datatracker应通知RFC编辑和赞助广告。
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.
此外，当I-D的状态已移动到“RFC Ed队列”或“RFC发布”以外的位置时，即当应从RFC编辑器和IANA处理队列中删除时，Datatracker应通知RFC编辑器和IANA。详见第3.1节第4）项。
Once the Datatracker has been updated for the alternate streams [RFC6322], the Datatracker should be updated so that the following are automated:
为备用流[RFC6322]更新Datatracker后，应更新Datatracker，以便自动执行以下操作：
- The Datatracker should not expire any I-Ds that are under review for publication.
- Datatracker不应使正在审查发布的任何I-D过期。
- 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).
- 数据跟踪器应在正在审查的ID更新时（即新版本可用）自动通知审批机构。
- 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.
- 应更新Datatracker，以便议程包根据请求发布的流列出I-D。这将有助于在IESG审查期间提供额外的清晰性，因为将有一个文件来源的明确指示。
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.
RFC 6322[RFC6322]列出了扩展Datatracker以考虑备用流状态和注释的要求。特别是，文档引入了“发送到RFC编辑器”状态，这意味着文档已完成并已发送到RFC编辑器进行发布。
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.
Datatracker将为备用流提供生成统一发布请求的方法。使用Datatracker，流管理器应该能够生成一个发布请求，其中包含任何批准的ID的相关信息。
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.
此外，Datatracker将以机器可读的格式提供数据（与任何IETF发布请求提供的数据相同——见第4.2节）。这些数据将可供IANA和RFC编辑器使用，因此可以自动将数据输入IANA和RFC编辑器系统。
This update will allow the IANA and RFC Editor to handle documents in a similar manner, regardless of the document's stream.
此更新将允许IANA和RFC编辑器以类似的方式处理文档，而不考虑文档的流。
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.
Datatracker应具有“显示差异”功能。它应该显示Datatracker中符合特定条件的所有记录（似乎存在差异）。除了在屏幕上显示数据外，还应定期（如每周）向指定的相关方发送电子邮件。此功能仅对一部分个人（即IANA、RFC编辑器和秘书处）可用，以确保他们的队列同步。随着Datatracker的扩展（现在和将来），这将特别有用，以确保各方都能收到正确的消息/数据。
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.
- 显示已通过“已发送已批准公告”状态但没有RFC编辑器状态的草稿。
- 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).
- 显示具有IANA状态“进行中”的草稿，但RFC编辑器状态不等于“IANA”或不包含“*A”（见附录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).
- 显示具有IANA状态“等待RFC编辑器”或“RFC Ed Ack”但RFC编辑器状态为“IANA”或包含“*A”的草稿（见附录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.
- 显示除RFC编辑器或IANA队列中列出的“RFC已发布队列”或“RFC已发布”之外的状态的草稿。
This document does not propose any new Internet mechanisms, and has no security implications for the Internet.
本文件未提出任何新的互联网机制，对互联网没有任何安全影响。
The currently defined IANA states are listed below.
目前定义的IANA州如下所示。
* No value (blank) - A new document has been received by IANA, but no actions have been taken
* 无值（空白）-IANA已收到新文档，但未采取任何措施
* In Progress - IANA is currently processing the actions for this document
* 正在进行中-IANA目前正在处理此文档的操作
* Waiting on Authors - IANA is waiting on the document's authors to respond
* 等待作者-IANA正在等待文档作者的回复
* Waiting on ADs - IANA is waiting on the IETF Area Directors to respond
* 等待广告-IANA正在等待IETF区域主管的回应
* Waiting on WGC - IANA is waiting on the IETF Working Group Chairs to respond
* 等待WGC——IANA正在等待IETF工作组主席的回应
* Waiting on RFC Editor - IANA has notified the RFC Editor that the actions have been completed
* 等待RFC编辑器-IANA已通知RFC编辑器操作已完成
* RFC-Ed-Ack - Request completed. The RFC Editor has acknowledged receipt of IANA's message that the actions have been completed
* RFC Ed Ack-请求已完成。RFC编辑器已确认收到IANA的信息，即操作已完成
* On Hold - IANA has suspended work on the document
* 暂停-IANA已暂停该文件的工作
* No IC - Request completed. There were no IANA actions for this document
* 没有完成IC请求。此文档没有IANA操作
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.
IANA州由IANA定义，可能会发生变化。如果本文件中列出的州名称与IANA队列页面中列出的州名称之间存在任何差异(http://www.iana.org/about/performance/ietf-draft-status/)，IANA队列是确定的。
The currently defined RFC Editor Queue states are listed below.
下面列出了当前定义的RFC编辑器队列状态。
* AUTH = Awaiting Author Action
* AUTH=等待作者操作
* AUTH48 = Awaiting final author approval
* AUTH48=等待最终作者批准
* EDIT = Approved by the stream manager (e.g., IESG, IAB, IRSG, ISE), awaiting processing and publishing
* 编辑=由流管理器（如IESG、IAB、IRSG、ISE）批准，等待处理和发布
* IANA = RFC-Editor/IANA Registration Coordination
* IANA=RFC编辑器/IANA注册协调
* IESG = Holding for IESG Action
* IESG=等待IESG行动
* ISR = Independent Submission Review by the ISE
* ISR=ISE的独立提交审查
* ISR-AUTH = Independent Submission awaiting author update, or in discussion between author and ISE
* ISR-AUTH=等待作者更新的独立提交，或在作者和ISE之间的讨论中
* REF = Holding for normative reference (followed by I-D string of referenced document)
* REF=标准参考的保留（后面是参考文件的I-D字符串）
* RFC-EDITOR = Awaiting final rfc-editor review before AUTH48
* RFC-EDITOR=在AUTH48之前等待RFC编辑器的最终审核
* TO = Time-out period during which the IESG reviews document for conflict/concurrence with other IETF working group work (followed by date)
* TO=IESG审查文件与其他IETF工作组工作冲突/一致性的超时时间（后跟日期）
* MISSREF = Awaiting missing normative reference
* MISSREF=等待缺少的标准参考
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.
RFC编辑器状态由RFC编辑器定义，可能会发生更改。如果本文档中列出的州名称与RFC编辑器队列页面中列出的州名称之间存在任何差异(http://www.rfc-editor.org/queue2.html)，RFC编辑器队列是确定的。
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:
目前，RFC编辑器状态更改电子邮件中还使用了一些状态注释。这些不会以任何方式改变Datatracker，但出于完整性考虑，在此处列出：
*A = indicates that IANA actions are required
*R = indicates potential REFerence holds
*A = indicates that IANA actions are required
*R = indicates potential REFerence holds
Normative References
规范性引用文件
[IDTRACKER] "The IETF Datatracker tool", Web Application: https://datatracker.ietf.org/, August 26, 2011.
[IDTRACKER]“IETF数据跟踪器工具”，Web应用程序：https://datatracker.ietf.org/，2011年8月26日。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844]Daigle，L.，Ed.，和互联网架构委员会，“RFC系列和RFC编辑器”，RFC 48442007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
[RFC5741]Daigle，L.，Ed.，Kolkman，O.，Ed.，和IAB，“RFC流，标题和样板”，RFC 57412009年12月。
[RFC6174] Juskevicius, E., "Definition of IETF Working Group Document States", RFC 6174, March 2011.
[RFC6174]Juskevicius，E.“IETF工作组文件状态的定义”，RFC 61742011年3月。
[RFC6322] Hoffman, P., "Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams", RFC 6322, July 2011.
[RFC6322]Hoffman，P.，“IAB、IRTF和独立提交流的数据跟踪器状态和注释”，RFC 6322，2011年7月。
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
阿曼达·巴伯·格伦·巴尼·阿德里安·法雷尔·爱丽丝·哈根斯·保罗·霍夫曼·罗斯·霍斯利·艾德·朱斯基维奇斯·亨里克·列夫科维茨·辛迪·摩根·雷·佩尔蒂亚·彼得·圣安德烈·罗伯特·斯帕克斯·艾米·维扎
Authors' Addresses
作者地址
Sandy Ginoza Association Management Solutions 48377 Fremont Blvd., Suite 117 Fremont, CA 94538 United States
Sandy Ginoza协会管理解决方案48377 Fremont Blvd.，美国加利福尼亚州Fremont市117号套房，邮编94538
Phone: +1 (510) 492-4000
EMail: sginoza@amsl.com
URI: http://www.amsl.com/
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
Michelle Cotton互联网公司，地址：美国加利福尼亚州马里纳德雷市金钟路4676号330室，邮编：90292
Phone: +310-823-9358
EMail: michelle.cotton@icann.org
URI: http://www.iana.org/
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
美国加利福尼亚州弗里蒙特市弗里蒙特大道48377号Alexa Morris Association Management Solutions，117室，邮编94538
Phone: +1 (510) 492-4000
EMail: amorris@amsl.com
URI: http://www.amsl.com/
Phone: +1 (510) 492-4000
EMail: amorris@amsl.com
URI: http://www.amsl.com/